About Me

Bay Area, CA, United States
I'm a computer security professional, most interested in cybercrime and computer forensics. I'm also on Twitter @bond_alexander All opinions are my own unless explicitly stated.

Wednesday, April 13, 2011

Firefox 4 Browser Forensics, Part 1

Firefox 4 was released almost a month ago now, and was in open beta for a significant time before that. However, a cursory Google search doesn't reveal much documentation of it's features of forensic interest, or it's changes since the last version.

For this analysis, I'm using Firefox 4.0 (current version as of writing) running on a Windows 7 VM. To examine the sqlite databases, I'm using the sqlite3 command line tool. Sqlite3 runs under Linux and Windows, and you can feed it SQL commands to script common actions, such as searching history for keywords or for browsing during a time range of interest.

Just like Firefox 3, Firefox 4 stores the browser history in an SQLite database. For Windows Vista/7, it's located at :\Users\\AppData\Roaming\Mozilla\Firefox\Profiles\\places.sqlite This database contains the tables moz_anno_attributes moz_annos moz_bookmarks moz_bookmarks_roots moz_favicons moz_historyvisits moz_inputhistory moz_items_annos moz_keywords and moz_places These tables seem unchanged from version 3, as documented on the MozillaZine.

When a person begins typing into the address bar, Firefox searches through it's browser history to try and connect what the user is typing with the websites he has visited recently. It outputs the suggestions with the webpage title and full URL in the suggestions below the address bar. When the user clicks the suggestion, the text they typed to find that url is stored in the moz_inputhistory table. The moz_inputhistory table is of particular interest to forensics because it can show that the person using the user account typed something into the address bar to access the site, rather than following a link or getting forced there by a pop-up.

The column names for this table are place_id, input, use_count, and PRIMARY KEY. Here's an example of the contents of the table, taken from my test system.

Note that none of these are full links. What you see here is what you get when someone starts typing a URL or keyword into the address bar and then clicks on one of the autocomplete terms. It does not seem to record full URLs. So, we get "ars t" and "arstechn" from two of the ways I accessed Ars Technica. It does not store search terms from the search box.

place_id refers to the destination of the input. This number can be converted into the actual website visited via the moz_places table. So, for example, I see that when I typed "ars t" into my address bar, I clicked on the website with id 197. The command > select * from moz_places where id=197; returns the website URL (http://arstechnica.com/) and the website title (Ars Technica) as well as other information that we'll cover when we get to the moz_places table.

The last column, use_count is an odd one. David Koepi looked at Firefox 3.6 and suggested that use count refers to the number of times the same text was typed into the address bar. On my system in Firefox 4, that doesn't seem to be the case as most of the values in use_count are decimals (see screenshot above). Running some tests, it seems to be related to the number of times run ... for example, typing "sans.o" into the address bar the first time adds it to moz_inputhistory and sets use_count to 1. So far so good, but here's where it gets odd. Typing it in four more times changes it to 1.9, then 2.71, 3.439, and 4.0951. As you can see from the other links in my history, many of them end up with values less than 1. This is probably a bug in Firefox, so I wouldn't rely on the value of this for any reason until it's better understood.

This is why it's important to do your own testing, instead of just believing what you read on the Internet.

moz_bookmarks and moz_bookmarks_roots
Bookmarks are also valuable for an investigator to examine because like inputhistory it implies that the user took an active action with the site, in this case marking it for later re-visit. The fields here are id, type, fk, parent, position, title, keyword_id, folder_type, dateAdded, lastModified, and guid. Comparing to the documentation by David Koepi and firefoxforensics, it appears guid has been added for FF4. According to the Mozilla wiki, guid was added in order to have a unique global identifier, rather than the simple incrementing index of id. This means that gid, not id, would be the proper link between bookmarks across computers using the new Sync service in FF4. Note, I haven't tested this.

type is an integer referring to the type of the bookmark. Type 1 is a normal bookmark, 2 is a tag (folders are really just a type of tag). Type 3 is a separator, and so has no useful info. fk is a foreign key, which links to the id in moz_places (where you can find the actual url). parent refers to the id of the containing object (folder), which can tell you where the user categorized the bookmark. position refers to the listing order of the bookmarks, and is not likely to be interesting. title refers to the display name of the bookmark and keyword_id is the index number of the keyword (moz_keywords) associated with the bookmark. It may be useful to find associated bookmarks. folder_type is not likely to be useful, but dateAdded and lastModified would be. These values are exactly what they sound like, stored as PRTime

moz_bookmarks_root defines the root folders in the Firefox bookmark structure, and is not of forensic interest.

In Part 2 I'll get into moz_places and more browsing history. Part 3 has moz_historyvisits and signons.sqlite. Part 4 covers cookies, cache, downloads and more.

No comments:

Post a Comment