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.
Why CISOs Need a Security Reality Check
Joel Fulton, Chief Information Security Officer for Splunk,  6/13/2018
Cisco Talos Summit: Network Defenders Not Serious Enough About Attacks
Curtis Franklin Jr., Senior Editor at Dark Reading,  6/13/2018
Meet 'Bro': The Best-Kept Secret of Network Security
Greg Bell, CEO, Corelight,  6/14/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-12294
PUBLISHED: 2018-06-19
WebCore/platform/graphics/texmap/TextureMapperLayer.cpp in WebKit, as used in WebKitGTK+ prior to version 2.20.2, is vulnerable to a use after free for a WebCore::TextureMapperLayer object.
CVE-2018-12519
PUBLISHED: 2018-06-19
An issue was discovered in ShopNx through 2017-11-17. The vulnerability allows a remote attacker to upload any malicious file to a Node.js application. An attacker can upload a malicious HTML file that contains a JavaScript payload to steal a user's credentials.
CVE-2018-12588
PUBLISHED: 2018-06-19
Cross-site scripting (XSS) vulnerability in templates/frontend/pages/searchResults.tpl in Public Knowledge Project (PKP) Open Monograph Press (OMP) v1.2.0 through 3.1.1-1 before 3.1.1-2 allows remote attackers to inject arbitrary web script or HTML via the catalog.noTitlesSearch parameter (aka the S...
CVE-2018-10811
PUBLISHED: 2018-06-19
strongSwan 5.6.0 and older allows Remote Denial of Service because of Missing Initialization of a Variable.
CVE-2018-10945
PUBLISHED: 2018-06-19
The mg_handle_cgi function in mongoose.c in Mongoose 6.11 allows remote attackers to cause a denial of service (heap-based buffer over-read and application crash, or NULL pointer dereference) via an HTTP request, related to the mbuf_insert function.