Be aware of ADB

As I was responding to the questions in this article I realized, I couldn't summarize my answer into comments. So I figured I would write a separate blog.

The intention is to highlight the overlooked point of the original article about the attacks through ADB. Although what the article claims could be true, I felt it is a bit misleading. Researching android devices under a specific region(which is famous for rooted devices/custom android images), the article seems to generalize the issue. It does mention,

It is also clear some people are insecurely rooting their devices, too.

But doesn't seem to highlight it as the major issue. I completely agree where it's the vendor's fault to ship devices with 'ADB' enabled, the scenario where the device runs a rooted custom android escalates the issue to another level.

Just looking at the title & the fancy technical terms, a novice android user would get scared if not concerned a bit about his privacy. Nowadays, where hacking seems to occur almost every day, I don't blame anyone when they hear the words, "android" & "hack" together, get scared or worried about their privacy. I want the people to know about how 'ADB' tool works so that they can better understand when hearing about issues related to ADB and make an informed decision rather than jumping to conclusions.

Note:

1. Please note that I'm not saying Android is secure. It has multiple layers of protection; But like any other systems, it's not immune to attacks.
2. Security in Android is a vast topic, and I'll try to cover as much as I can be based on my experience. Please feel free to add upon more info and correct if there are any mistakes.

As per the original article, it claims that the several vendors(specific to a region) ship Android with ADB enabled. Which then enables a hacker to connect over TCP (Wifi/Ethernet), to hack the device and steal user information. It's certainly true that when 'ADB' is enabled on a device, it's quite easy to connect to the device over TCP if you know the IP address of the device. But how much the hacker can do once he gets access to the device depends on if the android was a rooted or non-rooted device.

Be aware when you root the device

When connecting through ADB on a rooted android device(i.e., device that runs custom android images rather than the factory defaulted image), the user has elevated 'root' permissions. So the hacker has the potential to run commands that compromise the security/privacy of the user. So one should be aware of flashing custom images on your phones. The image may have enabled "USB Debugging" by default and even worse, "enabled USB Debugging over TCP" through 5555 or any other ports. It basically opens the doors for the hacker to use the phone as they wish.

In the case of non-rooted Android devices, "ADB Access" is disabled by default and has to be enabled through a process. Although the process is not complicated, it's not something a common person can stumble upon. I will walk through the steps shortly. One more thing to note here is, even if you enable ADB connection in a non-rooted Android device when you connect from a PC, you will not have "root" access in the shell.

What a normal user familiar with

When you connect an Android device to a PC, it typically connects in MTP(Media Transfer Protocol) mode. You can transfer files/photos/music between the device and the PC. Most of the manufacturer provided software connects through this mode. eg., Samsung Smart Switch, Android File Transfer.

How ADB works

For our exercises, you need an android device(or an emulated Android device), a micro-USB cable & ADB, the developer tool in question. I'm using an Emulated Nexus 5.

'Android Debug Bridge-ADB' is a tool that helps in communicating between the device and PC, which can be obtained by installing Platform tools. For more details on 'ADB', you can read this article from developer.android.com.

Practice-1: Enabling ADB Access

If you want to enable 'ADB', you have to first enable "Developer Settings", Which is actually hidden in Settings.

1. Open Settings in your Android device
2. Find "Build Number" in "About Phone" and tap it "7" times. It will show a notification that "Developer Settings" is now enabled.
3. Press back to return to settings, and you will see "Developer Settings".
4. Open "Developer Settings", scroll down to "USB Debugging" and enable it.

Now you will have ADB access to the device.

Note: If you like to enable ADB Connection over Wifi, the same article from developer.android.com covers how to do that as well. For our exercise, it doesn't matter whether you connect over WiFi or micro-USB.

Android adds another level of security. When you connect your device to a PC after enabling ADB, it will ask permissions to "Trust the Computer".

Practice-2: Understanding the android shell & methods to communicate

In simple words, "shell" is just an interface that lets you talk to the underlying OS. Android has a Unix shell that can talk to the underlying kernel. Based on the toolset available, the list of commands can vary. ADB is just a tool that communicates your commands to the android shell.

Before we start a bit of practical explanation. You can execute the commands in two ways. For ex., 'ls' is a shell command that lists the files & directories in the current path.

1. From your PC, Get into the shell and fire the 'ls' command.

> adb shell
> $ ls

When you fire, 'adb shell', you will get into android's shell. Type, 'exit' to exit from the android shell to PC. 2. From your PC, Fire the 'ls' command through the shell. You will remain in your PC's shell.

> adb shell ls

Note: In this article, I'm currently using 'ADB' to connect to the android shell. 'ADB' has more commands that can let you install, uninstall, query apps and much more.

Practice-3: Understanding ADB Users

