Your Encrypted Database May Not Be So Secure...
What is an Encrypted Database?
Examples of encrypted dbs:
as per their description:
Encrypted databases operate on top of a commodity database management system (DBMS) such as MySQL or MongoDB but store data in an encrypted form so that even if the DBMS or underlying OS is compromised, the attacker cannot obtain the protected data… For efficiency, encrypted databases rely on specialized encryption schemes that allow the server, given only the ciphertexts, to perform some computations in response to client queries. The price is the leakage of partial information about plaintexts.
The Old Way
Its well known that a very persistent hacker can observe query evaluations, and employ some tricks around property-revealing encryption schemes... but there is a new cowboy in town
Introducing... snapshot attacks!
A running DBMS will have state information in any (or all!) of four places: volatile DB state in RAM and CPU registers, persistent DB state on disk, volatile OS state, and persistent OS state.
Snapshot attack mechanisms
- Disk theft will yield the persistence information stored by the DB and OS, but not any volatile state. (Ignoring full disk encryption in this analysis, since EDBs claim protection even in the absence of this).
- SQL injection can enable arbitrary code injection and full control of the memory space of the DB process, yielding the persistent and volatile DB state.
- A DBMS running in a virtual machine is vulnerable to VM image leaks which give you everything – persistent and volatile state for both DB and OS.
- A full-system compromise (e.g rooting the DBMS) gives full access to the persistent and volatile OS and DB state. “This enables persistent passive and active attacks, but ‘smash-and-grab’ attacks that simply grab available data and leave are prevalent.”
All these attack vectors can be aptly described by the following:
We at superawesomesecure bank built THE BEST AND MOST SECURE front door ever!
3 months later
turns out... no one thought about the windows being left open. oops.
Information in logs
Log record changes to the individual database records at the byte level. Using standard forensic techniques for reconstructing insert, update, and delete transactions from these logs, an attacker who compromised the disk can reconstruct queries that modified the database.
Information in Diagnostic tables
Modern DBMS’s include tables – extractable via SQL injection – that store a great deal of performance statistics intended to help tune specific databases to their workloads and diagnose problems and performance bottlenecks.
Information in in-memory data structures
The full text of the original query appeared in three distinct locations in memory, and the random string appeared in three additional locations by itself… This leak is not surprising since MySQL is not designed for security-critical operations and does not implement secure deletion. In Section 6, we show that in the context of encrypted databases this otherwise minor oversight has dramatic implications for the (lack of) security.
In Summary, Deploying encrypted databases on commodity DBMS’s can have tremendously bad consequences for security. Logs, caches, and data structures kept by DBMS’s may leak information that is not accounted for in the threat models used by the designers of encrypted databases. Critically, today there is no such thing as a “snapshot” attacker who cannot observe past queries, workloads, and access patterns—because any realistic snapshot of the system contains this information.