Security researchers remotely hack iOS and Android, steal data (photos, videos, contacts, etc.)

At the EUSecWest 2012 conference in Amsterdam, there is a Mobile Pwn2Own contest in which security researchers — or hackers, if you want — try to demonstrate their prowess at hacking mobile devices. The two best hacks of the day? A hack by a Certified Secure team that exploits a vulnerability in Safari on iOS 5 and iOS 6, and a hack by a MWR InfoSecurity team that exploits two operating-system level vulnerabilities on Ice Cream Sandwich (Android 4.x).


The hack on iOS was performed on an iPhone 4S running iOS 5.1.1 and tested on all iPads, iPod Touchs, and the iPhone 4. While the hack was conducted on iOS 5, the Safari security vulnerability is still there in iOS 6 which means the upcoming iPhone 5 is also vulnerable (unless Apple patches this).

The hack involves a drive-by attack when a user loads a malicious website in Safari on iOS. The researchers were able to steal an iPhone 4S’ address book, browsing history, photos, and videos and send the data to a remote server just by loading the malicious website on the iPhone 4S — there didn’t even need to be anything downloaded by the user for the exploit to work. To make maters worse, the exploit does not crash Safari so users would not even know their data has been stolen.

According to Certified Source CEO Joost Pol, it took their team roughly three weeks to discover the vulnerability and exploit it:

It took about three weeks, starting from scratch, and we were only working on our private time. We really wanted to see how much time it would take a motivated attacker to do a clean attack against your iPhone. For me, that was the motivation. The easy part was finding the WebKit zero-day.

For you iDevice owners that are worried, calm down — Certified Source did not reveal details about hack aside from demonstrating it because they don’t want the hack to be implemented in-the-wild. They also notified Apple about the exploit so there will likely be a fix for it, soon. Unless someone else figures out this exploit in between today and when Apple issues a patch, you have nothing to worry about.

Galaxy S Insecure

Samsung Galaxy S III is the unlucky device to be exploited by MWR InfoSecurity. Utilizing two separate Android vulnerabilities, the researchers were able to upload a malicious file onto a Galaxy S III, execute the file 185 times (they had to execute it this many times for the exploit to work), then escalate their system access (bypassing Android’s app sandboxing security features) and install their custom Mercury app. The Mercury app was able to steal any and all data on the Galaxy S III and even make phone calls.

This hack by MWR InfoSecurity was initiated by the team sending a malicious file over NFC to the Galaxy S III handset, but the researchers say NFC is not required — the malicious file can be inserted into an Android handset via other measures, such as drive-by website attack or e-mail attachments.

The researchers mention the hack was enabled by flaws with how Google implemented Address Space Layout Randomisation (ASLR) and Data Execution Prevention (DEP) in Android 4.0.4:

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.

It isn’t entirely clear if both of the exploits used by the researchers can be combined to successfully hack a Galaxy S III only or other Android devices, too.

On the bright side, Google has already fixed the issues with ASLR and DEP… in Jelly Bean (Android 4.1.x). The obvious problem is most Android devices do not have Jelly Bean yet and likely won’t for a while; some devices may never get Jelly Bean, unless the owners want to install custom ROMs.

MWR InfoSecurity will post the technical details about this hack in a blog post as soon as Samsung issues a fix for the exploits.


Shoulda bought a Mac.

[via TheNextWeb (1), (2) | Image via Tsahi]

Related Posts