Apple Removes Chinese iOS App Masked as Language Learning App, Functioning as Pirated App Store
Recently, security researchers from Palo Alto Networks discovered an iOS application named “Happy English Daily” that was masquerading itself as a “functional” English language learning app, while in reality functioning as a full-feature 3rd party app store in China. What was particularly noteworthy was the app’s ability to install pirated, unauthorized iOS applications – even on non-jailbroken devices. The hackers had also implemented geographical filtering limiting the unauthorized app store to consumers within China – otherwise routing to the language learning app when accessed outside of the mainland.
The researchers from Palo Alto Networks first reported the app, which they coined as “ZergHelper”, to Apple on Feb.19th; Apple removed the app from the App Store later that day (the app was made available on the App store in October of 2015). The researchers’ analysis of ZergHelper did not reveal malicious functionality, and was subsequently classified as ‘Riskware’. However, they did note it presented several security risks, as documented in Claud Xiao’s (Palo Alto Networks) blog.
Patrick Wardle, Synack Director of R&D and Apple security expert, provided his perspective on the situation, prefacing with the fact that, “Xiao’s blog is very technically comprehensive”.
· What’s intriguing about the discovery of the application is that ‘ZergHelper’ made it into App Store in the first place – meaning it had to bypass Apple’s ‘strict’ code review process (a process that seeks, amongst other things, to disallow and prevent the installation of pirated application on non-Jailbroken devices).
· We saw vShare back in December which provided a 3rd party App Store “platform” website to download cracked/pirated apps onto non-jailbroken phones. What’s more interesting here is that ZergHelper is a native app that made it into the App Store by taking advantage of the new, personal code signing certification process, as well as over 50 different enterprise certificates. These bypass techniques were complemented with additional tricks once downloaded, such as creating a fake iTunes client and creating, or potentially stealing, Apple IDs to facilitate the installation of pirated apps onto a non-jailbroken iDevice.
· So how exactly did the app bypass Apple’s review process… it is theorized, that by executing different logic based on the location of the user* – specifically, if the user was in mainland China, the app would execute its true logic, the 3rd party App Store interface. It’s likely that Apple’s review process was only ‘shown’ this benign, seemingly approvable language-learning interface – Apple unknowingly approved the riskware App Store application in the process.
*Note: this isn’t a tremendously novel idea – it’s actually pretty simple, and somewhat surprising that this worked.
· The app also included an embedded interpreter (Lua), that allowed the app developer to update code (un-reviewed by Apple) and extend the functionality of the app at anytime – another strict ’No-No’… Apple failing to notice this well-known methodology is also surprising!
1. New Features = New Attack Surfaces – When Apple started to provide free personal certificates (as opposed to the $99/developer option) in June of 2015, this opened up a mechanism for hackers to abuse, as demonstrated by ZergHelper here. New features should always be thoroughly vetted to ensure they don’t undermine the security of a system, or introduce new abuse/attack vectors.
2. Apple is NOT Invincible – A false sense of protection has been provided by Apple’s “secure out-of-the-box” branding. It’s always going to be a cat and mouse game, but hackers will generally find a way to win. Apple’s iOS is assumed to be a hard target – still hackers have shown that with enough motivation and/or financial incentive, they will find ways around some of the most stringent safeguards.
3. Malicious or Not? = Not as Clear as it Sounds – As Fred Cohen famously noted, there is no way to theoretically prove if something is malicious or not… Still, it is surprising that Apple’s review was so easily bypassed. How did large portions of unexecuted code, and an embedded interpreter capable of dynamically executing unchecked code, go unnoticed?