You will not get "root" access on standard non-rooted android devices. You can only run a limited set of UNIX commands.

• On non-rooted device,

▶ adb shell
generic_x86:/ $ pwd
/
generic_x86:/ $ ls
ls: ./ueventd.rc: Permission denied
ls: ./ueventd.ranchu.rc: Permission denied
ls: ./init.zygote32.rc: Permission denied
ls: ./init.usb.rc: Permission denied
ls: ./init.usb.configfs.rc: Permission denied
ls: ./init.rc: Permission denied
ls: ./init.ranchu.rc: Permission denied
ls: ./init.environ.rc: Permission denied
ls: ./init: Permission denied
ls: ./fstab.ranchu.early: Permission denied
ls: ./fstab.ranchu: Permission denied
acct bugreports cache charger config d data default.prop dev etc mnt oem proc root sbin sdcard storage sys system var vendor

Please note the '$' sign. This implies that you logged in as Normal User. You will have limited permissions to run commands.

• On a rooted device,

root@xxxx:/ # ls
acct
bin
cache
charger
config
d
data
default.prop
dev
device
etc
file_contexts
fstab.freescale
init
init.environ.rc
init.xxxx.rc
init.xxxx.usb.rc
init.rc
init.trace.rc
init.usb.rc
mnt
proc
property_contexts
res
root
sbin
sdcard
seapp_contexts
sepolicy
storage
sys
system
ueventd.xxxx.rc
ueventd.rc
vendor

Please note the '# ' sign. This implies that you logged in as root/admin User. You have elevated permissions.

This is one level of security. Unless you have a rooted android device, you will not gain 'root' permission when connecting over 'ADB' be it over Wifi or Micro-USB. Also based on the toolset(busybox, toolbox) available in your Android device, the list of commands available to a root user will also vary. Of course, once you have a root user, you can install more commands.

To give another example, There's a partition '/data' in Android, where the apps store their data.

• In a typical non-rooted android device,

generic_x86:/ $ ls /data
ls: /data: Permission denied

'/data' partition is disabeld by default

• In a rooted android device

root@xxxx:/ # ls /data
anr
app
app-asec
app-lib
app-private
backup
bugreports
cron
dalvik-cache
data
dontpanic
drm
local
lost+found
media
mediadrm
misc
network
property
resource-cache
security
ssh
system
tombstones
user

Practice-4: Understanding App level security

All applications on Android run in an Application Sandbox. By default, an Android application can only access a limited range of system resources. The access to system resources is protected by permissions provided to the app.

So any time when you install an app, review the permissions when you install an app. With the recent Android releases, android started rolling out asking permissions separately each time, when the app tries to access a system resource eg., Camera.

Each app runs on its own sandbox, it can't access 'data' portion of other apps. We saw earlier in a non-rooted device, access to '/data' portion is disabled.

There's one exception. If you install an app through 'ADB', you can access the 'data' portion of that particular app. Note that the app has to be designed for debugging, to be more specific it should be an apk for debugging.

generic_x86:/ $ run-as com.xxx.androidarchroom ls com.xxx.androidarchroom
ls: com.xxx.androidarchroom: No such file or directory
generic_x86:/ $ run-as com.xxx.androidarchroom ls /data/com.xxx.androidarchroom
ls: /data/com.xxx.androidarchroom: No such file or directory
generic_x86:/ $ run-as com.xxx.androidarchroom ls -ls /data/data/com.xxx.androidarchroom
total 12
4 drwxrws--x 2 u0_a85 u0_a85_cache 4096 2018-09-27 13:02 cache
4 drwxrws--x 2 u0_a85 u0_a85_cache 4096 2018-09-27 13:02 code_cache
4 drwxrwx--x 2 u0_a85 u0_a85       4096 2018-09-27 13:02 databases

Note that the app, 'androidarchroom' has user-id as 'u0_a85'. Also note that it can only access it's own data folder.

Another example,

generic_x86:/ $ run-as com.xxx.voicemails ls -la /data/data/com.xxx.voicemails
total 20
drwx------   4 u0_a79 u0_a79       4096 2018-10-04 04:54 .
drwxrwx--x 103 system system       4096 2018-10-04 04:54 ..
drwxrws--x   2 u0_a79 u0_a79_cache 4096 2018-10-04 04:54 cache
drwxrws--x   2 u0_a79 u0_a79_cache 4096 2018-10-04 04:54 code_cache

generic_x86:/ $ run-as com.esi.androidarchroom ls /data/data/com.esi_estech.voicemails
ls: /data/data/com.esi_estech.voicemails: Permission denied

Here, the 'voicemails' app has user-id as 'u0_a79'. And notice how, 'androidarchroom' app can't access the 'data' of 'voicemails' app. Both apps runs on it's own sandbox and the users are different which controls the permissions.

