CVE-2020-23826 - RCE vulnerability in Yale WIPC-303W IP camera

 

I have recently reported a vulnerability in Yale IP camera WIPC-303W. 

Yale is is one of the world's oldest lock manufacturers, owned by Assa Abloy (from Wikipedia) , and apparently they also started manufacturing cameras and other IoT products for home security a few years ago.

VULNERABILITY DETAILS

This vulnerability allows attackers who have managed to authenticate successfully with the web interface of the camera's management system, to send a specially crafted packet which will result in the attacker's ability to run arbitrary commands on the camera itself remotely. 

This is possible due to a lack of input validation in one of APIs the web CGI exposes to the user, resulting in a command injection vulnerability.

 

Affected versions tested: WIPC-303W 2.21 - 2.31

Nmap most common ports | Top 1000 ports used by Nmap

 

 

 

Nmap is a well known tool used by IT managers, information security analyst and hackers, to scan a network or an IP for information like open ports, services, OS types and more.

On a default Nmap scan, Nmap scans the 1000 most common ports on the target IP.

This list of ports is fetched from the 'nmap-services' file which is downloaded when you install Nmap, the file contains the service name usually listening on the port, the port number and type (tcp/udp) and the frequency of the port as seen on the internet.

The frequency attribute is used in order to pick to the top 1000 most common ports on a regular, default scan, or top 100 most common ports which are used when the '-F' flag is used to run a quick scan (https://nmap.org/book/man-port-specification.html).

I've written a tool which will use the default installation path of 'nmap-services' file on Linux or Windows, and will print the most common ports used by Nmap scans. The number of top ports to print can be set by the user with the '-t' flag. For example '-t 1000' will fetch the 1000 most common ports. The default is 100.

Open in GitHub

How to get a free anonymous proxy connection using Raspberry PI

* The following guide doesn't take into consideration the legality of the process described. Do not use this in real scenarios if you don't know if and when it's legal in your country.

** I can only assume the following method is probably already used in the wild today by legitimate users as well as cyber adversaries in order to maintain anonymity and evade detection.I don't remember reading about this specific method though and it sounded like a fun project to do on my new Raspberry PI, so I decided to test it on my own.

 

My idea is pretty simple, there's WIFI everywhere around us right? some of these WIFI networks are even free or password protected with easy ways to retrieve the passphrase (yes I'm talking to you public WIFI networks on hotels, airports (just kidding is Covid-19 time right now :), restaurants, coffee shops and the list goes on). Most of the times, the password is even printed in a visible way like on menus, cards or signs. Even if it's not, usually all you need to do in order to get it is to ask nicely and smile (remember always smile :)

So, can we use these networks in order to have a free anonymous connection from anywhere in the world? probably. Here's how: 

Step 1: get yourself a Raspberry Pi (I went for the Pi Zero W because it's smaller and stealthier). You can probably do it with any other portable SoC (System on a Chip) with WIFI support.

Step 2: after you installed Raspberry Pi OS  (Raspbian) on your Pi, go to Ngrok and register a new account (it's free!). 

If you don't know Ngrok - it's a really cool tool that essentially lets you tunnel a process connection through the internet. This way you can connect to a listening process on a remote device even if you don't have any incoming open ports on it (for example, you can use it if you want to test a web server hosted on your PC from the internet, without forwarding any ports on your home router or firewall). 

We're gonna use Ngrok to run a SSH server which will be used as our proxy server (you can also use it as a SOCKS proxy server, and then configure it on your web browser's network settings to get anonymous web browsing, but it won't be covered on this guide. Search the "-D" option on ssh client if you're interested to learn more).

After you successfully downloaded and configured Ngrok with your token, run the following:

"nohup ./ngrok tcp 22 & "

   nohup -  makes sure your ngrok session won't be killed when you logoff

 ngrok tcp 22 - opens a tunnel to tcp port 22 (this is the default ssh port, if it's different on your Pi, change the port number to the appropriate one. Make sure OpenSSH is up and running before you continue)

& - run the ngrok process in the background

Step 3: after you made sure your ngrok process is running, you can use your PC, launch a terminal and run:

" ssh  myuser@2.tcp.ngrok.io -p port_number"

ssh - your ssh client (it's installed by default on most operating systems, Windows 10 has it too by default)

myuser - this is the Raspberry Pi username - if you installed the OS without making critical changes, the default username is "pi"

 2.tcp.ngrok.io - this is the URL ngrok assigned to you, you get it from the ngrok dashboard under "Tunnels"

-p port_number - this will be the port number ngrok assigned to your session, will appear in the same place as the above

If all went successful you will be prompted to enter your Pi's password (you should change your default Pi password to a complex one! better yet use a key instead).

Congratz! you now have an anonymous connection to a remote proxy server. You can check if your IP really changed by comparing your PC IP to the output of the following command from your Pi:

" curl 'https://api.ipify.org' "

 Cool ! :) 

Check out this post from a Reddit user, where he finds a lot of these Pis hidden in his college, this surely demonstrate how easy is to hide them.

*** Unless you can find a power output no one is using which is also close enough to the WIFI reception range (you REALLY shouldn't do that :P !) , you'll probably need your own mobile power supply. This can be easily achieved with a battery connected to your Pi's GPIO or a power bank connected to the Pi's micro USB 5V input.

Android 0day vulnerability to allow permission bypass and acess to devices network information

Geektime published a news item about the recent vulnerability I've found (Hebrew):

https://www.geektime.co.il/android-security-vulnerability-found-by-israeli-researcher

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.

GitHub: https://github.com/agentzex/ESP_network_ip_scanner

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 3^rd 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.