Application Security
1/22/2016
11:00 AM
Paul Drapeau
Paul Drapeau
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
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.
Hacked IV Pumps and Digital Smart Pens Can Lead to Data Breaches
Dawn Kawamoto, Associate Editor, Dark Reading,  12/4/2017
Tips for Writing Better Infosec Job Descriptions
Kelly Sheridan, Associate Editor, Dark Reading,  12/4/2017
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Managing Cyber-Risk
An online breach could have a huge impact on your organization. Here are some strategies for measuring and managing that risk.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.