A team of researchers from Georgia Tech has demonstrated how hackers can slip a malicious app by Apple's reviewers so that it's published to the App Store and ready for unsuspecting victims to download.
Led by Tielei Wang, a research scientist at Georgia Tech's school of computer science, the team created a "Jekyll" app -- named for the Robert Louis Stevenson novella, Strange Case of Dr. Jekyll and Mr. Hyde -- that posed as a benign news reader. Hidden inside the app, however, were code fragments, dubbed "gadgets," that self-assembled to create a proof-of-concept exploit only after the app was approved by Apple.
The assembled attack code was able to send tweets, email and texts without the user's knowledge, and could steal the iPhone's unique device ID, turn on the camera and take video, forward voice calls to other phones and connect with local Bluetooth devices. Because the reconfigured app also "phoned home" to a server operated by the researchers, they were able to download additional malware and compromise other apps on the smartphone, including the Safari browser.
What had seemed on the surface -- far below the surface for that matter -- to be a harmless Dr. Jekyll was silently transformed into an evil Mr. Hyde.
Those code gadgets -- and the app's true control flow and operation -- were disguised in such a way that it would be virtually impossible for Apple's current review methods to discover the app's real intent. "Even with a longer time [to analyze the app] they can't find that it's malicious," said Wang in an interview Monday.
Vulnerabilities, which the Jekyll app secretly planted in its code, are also nearly impossible to detect or stamp out, he said.
In fact, Wang and his team -- Kangjie Lu, Long Lu, Simon Chung, and Wenke Lee, all of Georgia Tech -- sidestepped every major security technique baked into iOS, including sandboxing and code signing, as well as anti-exploit technologies like DEP (data execution prevention) and ASLR (address space layout randomization).
"For instance, the app can deliberately leak its memory layout information to the remote server so that ASLR is completely ineffective," the group wrote in the paper ( download PDF) they presented Friday in Washington, D.C. at the USENIX Security Symposium. "Based on the memory layout information, attackers can launch attacks by reusing the [existing] code inside the app. As a result, DEP and code signing cannot prevent the exploit."
The Georgia Tech researchers built their Jekyll app and submitted it to Apple, which approved it seven days later. Once on the App Store, the team downloaded the app onto their own iPhones, told it to transform into a Mr. Hyde and ask for instructions from their server. After confirming that it worked as designed, they removed the app from the App Store.
No other users downloaded the app while it was available, Wang said.
Unlike Android, Apple's iOS has been remarkably free of malicious apps, due to the Cupertino, Calif. company's mandate that only apps from its App Store can be installed on an unmodified iPhone. Apple also conducts a review before approving an app, purportedly looking for malicious code or unsanctioned operations. It rejects those it believes are suspicious or that sport illegal functions.
But the review process, even if it was beefed up with personnel and the analysis done with different tools, would not stymie Jekyll apps, Wang and his team wrote in their paper.
"We argue that the task of making all apps in App Store vulnerability-free is not only theoretically and practically difficult, but also quite infeasible to Apple from an economic perspective because such attempts will significantly complicate the review tasks, and therefore, prolong the app review and approval process that is already deemed low in throughput by third-party app developers," they wrote.
With little chance of catching Jekyll apps during review, Apple should enhance iOS security to stymie such masquerading software at runtime, or when it's on an iPhone and active, Wang said.
They made several recommendations, including improving ASLR and providing a finer-grained permission model, but pointed out that hackers may be able to work around those defenses, too.
One way Apple could monitor apps at run time and thus stop Jekylls, was with "control-flow integrity" (CFI), an advanced anti-exploitation technology that requires code execution to follow pre-defined paths, and no others.
Ironically, Apple's rival Microsoft has been at the forefront of CFI research, with papers from its scientists going back to 2005. And last year, the winner of Microsoft's BlueHat Prize was awarded $250,000 for coming up with a "lightweight form of control flow integrity" to protect Windows against ROP, or "return-oriented programming" attacks.
"CFI is a very hot research topic right now," said Wang.
Wang and his team reported their findings to Apple in March, long before the paper was made public. "They said they appreciated the report," said Wang. But he was, like everyone else, in the dark about what Apple might do to block Jekylls from reaching the App Store, or failing that, from executing on iPhones.
Apple did not reply to a request for comment, but elsewhere the company has said it made changes in iOS in response.
According to Wang, iOS 7 is still vulnerable to the technique of hiding vulnerabilities in a Jekyll app and exploiting them after approval to do dirty work.
"However, Apple did enhance its sandbox policies," Wang said Tuesday in an email reply to follow-up questions. "Some of our attack instances no longer work, but we need to further figure our whether iOS 7 completely fixes the issues."
Apple has to do something, Wang argued. "It's not a big deal for a malicious app developer [to do this]," he said.
His recommendation to users? "Be very cautious when you download unknown, third-party apps," he said.
Good advice, certainly, because who wants Mr. Hyde on a rampage when they expected Dr. Jekyll at the door?
Gregg Keizer covers Microsoft, security issues, Apple, Web browsers and general technology breaking news for Computerworld. Follow Gregg on Twitter at @gkeizer, on Google+ or subscribe to Gregg's RSS feed. His email address is email@example.com.
Read more about malware and vulnerabilities in Computerworld's Malware and Vulnerabilities Topic Center.