Zero-day exploit lets App Store malware steal OS X and iOS passwords
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. (We have a request out to Apple for comment.) 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.
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.
Four paths to crack
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 help 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
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.
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.