We at Clutch Mobile strive to constantly be up-to-date on the latest threats and techniques that malware authors employ out in the wild. To do this, we conduct our own in-house research and development to find security flaws.
Recently, our curiosity was drawn to reverse shell exploits and how they can be used on Android. Our goal was to write an app that used minimal Android permissions and employed some well known and not so well known exploits. Furthermore, we wanted to ensure that AppSanity (our app malware detection platform) would identify this type of app as malicious.
First, we decided to explore assets that can be bundled with an Android app. Using the Android NDK, we statically built versions of the popular utilities netcat and busybox and bundled them with our test app.
Next, we added methods to extract and execute these bundled assets. Below are some of the methods that we included in the app: one to use the netcat binary to send a real time reverse shell back to our servers, and one to send back a log file that was created about the device (IMEI, IMSI, Phone #, CPU information, file listings on the device). These methods are executed when certain menu options are pressed on the touch screen. The main reason why this is possible is that Android does not restrict the use of Runtime exec() to execute shell commands.
Once one has shell access to the phone, many things on the device become available. The powerful am command allows applications to be launched, URLs to be visited, and other intents to be sent. To gain this type of access in our test application the user only needs to allow one Android permission – INTERNET – which is used to send the shell and data from the phone. There are even techniques to not require this permission by using the native browser’s own permissions.
Once on the device, the app can lift almost anything off of the external storage (eg, personal pictures and videos) without even notifying the user it is accessing the SD card. Using the busybox asset, the app can FTP these files to a remote server.
It should be noted that at this point, the app does not even have root access. While there are some limitations of not having superuser privileges, with a shell and a little bit of Linux experience, a lot of personal and enterprise data can be obtained with just a normal shell. If superuser access is desired, it is possible to upload a local exploit to root the device, leaving the attacker able to do anything he or she wants.
While each of these techniques individually (reverse shell, perusing the Linux filesystem) are not groundbreaking, when combined together and used on Android they become very dangerous.
The next step was to test if our malware detection platform known as AppSanity could detect this type of exploit and without any type of modification the answer was yes. Based on pure static analysis, detecting this type of exploit is more difficult, but with AppSanity’s behavioural detection techniques it is able to run any application, inspect API calls and monitor network usage. In this case, the use of the Runtime exec() along with the data sent out over the network flagged the application as suspicious.
How can exploits of this type be mitigated?
- Restrict / regulate assets that can be bundled with an application
- Restrict access to executing commands via a shell – maybe another permission in the Android manifest?
- Outbound traffic monitoring
- Know the source of your applications and if you’re not always sure invest in some 3rd party security software
While the netcat reverse-shell is interesting and fun to play around with, the real goal here was to show an actual example of how an attacker could leverage just a couple permissions to create a malicious application.
This particular app was tested on Android 2.3, 4.0, and 4.1.
Big thanks to Mike for doing this write-up, research, and hacking!