Phun with Phones: 3 ways to phreak Android, iOS
Connecting state and local government leaders
The convergence of computing and mobile telephony has made smartphones the new frontier of cybersecurity, with a host of new vulnerability research presented at this year’s Black Hat Briefings.
Phreaking — the old practice of analyzing and exploiting the weaknesses in the public switched telephone network — is an antecedent of today’s computer hacking. Now that phones are becoming computers and vice versa, things have come full circle and mobile phones are drawing the attention for cybersecurity researchers.
There were a host of presentations at this year’s Black Hat Briefings, covering weaknesses in LTE carrier networks, the danger of femtocells and the vulnerabilities in BlackBerry, iOS and Android platforms. Smart phone exploits still lag those targeting laptops, desktops and servers in their ability to monetize attacks, but the growing functionality and use of smart phones could shift that balance in the not-too-distant future.
Here is a sampling of some of the mobile phone hacks offered at Black Hat.
Android: One root to own them all
Jeff Forristal, CTO of Bluebox Security, demonstrated an exploit that circumvents the cryptographic verification of Android applications, allowing the installation of a modified application without invalidating the digital signature.
This was a much anticipated presentation, but by the time Forristal took the podium it already was old news.
“This one leaked,” he said. “The last two weeks have been really interesting,” and included the appearance in the wild of a fully-automated version of an exploit targeting this bug.
Android app files are cryptographically hashed, and the smart phone verifies the hash before installing. If there is a discrepancy between the original hash and that of the files being installed, the app will not be installed. Forristal found a way around this by creating an extra copy of one file in an application, containing a malicious payload. This copy has an invalid hash, but if it is followed within the application by the authentic file that has the proper hashthe phone will ignore the bad copy and validate the good one instead, eventually validating the entire application.
But when the app is installed, the phone installs the first — malicious — copy of the file, and then ignores the second — authentic — copy, believing it to be only a duplicate. This puts malicious code on the phone where it can run.
There is a class of applications created and signed by the phone manufacturer that, if spoofed this way, can give a hacker control of the phone.
This exploit works on just about every type and recent version of Android phone, Forristal said. “It doesn’t matter what architecture you are working on,” although manufacturers began fixing this flaw in June.
The bug originally was disclosed to Google in February, and Google released a patch to partners in March. By mid-June smart phone vendors were beginning to issue updates, and it was anticipated that fixes would be in place before the public disclosure at Black Hat in August. But the July 3 announcement of the presentation gained a lot of attention in the media, and details of the bug became public July 6. Within a day the first versions of exploits were released, and by July 21 fully automated versions were available in the wild.
Abusing Web APIs through scripted Android apps
Barracuda principal researcher Daniel Peck demonstrated another Android flaw, in which well-meaning efforts to make Application Programming Interfaces for mobile applications easier to use also makes them vulnerable to manipulation.
Websites and services often publish APIs to enable third parties to develop mobile applications for them. Because of the limitations of a mobile platform, these APIs eliminate requirements for Captcha verification, e-mail verification and other security requirements to reduce their “friction,” Peck said. By analyzing traffic from a legitimate Android application, signing keys can be identified and extracted, and the JRuby scripting language can be used to load, modify and run code from the application being exploited.
Because of the lax security requirements in the API, bad actors can create social bots that can be automated to create an unlimited number of accounts on social networking sites, creating a spam platform.
Mactans: Injecting malware into iOS devices via malicious chargers
It is not just Android phones that are at risk. A trio of researchers from the Georgia Institute of Technology showed how to bypass Apple iOS safeguards to load a malicious application on a pristine iPhone in little more than a minute.
“It’s not a jailbreak,” said Billy Lau, a research scientist at Georgia Tech. The technique bypasses the application signing requirement without breaking it.
Lau, along with Ph.D. students Yeongjin Jang and Chengyu Song, leveraged the ability of USB connections to bypass defense mechanisms, using a custom-built malicious charging device called Mactans.
The proof-of-concept device, manufactured with a 3D printer, is a functioning charger but also contains a BeagleBoard single-board computer from Texas Instruments and costs about $35 to build. It takes advantage of the USB unified data, control and power interface that can be used both for battery charging and device control on the iPhone. So while the Mactans device is charging the battery, the onboard computer can access a private API that does not have the same restrictions as the API used for legitimate Apple applications.
The researchers loaded a false version of a Facebook application onto a Version 6.1.4 iPhone in about 80 seconds. The malicious payload itself takes about five seconds to load, and a smaller application could be loaded in under a minute. When running, the malicious app hides the legitimate app. For the demonstration, the phony app made an automated call from the compromised phone.
Apple has addressed — if not completely solved — the vulnerability in its latest iOS release, Version 7. When attached to the malicious charger the phone recognizes it as a computer, and a dialog box appears asking the user if he trusts the computer. But if the user clicks “yes,” the compromise can proceed.