High Sierra Stored APFS Volume Passwords in Log Files
I’ve been updating my course (Mac and iOS Forensics and Incident Response) to use new APFS disk images (APFS FTW!) and came across something that both incredibly useful from a forensics perspective but utterly horrifying from a security standpoint.
[…]
I used the following command to watch my unified logs in the Terminal while the process above was doing its thing:
log stream --info --predicate 'eventMessage contains "newfs_"'…and there we have it, a plaintext password!
It’s fixed in macOS 10.13.2 [Update (2018-03-25): Actually not; see below.], but I wonder how many passwords are still stored in logs somewhere, e.g. in sysdiagnoses uploaded to Radar. Also, judging from the usage message for newfs_apfs, it looks like the fix may have been simply to suppress this particular log message. It still takes the passphrase as a command-line argument, so it might still be exposed in other ways, rather than using the more secure -stdinpass method that hdiutil uses.
If you:
- encrypted an APFS volume using macOS 10.13 to 10.13.1 using Disk Utility, and
- have a copy of the unified log collected at the time of that encryption, in a logarchive
chances are, that logarchive will contain the passphrase recorded in plain text. You therefore might like to destroy or encrypt that logarchive.
[…]
I am not aware that Apple has issued any warning of this potential security breach. Given that the bug appears to have been recognised and fixed, that seems more than a little remiss.
Previously: Encrypted APFS Volume’s Password Exposed as Hint, High Sierra Bug Allows Root Access With Blank Password, App Store System Preferences Can Be Unlocked With Any Password.
Update (2018-03-25): Moe Lassus:
Reproducible on 10.13.3.
Thanks to @moelassus, who reported seeing this bug persist in 10.13.3, and Sarah Edwards, we have established that this is a 100% reproducible bug in 10.13.3. It does not, any longer, affect the creation of new encrypted APFS volumes, but occurs when an existing unencrypted APFS volume is encrypted, by erasing just that volume in Disk Utility.
[…]
When Apple ‘fixed’ the original bug, which occurred when creating a new encrypted APFS volume, it clearly did so by accident, and was unaware that the change that was made to the volume creation step blocked the entry of the plaintext password in the log. Consequently, another instance in which an almost identical call was made by
diskmanagementd, tonewfs_apfsto make an existing volume encrypted, was left in the code. It is that call which is currently appearing in the log.
Previously: Sierra Log Littering.
Update (2018-03-30): Sarah Edwards (Hacker News):
The previous examples were found in the unified logs which can hang around for a few weeks, this new example stores the exact same information in the system’s /var/log/install.log. I have found that the install.log will only get wiped out upon major re-installation (ie: 10.11 -> 10.12 -> 10.13), therefore these plaintext passwords will hang around for quite a bit longer than a few weeks! I had entries dating back to when I originally installed High Sierra on this system back in November of 2017!
Update (2018-03-31): Howard Oakley:
Although 10.13.4 fixes this leak, it still only does part of the job. It doesn’t roll the install.log to remove all those old plaintext passphrases, which remain in the log for all to see. What is worse, to my mind, is that it doesn’t stop diskmanagementd and associated processes from writing to install.log.
Update (2018-04-01): Howard Oakley:
When Apple introduced its new unified log in macOS Sierra, almost every other system log went silent (other than in residual entries by legacy products), apart from install.log. Why that was spared has never been explained by Apple, which suggests that it wasn’t part of its plan. This has now proved helpful in many situations, as sysadmins and others can still examine installation and update problems without having to do battle with thousands of other entries in the unified log.
[…]
One potentially good reason for continuing to write to a traditional log as well as the new unified log is the weakness of Apple’s tools – then and now – for accessing the unified log. Console still lacks any ability to browse history in the unified log, except when the live log is converted into a logarchive, and even then it is hard to use. install.log remains far more convenient to examine, and the engineers working on those parts of macOS which have been writing to it have probably been very grateful that they were not forced to work with the unified log alone.
[…]
Returning to the accident chain behind this, I can see the following links[…]
APFS encrypted volumes can be created on the disk level as well as the volume level and it truly seems to make a difference. Please also test if you find (or don’t find) the results in the Unified logs and/or the install.log or neither (and god forbid any other locations you might come across!). I’m also consistently using the “Erase” button versus the “Partition” button.
Update (2018-05-11): See also: Paul Ducklin.
7 Comments RSS · Twitter
Streaming logs shows private data that is never actually stored in the log archives on disk. Has it been confirmed that the password is actually archived? Or is it strictly only available when streaming the logs?
@Kevin I have not seen anyone confirm that. However, my understanding is that the log entries that are (by default) not actually stored to disk are the ones with the lower types. The screenshot from Edwards shows these as the highest type (Fault), so I think they would be persisted.
These are not streaming logs from Console (not in my case, at least), but taken from Consolation, which calls log show.
As Michael points out, they are Fault level, so according to Apple's rules are invariably saved to disk.
The original report from Sarah Edwards was actually found when searching an old logarchive.
Howard.
I wasn't disputing whether the log line was saved to disk, I was disputing whether the password in the log line was saved to disk. The way the new logging stuff works is arguments to a log format string can be marked either private or public, and non-constant string arguments are private by default. Private arguments show up when streaming live logs, but are redacted when saving to disk.
That said, I do see log show in the screenshots, which indicates it is being saved to disk.
[…] Previously: macOS 10.13 High Sierra Released, Hello HEIF, High Sierra Stored APFS Volume Passwords in Log Files. […]
