Apple is about to release two new OS upgrades in the form of iOS 14 and macOS 11 (whoa, that’s weird to say) this fall. With new OS versions is always going to come a lot of new artifact testing. I’ve always been fascinated with tracking browser preferences and due to the nature of how Safari operates, I feel that it’s one of the most important browsers to track and understand the preferences of.
Apple likes to make sure that there’s a level of protection between a user and granting permission for an application to do something. This is tracked as part of Apple’s “Transparency, Consent, and Control” and tracked within the TCC.db across macOS and iOS. These databases are always a hot point of investigation for me because I’m always curious as to what permissions the application has asked for, as well as what permissions the user has granted. This can help guide me toward specific things to look for that may have been generated by an application.
For Safari, Apple also wants to extend that same protection and control to its users. This is done in the form of pop-ups that appear at the top of Safari asking a user if they want to extend specific preferences for a website to do a specific task. In the days of online conferencing and video chatting, its important to know if a site has been asking for certain information from the user and whether or not the user has accepted. But I’m getting ahead of myself. Let’s start at 0.
Recently I got an update notification for Safari 14. Safari 14 is the version that will ship as part of iOS 14 and macOS 11. After updating, I started checking on some preferences to make sure they hadn’t moved. Earlier this summer, I wrote a blog post on the main Magnet Forensics’ blog to discuss some of my findings on Safari preference data. (Link: ) I figured that with Safari 14 updated, it’s good to just revamp the post and give everyone a rundown of location values of specific files and how they can play info your investigations.
Let’s start with a baseline. Safari, by default, records the following preferences:
The biggest issues we see here is how the default settings can complicate an investigation. Three points specifically I always like to mention when it comes to active investigations are as follows:
- History: Safari for macOS will only keep 1 years worth of web history (by default). This differs from the 30 days of history that iOS keeps.
- Downloads: Safari only tracks the last 20 downloads in the Downloads.plist file, but this setting keeps that information only to the last 1 day as well. Meaning that by default only the last day’s downloads will be available for review.
- Open Safe Files: If you’re trying to prove if the user “opened” a file this can complicate things. Items that Gatekeeper deems “safe” it will automatically open after download. (Gee officer, I didn’t know that video had bad stuff in it. I never played it.) Safari could still open a file FOR the user even if the user never intended to.
These preferences can be found in ~/Library/Containers/com.apple.Safari/Data/Library/Preferences/com.apple.Safari.plist.
The interesting thing about this plist file is that many of the preferences will NOT be present in this file if they have never been changed from the default. For example, if the user has never changed the following settings, there will not be a record referencing them in the plist:
- History Storage Time
- Download Storage Time
- Download Locations
- Search Engine
- Open “Safe” Files setting
For this next test I have gone through and changed a bunch of settings. You can see the new settings here:
Changing the settings then presents several new keys that aren’t in the original file. Doing a side-by-side comparison of the original to the new gives me several interesting values to track. The following values were added to my plist file only after they were changed. [Note: I just realized HomePage snuck in there. That one is always present even if it’s the default. Sorry!] After I changed them back to their default values, they still remained present in the file. Presence of one of these keys means that a user has changed from the default before!
The DownloadsClearingPolicy is obviously not a boolean like some of the others. It references the value in the dropdown for the preference for “Remove history items: ” in the Safari preferences window.
When Safari Quits = 1
Upon successful download = 2
Manually = 0After one day = 3 [Default]
SearchProviderIdentifier is referencing one of the listed search engines on the Search tab of preferences.
Remove history items will reflect the number of days it’s supposed to keep it with 365,000 being the option for “Manually.”
Now on to the site preferences managed for each URL that we visit. Every time a location requests one of several permissions, a user is presented with a pop-up window at the top of Safari to either allow or deny said permission (just like our applications).
Some of these preferences are managed within a database, while others are managed in plist files. Regardless, all of the per-site preference managing files can be found in the directory ~/Libary/Safari/ and we’ll evaluate each of the files for their goodies below. If a user goes to the Websites tab of their Safari preferences they can see a listing of all the requested permissions on the left as well as what website was granted/asked/denied permission on the right. It is important to realize that some permissions are NOT granted permanently and must be accepted each and every time. This could explain why information is not always present in these files.
The first place to check is the PerSitePreferences.db file found within ~/Library/Safari. This file tracks the bulk of the preferences. Preferences can be found in the preference_values table and the ones I’ve been able to map so far are:
I think the first three preferences will be the most frequent ones requested by web sites (at least in my browsing experience). Downloads was the heaviest populated because every time a file wanted to be downloaded, it first had to pass a test. NOTE: When the Global preference for “Ask every time” on download location was set, this did NOT ask for permission and did not populate in the database. That’s a big one to check for before getting here.
Each value is listed in the database table with a domain, preference, preference_value, and a timestamp value. In my testing the timestamp was always NULL. The preference_value reflects a 0, 1, or 2. These numbers however change for what the preference is reflecting (ugh...).
- Allow = 0
- Ask = 1
- Deny = 2
- Block = 1
- Allow = 2
- Ask = 0
- Deny = 1
- Allow = 2
- Allow All Auto-Play = 0
- Stop Media with Sound = 1
- Never Auto-Play = 2
The next preference file is to track the Page Zoom. While possibly not the most important, we’re here, so we might as well take a look. This is tracked within the PerSiteZoomPreferences.plist inside the same Safari directory. Each URL will be listed along with a PageZoom and TextZoom value. These values are represented in smaller numbers but correspond to a percentage (ie 1.15 = 115% and 1.75 = 175%).
The Notifications permission is tracked in the UserNotificationPermissions.plist file in the same directory. This files uses a boolean value to track whether or not notifications are allowed to pass through to the macOS Notification Center from Safari as well as when this permission was added by the user. 0 = Deny / 1 = Allow
And now, the moment you’ve been waiting for. How do we track if Safari has permission to use my Camera, Microphone, or to share my screen? With all of the web-based conferencing and video calling going on, I felt like this one was the most fascinating. Once I got into how Apple was storing the data, it was!
All three permissions can be tracked using the UserMediaPermission.plist file. Regardless of what permission has been allowed or denied, it will be given a listing in this file. A URL and a timestamp recorded in Apple/Mac Absolute Time will be listed for when the permission was granted and expires. The permission value however is actually a bit mask (which is a fun term a developer recently taught me). Essentially, each value is assigned a number and then that number corresponds to possibly one or more values added together. Some values didn’t appear to be used in my testing.
1 = ???
2 = Deny [Microphone]
4 = Allow [Microphone]
8 = ???
16 = Deny [Camera]
32 = Allow [Camera]
64 = ???
128 = Deny [Screenshare]
Note: Permissions for screen sharing can only be set to Deny or Ask. The default value is always Ask and you can’t set that causing a value for it to be populated.
Let’s look at some examples.
Example One: Screensharing is denied. No other permissions changed.
Example Two: Camera and Microphone are allowed, no other permissions requested.
Example Three: Camera, Microphone, and Screen Sharing are all denied.
As promised here’s the TL;DR version in chart form. Operating System : macOS 10.15.6 / macOS 11Application: Safari 14.0
|Stores multiple global safari preferences like home page, recent web searches, data and history keep rates, and whether to open files automatically upon download.
|PerSitePreferences.db > preference_values
|Stores information on preferences for Downloads, Geolocation, PopUps, and Autoplays.
|Tracks zoom levels for text and page views.
|Tracks which URLs are allowed to display notifications.
|Tracks which websites are allowed/denied permission for Camera, Microphone, or Screen Sharing.