Mobile Pwn2Own at EuSecWest 2012
Today MWR Labs demonstrated an Android vulnerability at the EuSecWest Conference in Amsterdam. The demonstration of the 0day exploit took place at the Mobile Pwn2Own competition. The exploit was developed in a team effort between our South African and UK offices. The vulnerability was found and the exploit was developed by Tyrone and Jacques in South Africa and Jon and Nils in the UK.
MWR showed an exploit against a previously undiscovered vulnerability on a Samsung Galaxy S3 phone running Android 4.0.4. Through NFC it was possible to upload a malicious file to the device, which allowed us to gain code execution on the device and subsequently get full control over the device using a second vulnerability for privilege escalation.
The same vulnerability could also be exploited through other attack vectors, such as malicious websites or e-mail attachments.
The first vulnerability was a memory corruption that allowed us to gain limited control over the phone. We triggered this vulnerability 185 times in our exploit code in order to overcome some of the limitations placed on us by the vulnerability.
We used the second vulnerability to escalate our privileges on the device and undermine the application sandbox model. We used this to install a customised version of Mercury, our Android assessment framework. We could then use Mercury’s capabilities to exfiltrate user data from the device to a remote listener, including dumping SMS and contact databases, or initiating a call to a premium rate number.
Challenges & Shortcomings
Android 4.0.4 has many of the exploit mitigation features that are common to desktop Linux distributions, including Address Space Layout Randomisation (ASLR) and Data Execution Prevention (DEP). Shortcomings in these protections allowed us to leverage the control we had of the device to trigger the second vulnerability. Crucially, the ASLR implementation is incomplete in Android 4.0.4, and does not cover Bionic (Android’s linker) and
/system/bin/app_process, which is responsible for starting applications on the device. Other protections which would make exploitation harder were also found to be absent.
A more in depth technical blog post will be released once the vulnerability has been patched by the vendor, detailing the process of finding and exploiting this bug.