Identifying Databases

From truxwiki.com
Jump to navigation Jump to search

This article describes how Truxton determines the type of a database file.

Introduction

Databases present a unique problem for Truxton. While it is easy to determine the basic type of the file, SQLite or ESE, determining the type of database for exploitation purposes is problematic. In order to know how to exploit a database file you must first exploit the database file.

This identification is database driven so you can add your own types if you wish.

Identification Process

Initial Identification

The first step in database identification is recognizing the type of the data file. This is the traditional method of analyzing the content of the file to identify the program that created it. This uses whatever technique is necessary, file signature or recognizing data structures, to determine the type.

This is good enough to tell you that a bag of bytes is a SQLite file but it won't tell you that it is a GMail mailstore.

Extract Schema

Once a database file has been identified, it will be sent to expansion. There it will be opened and schema extracted. A list of table names and the column contained in each table is produced.

Schema Scoring

Once we have the schema, we can compare it to a list of known schema and make a best guess as to the file type. The [DatabaseTableName] hosts the information we need to make this determination. It is used in several ways and they are (from worst-don't-ever-do to best practice):

Schema Hash

Truxton will sort the extracted schema by table name then column name. There will be a period separating the table name and column name. These are output to an ASCII file one entry per line. The resulting list is then hashed using MD5 algorithm and finally stored in the [Name] column of the [DatabaseTableName] table.

This was the first method Truxton used and it turned out to be a very bad one.

Pros:

  1. No chance of collision. There's no way to mess this up.
  2. Efficient. Only one record in the database per schema.
  3. Blind identification. You can have a signature for a particular schema without publishing to the world what you're looking for.

Cons:

  1. Vendors modify their schema on an hourly (seemingly) basis
  2. Some vendors have dynamic schema. Table names vary based on the data stored in the database.

List of Table Names

The next attempt at identifying schema was to match a list of tables. The file type with the most matching table names was chosen. This failed because many file types have common table names. As vendors changed their schema (hourly basis), the list of table names would change. Some file types had only one unique table name mixed in with a bunch of common ones. The table names were stored in the [Name] column of the [DatabaseTableName] table, one name per row. The file type with the most matching table names was chosen as THE file type.

Tables and Columns

Extending the idea of counting the number of matching table names, Truxton now includes the column name with the table name for scoring. This allows two different file types to have the same table name but scored differently. The format of the entry in the [Name] column of the [DatabaseTableName] table is "table.column"

Identification Walk Through

Let's say we are attempting to identify two different types of SQLite files:

  • Nuclear Launch Code Schedule
  • Bitcoin Wallet

They both consist of a single table, [_Meta] so we must dig a little deeper. The launch codes [_Meta] table has the following columns:

[_id]
[_date]
[_code]

The wallet has the following columns:

[_id]
[_date]
[_coin]

The [DatabaseTableName] table has the following entries in the [Name] column for launch codes:

_Meta._id
_Meta._date
_Meta._code

The entries for the wallet are:

_Meta._id
_Meta._date
_Meta._coin

When Truxton begins scoring this, each file type will have a score of two because they share the [_id] and [_date] columns. When Truxton encounters the [_code] column, it will match the launch codes file type raising its score to three. Once all tables and columns in the schema have been scored, the file type with most matches is chosen as the true file type.