7 ms·

Unsigned apps on High Sierra can programmatically dump and exfil keychain

130 points by EwanToo 9y ago

0x0 9y ago
So.. is this specific to macOS 10.13? Or is 10.12.6 also vulnerable?
- yuchi 9y ago
  Waiting for an answer too…
- Osmium 9y ago
  Most important question here... how long has this vulnerability been around for? Was all ready to upgrade this morning...
- gondo 9y ago
  "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
Cthulhu_ 9y ago
"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.
- sicher 9y ago
  Should probably still ask for credentials though.
- st3fan 9y ago
  If unsigned apps can do this then a signed app can probably do it too.
- EwanToo 9y ago
  Sorry about the "unsigned" bit, was doing it on my phone and it wasn't fitting, so I ended up chopping some words out.
- teilo 9y ago
  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."
- mikeash 9y ago
  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 9y ago
    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.
zimpenfish 9y ago
Is there actually any external verification that this can be done?
- Twisell 9y ago
  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?
  - pvg 9y ago
    The app is opened by right clicking and picking 'Open' from the context menu, this hasn't changed.
  - falsedan 9y ago
    I just downloaded an unsigned app (https://www.bitcoinarmory.com/download/ 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.
  - eridius 9y ago
    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.
Jdam 9y ago
Proves me once again that the best password vault is sitting on my shoulders.
- alien_at_work 9y ago
  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.
  - heavymark 9y ago
    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.
  - Waterluvian 9y ago
    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.
raimue 9y ago
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 9y ago
  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 9y ago
    False. Signed apps can have entitlements, unsigned apps cannot. Some entitlements grant access to keychain items.
    - teilo 9y ago
      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 9y ago
        There are both sandbox and non-sandbox entitlements. iCloud storage and push notifications are examples of the latter.
        teilo 9y ago
        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.
altitudinous 9y ago
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 9y ago
  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 9y ago
    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 9y ago
      Also visible with the built-in CLI tool security(1): $ security find-internet-password -s www.facebook.com -g
      - thoughtsimple 9y ago
        Didn't work for me on today's release of macOS High Sierra.
        9y ago
teilo 9y ago
Patrick Wardle (the source of this video) is on a roll today: https://www.synack.com/2017/09/08/high-sierras-secure-kernel-extension-loading-is-broken/ https://www.synack.com/2017/09/08/high-sierras-secure-kernel...
- teilo 9y ago
  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.
Osmium 9y ago
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.)

130 points by EwanToo 9y ago

0x0 9y ago

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

yuchi 9y ago
Waiting for an answer too…
Osmium 9y ago
Most important question here... how long has this vulnerability been around for? Was all ready to upgrade this morning...
gondo 9y ago
"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

Cthulhu_ 9y ago

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

sicher 9y ago
Should probably still ask for credentials though.
st3fan 9y ago
If unsigned apps can do this then a signed app can probably do it too.
EwanToo 9y ago
Sorry about the "unsigned" bit, was doing it on my phone and it wasn't fitting, so I ended up chopping some words out.
teilo 9y ago
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."
mikeash 9y ago
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 9y ago
  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.

zimpenfish 9y ago

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

Twisell 9y ago
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?
- pvg 9y ago
  The app is opened by right clicking and picking 'Open' from the context menu, this hasn't changed.
- falsedan 9y ago
  I just downloaded an unsigned app (https://www.bitcoinarmory.com/download/ 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.
- eridius 9y ago
  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.

Jdam 9y ago

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

alien_at_work 9y ago
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.
- heavymark 9y ago
  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.
- Waterluvian 9y ago
  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.

raimue 9y ago

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 9y ago
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 9y ago
  False. Signed apps can have entitlements, unsigned apps cannot. Some entitlements grant access to keychain items.
  - teilo 9y ago
    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 9y ago
      There are both sandbox and non-sandbox entitlements. iCloud storage and push notifications are examples of the latter.
      - teilo 9y ago
        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.

altitudinous 9y ago

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 9y ago
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 9y ago
  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 9y ago
    Also visible with the built-in CLI tool security(1): $ security find-internet-password -s www.facebook.com -g
    - thoughtsimple 9y ago
      Didn't work for me on today's release of macOS High Sierra.
      - 9y ago

teilo 9y ago

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

teilo 9y ago
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.

Osmium 9y ago

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