Interesting macOS Chrome Browser Files

This blog will take a quick look at Chrome files on macOS that are not protected by TCC and do not require root access to read from. As these files are not protected by TCC, any non-sandboxed macOS payload will be able to access these files without needing TCC permissions.

Chrome Files Not Protected by TCC

Note: Some Chrome files are locked when Chrome is running. However, as these files are not protected by TCC you can simply copy the locked file to another location and read from it there.

• ~/Library/Application Support/Google/Chrome/Default/Login Data (sqlite3 database)
• — → interesting tables:
• — — — — — → stats: stores the url along with the username that was used to authenticate; though the password is not stored, this can still be a useful data source for attackers, especially if the attacker has already compromised the corporate password of the user; additionally, root access is not needed so this database can be accessed is the user’s context); useful column names include “origin_domain” (site that the user authenticated to) and “username_value” (username used during authentication); is locked from reading when Chrome is in use
• ~/Library/Application Support/Google/Chrome/Default/Web Data
• — → interesting tables:
• — — — — — → autofill: stores autofill information to aid in web form completion; may contain a wide range of info, including email addresses, first and last name, phone numbers, mailing addresses, usernames, one time security codes, payment card expiration date info, payment card city and zip code info, etc.; when i searched this on my test machine I also found that this table contained a github personal access token from a while back! :-o
• ~/Library/Application Support/Google/Chrome/Default/History (sqlite3 database)
• — → interesting tables:
• — — — — — → urls: stores urls along with last visit time
• — — — — — → downloads: stores the url that a file was downloaded from along with the local path on disk where it was downloaded to and the timestamp
• ~/Library/Application Support/Google/Chrome/Default/Preferences (JSON file)
• — → This appears to be where settings are stored that reflect your Google accounts when you click your Google icon logo in the upper right from inside of GApps like Gmail. So if you have linked different Google accounts in a way where you can click the icon and switch between accounts you will find that info listed there in Preferences
• ~/Library/Application Support/Google/Chrome/Default/Accounts/Avatar Images
• — → This directory holds avatar images for the Google profiles currently configured in Chrome
• ~/Library/Application Support/Google/Chrome/Default/Bookmarks (JSON file)
• — → Where Chrome bookmarks are stored. Includes info such as date added, url, bookmark name, id, etc.

Keychains

A lot of good research has already been done around extracting Chrome cookies. Ex:

defaultnamehere/cookie_crimes

Hands in the Cookie Jar: Dumping Cookies with Chromium’s Remote Debugger Port

Definitely check those blogs out for more info around Cookie extraction.

The user level keychain databases themselves (ex: ~/Library/Keychains/login.keychain-db or ~/Library/Keychains/login.keychain) are not protected by TCC. However, you do need the user’s macOS password in order to read keychain database sensitive contents (ex: usernames, passwords, etc.). This presents an interesting attack path that still works on modern versions of macOS:

1. Gain non-sandboxed remote access. Several payload options would provided non sandboxed access, including installer packages or shell scripts masqueraded as .app packages (ex: CVE-2021–30657, which I reported to Apple and worked with them to validate the fix). Gatekeeper checks both file types for valid developer signatures and notarization when the com.apple.quarantine extended attribute is present but the user can still Right Click → Open to run.
2. Prompt the user for credentials. This can be done via the on disk osascript binary or can be done programmatically (several open source projects exist that demonstrate ways of doing each).
3. Download the keychain database file
4. Use forensic tool chainbreaker (https://github.com/n0fate/chainbreaker) and provide the user’s password to access keychain contents.
5. Generic password content, internet password content, keychain password hash, and other info is captured and displayed.