Leaking Passwords and more on macOS
wts.dev
wts.dev
You were able to type in an administrator username in any root sign in box (e.g. in the settings panel via the padlock icon) with an empty password. Hitting the Sign In button the first time told you that the password was incorrect. Dismissing that alert box and hitting sign in a second time signed you in as that user.
We were able to reproduce it 100% of the time day-of, and of course was patched pretty shortly after making the rounds on social media. Still seems like a massive oversight though.
Seems there's still some cruft around the auth mechanisms in Mac. Interesting to see the port system mentioned - it's not a well known fact of Mach kernels.
2017 it seems, submission at the time: "macOS High Sierra: Anyone can login as “root” with empty password" - 3001 points | 1073 comments - https://news.ycombinator.com/item?id=15800676
I'm surprised to hear someone say that, given that it's the fact about Mach to me. I'm not sure how people could know about Mach but not its defining system.
Still in early stages of development, mind you.
Sounds like the time my cat hacked my Sun 3/60 by simply sitting on the keyboard. XDM crashed when the username buffer hit 256 random characters, and then dropped a root shell. But this was in the early 90's when everybody was a lot more innocent about security.
It's funny, Apple themselves even suggest people use other apps for FTP: https://support.apple.com/guide/mac-help/servers-shared-comp...
> With read-only access, you can copy files from the server, but to copy files to the server, you may need another FTP app. Choose Apple menu > App Store to find FTP apps available for macOS.
Another funny note: NetAuthAgent has had a bug for years where you cannot connect to an FTP server if your username contains an `@` symbol. I understand the technical reasons for that, but it is technically supported by the spec and other clients work with it just fine. I'd dig up some old posts talking about it going back years, but I don't want to put in the effort, lol.
Basic auth and FTP had a username password schema like
ftp://username@ftpserver.address.com and even
ftp://username:password@ftpserver.address.com
I am completely aware of that, but I am aware that other clients handle it just fine. The bug actually forced me to use a different client for when I actually needed an FTP client.
There are definitely more recent flaws that might have been suspectible to "cat butt on keyboard", like this one in 2016: https://www.bleepingcomputer.com/news/security/linux-flaw-al...
L1-A to bring up the boot monitor. Search memory for `/bin/login` and replace with `bin/ed`. Enter any file name as your ‘user’ name, or just junk, and use `!sh`.
(Amazing what you remember from school…)
After highschool I saw an exploit for this where if you typed the right magic characters in you could highjack the execution of the login prompt and get a shell.
Got in trouble a few times during school years doing that.
Edit: terrible from today's security perspective, I meant.
“With many users now using modified config files to uncap their modems, most cable modem service providers acted to defeat this exploit by turning on the DOCSIS security feature that requires the CMTS to check the authenticity of the modem's config file during the registration process (this is explained in more detail in Chapter 9). As previously mentioned, this checksum is a HMAC-MD5 digest of the entire config file that uniquely iden- tifies its original contents, and it is constructed from the config file using a password chosen by the ISP. This defeats config file exploits because a user 8 Chapter 1| cannot create a checksum that would validate a modified config file without knowing the password that was used by the service provider when the original config file was created. Defeating the Message Integrity Check The fact that the systems of most ISPs had now been patched to prevent this type of uncapping was a challenge to be overcome. I began by attempting to hack the patch that the ISPs had implemented. My starting point was a phrase that was displayed in the modem's HTTP log page when the method described in the uncapping tutorial failed. The logs would read TFTP file complete-but failed Message Integrity check MIC. I wondered how I could bypass this message integrity check or MIC. One morning I awoke to frantic beeps coming from my computer; a member of my group was messaging me. He had the answer. The way to bypass the MIC was not to include the MIC! As simple as that might sound, I had no idea what he was talking about. He then sent me a copy of his config file and had me open it up in a basic hex editor (a program used to examine and modify binary files). The config file normally contained two different checksums at the end of the con- fig file: a standard MD5 checksum of the config, followed by another check- sum, the dreaded HMAC-MD5 (also known as the CmMic). He had simply trun- cated the config file, removing the HMAC-MD5 checksum and the two bytes before it (its header). Remarkably, this allowed any config to be used on any ISP. Once again, every ISP around the world was vulnerable to OneStep. NOTE This hack worked because the developers of the firmware used in the ISPs' routers, which process the config files and CMTS checksums sent from the modems, had not thoroughly tested the finished code. The basic config file processing function in the firmware would process operation codes (opcodes) that were present in the config file, including the CmMic opcode, and carry out the associated actions. But it would not check to confirm that the CmMic opcode had actually been sent (or even that the config file had success- fully authenticated). This flaw was severe because the ISP operators could not directly fix it in their routers; the only ones who could do so were the third-party vendors who supplied the firmware for the CMTSs. It would be a long time before the individual systems could be patched.”
I pressed Ctrl+C, and got a root shell. From it, I ran the enrollment scripts I could find; it gave me sufficient access to pull from the corporate repo. So I took a ticket, found a related bug in the code, and created a patch fixing it on the first day, technically by cracking into a corporate laptop. (I had to wait for a properly completed enrollment to be able to push the code.)
Does the Keychain stay unlocked for a while? And do people actually do this?
Say you do software development with a platform engineering and cloud flavour on top, you might be using aws-vault to keep access keys and SSO session keys in a dedicated keychain rather than in plaintext in ~/.aws/. That keychain has an ACL that only allows aws-vault to access it, and has a self-lock timeout of a few minutes. This is great, because it is pretty secure, there is nothing to 'steal' (even from an unlocked machine) and it's still extremely convenient.
However. Say you do this with an external non-TouchID keyboard, when the STS timeout expires and you need to re-authenticate, you also need to unlock the keychain for a few seconds so aws-vault can either read out the SSO session tokens or the static secret for non-SSO usage, and it has to write back the new STS session.
During that window, the keychain unlock from such a keyboard means manual password entry, which in turn means that has to be in memory for a bit. Because a legacy keychain doesn't use data protection (but if you create a new one you do have that option) it's essentially just an AES encrypted file on disk. Because humans aren't likely to remember an AES key, it's derived and wrapped so you have some KDF that uses a user-selected password, which has to be in memory for a bit while the key is unwrapped/derived. The AES key itself has to stay in memory the entire duration of the unlocked state of the keychain, because without the AES key it can't read or write secrets.
Technically, the same happens to encrypted disk images (the AES ones at least, other types I'm not 100% sure). The DEK has to stay in memory while it is in use. It's why Apple started using systems like cryptexes and SSVs so the container disk is almost irrelevant from an integrity point of view. Before that, encrypted disks were an all-or-nothing approach.
Security is pretty difficult to get right, so many tradeoffs as well.
Top level = Keychain Access.app or the security CLI tool
Mid level = keychains (in flavours of files, core storage, data protection-enabled, and iCloud)
Item level = an entry inside a keychain
There is a sub-level as well, some software stores encoded data as a single item so when it's decrypted it's a bunch of different data, not a single secret, but technically the keychain system isn't aware of that anyway.
I'm not sure if this necessitates physical access.
“If a hint was set in Disk Utility when creating an APFS encrypted volume, the password was stored as the hint. This was addressed by clearing hint storage if the hint was the password, and by improving the logic for storing hints.”
Entitlement checks are not in the Mach layer of the kernel.
https://github.com/nmggithub/wts/commit/2bdce1c0c76c7adc360e...
Just a one word change, fixing a factual inaccuracy when talking about how XNU works.
This looks like a case of confused deputy problem: https://en.wikipedia.org/wiki/Confused_deputy_problem
A capability-based design should be able to systematically prevent this kind of problems.
I think Entitlements could be considered a type of capability? And if so, then you're right on your this point, as the solution was to require an entitlement to talk to the daemon itself.
Realistically what are the risks?
As far as risks are concerned: any app with the ability to get a send right to NetAuthAgent (pretty much any un-sandboxed app) can just silently as NetAuthAgent for any saved credentials for file drives (FTP, WebDAV, Samba, etc.), as well as chaining into a leak of all iCloud Contacts and Calendars (plus other stuff from iCloud). Sandboxing makes it difficult, but not impossible.
The risks are zero if you're up to date (and the patch was in October of last year, so you honestly should be up to date already). If you are not up to date for whatever reason and choose not to be, the risks are far more (unless you diligently check every single process that ever runs on your device).
Technically, this might actually increase the potential attack surface (due to more different components existing together). But more specialised surface would then allow for simplified control and as an effect better protection of that surface.
To be honest, any sort of locked down messaging system requires more (i.e. validation of sender, etc.) than just the transfer of messages. And that's just not something you would get with a low-level communication protocol like Mach (unless Apple overhauled the MIG compiler to add entitlement checks).
Mach is fantastic when paired with entitlement checks.