Both of the above two apps are my development apps and I was running a debug apk. The APKs that you get from play store is of 'release' type which can't be debugged. Let's see what happens when I run on an app that's pre-installed/installed from play store.

generic_x86:/ $ run-as com.google.android.youtube ls /data/data/com.google.android.youtube
run-as: package not debuggable: com.google.android.youtube

So I can't access the 'data' of youtube app.

The above examples are true in case of the non-rooted device. In case of a rooted device, you can pretty much access 'data' portion of any app.

Note: People who have used Unix machines are familiar with the security concept 'DAC' which is used in Android as well.

Potentials for a hack

Okay, now after explaining a portion of android's security measures, let's see what's the potential options to hack in a non-rooted Android device over adb.

Shell commands

If you understand UNIX commands, there's a basic set of commands available through which you can poke around and find information about the device. Even as a normal user, you have access to run basic commands in certain directories. For ex.,

generic_x86:/ $ ls
ls: ./ueventd.rc: Permission denied
ls: ./ueventd.ranchu.rc: Permission denied
ls: ./init.zygote32.rc: Permission denied
ls: ./init.usb.rc: Permission denied
ls: ./init.usb.configfs.rc: Permission denied
ls: ./init.rc: Permission denied
ls: ./init.ranchu.rc: Permission denied
ls: ./init.environ.rc: Permission denied
ls: ./init: Permission denied
ls: ./fstab.ranchu.early: Permission denied
ls: ./fstab.ranchu: Permission denied
acct bugreports cache charger config d data default.prop dev etc mnt oem proc root sbin sdcard storage sys system var vendor

You can poke around with different UNIX commands, although the set of commands will be limited.

Android Tools

Android adds a set of tools on top of the UNIX shell, which can be used to understand the list of the apps the user has and launch the apps.

For ex., 'pm' [Package Manager](https://developer.android.com/studio/command-line/adb# pm) is a tool that can query packages.

generic_x86:/ $ pm list packages -f
package:/system/priv-app/CtsShimPrivPrebuilt/CtsShimPrivPrebuilt.apk=com.android.cts.priv.ctsshim
package:/system/app/YouTube/YouTube.apk=com.google.android.youtube
package:/system/priv-app/GoogleExtServices/GoogleExtServices.apk=com.google.android.ext.services
package:/system/priv-app/TelephonyProvider/TelephonyProvider.apk=com.android.providers.telephony
...

By understanding the list of packages available, You can further perform a bunch of more actions. For example, clearing data of an app.

130|generic_x86:/ $ pm clear com.google.android.youtube
Success

Launch an app from command line,

generic_x86:/ $ pm dump com.android.calculator2 | grep -A 1 MAIN
    android.intent.action.MAIN:
      b91fd0a com.android.calculator2/.Calculator filter 84c5cb
        Action: "android.intent.action.MAIN"
        Category: "android.intent.category.LAUNCHER"
generic_x86:/ $ am start -n com.android.calculator2/.Calculator
Starting: Intent { cmp=com.android.calculator2/.Calculator }

Analyzing logs

"Logcat" is a tool that prints the logs of the apps installed including system apps. Although it's a tedious process, one can watch the logs for potential user related info. For eg.,

generic_x86:/ $ logcat | grep http
10-04 05:30:41.470  7966  7998 W GAv4: AnalyticsReceiver is not registered or is disabled. Register the receiver for reliable dispatching on non-Google Play devices. See http://goo.gl/8Rd3yj for instructions.
10-04 05:30:41.478  7966  7998 W GAv4: CampaignTrackingReceiver is not registered, not exported or is disabled. Installation campaign tracking is not possible. See http://goo.gl/8Rd3yj for instructions.
10-04 05:30:41.479  7966  7998 W GAv4: AnalyticsService not registered in the app manifest. Hits might not be delivered reliably. See http://goo.gl/8Rd3yj for instructions.

App vulnerabilities

Apps released through the play store will not have any 'debug' logs and the logs are limited to 'error'. But it doesn't prevent the developer from printing sensitive information in the error logs. Also, Google does scan the uploaded apps before releasing, there could be potential vulnerabilities in the apps. A malicious user can make use of the app vulnerability to steal user information.

Overall,

1. Be wary of the system images that you flash and careful if and when you root your android device.
2. Be wary of the apps that you install through non-standard way(downloading from other sites, shared through links).
3. Be aware of the permissions that the apps request, when you install the apps from play store.
4. Don't enable ADB access, unless you develop. Rather I would put be conscious when you enable ADB access.

In my opinion, ADB and other tools exist to debug, resolve and develop better apps. It's not the fault of the tools if they are used for malicious purpose. Most often it's us the users who open doors for potential attacks.

This post is also available on DEV.