logs

AirDrop Analysis of the UDP (Unsolicited Dick Pic)

I saw this article “NYC plans to make AirDropping dick pics a crime” on Friday and it got me thinking. What exactly are the cops going to find if they do an analysis of a device, either the sender or the receiver? 

I’ve already done my fair share of analysis when it comes to the Continuity technology with Apple devices with Heather Mahalik at the SANS DFIR Summit in 2017. This article gave me a good reason to do a revisit on how AirDrop artifacts between mobile devices.

Testing Scenario

I’m using the scenario of sending of dick pics in the middle of Times Square as an example. I have two test phones, an iPhone 7 and an iPhone 6. The iPhone 7 belongs to “David Lightman” and the iPhone 6 belongs to “Jen Mack”.  Each device is on iOS 11 for this test. Instead of UDPs, Jen is going to be sending David USP’s instead, or Unsolicited Squirrel Pics – I suppose I need to keep this family friendly right?

AirDrop works over ad-hoc Peer-to-Peer networking over Bluetooth and Wi-Fi. When a user attempts to AirDrop someone a file it will determine who is within range and who is currently receiving AirDrop connections. This may be set to Contacts Only or Everyone (or Receiving Off for those who don’t want UDP’s, smart choice). Poor David has the setting to Everyone, he’ll get some surprises!

To send the squirrel photo to David, Jen used the native Photos application’s sharing feature to select a device to AirDrop the USP to. The only device within range that has AirDrop turned on and in a receiving mode is David Lightman’s iPhone.

Jen selects his phone and sends the picture. On David’s device he receives a pop-up, he can choose to Decline or Accept. 

AirDrop ID

Important to this analysis is an AirDrop ID. On devices this can be found in /private/var/mobile/Library/Preferences/com.apple.sharingd.plist. The keyword ‘sharingd’ is very important in this scenario as much of the Continuity artifacts can be found by searching for that process name. This plist file should be available in an iTunes backup and from any commercial forensic utility. 

Jen’s AirDrop ID is 3DAA769F9F23.

David’s AirDrop ID is E7D713098E3B, also take note of that the DiscoverableMode is set to Everyone. (Jen does not have this key, hers was set Contacts only.)

Artifacts from the Receiver’s (David Lightman) Device

Assuming that the receiver is the individual who would likely make the complaint to the cops, we will look at this iPhone first to determine what artifacts will persist and if they are show attribution to a certain device and/or owner.

Very few artifacts on the devices will actually show this connection happening. Let’s take a look at some of the main artifacts that I would explore if I had the case.

Unified Logs  

Logs can show lots of data and in great verbose detail. Unfortunately, these Unified Logs do not get backed up on iOS devices. The only way to extract them from the device is to get a physical file dump of the device (Jailbreak/Cellebrite CAS/GrayKey). (UPDATE: 12/04/18 - It has come to my attention from a commentor that these unified log files can be collected using the sysdiagnose process on iOS devices. I’ve tested this and they are in fact there. Funny enough, per Apple Documentation, it wants you to copy this archive off the device using AirDrop. 🤷🏻‍♀️ Not entirely the most forensically sound method but hey, data is data - get it with whatever means your legal team will allow. Thanks ‘G’!)

In this example on David’s iPhone, you can see the sharingd process start to scan, attempting to find peers (Continuity connections). During this process you will also see lots of wirelessproxd and bluetoothd activity as well since AirDrop uses Bluetooth and Wi-Fi services. You will also see references to AWDL or Apple Wireless Direct Link.

Follow the logs down a bit and you’ll start to run into some potentially identifying information. We are now starting to see records containing Jen’s device name “Jen Mack’s iPhone”. Pay close attention to the first record highlighted and you’ll see what looks like a MAC address, however it is neither the Bluetooth nor the Wi-Fi addresses. This address is generated different every time a connection is made, therefore not an ideal data point for attribution. 

Going back to the device’s name. This may lead you in the right direction, however anyone can name their device anything they want. I can call my iPhone X “Samsung S9” for instance, no identifying information and frankly a device that doesn’t even do AirDrop.

The next couple of highlighted sections (in red), show the start of the AirDrop connection. We can see an incoming request and start seeing records that include the AirDrop ID of Jen’s iPhone, 3DAA769F9F23. This is where I think attribution may be possible. This ID seems consistent across connections and different devices in my experience. It may be possible to tie this to an Apple ID or specific device. I have yet to find this connection however – it’s not part of the Serial, UDID, or various MAC addresses that I can tell. More research is needed here.

