Initialization vectors: Local Storage - Firefox Focus Privacy Browser Artifacts in Android

Thursday, April 19, 2018

Local Storage - Firefox Focus Privacy Browser Artifacts in Android

Short version: 

Data placed by websites in the Local Storage folder LevelDB database for the Firefox Focus Privacy Browser (FF-Focus) app will remain and be accessible even after browsing history deletion.  The data will be located at '/userdata/data/org.mozilla.focus/app_webview/Local Storage/leveldb' directory.

Long version: 

First I want to thank Ryan Benson (@_Ryan Benson) and Phill Moore (@phillmoore) for their help and guidance with this analysis.  I am thankful for their generosity in regards to their expertise and time. Any and all shortcomings with this analysis obviously reside with me. And like anything else in life always make sure to validate, validate, validate.

FF-Focus is a privacy oriented browser developed by the Mozilla organization. As stated in the picture below the app blocks ads, trackers and deletes all browsing related items like history and cookies.

No ads, no history, no nothing!!!
Testing 

I wondered how much data could remain, if any, after the app completed its privacy routines. In order to test I used some of the equipment mentioned in the following link for testing and analysis.

Android - Mobile testing hardware and software

After downloading the app to my exemplar phone, I did some browsing and imaged the device before closing the app. As can be seen below, the app had created all the files we would expect to see in a typical browser directory when in use. The cache folder has contents and the current session cookies are accessible.
Cookies are there. Yum.
If called to image a target device, being able to do so when FF-Focus is open would be the ideal thing, it will also be the most unlikely scenario. After the app is closed all those browser artifacts are gone.
All gone except...
The was only one remaining directory, Local Storage, and within it the LevelDB folder. The files within it were:

  • 000003.log
  • CURRENT
  • LOCK
  • LOG
  • LOG.old
  • MANIFEST-000001

After a quick view of contents of each file, the 000003.log seemed immediately relevant because it contained the domain names of the websites I had browsed previously.

I can see domain names.
After consulting with Phill Moore he referred me to Ryan Benson and his excellent presentation on browser forensics which he delivered at the SANS DFIR Summit 2017. The presentation can be seen at Youtube in the following link.


I strongly encourage the reader to check out the whole of Ryan's presentation since my summary of the aforementioned data stores will do no justice to the depth of the explanation found in the video. 

In summary, the files seen in the Local Storage directory are responsive to website data stores that use the Google developed LevelDB database. This data store is based on key - value pairs unlike the traditional SQLite databases found everywhere in mobile devices. If a web page inserts a key-value pair where either the key or the value is the domain website, it will remain there even after the app deletes all the browsing history. It is also interesting to note that new key-values are added to the data store across browsing sessions.

These observations led to the following questions:
  • Do all web pages leave data in the data store?
  • Can all the domain names in the data store be attributable to a deliberate user request for a page?
  • How are these records accessed? How are they ordered? Are there any timestamps available? Any ordering values?
Local Storage usage by web sites

In order to have an idea of what type of values a web page might place in the data store I examined the values being pushed to the browser by using the developer options functionality in Chrome and Firefox on my testing desktop. Ryan's video has a detailed explanation and a visual of such tools. 

The next image shows one of the pages I visited using FF-Focus for testing.

There is no key-value for the domain name.
Notice there is no key-value pair for the domain name. As expected I did not find the domain name for the visited page in the data store of the phone either. This seems to indicate that not all websites will leave a trace of the domain name in the store in question.

Now lets look a the following image from CNN.com

Local Storage values from CNN.com
The values in the image mirror the values found in the data store in the FF-Focus app directory. And yes, the domain name was there. But also notice that some domain names I did not visit explicitly, like Youtube, do appear in the data store. It is my hypothesis that video content played within the page will leave such traces in the data store. This needs further testing.

It is also worth nothing that these behaviors in FF-Focus might also be mirrored in most if not all browsers. 

Data Extraction

In order to view the key-value pairs more easily I needed to dump the data from the data store. The data was located in the 000003.log file. For this purpose Ryan shared with me a python script he quickly wrote that uses the leveldb wrappers to access data store. For my testing I collected 8 versions of the data store at different times after browsing a growing number of web pages per extraction. The following process was the most consistent way of dumping the values in the data store. It worked for all extractions tested.
  1. Export the 'leveldb' directory from Local Storage and run the lvl.py script here. The script will access the data in the log file and move it over to a .ldb file. This is expected behavior of a LevelDB data store. I used the Linux version of the SIFT Workstation due to limitations with LevelDB python support in Windows.

    The usage is as follows:
    Run 'python lvl.py ~/location-of-the-leveldb-folder/leveldb'

    The script will dump the contents to the file to the screen (or to a file using a redirector) as it iterates through it. In some of my test data the contents did not show. The only consistent way of accessing the data was by dumping the data directly from the generated .ldb file.
  2. To dump the data from the generated .ldb file I used the ldbdump tool found in Golang. Steps for my testing environment:

    - Install Golang for Windows. Link here.
    - Install Git for Windows. Link here.
    - Get the Golang leveldb repo. Run 'go get github.com/golang/leveldb'.
    - Navigate to 'C:\Users\username\go\src\github.com\golang\leveldb\cmd\ldbdump'.
    - Run 'go build -o ldbdump main.go'.
    - Take the ldbdump file and add the .exe extension.
    - Run 'ldbdump target.ldb > exportedldb.txt' where target.ldb is the extracted file name.
The exported data will look something similar to this:

Key value pairs. Some hex.
Pending items

After the data is extracted a noticeable pattern of hex values accompany the key in the data store. Currently I don't know what those values mean. They could be artifacts from the browser, some sort of data store ordering scheme or something totally different.

The formatting of the exported data still needs work. Further work on a script that can address the need is also to be done.

Why does this matter?


Being able to have some clues regarding subject browsing habits might be key to an investigation. This is even more essential when the involved individual/s are using a no history, privacy centric application like FF-Focus.