The pervasive use of databases for the storage of critical and sensitive information in many organizations has led to an increase in the rate at which databases are exploited in computer crimes. While there are several techniques and tools available for database forensics, they usually assume apriori database preparation, such as relying on tamper-detection software to already be in place or use of detailed logging. However, investigators need forensic tools and techniques that work on poorly-con gured databases and make no assumptions about the extent of damage in a database. In this paper, we present our database forensics methods, which are capable of examining database content from a storage image (disk or RAM) without using logs or any system metadata. We describe how these methods can be used to detect security breaches in a compromised environment where the security threat arose from a privileged user (or someone who has obtained such privileges).
Cyber-crime (e.g., data ex ltration or computer fraud) is a signi cant concern in today's society. A well-known fact from security research and practice is that unbreakable security measures are virtually impossible to create. For example, 1) incomplete access control restrictions allows users to execute commands beyond their intended roles, and 2) users may illegally obtain privileges by exploiting security holes in a Database Management System (DBMS) or OS code or through other means (e.g., social engineering). Thus, in addition to deploying preventive measures (e.g., access control), it is necessary to 1) detect security breaches in a timely fashion, and 2) collect evidence about attacks to devise counter-measures and assess the extent of the damage (e.g., what data was leaked or perturbed). This evidence can provide preparation for legal action or valuable information to prevent future attacks.
DBMSes are targeted by criminals because they serve as
repositories of data. Therefore, investigators must have the
capacity to examine and forensically interpret contents of a
DBMS. Currently, an audit log with SQL query history is
a critical (and perhaps only) source of evidence for
investigators [
Digital forensics provides tools for independent analysis
with minimal assumptions about the environment. A
particularly important and well-recognized technique is le
carving [
Even in an environment with ideal log settings, a DBMS
cannot necessarily guarantee log accuracy or immunity from
tampering. For example, log tampering is a concern when a
breach originated from a privileged user such as an
administrator (DBA or an attacker who obtained DBA privileges).
Tamper-proof logging mechanisms were proposed in related
work [
The goal of this work is to 1) develop DBMS forensic methods, and 2) use these methods to detect and describe security breaches in compromised environments. Table 1 summarizes the remainder of this paper; future work is bolded.
Unlike traditional les (e.g., PDF), DBMS les do not contain headers that allow for le identi cation. At the same time, all row-store DBMSes use xed-size pages to store user data, auxiliary data (e.g., indexes and materialized views), and the system catalog. DBMS data is accessed and cached in page units. Pages maintain a consistent structure, whereas individual record structure varies throughout DBMS storage, which is why we approach database forensics at the page level. In this section, we describe page carving including our implementation (DBCarver), future work support application development from DBCarver output, and anti-forensics techniques that can sanitize and hide data in DBMS storage. 2.1
Database page carving is a method we previously
introduced for the reconstruction of relational DBMSes without
relying on le system or the DBMS. Page carving is similar
to traditional le carving [
While each DBMS uses its own page layout, a great deal of
overlap between page layouts allowed us to generalize
storage for most row-store DBMSes. In [
Deleted Data. When data is deleted, the DBMS initially
marks it as deleted, rather than explicitly overwriting it.
This data becomes unallocated (free listed) storage { in [
Figure 1 visualizes an example of deleted records for several DBMSes. In all three pages, Row2-(Customer2, Jane) is deleted while Row1-(Customer1, Joe) and Row2-(Customer3, Jim) are active. Page#1 shows a case when the row delimiter is marked, such as in MySQL or Oracle. Page#2 shows when the raw data delimiter is marked in PostgreSQL. Page#3 shows when the row identi er is marked in SQLite. Figure 1 omits DB2 and SQL Server example because they only alter the row directory on deletion. 1 oCustomer1 w R Joe
60 2 oCustomer2 w
44 3 oCustomer3 w R Jim 2, 9, 24
Delimiter Joe Row
2, 14, 24
2, 9, 24
0, 0, 0, 1
Joe 0, 226, 0, 57
0, 0, 0, 3
Figure 1: Deleted row examples: 1-MySQL/Oracle, 2-PostgreSQL and 3-SQLite
Column-Store and NoSQL DBMSes. Currently, our page carving only supports row-store DBMSes. Column-store and NoSQL DBMSes do not use the same pages structure as row-store DBMSes. Future work will expand our database forensic methods to column-store and NoSQL DBMSes. 2.2
We previously presented our implementation of page
carving called DBCarver [
E
Capture DB storage C Disk Images G
F
DBCarver
H Reconstructed Storage ● Data pages (e.g.,
table, index) ● Deleted data ● Catalogs, logs
The parameter detector loads synthetic data into a DBMS
(B), captures storage (C), nds pages in storage, and
captures page layout parameters in a con guration le (E) {
a text le describing page-level layout for that particular
DBMS. Parameters include those described in [
The carver (F) uses the con guration les to reconstruct any database content from disk images, RAM snapshots, or any other input le (G). The carver returns storage artifacts (H), such as user records, metadata describing user data, deleted data, and system catalogs. output. Furthermore, analyzing DBCarver output often requires an in-depth understanding of DBMS storage internals, which is unreasonable to expect from most users.
To introduce composability for application development with database forensic output, we propose a framework that has two goals: 1) de nes a standard set of elds that describe forensically extracted user data, system catalogs, auxiliary objects, and other metadata, and 2) an user-friendly Python library that interprets this set of elds. This module will remove the need for specialized knowledge of database storage in development of applications based on DBCarver output.
We propose building a uni ed and standard output that
automates the initial forensic analysis. To do this, we will
store metadata from the DBCarver output in a series of
JSON objects that maintain a consistent structure for all
row-store relational DBMSes, while the original DBMS
snapshot returned by DBCarver will be loaded back into our
internal DBMS. The JSON objects will contain categories based
on the work of Gar nkel et al. [
Working with the forensic output may require users to have an in-depth understanding of DBMS storage, which is unreasonable because each DBMS uses a highly customized storage engine. Such a requirement may prevent users in other domains from developing applications. We propose building a Python module to ease the interaction with the JSON objects and the reconstructed data stored in a DBMS. This module will contain methods to access individual properties from the JSON les. Furthermore, this module will allow for connections to be made between the metadata stored in the JSON les and the database snapshot stored in a relational DBMS. 2.4
Anti-forensics (AF) is the eld of interfering with forensic
techniques [
Two of the most representative AF techniques we consider
are data wiping and steganography. A corporation can use
data wiping to erase the already-deleted customer
information to prevent data theft. Steganography is a data hiding
technique { e.g., a means to discretely blow a whistle on
company's wrongdoing. Most prior work in database AF has
been highly DBMS-speci c; e.g., Stahlberg erased deleted
MySQL data by modifying the purge thread in source code [
Privileged users (e.g., DBA), by de nition, have the ability to control and modify access permissions. Therefore, audit logs alone are fundamentally unsuitable for the detection of malicious, privileged users. DBMSes do not provide many tools to defend against insider threats. Interestingly, DBAs have little to no control over how data is stored at the lowest level. Thus, malicious activity will still create inconsistencies within storage artifacts. In this section, we consider attack vectors that are detectable using database forensics methods from Section 2. All of these solutions assume that some level of logging was enabled and is available. 3.1
Audit logs are a critical piece of evidence for
investigators { and existing research has explored tamper-proof logs.
However, DBAs can disable logging for legitimate operations
(e.g., bulk loads). Therefore, we consider an attack where
logging was disabled, malicious activity was performed, and
logging was re-enabled. We proposed DBDetective in our
previous work [
To detect unlogged activity, DBDetective compares the disk images and/or RAM snapshots output from DBCarver against the audit logs. We classify two categories of hidden activity: record modi cations and read-only queries (i.e., SQL SELECT). When a record is inserted or modi ed the record itself changes, page metadata may be updated (e.g., a delete mark is set) and index page(s) are likely to change. We ag any artifacts that cannot be explained by a log entry as suspicious, as shown in Figure 3.
Log File T1, DELETE FROM Customer WHERE City = ‘Chicago’; T2, DELETE FROM Customer WHERE Name LIKE ‘Chris%’;
UNATTRIBUTED DELETE
DICE Output Del. Page Type: Table Flag Structure: Customer
1, Christine, Chicago 2, George, New York 3, Christopher, Seattle 4, Thomas, Austin 5, Mary, Boston
Privileged OS users commonly have access to database
les. Consider a SysAdmin who, acting as the root,
maliciously edits a DBMS le in a Hex editor or through Python.
The DBMS is unaware of external le write activity taking
place outside its own programmatic access and thus cannot
log it. Such an attack is a `black-hat' application of
antiforensics discussed in Section 2.4. In our previous work [
To detect database le tampering, DBStorageAuditor [
Privileged users with access to the DBMS server have the capability to change server information, speci cally the global clock. This quietly a ects the veracity of DBMS audit logs. Consider a system administrator who changes the server global clock to an earlier date, performs malicious activity, and resets the global clock. Such an attack backdates activity without altering the log les, and disguises when the actual execution time of the malicious activity. As future work, we will detect such attempts to backdate log entries.
In such an environment, any global or logical clock can not be assumed to be reliable. Therefore, to create a timeline of events, we believe it is necessary to use storage metadata, which even a privileged user cannot modify. The internal RowID pseudo-column is of particular interest to construct a timeline. RowID is used by indexes and re ects the physical location of a record including its PageID. Whenever a page is modi ed, we can store the PageID to know when data was modi ed. Thus, the order of the PageIDs must be consistent with the order of the log events. We will propose tamperproof techniques to store the PageID. 3.4
Quantitative Analysis and Reproducibility As future work, we will determine the detection accuracy for each attack described in this section. For each detection type, we will compute a con dence rating based on a variety of environment variables (e.g., bu er cache size, volume of operations, and DBMS storage engine). For example, given a low volume of DELETE operations in Oracle, DBDetective would detect attacks with higher accuracy because Oracle controls storage with a percent page utilization. This engine setting prevents deleted records from being overwritten until a page contains a signi cant quantity of deleted data.
To verify the presence of malicious operations, a repeatable analysis analysis must be guaranteed. We will develop algorithms to collect the minimal subset of storage artifacts needed to reproduce our results. These collected storage artifacts must be su cient to verify the security breach independent of our analysis. For example, such functionality is needed to present evidence in court.
In this work, we presented page carving and our page carving implementation, DBCarver. Future work will expand this method to include support for column-store and NoSQL DBMSes, o er meta-querying functionality, and incorporate anti-forensic methods to further protect data. We also presented methods that use page carving to detect security breaches in untrusted environments. DBDetective considered an attack where logging was disabled, DBStorageAuditor addressed DBMS le tampering, and future work will address tampering of the system global clock to backdate logs. 5.
This work was partially funded by the US National Science Foundation Grant CNF-1656268.