Next, in purple, is more metadata about the file transfer to include transfer status, media type, originating device name, source application, and associated transfer GUID.

In between these metadata records, it shows that it is transferring a file to /var/mobile/Downloads/com.apple.AirDrop/BA40D8CF-54E6-4B09-8F2F-717FB638174E/Files. Whether the user chooses Accept or Decline, the photo still gets transferred to the device.

Finally, the user receives an alert about the AirDrop’ed photo. Following this record is more details on how the user is alerted to the connection audibly and physically with alert tones and vibrations.

This particular AirDrop connect was “Declined” by David. This can be seen in the records below where the ‘selectedAction’ now shows Decline and a clean-up process has started. Highlighted in teal is the AirDrop connection closing.

If the user Accepted the AirDrop’ed photo, the logs would look like the following. The file would have been ‘accepted’ in the metadata records. Finally, since it is a photo – the default application Photos wants to import it into its files and databases. The AirDrop connection is also closed at this time.

Photos Database

Since the photo gets transferred into the user’s Photos database we can look there for hints. This is one file that does get backed up by iTunes and commercial forensic utilities. The Photos database is located /private/var/mobile/Media/PhotoData/Photos.sqlite on the physical device. 

The filename on Jen’s device was IMG_0007.JPG before it got renamed to IMG_0110.JPG on David’s phone. The original filename can be found in the ZADDITIONALASSETATTRIBUTES table in the ZORIGINALFILENAME column.

It is worth noting that the imported photo will carry the same EXIF data as the original on Jen’s device, in fact it is exactly the same photo (hashes should match). The file size and some timestamps get carried over into the Photos database. Other metadata items can be used to determine a photo from another device are the Height/Width, assuming it is from a different family of devices the pixels may be different.

In the ZGENERICASSET table, we have the same Height/Width, however some timestamps are updated to match the time of import via AirDrop. The ZDATECREATED timestamp matches the original creation of the photo. The ZCLOUDASSETGUID matches the GUID seen in the last few entries in the logs above. There does not appear to be any attribution data in this database.

Artifacts from the Sender’s (Jen Mack) Device

In the rare event that the Sender’s device was acquired, the related artifacts are below.

Unified Logs

Much of the logs look similar to the receiver. The sample below shows the sharingd process connecting to David’s AirDrop ID, E7D713098E3B and shows his iPhone device name. Again, the MAC address does not appear to be consistent and will change on every connection.

A few more lines down we can see some file conversion for the photo, IMG_0007.JPG (which apparently wasn’t needed). This is followed by an AirDrop transaction with the AirDrop ID of David’s iPhone.

Conclusion

The lack of attribution artifacts at this time (additional research pending) is going to make it very difficult to attribute AirDrop misuse. At best, if the cops are provided each device, they can pair the connections up – however this will require access to file system dumping services like Cellebrite CAS, GrayKey from GrayShift or performing a jailbreak to get the most accurate analysis. If the devices are named appropriately (ie: If Jen Mack’s iPhone was actually named ‘Jen Mack’s iPhone’) this may make an analysis easy, however I can see an instance where this can be abused to imitate someone else.

Curious about the USP, here you go. This was an advertisement in the DC Metro system, that for some reason whenever I saw it I giggled. 🤷🏻‍♀️

Ok Internet, Lets Test this APFS Plaintext Password Bug Properly

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.

For previous related blogs see here and here.

YAY TEAMWORK!

pay attention to me cat GIF-source.gif

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

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!

Pincodes, Passcodes, & TouchID on iOS - An Introduction to the Aggregate Dictionary Database (ADDataStore.sqlite)

Have you ever wondered how Apple can put out statistics such as “The average iPhone is unlocked 80 times a day”? How the heck do they know?

Now I do not know for sure that they use this database, however I'd consider putting some cash down on this bet. The Aggregate Dictionary database aggregates (hence the name) certain features of the iOS operation system.

This database is located on the physical device in the path below, and it is not backed up in iTunes/iCloud backups.

  • /private/var/mobile/Library/AggregateDictionary/ADDataStore.sqlitedb

It is worth mentioning here, the ‘dbbuffer’ plaintext file) in this same directory – is exactly what the filename suggests, a buffer for the database. Worth looking at for entries not yet written into the main database.

