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