The first serious proof of concept exploit for Android platform was made publicly available last week.
The targeted vulnerability, discovered in the Webkit mobile browser platform is already fixed by Google in the latest Android release (2.2 Froyo). According to Google, Froyo is used by 36% of all Android devices, which means that the majority of the devices can still be successfully attacked using the exploit.
A few months ago, while attending the BlackHat and Defcon conferences in Vegas, Chet Wisniewski and I spotted a definite trend for researching attacks on Android platform. Presentations by John Hering and Kevin Mahaffey of Lookout security and especially by Christian Papathanasiou and Nicholas J. Percoco of Trustwave SpiderLabs were very well received by full auditoriums.
Immediately after the conferences, we were a bit skeptical about their findings and recorded a podcast in which we expressed our opinions on the subject.
3 August 2010, duration 11:59 minutes, size 11.0MBytes.
Though it was quite clear at the time that it is relatively easy to write malicious software for Android, I was fairly confident in Android’s security model, both on and off the device.
On the device, the tried-and-tested Linux security model is used to assign unique user names and privileges to every installed application, which allows the application code and the data to be separated and stored safely away from the prying routines of malicious applications.
Off the device, potentially malicious applications installed through Android Market can be easily removed from the Market and from the devices directly by Google, which makes the malware remediation easier as long as rogue applications do not interfere with the uninstallation process.
Despite my skepticism, as soon as I found out that a web-based remote security exploit for Android was to be made available by M.J. Keith of Alert Logic I was very curious to take a closer look at it.
The proof-of-concept code is very similar to the typical browser exploit code we often see in malicious webpages attacking desktop-based browsers. The exploit contains a heap spray to fill the memory with the ARM-based shellcode which is reached when the exploit is triggered, due to Webkit’s incorrect handling of floating point data types.
I fired up the Android emulator Android SDK and installed the exploit on my test server. This setup mimics the real situation, when the user visits a malicious webpage. The exploit was successful most of the times on versions 2.1 and 2.0.1, but I have not been able to make it work on Android 1.6.
Though the connection to port 2222 was being made, I could not do much with the Linux shell backdoor at first and had to look at the shellcode functionality with IDA.
I do not consider myself to be a proficient ARM assembly reader but the shellcode is easy to read and with the help of the Android system call table I quickly realized it was a simple reverse connecting shell, which creates a socket and redirects the standard input, standard output and standard error of the Linux shell to the socket.
Once I realized the shellcode is that simple it was obvious I needed to set a few environment variables before I started exploring the system using the backdoor opened by the exploit and the usual shell commands. The Linux security model kicked in once I tried to access various areas of the system. If we look at the process list, it is clear that the backdoor shell has the same privileges as the browser application.
In Android, every application gets its own user identity and it is not allowed to access the data and sensitive system areas of other applications. The installed applications and the application data is installed in the directory ‘/data’ which was not accessible to my remote shell.
To cause more damage and take complete control over the device, a local privilege escalation exploit is required.
Unfortunately, recent research by Coverity indicates that the Linux kernel 2.6.32 used by Android 2.2 contains a high number of potentially exploitable vulnerabilities which could be combined with the Webkit exploit.
Although we can expect that Google fixed the discovered vulnerability in the latest Android release, the question about more than 50% Android devices using vulnerable versions of the operating system remains.
In addition to that, the kernel issues discovered by Coverity will make things even worse, if they are proven to be serious.
If the pressure from the security community continues Google will have to provide some good answers if they have decided not to create an automatic security update mechanism similar to the update mechanisms we are used to in desktop operating systems.
Of course, modern smartphones are just as powerful as the desktop computers of only a few years ago so the requirement for a flexible security update mechanism should not be a surprise for the operating system developers and handset manufacturers.