XARA: Unauthorized Cross-App Resource Access
Six university researchers have revealed deadly zero-day flaws in Apple’s iOS and OS X, claiming it is possible to crack Apple’s password-storing keychain, break app sandboxes, and bypass its App Store security checks.
Attackers can steal passwords from installed apps, including the native email client, without being detected, by exploiting these bugs.
The team was able to upload malware to the Apple app store, passing the vetting process without triggering alerts. That malware, when installed on a victim’s device, raided the keychain to steal passwords for services including iCloud and the Mail app, and all those stored within Google Chrome.
Luyi Xing et al. (PDF, Google Drive) found four main vulnerabilities. On the Mac, controlling a target application’s keychain items:
One scenario for this exploit is that when the malware runs before the victim app creates a password (or rather a keychain item) in the keychain. What the attacker can do here is to use the attributes of the target app (the victim) to claim an item and also craft an ACL that includes the target as a trusted app. When the target uses the keychain to store password, it discovers the item with its attributes already there and treats the item as its own secure storage (illustrated by the Apple’s template code in Figure 2). Note that this is reasonable given that an app’s older version or other apps from the same developer may have already been installed on the system. Since the target is on the ACL of the item (which is controlled by the attacker), the OS allows all its operations to proceed. Therefore, at no point the target gets any indications from the keychain that it is just a guest user of the item, and the owner is untrusted. This confusion will cause the target to divulge its secrets to the attacker, whenever it updates the user’s credentials to the keychain.
[…]
We checked the most recent OS X 10.10.3 and beta version 10.10.4 and found that they attempted to address the iCloud issue using a 9-digit random number as
accountName. However, theaccountNameattribute for other services, e.g. Gmail, are still the user’s email address. Most importantly, such protection, based upon a secret attribute name, does not work when the attacker reads the attribute names of an existing item and then deletes it to create a clone under its control, a new problem we discovered after the first keychain vulnerability report and are helping Apple fix it.
Using a helper with the target’s bundle identifier to access the contents of its container:
Interestingly, we found in our research that the MAC Store fails to verify whether a sub-target’s BID is in conflict with those belonging to other apps or their sub-targets, except for the Apple reserved BID (those starting with com.apple). This allows one to publish an attack app whose helpers or XPC Services are using the BIDs of other apps, their helpers or XPC Services. Once the attack app is launched, whenever the OS finds out that the container directory bearing the sub-target’s BID (as its name) already exists, the sub-target is automatically added onto the directory’s ACL.
Intercepting communication from the 1Password browser extension to the 1Password helper application:
In our research, our sandboxed app created a local WebSocket server that took over the port 6263, before the 1Password app did, and was successfully connected to the password extension and downloaded the password whenever the user logged into her web account. We reported our findings to the 1Password security team, which acknowledged the gravity of this problem. This attack succeeded on OS X 10.10 (latest version when we reported the problem), against Chrome, Firefox and Safari. Our attack code passed the vetting process of the MAC Store.
And, on iOS, intercepting credentials by hijacking a URL scheme:
Scheme hijacking poses an especially serious threat to iOS, which heavily relies on URLs for interapp interactions (Section 4.2). As an example, we exploited this weakness and successfully obtained the victim’s Facebook token for Pinterest, the most famous personal media management app. […] Most importantly, once it got the secret to- ken from Facebook, the attacker forwarded it to the Pinterest app through “fb274266067164://”, which completely hid the attack from the user
Lead researcher Luyi Xing told The Register that he reported the security flaws to Apple in October 2014 and complied with the iPhone maker’s request to withhold publishing the information for six months, but has not heard back from the company since and is now exposing the zero-day vulnerabilities to the public. The flaws affect thousands of OS X apps and hundreds of iOS apps and can now be weaponized by attackers.
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.
In this case, both failed.
It’s not the first time researchers have found flaws in application sandboxes. The attack exploiting WebSocket weaknesses, for instance, can also succeed in Windows under certain conditions, the researchers said. Interestingly, they said application sandboxing in Google’s Android OS was much better at withstanding XARA threats.
[…]
In light of the vulnerabilities, users of all OSes should limit the apps they install to those that are truly needed and explicitly trusted.
The threat is that a malicious Mac app can pretend to be 1Password mini as far as the 1Password browser extension is concerned if it gets the timing right. In these cases, the malicious app can collect Login details sent from the 1Password browser extension to the fake 1Password mini. The researchers have demonstrated that it is possible to install a malicious app that might be able to put itself in a position to capture passwords sent from the browser to 1Password.
Note that their attack does not gain full access to your 1Password data but only to those passwords being sent from the browser to 1Password mini.
It is important that the threat only affects communication in one direction. If you always update your passwords directly in 1Password, rather than relying on the extension to send them to the helper, it shouldn’t affect you. [Update (2015-06-18): Make sure that you uncheck “Automatically ask to save new Logins”.] And it’s still safe to use the main feature of 1Password, sending the password to the browser extension.
Neither we nor Luyi Xing and his team have been able to figure out a completely reliable way to solve this problem. We thank them for their help and suggestions during these discussions. But, although there is no perfect solution, there are things that can be done to make such attacks more difficult.
The Register’s subheadline, “Keychains raided, sandboxes busted, passwords p0wned, but Apple silent for six months” made me think that all of my 1Password data was at risk. After all, with Touch ID the master password is stored in the iOS keychain. However, putting together the details above, it sounds like this should not be a concern because the keychain and container vulnerabilities only affect the Mac.
Update (2015-06-18): Jeff Johnson:
I don’t understand all the hubbub about the “Unauthorized Cross-App Resource Access” paper. How can you possibly expect your system to remain secure if you’re already running malware? The important thing is to prevent malware. If you fail, you’re screwed.
We already knew that Apple’s app review was a joke, so that’s nothing new. Malware can easily get through that. You can’t expect to install apps from random, unknown developers and remain safe.
The promise of the Mac App Store and sandboxing is that this is safe. There isn’t supposed to be malware in the store, and even if there is it shouldn’t be able to affect your other apps.
There are many ways to get sensitive information from any computer system, including phishing, spoofing, and social engineering attacks, but XARA is a serious group of exploits and they need to be fixed (or systems need to be put in place to secure against them).
Update (2015-06-19): Nick Arnott:
Ultimately, we’ll have to wait and see where Apple goes from here. Several of the above items seem like bonafide, exploitable security bugs to me; unfortunately, until Apple fixes them, your best bet is to stay cautious and monitor the software you install.
Update (2015-06-21): Brett Terpstra:
Most of the vulnerabilities reported are related to “legacy” systems that Apple built on top of the OpenBSD framework, such as the Keychain, url handlers, inter-app communication systems. These are all things that make OS X great to use, so we’re walking the line between security and convenience again. Most of what I do every day relies on these technologies.
[…]
I’m sure there will be increased scrutiny of all App Store apps using these systems for communication and credential storage. I’m hoping that we don’t just see the pod bay doors snap shut, but that we’ll see new, more secure means of handling the flexibility some of us love.
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," an Apple spokesperson told iMore. “We have additional fixes in progress and are working with the researchers to investigate the claims in their paper.”
2 Comments RSS · Twitter
OK, let's be honest for once.
What's really shocking when this paper is read for the first time is that "Mac" is written "MAC", not that there could be security risks.
@someone What publications have you been reading the last 31 years that got the capitalization right?
