Tag Archives: Apple KeyChain

Apple KeyChain Vulnerability Disclosed

Last week a security researcher publicly disclosed a vulnerability within Apple macOS’ Keychain (Apple’s password management system). The exact proof of concept code has not been released.

TL DR:  This vulnerability is currently unpatched by Apple. Be cautious of the links you click on, email attachments and applications you download/open. Keep your system current with already released updates. Watch for updates from Apple in the near future.

Why should this vulnerability be considered important?
This vulnerability affects all versions of Apple macOS up to the most recent 10.14.3 (Mojave). Apple Keychain is used to store passwords for application, websites and servers. This information is encrypted by default blocking access via other means without your permission.

However; the exploit allows an attacker to access this information from a standard user account (thus not requiring root (defined)(privileged) access) without generating a password prompt. The keychain must first be unlocked but it is when you are logged into the system. The System keychain which contains (among other items) is not affected. Thus, if the attacker can persuade you to run an application of their choice (e.g. substituting an app that looks like an app you regularly download manually); they could obtain your passwords/sensitive information. A YouTube video demonstrating the custom application designed to exploit this is provided below:

https://youtu.be/nYTBZ9iPqsU

How can I protect myself?
Please see the TL DR above. You should also consider manually locking your keychain or setting a keychain specific password (further details below).

===========

Lock your Keychain:
Open Keychain Access in the Applications: Utilities folder. Select your keychain (usually your user name) in the drawer (click on Show Keychains in the toolbar if it’s not visible). Then choose Edit: Change Settings For Keychain keychain name. Select Lock After 5 Minutes Of Inactivity (or lower according to your preference).

Password Protect Your Keychain:
Open the Keychain Access application, and select your keychain in the drawer. Select Edit: Change Password For Keychain keychain name, and then enter a new password.

With thanks to MacWorld:

===========

Why did the researcher not disclose this to Apple privately?
The researcher, Linus Henze chose not to privately disclose this to Apple since while Apple have a bug bounty for iOS which is by invite only; they don’t have such a program for macOS. The researcher wishes to highlight this omission. A quote from the researcher is included below (my thanks to Sergiu Gatlan of BleepingComputer.com) for this:

“Please note that even if it looks like I’m doing this just for the money, this is not my motivation at all in this case. My motivation is to get Apple to create a bug bounty program. I think that this is the best for both Apple and Researchers. I really love Apple products and I want to make them more secure. And the best way to make them more secure would be, in my opinion, if Apple creates a bug bounty program (like other big companies already have)”

Separately he is not the only researcher to be criticising Apple’s approach to vulnerability remediation. Ian Beer of Google Project Zero publicly criticised Apple last August for simply fixing vulnerabilities rather than thinking of them in an exploit context namely “Why is this bug here? How is it being used? How did we miss it earlier? What process problems need to be addressed so we could have found [the bug] earlier? Who had access to this code and reviewed it and why, for whatever reason, didn’t they report it?”

Thank you.

Apple App Store Apps Vulnerable to Elevation of Privilege Vulnerabilities

A group of 6 researchers from Indiana University have made available a report that details 4 sets of flaws within apps available in the Apple App Store. The researchers named these collections of flaws; unauthorized cross-app resource access or XARA.

What Are These Flaws and What Data Can They Steal From Me?
The first flaw which lies within Apple’s KeyChain is one mechanism that is used to share information between separate apps (such separation is called “sandboxing” where each app resides in a separate defined area/sandbox). Apps can store information in a private cookie on the computer but this flaw allows a malicious app (which must have been approved by Apple to be available in the App Store) to delete the existing relationship the genuine app has with KeyChain (and thus to it’s private login cookie) and then re-create the relationship but this time with additional permissions given to the malicious app (the app’s ACL) that allows the malicious app to access data that it otherwise couldn’t. As an alternative to deleting the existing relationship, it is also possible to create a relationship with KeyChain for the legitimate app (and including the malicious app) before the legitimate app creates such a relationship in the first instance. This is the elevation of privilege flaw since the malicious app now has more access than it should. The researchers used this flaw to obtain Apple iCloud and Facebook passwords.

=======================
Aside:
What is an ACL?
An Access Control List (ACL) is a list that is present with an object and this list controls who has access to that object and what kind of access they can have (e.g. read only, write, delete etc.). An object is something (e.g. a computer, a folder, a file etc.) that you wish to protect by controlling who has access to it.
=======================

The second flaw, Container Cracking is where one app’s private data store e.g. the contents of your Evernote folder can be accessed by another malicious app simply by that malicious app masquerading as the genuine app by assuming the genuine app’s BID (Bundle ID). If the malicious app can be launched first with the genuine app’s BID, then the operating system will add that malicious app to the ACL that will allow that app to access the private data store, in this case your Evernote folder.

The third flaw, IPC Interception would allow a malicious app to impersonate a legitimate app, the security researchers gave the example of a malicious app impersonating the 1Password Browser extension and could thus intercept data travelling on an internet port (assigned to the browser extension) to capture the login data for a specific website where a user is attempting to login. 1Password has offered advice in this blog post on preventing this attack and discusses approaches that it is currently considering in order to mitigate this issue in the long-term.

For the fourth and final flaw; Scheme Hijacking, the researchers found that a URL scheme used to share information between apps could be hijacked by the first app registering that specific scheme (in Apple iOS, it is the most recent app that registers for that URL scheme is then allowed to make use of it). For OS X the researchers were able to hijack the access token of Wunderlist (a To Do list app). For iOS the researchers were able to hijack the URL scheme for communicating between Facebook and Pinterest apps allowing the Pinterest app to access data within the Facebook app.

To see the extent of which apps are vulnerable to such flaws (within the 4 categories mentioned above), please see Table 1 located on page 9 of the researcher’s report. In addition, for a detailed list of the types of data that can be exposed during these attacks, please refer to Table 2 on Page 10 of their report.

How To Defend Against These Attacks
Since the researchers reported these flaws to Apple in October last year it is reasonable to assume that Apple is working to resolve them and would have more strict checks in place to prevent further apps becoming certified within their Store containing these flaws.
These flaws are not trivial for Apple to resolve since the apps are working as intended and these flaws stem from design decisions that have been abused in novel ways. Thus to resolve them will either mean re-designing these apps intercommunication mechanism to prevent these flaws having malicious effect or adding stricter checks to prevent apps being placed in the Store that inadvertently use these mechanisms in ways that were not intended by Apple. Thus to defend against the exploitation of these flaws I would simply recommend only downloading apps that you know and trust from the Apple App Store.

Further resources discussing these flaws are this post and this post.

Thank you.