The ADDataStore.sqlitedb aggregates data on a 7-day per-day basis (first day in, first day out). You will generally see the last weeks worth of data. The day is stored in the column ‘daysSince1970’ which can be converted to human-readable time by using the SQL date function as shown below. It is worth noting this data is being stored in UTC.

I’ve known about this database for a while but have not had the chance to really dig into it. Recently, a reader emailed me about a case they were working on and wanted to know if the passcode was turned on or off on a specific day. Luckily this investigator had a physical acquisition to analyze and the specific day was in the last week of when the acquisition was created. The physical acquisition has many more of these logging databases are available for analysis too! - Want to see more about these awesome databases, check out my iOS of Sauron presentation.

The ADDataStore.sqlite database stores all sorts of seemingly odd settings in the ‘key’ column of the ‘Scalers’ table. The key that I was interested for this readers inquiry was the ‘com.apple.passcode.PasscodeType’ key which stores the passcode type. The ‘value’ column stores a numerical representation of the passcode type last used during each day (UTC time). If the user changes their passcode type throughout the day, it will store the last one configured.

I have enumerated the following passcode types. The example device show above used the 6-Digit passcode, then recently switched to a Custom Numeric passcode.

  • -1 = 6-Digit
  • 0 = No Passcode
  • 1 = 4-Digit
  • 2 = Custom Alphanumeric
  • 3 = Custom Numeric

We can take a look at how many times the device was unlocked successfully or unsuccessfully by using the keys ‘com.apple.passcode.NumPasscodeEntered’ and ‘com.apple.passcode.NumPasscodeFailed’, respectively. The user was mostly successful inputting their passcode, but put the wrong passcode in once (highlighted in pink).

Hrm. Those values look small – the user is probably using TouchID instead of manually entering their passcode. TouchID allows users to enroll up to five fingers to unlock their devices. Note: They still need a passcode to do this, but it allows the user to have a more complex passcode because they can use their enrolled fingerprints to unlock the device for convenience and general usability

Looking at the ‘com.apple.fingerprintMain.templateCount’ key we can determine how many finger “templates” have been enrolled. The example tells us that four fingerprints were enrolled.

By default the enrolled fingers are named ‘Finger 1’, ‘Finger 2’, and so on as shown below. (Nerd Note: When you are in this screen as a user of the device you can check if a finger is enrolled because it will be highlighted in gray as shown - well, I thought it was neat.).

*** WARNING - RESEARCH BELOW IS ONGOING - READ AT YOUR OWN RISK ***

...just kidding...its actually kinda interesting.

I did want to show the complexity of this database therefore I decided to post this as some readers might find it interesting, however don't take my word on this - I can be wrong. In encourage everyone to do their own testing!

This is where it becomes less clear and more research will need to be done. In the Scaler table at any given moment there are many entries that contain the keyword “fingerprint” for all sorts data. I've listed some of the more interesting keys below.

  • com.apple.fingerprintMain.enabled – Binary value – 1 = Enabled, 0 = Not enabled
  • com.apple.fingerprint.countimagesForProcessing – This appears to be the number of times that TouchID was used (whether or not it was used to unlock the device).
  • com.apple.fingerprint.match.autonomousAttempts & com.apple.fingerprint.match.attempts - Match attempts (Not entirely sure the difference as of yet – I think one may be for unlocks (autonomous) and others for other TouchID functions.)
  • com.apple.fingerprint.unlock.touchesTouchIDNotAllowed – How many times a TouchID was attempted but not allowed for some reason, perhaps fingers were the wrong ones or greasy from a hamburger! (c’mon, we’ve all been there)
  • com.apple.fingerprint.unlock.bioLockouts – I found this key to be incremented when I attempted to unlock the device with the wrong finger too many times.
  • com.apple.fingerprint.unlock.passcodeUnlocksNonMandatory – The user put in the passcode, however they were not required to do so.

Enrolling Fingerprints

  • com.apple.fingerprint.enroll.attempts – Fingerprints “enrolled”
  • com.apple.fingerprint.enroll.popup.tooLittleMoves – Apparently I didn’t move my finger enough when enrolling. 

