Literally make history with Firefox 3

I reckon most people will have seen the news that there is a new major release of ‘the other’ web browser, Mozilla Firefox (no browser wars please ;) ). The release of version 3 of this web browser was hyped up with an attempt to make it to the Guinness Book of Records, with a world record for the highest number of software downloads in 24 hours. “Make history with Firefox” was the slogan, but I will take a look at a way to literally make history with Firefox 3. Browser history, that is.

One of the changes in this new relase, is the new way of dealing with browser history. End users will most likely first notice this, when they start typing a web address into the location bar. In the ‘old days’, when you started typing ‘news’, you would most likely see a list with sites like ‘news.google.com’ appearing below the location bar: the browser would show you sites you had visited before, where the URL starts with the words you started typing.

However, in the new browser, you will also (of course depending on the sites you have visited so far), see sites like slashdot.org appearing. A closer look will reveal that this is because the title of the Slashdot page contains the word ‘news’ (as in ‘News for Nerds, stuff that matters’). It will not take long to realise that the browser is now doing some sort of full-text search on your surfing history, including all aspects like URL and title of a page.

To be able to offer this type of behaviour, the internal way of storing history has changed. Firefox used to store history data in a sort of flat-file database format (called Mork file format). In version 3, they have changed this and have started using SQLite: a lightweight implementation of a relational database that is mostly compliant with SQL.

By using this new architecture, it is possible to quickly do (for example) the type of lookup queries that are required to power the new location bar. But this new architecture also opens door to other possibilities, that might be interesting from a forensics perspective. After all, a database is good at both storing, retrieving but also manipulating data…

Let’s start up some tools: the SQLite Manager Add-on is a good one for testing. This add-on does exactly what the name states: it helps you to manage a SQLite database. When you have installed this tool, you can navigate to the %APPDATA%\Mozilla\Firefox\Profiles\ folder. Below this folder are the profile directories, named .profile . In these folders, you will find the .sqlite files that we need. For the history/location bar, we fill focus on the places.sqlite file.

Via ‘Connect database’ in the SQLite Manager, you can select this specific file. You will see a screen similar to this one:

SQLite Manager view of places.sqlite structure

This screen will look familiar to people who have used tools like PhpMyAdmin before.

There is a lot to tell about the way the various tables interact (as the column names are quite meaningful, most people who are familiar with databases should be able to get a feeling about what the specific fields are used for anyway, or refer to the Forensics Wiki), but for now we will focus on the potentially evil part :)

The moz_places table contains the ‘raw’ URL data: the URL, the hostname, the TITLE tag that the page has returned (so the title that is shown in the title bar of your browser), the numbers of visits to this page and whether or not this URL entry was typed in or not (in the latter case, it was apparently accessed by clicking on a direct link). Other tables that control the history or the bookmarks refer to this raw data by using the ID’s of these entries (like a proper relational database works :) ).

By using the search option, we look at the specific rows where the ‘url’ field contains the word ’schneier’:

Entries with schneier in url field

Remember, if you start to type in ’schne’ etc. into the location bar, you will see something like this:

schneier entries in location bar

Now let’s make these highly work-related websurfing into something that an employer might like a bit less…

We execute this SQL statement:

UPDATE moz_places SET url=replace(url,’schneier’,’notworkrelatedxxx’) where url like ‘%schneier%’;

This is a bit of a rough way of doing this, as it will only replace the ’schneier’ part with ‘notworkrelatedxxx’ in the URL field, so the title field for example will not be changed. But anyway, let’s see what we now get when we start typing ’schn’ etc. in the location bar again:

location bar after update query

The original title tag and the parts behind the hostname of course give away that something is not right here, but even then you probably would not like your boss to be looking over your shoulder when you have this on your screen…

This is of course a very rough, hardly proof-of-concept example of manipulating the history, but I assume it will be clear that with a bit of preparation you can do some very convincing manipulation of browser history and typed URL’s. Not only the URL and title, but also elements like time and date or number of visits can be manipulated, deleted or added.

So the challenge for forensic investigators will now be to determine whether the old data in the database can still be recovered. As SQLite is using quite some temporary files, there might be some options to pursue there.

On the positive side, it is now easier for forensic investigators to get an overview of browsing history of Firefox users. I will try to make a quick tool that will allow you to view the contents of a .sqlite history file in way that is useful for forensic investigations, without having to do SQL queries yourself.