As a follow up to my post about Cesar Cerrudo's new whitepaper, earlier this month David Litchfield talked about putting honeypots in the database in his blog post, Database tripwires..., to catch someone snooping around. The basic idea for non-Oracle databases is to create some sort of alerting function (such as one that fires an email) that gets called by a view with an interesting sounding name or interesting sounding column names. Triggers could work for INSERT, UPDATE, and DELETE, if the attacker is attempting to alter data. However, if the attacker is simply collecting information, then triggers aren't effective because triggers can't be defined on SELECT operations. This is why he points out the use of a view.
The example Mr. Litchfield gives is to name a view USERNAMES_AND_PASSWORDS. This certainly would catch the attention of a piece of malware like what Mr. Cerrudo describes. Normal users wouldn't touch this view (especially if only apps directly access the database), but an attacker snooping around would (for instance, the malware talked about by Mr. Cerrudo). This would cause the alert to fire because the tripwire has been hit, and we would know someone or something has been in the database in a manner that is unexpected.
This has to be done on a view that wouldn't be touched during normal operations. If it were on an actively queried view, we would get too many false positives and eventually the alerts would simply be ignored, thereby rendering the control ineffective.
Technorati Tags:
DATABASE |
SQL |
MySQL |
Security |
