Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 

K. Brian Kelley - Databases, Infrastructure, and Security

IT Security, MySQL, Perl, SQL Server, and Windows technologies.

Honeypots in the Database

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 | T-SQL| SQL Server | Microsoft SQL Server | SQL Server 2000 | SQL Server 2005 | MySQL | Security | Database Security | SQL Server Security
 

Comments

Posted by AB on 27 November 2007
Even the SELECT could be monitored with a very lightweight server-side trace, e.g. TSQL/Statement Started LIKE '%USERNAMES[_]AND[_]PASSWORDS%' ...

You could also make a couple of encrypted stored procedures with tempting names, like GetUsernamesAndPasswords, which could easily do logging of their own.
Posted by rudy komacsar on 10 December 2007
I dunno about 'honey pots' ... if a potential attacker is adept enough to get in I think the malware would be intelligent enough to determine the dbms and then make the appropriate user and or table selections. I actuality the intelligence factor is very overstated. A quick bit of googling can turn up the code to list the needed information rather rapidly. One would not even need to make it very conditional either since you wwould get one of 3 responses no matter what dbms vendor code executed against another dbms vendor - security error, syntax error or success. After all if we are reading this blog aren';t they (the potential attackers).
Leave a Comment

Please register or log in to leave a comment.