[Previous entry: "Navy vs. Notre Dame"] [Next entry: "Oracle 11g/10g Installation Vulnerability"]

11/06/2007: "Database tripwires..."

I was thinking about the problem of creating a cheap tripwire for database servers that doesn't require a third party agent and it will alert us to when someone's snooping around places in our databases where they shouldn't be snooping. We could set up a honeypot table or view with an appropriately attractive name like USERNAMES_AND_PASSWORDS. Because this is a fake table no-one should ever really be looking at it and we can get the database to alert us when anyone touches it: there's a snooper online.

This could be achieved with a trigger in the case of an UPDATE, INSERT or DELETE of course but not so with a SELECT query. This limitation is easy to fix in Oracle with the use of fine grained access control by setting a policy on the table in question using DBMS_FGA. But what about other database servers that don't have an equivalent? Well, we can still achieve the same results with a simple view.

First off we create a function that does the actual alerting - whatever that happens to be - for example sending a mail to the DBA. Once we've created this function we then create a view that calls this functions - this view becomes our honeypot:

CREATE VIEW USERNAMES_AND_PASSWORDS AS SELECT FOO, BAR FROM TABLE WHERE ALERTFUNC = 1;

Thus when someone's snooping around our database and they look at DBA_OBJECTS / SYSOBJECTS / SYSTABLES and they see a name of USERNAMES_AND_PASSWORDS hopefully their curiosity will get the better of them and they'll do a SELECT thus firing our alert function.

This could be extended to extant views such as DBA/ALL/USER_OBJECTS; if you know none of your application logic queries these views then you could tripwire them up so as to be alerted when someone queries them - a potential snooper. Tripwiring up DBA/ALL/USER_VIEWS might also be a good option if the attacker selects a view's text/body before selecting from the view itself to ensure it's not a trap. They could of course just select from the VIEW$ table to bypass this but then we can hope that most attackers won't