Apple’s (Not Quite) Secure Notes
By: Sarah Edwards, Senior Digital Forensics Researcher
While I was researching the Apple Notes application on macOS and iOS, I came across a peculiar scenarios where “secure” notes were partially and temporarily unsecure. This provides forensic analysts the opportunity to peek into these notes to potentially gather more information about the contents of them, which can potentially benefit your investigations. These examples are from macOS 10.15.3 and iOS 13.3.
Let’s walk through what these “secure” notes look like and how using BlackLight, we can attempt to recover some of these hidden leaked secrets.
Each note always starts off in a normal non-secured state. A user has to explicitly select a note to be locked or secure. In the example below I created one new note with the Title “I have a secret to tell you…” The content of this note is “The sky is blue. The ocean is wet.”
Currently this note is in an unsecured state in the database.
To make this a “secure” note a user needs to go the Lock Note icon or use the item in the File menu.
If this is the first secure note, the user would be presented with this password screen where they can create a password and a password hint. My password is quite literally “password” as my password hint suggests. Certainly, this password and hint are not generally recommended but would make my job as an investigator much easier and I appreciate that!
Once notes are locked they can be unlocked for a short period of time or until the user chooses to “Close All Locked Notes”.
Once notes are locked, the user will be presented with a screen to unlock the note either by password or if the device hardware supports it, Touch ID (macOS/iOS) and Face ID (iOS).
The NoteStore.sqlite database is located ~/Library/Group Containers/group.com.apple.notes/ on macOS 10.15 and /private/var/mobile/Containers/Shared/AppGroup/<GUID>/ on iOS 13.
The process above creates two entries in this database. [Note: This is a partial extraction of a few columns and a few tables joined within this database.]
Z_PK = 5 is the initial non-secured note created while Z_PK = 6 is the “secured” version of this note.
The ZTITLE1 column (renamed NOTE TITLE) shows the title of the note, “I have a secret to tell you…”. This content is not expected to be secured.
The ZPROTECTED column keeps track of secure and non-secure notes. A value of 0 is not secure while 1 is secure. Also take note of the ZMARKEDFORDELETION column, the previous unsecured note is marked to be deleted with a value of 1. Secure notes also have contents in the ZCRYPTOINITIALIZATIONVECTOR specific field shown (only one crypto related field is shown for brevity).
The content of the note is stored in a protobuf structure inside of a gzip archive in the ZDATA column. In this case, the contents have been cleared of anything sensitive and moved to the ZDATA contents of the secured note which is encrypted. This is expected, standard practice is to move the data to an encrypted location and remove the sensitive information from the previous unencrypted area.
However, the ZSNIPPET column show the partial unencrypted content of this note. This is where potentially sensitive information from the note could be extracted. While I cannot see the full contents of the secure note, I can see the snippet or the first line of the note! I am unable see “The ocean is wet.” in this field.
Now what happens when I have a note that has media attachments like map locations and photos? I created another note that shared the location “Bletchley Park” from the Maps application with the Notes application. I then added a photo of Alan Turing’s statue at the museum.
Next I locked the note by providing the same password as above.
Reviewing this version of the database shows quite a few more entries!
Z_PK 8-21 is the unsecured version of this note while Z_PK 22-41 is the secured version. I have drawn a red line in between the unsecured and secure entries in the database output screenshots shown below.
This output may appear a bit disjointed. The Notes database keeps everything as an object with specific metadata for each object, I have substituted text for these object types under the OBJECT TYPE column.
Each note will have a NOTE entry. If an attachment is brought into the note an ATTACHMENT METADATA entry is created, there are two for this note – one for the map and one for the photo. Since a file was attached, the photo, there is also a FILE object. Attachments may have associated thumbnails which get the object type ATTACHMENT THUMBNAILS.
All these objects are tied together through primary keys or Z_PK values. For example, NOTE (Z_PK=17) has two ATTACHMENT METADATA entries (Z_PK=8 & 19). The FILE entry for the photo is (Z_PK=18). The other entries are the attachment thumbnails. Each of these objects may have metadata associated with them.
I want to point out that this particular time the ZSNIPPET entry was not kept but removed as it should have been. The original ZDATA BLOB value has also been emptied of sensitive data. All previous entries have also been marked for deletion, but when exactly do they get removed? I promise we will get there!
The first metadata we will take a look at is the location data. The map has embedded location data located in the database (ZLATITUDE, ZLONGITUDE, AND ZPLACEMARKDATA). These contain the coordinates to Bletchley Park. The ZPLACEMARKDATA contains a NSKeyedArchiver binary plist which holds more specific location data, some of which is shown here.
From the original unsecured note, the coordinates were kept however the contents of the ZPLACEMARKDATA column were removed for the secured version of the note.
Now let’s look at the file metadata for these entries. Starting with the FILE entries, we get the filename of the photo if the unsecured note entry sticks around, in this case IMG_0060.HEIC for the photo of the Alan Turning statue. It was removed in the secured entry.
For the ATTACHMENT METADATA entries, we get a few items. Height and width of the image (for the photo, not the map) while the thumbnails also get their height and width recorded for photo and map data.
ZSUMMARY for the photo contains a suggestion of the contents of the photo. The photos are analyzed for objects and text and recorded in this field. This appears to be removed in the secured version of the note. This cell includes the text below. Note: There is a plaque below the statue which is not shown in the screenshots above.
The field ZTITLE contains the titles of the map item and an attempt at the contents of the photo – Han Turing. These do not appear in the secure version of the note.
The field ZTYPEUTI contains the type of attachment. A URL for the map item and a HEIC file type for the photo. These are the kept in the secure version.
The ZURLSTRING contains an Apple Maps link to the map item, Bletchley Park. This does not get recorded in the secure version.
Finally, ZFILESIZE contains the size in bytes of the attached file. We get a value of 0 for the map item because there is no file attached. This does appear to be saved in both the secure and unsecure versions of the note.
Files attached to notes are saved outside of the database in the /Accounts/LocalAccount/Media/ directory. Media can be tied to a database entry by the GUID that represents it in the ZIDENTIFIER column.
A normal unsecured note would show the file attachments in this area. One that was unsecured and is now secured gets zeroed out and a new encrypted version of the note created.
The thumbnails also appear to be blank and new encrypted versions created. In my testing, every once in a while, I do see a thumbnail persist so it may still be worthwhile to look!
I mentioned previously about the ZMARKEDFORDELETION column. When do these entries get deleted? Turns out, a few different ways!
- Upon exiting Notes on macOS
- Upon closing the Notes window on macOS
- Upon swiping up (to go to the home screen) on iOS. Switching to another app does not necessarily delete the entries.
From a live response perspective, if the Notes application is open it is best to capture the database in a live state to preserve these entries before they are deleted, especially if you are aware that the user may be using secure notes. On iOS this is going to be more difficult due to how mobile devices are used.
A sample of our previous database showing many less secrets! The attachments have been cleaned up as well.
However, this doesn’t mean the deleted database entries have been securely cleaned up. Running ‘strings’ on the database files I can still see strings associated with the map item, the photo recognition data, and the “The sky is blue” snippet! The unsecured “secure” data is still there!
Using BlackLight we can attempt to recover some of these hidden leaked secrets using the SQLite Preview pane and investigating the recovered database entries. These entries appear in red italicized text.
Due to the nature of how Apple Secure Notes work, it is possible for forensic analysts to acquire information, even if it is currently encrypted. The examples above illustrate that we can potentially get unencrypted content, file metadata, and location information from Apple Secure Notes. As Apple Notes continues to add capabilities and features, even more information may be recoverable.
To learn more BlackLight, see our latest features and additional enhancements, visit here or read our latest release notes here. See BlackLight in action by viewing one of our latest webinars or requesting a free 30 day trial.
- Exploring the Windows Activity Timeline, Part 2: Synching Across Devices - March 24, 2020
- Apple’s (Not Quite) Secure Notes - March 3, 2020
- Exploring the Windows Activity Timeline, Part 1: The High Points - January 21, 2020