Okay, I had more trouble naming this post than I did writing it so bear with the title, because I think this is actually a pretty interesting problem. I went out for cigars with a few uber old school hackers from a huge company last night and we got to talking about databases. I’m not exactly sure what lead my brain down the path, but I suddenly realized there’s actually some fairly tricky issues around data deletion/retention that can lead to sensitive information disclosure. Here’s how it works. Let’s say you have three people, Alice, Bob and Cathy. Alice and Bob are both good users of a web site message board. Maybe they have special privileges, or maybe they are just communicating privately and Cathy wants that information.
In a secure database setup, if a user is deleted from a system no other user can take over their information after they are gone from the system. It’s not deleted (for data integrity/forensics, etc…) but it should be inaccessible to users. However, it turns out that not all database structures are made equal. Sometimes people use usernames as primary keys, or hashes of usernames, etc… instead of a non-reputable number. So let’s say Alice had her account deleted (intentionally or accidentally) there is an opportunity for Cathy to create a user account with the same name as Alice’s username and suddenly gain access to the same information that was supposed to be accessible only to Alice.
Let’s take this further and bring back an old favorite and normally not all that interesting attack - DoS by CSRF - that is forcing a user to click on a “delete my account” link. Typically DoS isn’t all that interesting to me, but here’s where you can actually use it to take over the account. This all relies on knowing the username of the person you are attempting to compromise. So let’s say Cathy creates an account on the message board. On a forum she places an image link to http://www.evil.com/x.php?.jpg which looks at the referring URL before making the decision on whether to show a benign image, or redirect the user’s browser via 301 or 302 redirect to the delete user function (eg: http://www.good.com/deluser.php). If the referring URL contains the username “Alice” the Alice user’s browser automatically is redirected and the account is deleted.
At this point Alice is probably almost immediately aware that her account has been deleted, so it is time critical that Cathy immediately registers with the same name “Alice”. Assuming the database uses the registered user as the primary key (or some derivation of the user name) it is possible for Cathy to now assume control over Alice’s account. Now she can read Alice’s private communication with Bob, or if Alice had some administrative controls, it might be possible for her to do other nefarious things, like promote other user’s access, etc…
There is an alternative to trying to detect Alice’s name in a referring URL. One example is if images can be sent within private messages or other out of band communications, assuming Alice is already logged in it will have the same net effect of targeting the individual user. It’s also fairly easy to detect this in a blackbox situation simply by creating an account, using all the functions, deleting it and re-creating the same name to see if any data was retained during the creation of the account. The point being, it’s bad form to use a username as a primary key unless it’s forever off limits for future users attempting to re-assume that username. Kind of an esoteric problem, but as I talked with the gurus, at least one of them had actually seen this happen in his own penetration tests against some very large well known companies. So there you have it, it’s not even just a theoretical attack. Yet another thing to look out for and at least one good reason to protect account deletion functions from CSRF.