Cenzic 232 Patent
Paid Advertising
web application security lab

Enumerating Through User Accounts

I was playing around with a pretty custom Google dork primarily used for breaking into random user accounts through helpdesk systems today. As you might guess, it’s not particularly good for targeted attacks, and for a while I thought it was pretty useless in general (who wants to read helpdesk tickets all day long anyway)? Then I happened upon a small online retailer with far more serious issues.

The search engine had somehow indexed a valid credential for the system. The credential was in the QUERY_STRING as was the user ID and the customer ID. Why those two things aren’t the same on this system I really have no clue. But sure enough changing the customer ID allows me to switch accounts. Not only that, but the customer ID is directly used in the SQL query and if that wasn’t bad enough each “customer” that I was looking at was actually a reseller and each reseller had many customers of their own, each of which had email addresses, full names and addresses, without even attempting to attack the data base (yes, there is a lot more info in the database). Ouch, ouch, ouch.

Let’s just count the ways in which this was a poorly designed system. 1) They stored user credentials on the QUERY_STRING. 2) They didn’t invalidate the credentials over time. 3) They didn’t validate that the user ID matched the customer ID. 4) They didn’t even attempt to stop the SQL Injection of the customer ID by validating that it was a valid looking number. Also, the auth token itself was what I would call “small”, being only 10MM total possible combinations. I doubt highly that anyone is monitoring that system so guessing 10MM requests might seem out of the realm of possibility, but a low and slow attack might be successful - not that you have to when the search engine has done a nice job of storing the credentials permanently for anyone who wants one.

Anyway, this was one of the worst secured systems I’ve seen in a long time, and I thought you all might like to hear about it. Almost all of these issues surface at one point or another but rarely all at the same time. To make matters worse this isn’t exactly a little known website according to Alexa. Makes me worry about where I’ve used my credit card in the past.

3 Responses to “Enumerating Through User Accounts”

  1. Legionnaire Says:

    Makes me worry about where I’ve used my credit card in the past.

    This is really an issue. Web sites that store your credit card info for “future use” and for your own “convenience” are a primary target for attacks. And of course nobody can be sure whether their system is good, average or just sucks. And even if it’s good it’s not perfect so there’ll always be doubts whether your info is secure or not.

    So if you ask me, what makes a secure site more secure is the fact that is does not, under any circumstances, store sensitive data from its users.

  2. Thomas Says:

    lol, this made me look for dorks like these:
    inurl:select inurl:from
    shitloads of vulns :)

  3. RSnake Says:

    Yes. Ugh. That would definitely find you a ton of SQL injection issues in tons of sites. Why people construct SQL statements on the client I’ll never know. That’s not even sloppy coding, I have no idea what that amounts to. It’s just another level of bad that has no definition.