Well written article. It reminds me of the zero day that Apple tried to cover up somewhat - the "empty password tried twice" root login bypass. This was ca. 2017 or so, maybe 2018.
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.
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.
I feel like that (innocence about security) might be a bit of the reason why this vulnerability existed in the first place. I'm sure the NetAuthAgent code is very old, and was probably written at a time before even Apple was serious about security. And what really can you add new to a web server client? I wouldn't be surprised if the entitlement check is the first thing they've added to it in years.
> 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.
> I understand the technical reasons for that, but it is technically supported by the spec and other clients work with it just fine.
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.
I would've guessed that once it's established that the bug is caused by the app injecting the specified username into the USERINFO portion of a URL without the necessary percent-encoding, a workaround (other than using a different client) would be to manually percent-encode the username, i.e., replace the "@" with "%40" ... although this wouldn't work if the app actually did percent-encode an entered "%" despite not encoding an entered "@"!
Back in the day, on my first day in a huge corporation famous for its refined engineering culture, I was issued a laptop that had some installation program running, to create a user for me, enroll on the corp network, etc. It had a bug, which made it run certain actions in an infinite loop.
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.)
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`.
I remember the first time I encountered a Windows machine you had to log in to to use (1996). At my first job, I had write access to all the system directories on the corporate VAX machine. I could have easily taken down a major corporation through a careless mistake (but fortunately, never did).
I remember using Novell netware in high school and if you random long lengths of passwords you could get the machine to crash. Didn't have any idea what was going on at the time.
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.
back in the 80s I got into a DEC system by doing roughly the same thing to an application running on VMS. basically you when it interrogated the terminal you could overflow it and drop into the command line.
“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.”
> It reminds me of the zero day that Apple tried to cover up somewhat - the "empty password tried twice" root login bypass. This was ca. 2017 or so, maybe 2018.
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
Aside: >1000 comments in 2017 is significant. Is there a straightforward way to list such highly-engaged HN submissions? Ideally sorted by prominence within a short (1yr is fine) time window, but a simpler sort (no regard for prominence, just absolute engagement, which would strongly tilt the results toward the present, due to platform growth) would also be ok.
> Interesting to see the port system mentioned - it's not a well known fact of Mach kernels.
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.
Maybe OP is referring to the fact that there is a Mach kernel underneath. Most developers I guess would like to write CLI apps that are portable to Linux and macOS, so they only use the POSIX side of the API. These don't need to know about ports. And if developers are writing Mac-specific software, Core Foundation is probably the lowest practical level they will go with.
Yes, that's what I meant. I'm making a kernel that uses ports not dissimilar to Mach's and I get asked if there are other modern kernels that do the same thing from time to time. Everyone I've talked to has been surprised to hear it has them.
Yeah, if you're writing user-facing apps, writing against Mach wouldn't be smart. But if you're a vulnerability researcher on the other hand... it's a neat trick and might just help you find a CVE! (even though most stuff has moved to XPC now and you could just used the public XPC API's there)
“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.”
That's nothing. You used to be able to grep any user's FileVault password from the page file for many years. It was a simple one-liner and worked 100% of the time.
TBH this is still possible in some scenarios, mostly when someone isn't using data protection and manually unlocked a local Keychain. It's pretty much the same as dumping LSASS memory on Windows when IOMMU isn't used, and in some cases even when IOMMU is used.
Yeah so it really depends on the local setup. Here's a wall of text if you're interested:
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.
Yeah, it's a bit overloaded. There are keychains (.keychain files) and keychain items (secrets inside of them). The keychains are visible in the Keychain Access app, but also available in the 'security' command line. And then there are modern keychains, those are more like SQLite databases and those can have anything from SQLCrypt type of management to Secure Enclave DEKs.
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.
A filevault password is useless unless you have root/physical access. If it's mounted by the system, then filesystem ACLs will still be in effect. Otherwise you need root to read raw block devices.
A very detailed article. Love the history of all the kernels too. My only minor gripe is that since it's about a serious security issue, I would like a very brief explanation in the beginning, like what is the impact, the requirements for the attack, is it a logic error or memory corruption etc. Very brief, only long enough to know if I want to read the rest of the article or not :)
Thanks for the feedback! I was burying the lede a bit on purpose to entice the reader to read more, but I also completely understand your perspective as well.
> if a process were to expose a mechanism for other processes to essentially proxy keychain queries through it, that can undermine the security of the whole system.
> 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.
The PoC code should work. You just need to install Kass as a dependency. If you have done that, are there any other issues you are facing?
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).
Well, it took 8 hours, but this post is now no longer top 5 on the front page (it's #27 now for me, so still front page, just the bottom). Thank you everyone for your comments!
At this point it feels like Mach is a reliable source of bugs in macOS. I know Apple is working hard to lock it all down, but is there any path to shifting away from Mach completely?
I would argue that Mach was not the source of the bug here, but rather it was the lack of an entitlement check. Entitlements are honestly a very good security system, but they are opt-in. If a daemon doesn't check entitlements, then its insecure. Don't blame the messaging mechanism, blame the way it is used.
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.
Yes, there was a post recently about moving more and more parts out of Mach. Some of it to L4, some of it to user space.
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.
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.
reply