Application Security
1/22/2016
11:00 AM
Paul Drapeau
Paul Drapeau
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail
100%
0%

The Apple App Store Incident: Trouble in Paradise?

The fact that Apple's security model has worked so well in the past doesn't mean it will work well forever. Here's why.

Apple’s App Store and development ecosystem is often described as a walled garden, due to its closed developer ecosystem and stringent security. Since 2008, Apple’s approach has been reasonably successful in preventing malicious iOS apps from making their way into the store and onto users’ iPhones and iPads. But a very public incident in September 2015 highlighted a weakness in Apple’s security model that may spell trouble in the future.

Initially, Apple confirmed that 39 malware-infected apps had been found and removed from its China App Store, including popular messaging and car-hailing services. The tainted apps, which one research firm called “very harmful and dangerous,” contained code that steals sensitive user and device information. Independent researchers soon revised the number of infected apps upwards to 344, then 4,000, saying they may have been downloaded to hundreds of millions of devices.

This incident highlights an important issue: Developers are an attractive target for propagating advanced attacks because the product of their labor is widely distributed downstream and is trusted by end users and organizations.

In this case, legitimate developers in China were enticed into downloading an illicit copy of Apple’s XCode developer toolkit from a local server rather than using official Apple sources. It’s likely the attackers were exploiting the human tendency to take shortcuts: Due to China’s internet restrictions, downloads from the U.S. take up to three times longer. Unbeknownst to the developers, the illicit tools (dubbed XCodeGhost) inserted malware into their apps. Submitted to the App Store under the developers’ own trusted credentials, the apps were assumed to be safe.

Although Apple moved quickly to repair the damage, the incident is troubling in a number of ways. It tells cybercriminals that Apple security is not invincible and that attacking higher up the value chain, by compromising developer tools and credentials, can be an effective approach.

A falure on two counts 

The fact that the breach was discovered by external researchers suggests that Apple’s own security failed on two counts: Apple didn’t detect the developers’ use of the illicit tools and didn’t recognize the presence of malicious apps once they had gotten into the store. Furthermore, Apple is moving toward a similar development-and-deployment paradigm for Mac applications, potentially exposing them to the same risks as iOS apps.

This incident should serve as a warning. The fact that Apple’s security model has worked so well in the past doesn’t mean it will work forever. That’s especially true as the number of iOS devices gets larger—Apple had sold more than a billion as of last January—and the content they transport or store gets juicier. Today’s developer shops run almost exclusively on Macs. A huge number of business executives, government officials, and senior professionals conduct sensitive communications on their iPhones. Given this reality, attackers will persist in looking for new, creative ways to compromise those devices for profit, political gain, or sheer spite.

There’s no indication that Apple plans to overhaul its security regime any time soon. However, the recent insertion of malicious code could have been detected and shut down earlier and with less damage if Apple’s security strategy had employed large-scale, behavioral analytics on the endpoints themselves, alongside other security measures.

On the developer side of such an attack, it’s important to compare the reputation of each developer’s toolset against known good tools. By detecting if and when new versions show up in the environment and where they were downloaded from, it’s possible to quickly identify illicit sources or versions of the developer toolchain. On the end-user side of an attack, Apple would benefit from opening the iOS platform to allow monitoring of a device’s network connections, reputation services, and behavioral detection.

Historically, Apple’s implicit message about iOS security has been this: “Trust us. We have all these controls in place around tools and credentials, so only secure stuff you can trust gets into the App Store.” But in the wake of this recent attack, enterprises, developers and end users can be forgiven for wondering, “Is that still enough?”

Releated content:

Paul Drapeau is a Principal Security Researcher for Confer, which offers endpoint and server security via an open, threat-based, collaborative platform. Prior to joining Confer he led IT security for a public, global pharmaceutical research-and-development organization. He is ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Christian Bryant
50%
50%
Christian Bryant,
User Rank: Ninja
1/24/2016 | 2:40:08 AM
Re: Bound to happen
For me, one takeaway here is that Apple needs to look to more external resources to aid in detection of malicious programs that get past the initial assessment.  Unless they plan to beef up their org with a large InfoSec team, as with most surprise hacks and hackables out there, things like this are going to continue to be identified by non-Apple staff.  Bounties are a great way to encourage folks to explore and uncover app store issues, but there can be complications here for people who aren't under direct contract with Apple who need to bend the rules to do the work.  

Ultimately, Apple simply needs to innovate and do more toward developing new ways of protecting customer through automated app code scanning and detection of "unusual" content in apps at both the code and binary level.  If folks complain the current process for developing and releasing through Apple iTunes and so forth is already complicated, will that deter Apple from beefing up security in this area?  Hopefully not.  After all, to innovate in the app store platform arena could mean great exposure from both a customer service and technology perspective.   
Joe Stanganelli
50%
50%
Joe Stanganelli,
User Rank: Ninja
1/22/2016 | 11:07:22 PM
Walled garden and antivirus
The iOS platform is still far less attacked, in general, than Android platforms.  Apple's walled garden does have a strong effect in keeping bad guys out, but it can't keep *all* the bad guys out -- which is why there needs to be increased awareness and advocacy for downloading and installing trusted anti-malware apps.

Come to think of it, our computers often come with anti-malware software pre-installed.  Why not our smartphones?
RyanSepe
50%
50%
RyanSepe,
User Rank: Ninja
1/22/2016 | 1:04:37 PM
Bound to happen
No matter how secure you think you are, this will eventually happen. Apple was quick to respond which is definitely a monumental benefit.

What takeaways would you provide to Apple citing this case for a future occurence. Either from a prevention or mitigation standpoint.
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Five Emerging Security Threats - And What You Can Learn From Them
At Black Hat USA, researchers unveiled some nasty vulnerabilities. Is your organization ready?
Flash Poll
DevOps Impact on Application Security
DevOps Impact on Application Security
Managing the interdependency between software and infrastructure is a thorny challenge. Often, its a developers are from Mars, systems engineers are from Venus situation.
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-7445
Published: 2015-10-15
The Direct Rendering Manager (DRM) subsystem in the Linux kernel through 4.x mishandles requests for Graphics Execution Manager (GEM) objects, which allows context-dependent attackers to cause a denial of service (memory consumption) via an application that processes graphics data, as demonstrated b...

CVE-2015-4948
Published: 2015-10-15
netstat in IBM AIX 5.3, 6.1, and 7.1 and VIOS 2.2.x, when a fibre channel adapter is used, allows local users to gain privileges via unspecified vectors.

CVE-2015-5660
Published: 2015-10-15
Cross-site request forgery (CSRF) vulnerability in eXtplorer before 2.1.8 allows remote attackers to hijack the authentication of arbitrary users for requests that execute PHP code.

CVE-2015-6003
Published: 2015-10-15
Directory traversal vulnerability in QNAP QTS before 4.1.4 build 0910 and 4.2.x before 4.2.0 RC2 build 0910, when AFP is enabled, allows remote attackers to read or write to arbitrary files by leveraging access to an OS X (1) user or (2) guest account.

CVE-2015-6333
Published: 2015-10-15
Cisco Application Policy Infrastructure Controller (APIC) 1.1j allows local users to gain privileges via vectors involving addition of an SSH key, aka Bug ID CSCuw46076.

Dark Reading Radio
Archived Dark Reading Radio
Join Dark Reading community editor Marilyn Cohodas and her guest, David Shearer, (ISC)2 Chief Executive Officer, as they discuss issues that keep IT security professionals up at night, including results from the recent 2016 Black Hat Attendee Survey.