
Unsigned apps on High Sierra can programmatically dump and exfil keychain - EwanToo
https://twitter.com/patrickwardle/status/912254053849079808
======
0x0
So.. is this specific to macOS 10.13? Or is 10.12.6 also vulnerable?

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

[https://twitter.com/patrickwardle/status/912392633909047296](https://twitter.com/patrickwardle/status/912392633909047296)

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

~~~
teilo
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.

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

~~~
Twisell
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?

~~~
eridius
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.

------
Osmium
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.)

------
raimue
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?

~~~
teilo
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.

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

~~~
teilo
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.

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

~~~
teilo
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.

------
Cthulhu_
"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.

~~~
mikeash
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.

~~~
eeeeeeeeeeeee
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.

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

~~~
alien_at_work
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.

~~~
Waterluvian
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.

~~~
snowwolf
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.

~~~
Santosh83
> 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?

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

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

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

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

------
altitudinous
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.

~~~
teilo
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.

~~~
mikeash
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.

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

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

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

~~~
teilo
Works for me on HS.

