What are poison records and how you can detect massive database breaches and leaks using them.
Imagine you’re storing a table containing a lot of sensitive data: customer names, emails, biometric information, etc… No matter how hard you work on security, at some point an SQL injection or a malicious insider will try to execute a SELECT * statement in an attempt at downloading the table. In some cases, they will succeed. What can you realistically do to prevent that? For instance, you can use poison records. Uhm, what?..
Poison records are decoy database records created to resemble actual database entries and never be returned as a response to legitimate query under normal circumstances.
To detect that a database responded with a poison record, we need some entity to “watch them”. For different approaches on detecting poison records, read our technical article on poison records.
For example, simply being present and detected in the database responses passing through a “watchdog” proxy server, poison records will raise an alarm in the system.
At Cossack Labs, we were sure we’ve seen the name “poison records” used elsewhere in the context of database protection and intrusion prevention. However, looks like “poison records” is a novel term coined by us while working on Acra — open source database encryption proxy for securing sensitive data in databases and database-driven applications. This is an article explaining what poison records are and how they can be used for database data leakage prevention, ELI5-style.
The concept of poison records can be traced back to the pre-Internet days of the Cold War when fake dossiers marked innocent citizens as spies and were stored alongside the real spy files in small batches. The purpose of this was traceability — if some of the non-spies got arrested, it meant that all the other dossiers and files in that batch were also compromised by an enemy intelligence service.
In the online world, honeypots and document fingerprinting data loss prevention tools could be called kissing cousins of poison records.
Document fingerprinting
Document fingerprinting is a data loss prevention (DLP) tool that marks some standard (text) form as sensitive information for which transport rules and security policies can be defined.
Usually electronic documents cannot contain an actual fingerprint info, so other ways to mark files are used for fingerprinting. For instance, a DLP agent creates a fingerprint document based on the unique word pattern. The resulting fingerprint is used for detection of all the outbound documents containing it. The server will detect attempts at sending out the documents with fingerprinted info and take appropriate measures (i.e. alert the system administrator) if pre-configured.
Honeypots
Honeypots are decoy pieces of IT infrastructure the sole purpose of which is to lure in the potential attackers through an intentional introduction of a weak and vulnerable element (honeypots purposefully combining several vulnerability types at once are called “dorks”).
Honeypots serve as a layer of security on which it is possible to study the attackers’ behaviour and find out the purpose of the possible future attacks (taking place in the real infrastructural elements).
Poison records bear some resemblance to production honeypots. Production honeypots pretend to be real functional elements of a production infrastructure to divert the attackers’ attention, serving as a false target, raising a security alarm on penetration.
Both honeypots and poison records can be successfully used in a number of settings where traditional (database) intrusion-detection and prevention systems would be inefficient. By their nature, honeypots and poison records are unaffected by such popular IDS-hampering issues as false positives and negatives, they remove the necessity to monitor and sift through an excessive amount of data, and require way less resources than an active monitoring system of the whole database. Yet, we don’t advocate them to be a replacement — but a valuable sidekick and another line in an echeloned defence.
However, the mechanics of work for poison records is totally unlike that of the honeypots. Poison records are not a part of the functional infrastructural elements.
So, what are the poison records?
Poison records
What if an attacker manages to compromise the system so badly that they are able to alter its behaviour (through an SQL injection or local code execution errors)? There must be a way to set a passive monitoring system in place, detecting these breaches.
Poison records are the data in your database (binary data in case of Cossack Labs’ Acra) that could be described as specifically designed content dummies. When deployed in the right places in the database, they can only be queried with a SELECT * request. Poison records can resemble any other type of data in your database by their size and “appearance”. They can be placed in the table cells or take up whole lines. When selected in a query, they serve as an indication of a breach and alert the system. Just like honeypots, poison records add an additional level of security and provide another tool for monitoring the suspicious and outright malicious behaviour taking place in the database.
The main distinction of poison records is that you need a specific tool for their creation and a tool for their detection; a tool that allows you setting a certain parameter to set the poison records apart from the “normal, regular” data in your database (i.e. a certain sequence of bytes in the beginning of the data), then something to detect it.
Poison records work alongside your monitoring system because something needs to watch out for the poison records being queried from the database (and raise an alarm afterwards). Poison records are just data (binary data in Acra’s case), marked in a special way. For monitoring, you can use the middleware of the app, traffic monitoring, DLP tools, or even set a trigger on a specific database cell instead of using Acra.
Acra Poison Record Illustrated
Let’s say, there is a database full of records (encrypted and plaintext). To provide decryption for the legitimate requests and users, we put the decryption proxy between application and the database. Aside from just decrypting records from the database, Acra will detect poison records in the database response.
To make this story more fun, let’s pretend the white bottles are unencrypted records and the black opaque bottles are the encrypted records:
If an attacker manages to get the access rights to the records and perform SELECT *, they will be able to steal and leak all the information they want and no one will ever find out until the breach is noticed due to some other reasons (or a very public leak).
But what if the database also contains poison records? It will look something like this:
The poison records are designed to resemble the regular database entries in type and size and they are never selected or otherwise addressed during a normal secure functioning of the database.
So, under normal circumstances, the poison records will remain in place, while other records in the database will be encrypted and decrypted, read, written, deleted, etc. Like this:
What happens when an attacker is able to force the database to answer to their custom crafted request?
AcraServer, sitting between attacker and database, will recognize poison record among other records in the output, which will trigger the security event.
Plain and simple.
Wait, what is AcraServer?
What is Acra
Acra is an open source database security suite that protects sensitive data against leaks and many other typical threats through strong selective encryption and intrusion detection capabilities. Put simply, Acra resembles a helpful “man-in-the-middle” that encrypts/decrypts the data as it goes into and outside the database. Poison records are one of the tools used for intrusion detection in Acra (we recommend checking out the full architectural scheme of Acra if you decide to try poison records).
Since AcraServer is the only entity in the infrastructure that decrypts sensitive data (narrowing down the attack surface for sensitive data to one specialized service instead of dozens of places) and sees all the requests addressed to it, it is AcraServer’s responsibility to tell the good behaviour from bad and to take appropriate action.
AcraServer’s key storage contains a special key which is used for recognition of poison records. Poison records are generated by a special utility that is configurable to make the poison records resemble your actual database entries..
Upon passing AcraServer, poison records will inform it of atypical behaviour. AcraServer will detect poison records, stop executing the query, and the system administrator will receive an intrusion alert (if Acra’s infrastructure was configured to do so).
You can get your hands dirty and try Acra with poison records in the Cossack Labs GitHub repository or do it without writing a live of code using Acra Live Demo. Or head over to our technical blog to read a more technical description of the poison records mechanics’.
Got comments? Have some questions about poison records or Acra? Also, if the term “poison records” wasn’t coined by us, please let us know — we’d love to find the full backstory. Please reach out to us via [email protected] or @cossacklabs.