macos

New Presentation from Objective by the Sea 2.0 - Watching the Watchers

in , ,

Just got back from a wonderful time hanging out with the who’s who of Mac security folk in swanky Monaco at the Objective by the Sea conference. I’ve uploaded my presentation Watching the Watchers in my Resources section. This presentation goes through some of the forensically useful artifacts of the following 3rd party monitoring software:

Direct link to the presentation here.

I cannot recommend enough that the OBTS conference is absolutely worth going to if you are at all involved in Apple Security. Next one is ~Q1 2020 and back in Maui!

Uh Oh! Unified Logs in High Sierra (10.13) Show Plaintext Password for APFS Encrypted External Volumes via Disk Utility.app

in

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!