Security researchers have found major flaws in OS X and a single one in iOS that open the door to malware. The exploits allow malicious apps that have made their way into the App Store to bypass or ignore sandbox and other security protections to grab passwords from others apps’ keychain entries, steal data from other apps’ private data storage, hijack network ports, and masquerade as different apps to intercept certain communications.
Apple’s review process for the App Store—both for iOS and OS X—is supposed to prevent malware from entering its system. If that bulwark fails, the company relies on sandboxing, which prevents apps from accessing data and files other than that managed by the app, except through very tightly defined channels.
However, six researchers have discovered many weak points in how Apple checks and requires apps to check on storage for apps and communication between apps. The authors called this “unauthorized cross-app resource access,” which they abbreviate as XARA.
One of the authors, XiaoFeng Wang, a professor of computer science at Indiana University, said in an interview, “OS X provides a richer functionality. In this case, it becomes vulnerable.”
The researchers say they notified Apple in October 2014 and twice thereafter, and were told it would take six months to repair the flaws. The authors also say Apple asked for their paper in February. This is considered a “zero-day” exploit because it is immediately available to put into malware, but industry practices for disclosure were observed.
What minimizes the attack vectors presented by the researchers is that any malicious app has to get into the App Store. Unfortunately for Apple, the paper’s authors were able to submit and get approved apps that exploited these weaknesses. They immediately removed them after approval, as they had had their proof of concept.
On Friday, an Apple spokesperson said in a prepared statement, “Earlier this week we implemented a server-side app security update that secures app data and blocks apps with sandbox configuration issues from the Mac App Store. We have additional fixes in progress and are working with the researchers to investigate the claims in their paper.”
The paper details four flaws, three of which are unique to OS X. However, without substantial changes, iOS could be subject to one or two additional exploits noted if certain kinds of inter-application or system-wide data storage changes were made.
The researchers’ analysis of hundreds of free apps reveals that most are vulnerable to most of these vectors of attack. Agile Bits, developer of 1Password, responded with a blog post on Wednesday, detailing what the company plans to do, and what users can do to protect themselves.
Researchers found that a slew of apps in the Mac and iOS App Stores are vulnerable to these attacks.
Four paths to crack
The paper outlines four separate points of weakness:
Password theft via the system-wide keychain.
Container cracking between apps, where one app can retrieve the contents of another sandboxed app’s ostensibly private data store.
Internet socket interception, which allows a malicious app to hijack the flow of traffic to an app.
Scheme hijacking (both iOS and OS X), in which the system-wide method of launching one app from another is redirected to capture login tokens or other information.
Password stealing. The authors found that they could determine the parameters used for any app in the keychain: “the attributes of any keychain item are actually public, though their content (credential) is protected,” they write.
A malicious app gains access to the keychain entry for a target app by either creating an entry before the victim, or by deleting one that exists. In either case, the malware is given access alongside the app when the entry is created or re-created.
…[A]ll the attacker needs to do is just identifying [sic] an existing item, removing it from the keychain and creating a new one of its own with the same attributes to wait for the target app to put its secret there.
A targeted app could check the access control list (ACL) used to limit what can access an OS X keychain entry, but this isn’t required or recommended by Apple.
The researchers attacked Internet Accounts, the preference pane that manages system-wide account data, including iCloud passwords, and the Chrome browser in their testing, but the technique works with any app.
Changes introduced in OS X 10.10.3 and the 10.10.4 beta include an element designed to resist the flaw, but the researchers found it ineffective.
Container cracking. Each sandboxed app may have a protected data storage area, but when apps want to share data with other apps, this opens a weakness the paper’s authors were able to exploit.
While Apple enforces uniqueness in the “Bundle Identifier” (BID) used to set up separate data storage containers in OS X, subsystems aren’t held to the same requirements. A malicious program can use the BID of a subsystem to get itself added to the ACL for another app’s main data container, allowing it full access.
Researchers performed end-to-end attacks on Evernote, WeChat, QQ, Money Control, and others listed in an appendix, and had an app approved in the App Store with this attack embedded.
For example, from the container of Evernote, our attack app, involving an XPC Service that hijacked the target app’s BID, successfully stole all the contacts of the user and her private notes from ∼/Library/Containers/com.evernote.Evernote/account/.
Internet socket interception. The Internet operates using addresses and ports. Addresses are unique to a given computer or mobile or other device. Ports are like apartments in an apartment building, each with a particular function.
In OS X, apps can register and use ports to communicate to and from browsers. The paper gives the example of 1Password, which has browser extensions that communicate with the main 1Password app. (Again, 1Password is working to fix this, and has offerd some advice for how users can prevent being attacked.)
A malicious app can hijack a port before it’s registered by the targeted app, and intercept data. In 1Password’s case, a malicious app (also approved through the App Store) could grab the password whenever a user logged into a web account.
This method also allows what was once called sidejacking: stealing tokens used to identify a user’s browser during a session with a site, and then using that token elsewhere.
Scheme hijacking. A scheme is a way to identify a kind of Internet or other resource and pass some information to it in the form of a URL. For instance, the generic web scheme is “http” (as in http://); all iOS and OS X apps register schemes with the system to allow other apps to pass data or to open a “deep link” within the app.
However, Apple doesn’t require unique schemes the way it does unique Bundle IDs. Any app can register any scheme with validation except for a handful of Apple-specific ones. There’s also no way for an app to determine that it’s passing a URL to the right app—it has to rely on the operating system.
The paper’s authors found:
For a scheme not on the lists, it will be bound to the first app that registers it on OS X and the last on iOS.
The researchers were able to grab tokens bound for other apps in OS X, where this method is used infrequently, and iOS, where it’s extremely common, and then sidejack sessions. One proof-of-concept they note was hijacking Facebook’s scheme so that the Pinterest app requested a token, and the Facebook response with the Pinterest app’s access token was then grabbed by the authors’ malware.
App developers could determine that the wrong app had redirected a response back—the Pinterest app would know something went wrong—but that wouldn’t stop the outbound hijacking that grabbed the token in the first.
Verify, then trust
The authors performed a variety of tests to determine how likely apps were to be vulnerable to these exploits and pulled down 1,612 free apps, representing up to the top 100 free apps in each major category. Of 198 that use the system keychain and should be susceptible, 18 out of 20 that they randomly selected they proved could be exploited. (Two Google apps are immune.)
For the scheme vulnerability, 982 Mac apps had the potential for this issue based on a code scan, and of 200 randomly selected for deeper analysis, 132 were found vulnerable.
Wang of Indiana University said that there’s clearly more to be found in iOS, as their research remains some of the only to deeply examine cross-app issues. “If I were a hijacker, I’m just going to move my target to iOS,” he said.
The short-term fix for these exploits is a combination of new recommendations and requirements to app developers, and additional procedures in the App Store review. “What the App Store can do is run something similar at least to identify—not malicious apps, but at least those vulnerable as targets,” Wang said.
His colleague, PhD candidate Luyi Xing, noted that “Apple should do something to enforce scheme management” as well. However, Xing said that it boils down to being a design problem, rather than an app implementation issue. That will require some deep rethink at Apple, and put some burden on developers as new authentication and registration procedures make their way into App Store requirements.
Because the flaws can only be exploited by apps that make it into the App Store, that provides a firewall for now.
Author: Glenn Fleishman, Senior Contributor
Glenn Fleishman’s most recent books include Take Control of iOS and iPadOS Privacy and Security, Take Control of Calendar and Reminders, and Take Control of Securing Your Mac. In his spare time, he writes about printing and type history. He’s a senior contributor to Macworld, where he writes Mac 911.