TouchID Passes – Various keys that I’ve seen that show the specifics of how a TouchID match was passed. Many of these are hard to test to explain.

  • com.apple.fingerprint.match.autonomousPassesAfterHomeButton – Incremented when a match was made after the home button was pressed.
  • com.apple.fingerprint.match.autonomousPassesAfterPowerButton – Incremented after boot when TouchID was used (after passcode of course).
  • com.apple.fingerprint.match.autonomousPassesButtonDown – Incremented after the home button was pressed or “pressed” if you have an solid state button.
  • com.apple.fingerprint.match.autonomousPassesButtonLifting
  • com.apple.fingerprint.match.autonomousPassesButtonUp
  • com.apple.fingerprint.match.autonomousPassesButtonUpWithPressureMitigation
  • com.apple.fingerprint.match.autonomousPassesHumid – I assume this one has to do if you are a live body or not.
  • com.apple.fingerprint.match.passesButtonDown
  • com.apple.fingerprint.match.passesButtonUp

TouchID Fails – On the flip side, if a fingerprint fails – we have many keys with many reasons, many with the same characteristics as above but failed.

  • com.apple.fingerprint.match.autonomousFailsBadImageBadBlocks
  • com.apple.fingerprint.match.autonomousFailsCancels
  • com.apple.fingerprint.match.autonomousFailsFingerOffAfterHomeButton
  • com.apple.fingerprint.match.autonomousFailsNoMatchAfterHomeButton
  • com.apple.fingerprint.match.autonomousFailsNoMatchAfterPowerButton
  • com.apple.fingerprint.match.autonomousFailsNoMatchButtonDown
  • com.apple.fingerprint.match.autonomousFailsNoMatchButtonLifting
  • com.apple.fingerprint.match.autonomousFailsNoMatchButtonUp
  • com.apple.fingerprint.match.autonomousFailsNoMatchButtonUpWithPressureMitigation
  • com.apple.fingerprint.match.autonomousFailsNoMatchHumid – I guess I might have been a bit under the weather? ;)
  • com.apple.fingerprint.match.failsNoMatchButtonUp
  • com.apple.fingerprint.match.failsNoMatchHumid

Getting specific, TouchID unlocks appear to be recorded in the ‘com.apple.fingerprintMain.unlock.unlocksByFinger*’ keys.

As far as as I can tell the keys containing “unlocksByFinger” (colored below in yellow) contain the actual number of unlocks, however in the example below the total unlocks were 11, not 22. I am not sure why there are two entries – I’m sure they record different items, however I cannot find documentation to sort out each one. I would rely on the ‘com.apple.fingerprintMain.unlock.unlocksByFinger#Fail’ entries. (As an aside, it’s worth noting that if you get ‘Finger2’ entries, they have an ‘s’ appended ie: com.apple.fingerprintMain.unlock.unlocksByFinger2Fails, maybe a strange type in the code?)

The ‘fail’ in the key would seem to suggest it records “failed” attempts however my testing shows these are in the green highlighted ‘unlocksCanceled’ entries instead.

What’s the ‘QT’ stand for? I have no idea. I tried looking through Apple documentation to find out, but I’ve got nothin’. Suggestions are welcome!

You might think, “Hey, I see Finger 0, Finger 1 in there – that must be the unlocks for each enrolled fingerprint right?”. That’s what I thought, however that was not the case in my testing. In my tests no matter which finger I unlocked the phone with it would be added to the ‘Finger0’ count.

Another key that looks interesting and related are the ‘com.apple.fingerprint.sortedTemplateMatchCount#’ keys. I would have thought these would be equal to the number of times the fingerprint template was used, however it appears that is not the case. I can try two different fingers (each enrolled) and sometimes they show up under the expected number (ie: finger 1 = com.apple.fingerprint.sortedTemplateMatchCount1) and sometimes it won’t – however one of them will increment. Not sure what is going on here.

In conclusion - I’ve only barely touched one of the tables in this database. There is so much data in this database! There is also the ‘DistributionKeys’ and ‘DistributionValues’ tables which store more numerical-based stats versus the incremental/binary stats of the 'Scaler' table. Try the following SQL query on your own and see what you find!

select 
DistributionKeys.key,
date(DistributionKeys.daysSince1970*86400,'unixepoch','localtime') as daysSince1970,
DistributionValues.secondsInDayOffset,
DistributionValues.value
from DistributionKeys
left join DistributionValues on DistributionKeys.rowid = DistributionValues.distributionID
whereDistributionKeys.key like '%unlock%'

I will hopefully be putting out a few more blog entries on other data found in this database (and other databases!). I will of course post updates to this research if and when I get the chance to do it! Stay tuned!