code

Monday, April 27, 2020

ESP32/ESP8266 Network devices scanner





I recently developed a project for ESP32/ESP8266 Microcontrollers based on the ESP-IDF framework of Espressif. These are small and cheap System on Chip (SoC) that are mainly used in IoT devices. You can find the core specifications here: https://en.wikipedia.org/wiki/ESP32

I decided to develop this project since I didn’t see anything similar available on GitHub for this platform, and I think it’s a cool idea to have a small and cheap network device scanner, while it’s also a great way to dive in the bits and bytes of ESP-IDF, it’s OS level FreeRTOS and its network stack lwIP.

The way it works is by sending ARP requests packets to all of the network possible addresses (currently it assumes the network's subnet mask is 255.255.255.0 as most home networks are) and then trying to read from the lwIP ARP table in batches of 10 (this is because the default MAX_SIZE of lwIP ARP table is 10 entries, so in order to not mess around with the default configs I preferred to use this solution).
When the scan is finished, all of the found IPs are printed to stdout of the device. The found devices list is stored in a cJSON object which can be sent later to server-side.
This tool now also tries to translate found MAC addresses to vendor name using "api.macaddress.io" API. I used this one because it has a free plan but you can also set it to any other similar API by changing "MAC_LOOKUP_SERVER_ADDRESS" header or disable this functionality completely.
If you do choose to use this API, you can just create a free account, get your API token and replace it in the "MAC_LOOKUP_SERVER_ADDRESS" header.
If this tool doesn't discover all of your devices, you can also try to use ICMP echo request (aka ping) and then try to read the ARP table again for any changes.




Wednesday, April 15, 2020

New vulnerability in Android allows any app to receive devices private network information (such as IP and MAC addresses) without any special permissions




Recently, while developing network utilities for Android, I’ve stumbled upon an interesting vulnerability. 

I wanted to retrieve network information from my Android device and others devices on my local network, such as IP, MAC address and device’s vendor name, and so I started to experiment with the different API Android supply in order to receive such information.

Since it’s been a few years since the last time I developed an application in Android, I noticed a lot of API hardening was done in order to protect users' location from being tracked and traced by 3rd party applications, without the users’ knowledge. One of these protections is implemented in the WifiManager API, which “provides the primary API for managing all aspects of Wi-Fi connectivity” (from Android API documentation).

Starting from Android 6.0 (API level 23), Android removed all access to the device’s local hardware identifier (such as the WIFI and Bluetooth MAC address, which can be used for location tracking) and when an app is trying to retrieve it, it will get a constant “02:00:00:00:00:00” MAC address. In addition, an app can try to retrieve the BSSID and SSID of scanned WIFI networks only if permission to “ACCESS_FINE_LOCATION”, as well as other WIFI and network permissions are granted to the app explicitly by the user.

The vulnerabilities I found, allowed me to bypass all of those restrictions and retrieve both the device’s WIFI network information (including its local IP and MAC address) and neighbor devices’ information on the same network, without any permissions declared on my app’s manifest file.

In addition, with only internet permission granted (which is a normal permission that doesn’t require any explicit run-time permission request from the user) I could further expand my app to be a fully-fledged network scanner (similar to the well-known “Nmap”) in order to discover, communicate and even try to attack other network devices on my local network, such as over computers, routers and IoT devices. These functionalities are not possible to obtain by an app without a set of permissions, some of them declared as “dangerous” by Android OS.


The vulnerabilities which allowed me to do most of these action were found on some of the Linux command-line programs, which are located in most Linux distributions in the “/bin” path. Android OS includes some of these Linux programs under its “/system/bin” path, but access to them is restricted without special or root access. Trying to interact with them from within an Android app, usually ends up with “operation not permitted” errors coming from the network layer and printed to the device’s stderr and stdout, without the needed permissions.
Through some command-line binaries (and many of their different options) though, this information can be accessed from within an Android app without any errors thrown. While combining several methods and then parsing their output from the Android's application layer, I could successfully build my network scanner without any special or dangerous permissions being explicitly asked for from the user.



I forwarded all of my findings to the Android security team, they acknowledged and after further investigation by them, it was found that this issue was already reported by an internal Google engineer. They mentioned that “the fix for this issue is targeted for release with the next major version of Android”.

Although I couldn’t personally test this assumption, I believe this vulnerability targets a large amount of different devices from different vendors, running different Android versions, including the latest Android version (10).


My personal tests included Android emulators running Android 5, 6, 7 and 10 stock versions as well as a test made on a Samsung Galaxy S8 device running Android 9 and (as for now – the latest) April security patch level.



Mastering Problem-Solving and Cultivating a Research Mindset in the ChatGPT Era (and why you still need to RTFM)

  In this post I'll present a technical problem (some will say it's probably a bug more than it is a feature) I had with a VR app, h...