APFS
I just had the honor of presenting at one of my favorite BSides Conference BsidesNOLA on the State of the new Apple File System (APFS). Sadly, I didn't have the time to go through the demos but I have uploaded them to YouTube and the slides have been uploaded to my Github, as promised.
Mounting an APFS disk in MacOS using xmount
Mounting an APFS disk in SANS SIFT (Linux) using ewfmount
Enjoy! I hope ya'll find it useful!
There has been some confusion (myself included) on what is vulnerable to this bug and what isn't. Some folks can replicate and some cannot - so I think its high time to test this properly to see what versions and scenarios are affected by this bug.
The table below is sorted by macOS version - I'm just testing 10.13.x here. (If you happen to get it to leak the password on 10.12.x please let me know.) I'm also organizing by disk formatting scenario since I believe this is where most of the confusion comes from.
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.
If I am missing a certain scenario that you think should be added please let me know. If you disagree with the current findings - also let me know (I will also expect screenshots/videos from you to be sure we're on the same page.) I have tested 10.3.3 (host system) and 10.13.4 (VM) but would love someone to sanity check me - I've been wrong in the past!) I would have done more testing on different versions but have a limited set of systems as I'm traveling right now.
I will update the spreadsheet below as necessary.
YAY TEAMWORK!
At some point you just need to stop looking and be blissfully ignorant...this was not one of those days.
In and update to my previously updated blog article, I have found another instance where the plaintext password was written to system logs. This time I found it in more persistent log. This is actually a worse problem than the one I previously reported on.
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!
Twitter user @sirkkalap, was unable to re-create what I previously reported on. I finally got some time this afternoon to re-test. As it turns out, I was unable to re-create my results from 03/24. I assumed that at some point in the past few days a silent security update was pushed out. I went to my install.log file to investigate further. As far as updates go - the only thing that has potential to be the cause of the fix is a GateKeeper ConfigData update v138 (com.apple.pkg.GatekeeperConfigData.16U1432). I have not investigated if this was the true cause. I have not updated to 10.13.4 yet, this was on 10.13.3.
During this investigations I was VERY surprised to see the same diskmanagementd logs that I had found in the unified logs. Why are they logged in the software installation log at all, I have no clue. It makes absolutely no sense to me.
UPDATE: PLEASE HELP ME TEST
UPATE TO THE UPDATE: Similar log entries are now found in another system log that is more persistent, see the article here.
UPDATE: This is still vulnerable on current versions of macOS 10.13.3 when encrypted an ALREADY EXISTING unencrypted APFS volume (versus, creating a NEW volume in original article). Thanks to @moelassus for pointing this out and to @howardnoakley for verifying. My verification test is below. Note that it gets stored in on-disk, collected logs (non-volatile logs).
Original Article Below:
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. Screenshot below of my course disk image.
It may not be noticeable at first (apart from the highlighting I’ve added of course), but the text “frogger13” is the password I used on a newly created APFS formatted FileVault Encrypted USB drive with the volume name “SEKRET”. (The new class images have a WarGames theme, hence the shout-outs to classic video games!)
The newfs_apfs command can take a passphrase as a parameter using the mostly undocumented “-S” flag. It is not documented in the man page.
However when run without parameters, it will show it.
I tried to recreate this scenario on my current system running 10.13.3 but was unable to do so therefore I believe this bug has been addressed. I was however able to recreate it on a 10.13 system (the image screenshot above is from a 10.13.1 system.) I have not tried it on a 10.13.2 system as I do not have one easily available. I will update this blog if someone can test it for me. UPDATE: Thanks to @ranvel (screenshot) and @applechinfo (video) for testing, it has also been fixed in 10.13.2.
I haven’t done as much testing as I would like (I’m running up against a course update deadline after all!), but I did want to get this out immediate so it can be used for various investigations. I used the following steps to recreate this my 10.13 system.
Created a “clean” flash drive formatted “Mac OS Extended (Journaled)” using Disk Utility.app. (Quick testing shows other base formats should work similarly.) It is the Kingston DataTraveler drive labeled “Untitled” below.
Next I used the menu option “Erase” to create an Encrypted APFS volume on the drive, shown below named “SECRET_USB”. (In my testing it works the same if I go through the “Partition” options and do the same general process. The “Partition” method did error out, however it still appears to be an encrypted USB drive and the logs are the similar.)
Select “Erase” and wait until it has completed.
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! (For better or worse.)
If anyone else does further testing I would love to know the results! Send me a message on Twitter or through my contact page!
Recently there has been some questions on the forums and Twitter as to how to mount forensic disk images that were captured from Mac system that implemented 4k block sizes. A few years ago, Mac systems started to use 4k blocks instead of 512 byte block sizes. This has caused some issues where you need to mount the image to do analysis without a major forensic suite. BlackBag wrote a good blog article on this last month however I hope to expand on it just a bit to include E01 files and FileVault encryption scenarios.
I will also detail how to mount the forensic disk images using newer APFS file system so analysts can start to do their thing while all the forensic tools catch up! APFS disk images already appear to use 4k block sizes as the default, at least on all my test systems. If you see otherwise, please let me know!
This article will try to provide some options to mount these images, however it cannot solve all the issues or combinations of disks/block sizes/host operating systems – it seems that you will have to upgrade to 10.13 at some point to solve many of these problems.
The following steps will bring you from a full HFS+ FileVault 4k disk image in EWF format to a mounted image using macOS 10.13. (If you have a raw (non-EWF) image, you can bypass steps 1 and 3.)
$ sudo mkdir /Volumes/4k_image/
$ sudo mkdir /Volumes/4k_mounted/
$ sudo xmount --in ewf --out dmg 4k.E01 /Volumes/4k_image/
$ hdiutil attach –nomount –blocksize 4096 /Volumes/4k_image/4k.dmg
[Input Password in Prompt Window]
$ diskutil cs list
$ sudo mount_hfs –o rdonly,noexec,noowners /dev/disk# /Volumes/4k_mounted/
1. Create a mount point to put the xmount converted DMG image (converted from EWF format). [sudo is required when dealing with /Volumes/ since 10.12]
2. Create another mount point to put the mounted image on. This will act as the root volume for the mounted image.
3. Using xmount (sudo required) to convert from EWF (--in) to DMG (--out) format. DMG is selected here since it is very Mac friendly. Provide the E01 image (use E?? if using segments) and the converted image mount point created in Step 1. This could take a few seconds if the disk image is large. Theoretically you can use another mounting utility, I've tried ewfmount on 10.13 and ran into errors that I'm still investigating. Having trouble installing Xmount? Does it say OS X Fuse is not installed? Look in the comments section for a fix.
4. Using hdiutil, attach (but don’t yet mount) the DMG file created in Step 3. Using the hidden argument –blocksize we can specify 4096 (‘4k’ can also be used here). It is worth noting here that while hidden in 10.13 this option does not appear to exist in 10.12 versions of this utility. It is also is not detailed in the hdiutil man page. Gotta love hidden functionality! This will output a bunch of /dev/disk* options, however none of these are the ones you need thanks to CoreStorage.
5. If the image is FileVault encrypted a password window will appear, please put the password for the disk in here so it can be unlocked.
6. Next use ‘diskutil cs list’ to determine which disk to using in Step 7. Determine which volume you will be performing analysis on, in the screenshot above it is /dev/disk6.
7. Using mount_hfs (with sudo again) we can mount /dev/disk6 (the ‘#’ is just a variable used above, yours may be a different number) using a variety of options (you can choose your own, however I normally use read only, ignore ownership, and limit binary execution options. Also provide it the second mount point you created in Step 2.
If it all works out, congrats you now have a mounted image!
A similar approach can be used for new APFS disk images. Anyone who has tried to capture their disk images in 10.13 might have had a problem doing so due to System Integrity Protection (SIP). SIP is now protecting /dev and will likely make forensic acquisition and analysis more difficult if you happen to interact with /dev often. Easy fix – disable SIP. While not technically good for security purposes, it can be a general pain in the posterior to have on. To disable it, reboot into Recovery mode, open the Terminal and type ‘csrutil disable’ and restart the system. Yes, you can re-enable it later with ‘csrutil enable’.
Because it is so similar to the process above, my description of each step here will be limited. In Step 4 we do not need to use –blocksize as it just happens to work without it. In Step 5, instead of ‘diskutil cs list’ we use ‘diskutil ap list’ – APFS does not use CoreStorage (cs) and instead uses APFS containerization (ap). The ‘ap’ will also be used in Step 6. Step 7 uses mount_apfs instead of mount_hfs for obvious reasons and would be used on /dev/disk6s1 as shown in the example screenshot below.
https://www.blackbagtech.com/blog/2017/10/05/apple-file-system-apfs-mac-forensic-imaging-analysis/
A big thanks to Ed and a “little birdy” for sanity checks and help!
