Explore how thousands of Android devices are exposed to the internet through the Android Debug Bridge. Find out what devices are exposed, how they are exposed, examples of what an attacker could do with this exposure as well as what the bad guys are already doing with this exposure. This presentation was presented at BSides Melbourne 2019.
On a Saturday night late last year I was doing a bug bounty for a large overseas organization.
And I decided to take a look at the infrastructure side of things…and very quickly I found something unusual…this organization had multiple devices with a service exposed to the internet through port 5555. and Although this was something I hadn’t seen before after 5 minutes of research and 2 commands I had remote access to these devices through a remotely exposed service - the Android debug bridge.
So today I’m going to walk through how over 30,000 devices are exposed to the internet via the android debug bridge. And yeah it’s as bad as it sounds!
I’ll go over which devices around the world are exposed, how they are exposed, what you can do if you access unrooted devices remotely through ADB as well as how threat actors are currently taking advantage of this exposure.
Now I don’t have time for a whoami but hi I’m Steph Jensen or bismuth on twitter
Explain what ADB is Native utility in the android SDK Developer feature – allows developers to understand how their application interacts with the underlying operating system And allows the developer to edit their application as required
Explain ADB Diagram You have the ADB daemon running on the android device Then you have a adb server running on…well..in our case the attacker device. And this is connected to the android device through the network over tcp 5555, usb or even Bluetooth…because why not right
So in seeing all of these exposed devices and how easy it was to get access to these I was like what is this android dumpster fire I’ve just walked into…so naturally I decided to look into it a little deeper…it was like a car wreck I couldn’t look away even if I wanted to… What devices are impacted Android tv boxes Mobile phones Smart TVs And even fuel tankers
So we all know about dirty cow. Well android released a patch for dirty cow in December 2016 and this made me think what versions of android were these exposed devices running and funnily enough the most prominent version was Jelly Bean…from 2012…next inline was nougat and marshmellow (from 2015 and 2016). I also checked the security patches on these exposed devices and found that they were commonly 2 years old or more.
https://www.youtube.com/watch?v=pBe_A146w-A using dirtycow on Android Running getprop ro.build.version.security_patch when connected with a adb shell you could determine all exposed devices around the world that have security patches before the dirty cow patch from December 2016 and then use dirty cow to write to files that should not be accessible – an example is the /etc/system/hosts file
What countries are exposed? What mobile devices are exposed? What does Australia exposure look like?
Why is this happening? 1, 2, 3 Angelaroot engineers left a developer application on oneplus devices that allowed root access if you had a specific password in application itself
Now for the fun part – so you might be thinking what about the newer android devices that are not rooted they’d be somewhat okay right? WRONG!
Dumpsys is a android tool that dumps system service information
Get full path of applications and can pull edit and push these back onto the device
So what are the bad guys doing with this?
Basically these devices are like a living ecosystem of malware
Crypominers – using adb for turf wars, trinity, fbot, ufo miner all competing for resources on these devices.
The organisation I did the bug bounty for even had a device with malware on it that was connecting to another companies server that had been compromised and taken over by a Russian threat actor which had repurposed this server as command and control infrastructure, they were using SNPP (Simple network paging protocol) which was really interesting! But that’s a story for another time.
Researching this I found a quite a bit of malware so I created a malware zoo Access to Malware zoo Newer Trinity variants Tracking malware authors that were changing their malware every few weeks
So I think there are a couple of takeaways from this: Number 1 – It is important to understand the potential security impacts of seemingly benign features throughout an environment, vulnerability management processes need to be inclusive of this fact. Number 2 – unrooted devices still make for pretty good targets And number 3 – Don’t expose the android debug bridge to the internet! So I hope you got something out of todays presentation and thanks so much for listening!
Making it Rain Android Shells - How 30,000+ Android devices are exposed to the internet and waiting to be compromised
Making it Rain Android Shells
How 30,000+ Android devices are exposed to the internet
and waiting to be compromised
Top 3 exposed Android versions
in order of prevalence:
1. Jelly Bean
Top Mobile device models exposed:
1. Pixel 2 XL (12% global exposure)
2. Samsung Galaxy Note3 (11.2%
3. Samsung S5 (11.3% global exposure)
Top Impacted Countries
1. South Korea
Why is this happening?
2. Vendors are shipping products
with ADB enabled
over the network1. Developers are enabling ADB
To assist in debugging operations
(easier over network than USB)
3. Users are
enabling ADB on
to access 3rd
What can you do with a remote ADB
connection on non rooted devices?
• ADB Commands
• Shell commands
• So many things you can do!!!
ADB command examples
Shell on 1 device if multiple devices are connected adb -s <ip address> shell
Connect multiple devices Run bash script – included at end
Upload any file onto device Adb push <file to upload> <file upload location>
Download file from device Adb pull <file to download> <location on attacking
machine to download files to>
Take a screenshot of what is happening on the device Adb screencap -p /<directory to save> <filename>.png
Take a video of what is happening on the device Adb screenrecord
View System messages and application logs Adb logcat (or can run in shell)
ADB Command example (pull & screencap)
File accessible in
Check when user
Unlocks screen then
Dumpsys service examples
See all services dumpsys * dumpsys | grep "DUMP OF SERVICE"
Accounts used for applications (email addresses) * Dumpsys account
Last known location of device * Dumpsys location
Data sync info * Dumpsys contents
Telephone and provider information * dumpsys telephony.registry
Network connection information * Dumpsys connectivity
Memory information * Dumpsys meminfo
Wifi interface information * Dumpsys wifi
• * Stands for “adb shell” or “adb shell –n” if you are connected to multiple devices with the adb+ script
Kernel version * cat /proc/version
Find external storage location on device * Echo $EXTERNAL_STORAGE
Input keyevents * input <type of input> <input value>
System state information * Dumpstate
Kernel debugging info * Dmesg
System/application logging information * Logcat
List all packages on the device pm list packages –f
pm path <package name>
Access databases using permissions available from
* adb run-as debuggable.app.package.name cat
databases/file > file
* Stands for “adb shell” or “adb shell –n” if you are connected to multiple devices with the adb+ script.
Information accessible via devices running
• Email addresses of user
• Username in use in other applications
• Notifications from all applications
• Phone numbers of contacts
• Emails received
• Applications the user uses
• Location of user
• Model, build, version of device
• Malware on device
• Internal network information
• Screenshots of the screen
• Access to files in external storage
• Database files associated with certain applications
What are the bad guys doing with this
• Cryptominer Turf Wars - (Trinity vs Fbot vs ufo miner)
• Backdooring malware
Identifying malware through ADB
Finding Cryptominers through dumpsys cpuinfo
Decompiled ufo.miner – run.html file
Free stuff for you!
Android Malware samples that use ADB as a vector for infection:
• “Features” can be more than benign features
• Even if a device isn’t rooted it can expose sensitive information that
can be used to takeover accounts, pivot to an internal network, assist
in social engineering campaigns or ransom the user.
• DON’T EXPOSE THE ANDROID DEBUG BRIDGE TO THE INTERNET