Root Bridge — how thousands of internet connected Android devices now have no security, and are being exploited by criminals.

Android has a feature called Android Debug Bridge (ADB for short) which allows developers to communicate with a device remotely, to execute commands and fully control the device.

“The adb command facilitates a variety of device actions, such as installing and debugging apps, and it provides access to a Unix shell that you can use to run a variety of commands on a device.” — Android’s developer portal

It is completely unauthenticated, meaning anybody can connect to a device running ADB to execute commands. However, to enable it — in theory — you have to physically connect to a device using USB and first enable the Debug Bridge.

Unfortunately, vendors have been shipping products with Android Debug Bridge enabled. It listens on port 5555, and enables anybody to connect over the internet to a device. It is also clear some people are insecurely rooting their devices, too.

During research for this article, we’ve found everything from tankers in the US to DVRs in Hong Kong to mobile telephones in South Korea. As an example, a specific Android TV device was also found to ship in this condition.

This is highly problematic as it allows anybody — without any password — to remotely access these devices as ‘root’* — the administrator mode — and then silently install software and execute malicious functions.

These are not problems with Android Debug Bridge itself; ADB is not designed to be deployed in this manner.

*in theory root shouldn’t be available in non-Development builds, but there’s an apparent bypass on some devices – adb shell “su -c command”.

This is already a network worm exploiting Android Debug Bridge

Using threat intelligence data from Rapid7’s Project Heisenberg and GreyNoise Intelligence’s datastream, we can see on February 1st 2018 there was a massive increase in scanning for TCP port 5555 — aka Android Debug Bridge.

Additionally, using data from Qihoo 360’s Netlab — which features extracts from Netflow data in ISPs and transit providers — we can see massive amounts of port 5555 traffic arriving live:

In terms of raw numbers I can see nearly ten thousand unique IP addresses scanning in any 24 hour window, and over a hundred thousand IP addresses scanning each 30 days. It is worth keeping in mind that because of Network Address Translation and dynamic IP reservations it is difficult to know the exact number of devices. But it is safe to say: “a lot”.

These devices are currently being used for cryptocurrency mining, where computing resources is misused without the owners permission to generate profits for criminals.

The first warning was issued by 360 on February 4th in some excellent research. It’s clear since then this problem has continued to grow, mostly in Asia.

Through a very quickly put together honeypot, by deploying into an IP range in Taiwan I’ve been able to get an infection.

The worm is spread using a modified version of Mirai’s code bolted onto a cryptominer. There is no central C2 server; in this case it is spreading peer-to-peer via port 5555. There are however bugs in the code, and it only works on certain types of devices.

It writes itself to tmp/droidbot, and spreads around. It uses the official Android ADB tools to remotely spread.

The hash for the spreader element is
940b47e9b71ba4968cfefd7ae6c374a319f2439e9b71ee0965e20a0ce00dcd67 — if anybody wants a copy of the code, please contact me via email.

Establishing the scope of the overall issue

While it is tempting to look at this as simply a cryptocurrency malware issue, it is not.

These devices are misconfigured, and available all the world. They even exist in corporations. If somebody wanted to, they could run something other than cryptocurrency mining — which could develop into a serious issue.

The next stop is Shodan, the Internet of Things search engine, to look for port 5555. One problem is anything can listen to port 5555, so there are clearly other software solutions listening to the port. However we know from Netflow data that a significant number of the devices are in China, so we’ll concentrate there:

Using Rapid7 Metasploit’s module adb_server_exec we can remotely probe the devices using the check command, which — if ADB is listening on port 5555, reveals the device product name, model number etc.

It’s very clear through digging through data and feeds that a huge number of misconfigured devices exist, hence all the scanning for port 5555.

Summing up, vendors need to not ship products with Android Debug Bridge enabled over a network — especially when they are designed for internet connectivity. It creates a Root Bridge — a situation every anybody can misuse devices.

It places the customers in harm’s way. Vendors who have done this should issue product updates to remediate the issue, and if automatic updates are not an option they should contact customers to ask them to update their software.

Enterprises should scan their internal and external networks for port 5555. If Rapid7 customers, they can use Metasploit to check for ADB details on impacted devices.

Thanks to Piotr Bazydło, hrbrmstr, 360 Threat Intelligence, Greynoise, J and Ug_0 Security for helping investigate.