Unsigned apps on High Sierra can programmatically dump and exfil keychain | Hacker News Reader

Unsigned apps on High Sierra can programmatically dump and exfil keychain

twitter.com

130 pointsEwanToo50 comments

So.. is this specific to macOS 10.13? Or is 10.12.6 also vulnerable?

Waiting for an answer too…

Most important question here... how long has this vulnerability been around for? Was all ready to upgrade this morning...

"other versions of macOS are vulnerable too" the author confirmed it on twitter

https://twitter.com/patrickwardle/status/912392633909047296

Patrick Wardle (the source of this video) is on a roll today: https://www.synack.com/2017/09/08/high-sierras-secure-kernel...

This makes me wonder if the vector for this exploit is a kernel extension that subverts the keychain service. Except that the kernel loading exploit appears to require root privileges.

Is there actually any external verification that this can be done?

On the screencast it appear that the dialog box have been reworked to be less constraining than in Sierra where you needed to go to Preferences>Gatekeeper to allow execution of unsigned app.

I haven't tested the beta so this struck me, can someone confirm?

The app is opened by right clicking and picking 'Open' from the context menu, this hasn't changed.

I just downloaded an unsigned app (https://www.bitcoinarmory.com/download/), and I see the usual `"Armory" can't be opened because it is from an unidentified developer.` message, with only an [OK] button to cancel the launch. I see that the video maker disabled Gatekeeper by choosing Open from the right-click menu.

Right-clicking an app and selecting "Open" has always given you the ability to bypass Gatekeeper. It's been that way since Gatekeeper was introduced.

This is scary if accurate.

For people unfamiliar with Keychain, the problem as I understand it is not that unsigned apps can do this per se (though I don't think this is a good idea), it's that they can do this without user intervention.

The normal flow for Keychain is that when an app wants access to a keychain item that was not created by that app, it has to ask for user permission to allow once or always allow access. It sounds like this isn't happening in this case.

(Aside: it used to be possible to trivially access all website passwords in Safari too (which I dutifully reported as a bug, because it was a terrible design choice), but Apple thankfully changed this to require authentication in new versions of Safari.)

From a security perspective, I would assume that signed binaries should not have additional restrictions that are also not in place for unsigned binaries. Would this exploit also work with a signed app as well, but avoiding the user confirmation?

There is no difference between a signed and unsigned app once it has been allowed to launch the first time. The permission model is the same for both. Normally you would have expected to see a system dialog asking if you would like to grant an app permission to access the keychain once or permanently.

EDIT: As another commenter pointed out, an app is also only granted access to one key at a time, each requiring an independent confirmation (with password). There is no way (normally) to grant cart-blanche access to the entire keychain.

False. Signed apps can have entitlements, unsigned apps cannot. Some entitlements grant access to keychain items.

Completely wrong. Entitlements are for sandboxed apps, and grant a sandboxed application access to other parts of the system. Unsigned apps are by definition, not sandboxed, and have no such restrictions. They are granted access, not by a sandbox entitlement, but by the Keychain API.

There are both sandbox and non-sandbox entitlements. iCloud storage and push notifications are examples of the latter.

Granted. In any case it is not relevant in the context of this discussion. Access to the local keychain does not require an entitlement. Even the "keychain-access-groups" entitlement only applies to the iCloud keychain.

"Unsigned" apps, I'd recommend a headline update to provide a bit of nuance.

How safe are unsigned apps anyway? I can imagine it's "all bets are off" level software.

Should probably still ask for credentials though.

If unsigned apps can do this then a signed app can probably do it too.

Sorry about the "unsigned" bit, was doing it on my phone and it wasn't fitting, so I ended up chopping some words out.

The "unsigned" part is irrelevant. All apps run with the same default permissions once you tell them to run. "Unsigned" just means you have to allow it to run the first time, depending on how you configured Gatekeeper, by right-clicking and choosing "Open."

Keychain is supposed to require user authorization before returning any data. Unless you're running as root, it's certainly not "all bets are off." Even if you are, the keychain is supposed to use crypto which would prevent reading it without the user's consent.

It's debatable.

Once the user has installed unauthorized software, the attacker can simply sit and wait for the user to expose more goodies (logins, bank data, 1password access, etc). In many ways, it is game over. If the attacker can leverage that to get your admin password, prompts are not going to save you.

Proves me once again that the best password vault is sitting on my shoulders.

How does that work? With Keychain I literally have a different password on every single site I visit. If someone hacks Facebook they'll have... my Facebook password (and whatever sites use OAuth and won't let me opt out of it). Does your brain consistently handle that level of password diversification, because that's the best defense against password theft.

Agreed. Though always does come down to the weakest link. Such as if a person had access to just your email account password then they could reset most any other password on other accounts you have in the middle of the night while you slept. Which is why 2 factor on your email is most important though, depending on what software/methods you use for 2 factor always a chance that could be bypassed.

Also if someone gains physical access to your device(s) while you are in the bathroom or what not, if they know your laptop password which is usually something easy to remember, then they have access to all your keychain passwords no matter how complex each of them are.

Still million times better than attempting to memorize custom passwords for each site, since most people will just have one password, and will add a few characters based on the site name/domain which can also easily be cracked.

For many years now I've used an algorithm for password generation that I keep in my head. It's pretty simple, I have a memorized string (like a traditional password), and a memorized set of rules. For example, I might have a rule where I take my password, replace the first character with the first character of the product (a for Amazon), and replace the last letter with the type of product I'm using (s for shopping).

I have a significantly more complex algorithm than that, but you get the idea.

Every password I have is different, but they're all trivial to remember. This isn't super hardcore security, but it helps me have like 40 passwords that are all different.

And how many of your passwords need to leak for that scheme to be completely transparent?

So your password has a root password and probably 2-4 pseudo random characters appended/prepended/replaced? That means once it has been leaked in 1 breach, your 'true' algorithmic password is only 2-4 characters long. Which should take a few minutes to crack on other sites. And the more breaches you are included in, the easier it would be to work out your algorithm, reducing the number of attempts further.

But they aren't going to target me specifically? They won't. They just find everyone whose password across multiple breaches is similar (Levenshtein distance or something) and brute force the differences.

> But they aren't going to target me specifically? They won't. They just find everyone whose password across multiple breaches is similar (Levenshtein distance or something) and brute force the differences.

Is this possible when the leaked passwords are all only salted hashes?

You mean like LinkedIn (SHA1 hashes without salt), Adobe (Poor Crypto), Dropbox (half of them SHA1), etc., etc.

[1] https://haveibeenpwned.com/PwnedWebsites#LinkedIn

[2] https://haveibeenpwned.com/PwnedWebsites#Adobe

[3] https://haveibeenpwned.com/PwnedWebsites#Dropbox

No, but not everyone follow good crypto practices...

I did this too, back when I had to use public terminals and obviously could not use password managers. But the idiosyncrasies of password rules on many sites added to the complexity of my own "transformation" of the base password, until the whole thing while workable, became burdensome. These days I do all logging in on my own PC and therefore I see no real need not to use a password manager and unique, random passwords for each site.

The obvious downside to this approach is if I were ever to be caught in a situation where I MUST log in to some site but do not have access to my PC AND phone, and therefore cannot risk opening the password DB on an alien system. Pretty unlikely scenario though.

This seemed like a great idea when I first encountered it, but trying to use it was a major fail for me. Encrypted files with a single long passphrase I can actually remember seems less prone to failure.

What exactly is the product name? What is the website name? Does it include www? What about other subdomains?

These are the same kinds of questions that make security questions so frustrating as designed.

"What was your elementary school?" Hm. Is preschool elementary, or separate? Is the private school I went to for K and 1st an "elementary school" (there was no division between those in that school)? Maybe I should use the first school I attended between K-6 that had such a division? Or maybe just when I started public school, since that one was the first one called elementary...?

"What was your mother's maiden name?" I hardly remember my mother, and when I started being asked her maiden name, I had to guess how to spell it. Is this security question one I answered when I was guessing wrong, before I knew how to spell it for real? Even if it's not, did I decide this time to use the old spelling for consistency, or to add a slight hitch to someone who looked that up and is trying to access my account?

Essentially every answer to these kinds of questions that isn't about a number (and some of those!) comes with so many caveats that it seems unlikely I'll remember which path down this tree I took when I added it. The world is so fuzzy. This is like those "puzzles" where the wording of the puzzle actually admits many possible answers depending on how you interpret words and phrases, but everyone seems to settle on a meaning that's obvious to them, but the most "obvious" answer seems different from day to day for me.

I did this myself for a couple years. I soon learned it is a flawed and insecure approach. I don't recommend it for a variety of reasons.

For web accounts I don't care about, a password manager seems to be handy. But for things like bank and email, I don't particularly trust a password manager. "CorrectHorseBatteryStaple" isn't too difficult to remember, and is plenty secure.

Even memory is a tradeoff. Assuming excellent memory, even then people won't use 20 character passwords because they're too hard to type precisely. The ability to store/copy/paste passwords makes for stronger passwords because size and complexity just doesn't matter

> people won't use 20 character passwords because they're too hard to type precisely.

I have friends who do this. They set huge passwords for "security", and then can't type them consistently, or forget them, and have to reset the password. Then they complain about their accounts getting locked.

I can't convince them that a shorter password is still secure, and will remove much of the aggravation.

How much shorter? Password security is related to the length of a password.

That’s not a very good solution either.

This is highly irresponsible advice (if your comment may be construed as advice).

If it isn't advice, then it's just a bad idea.

Confirmation bias is a powerful thing.

Isn't this how keychain works?

This is clearly not remotely executable, it needs to be run on the device that is signed in.

Say you visit facebook.com, your password is in the keychain, so the keychain must be decrypted to return the plaintext password so it can be passed in the password field to facebook.com

This is how keychain works isn't it??

You can view your entire password list in Safari Preferences - it does the same thing.

So this is nothing? Someone has written a command line version of this same tool.

Am I missing something, this seems to be normal functionality of the OS for a signed in user.

No. Application access to the keychain is restricted via an API with a (supposedly) robust security model behind it, for precisely this reason. Applications must explicitly be granted access to the keychain. There should have been a prompt requesting keychain access.

Furthermore, it's supposed to ask about each item the app wants to access. You can see this in Keychain Access. Pick a password, inspect it, click the Show Password box, and a prompt will appear asking you to authorize it before it'll show you anything. That's part of the Keychain API, not something special to Keychain Access.

Also visible with the built-in CLI tool security(1):

  $ security find-internet-password -s www.facebook.com -g

Didn't work for me on today's release of macOS High Sierra.

Works for me on HS.

Reply on news.ycombinator.com