Account Enumeration Via Database Collision

A Nops #AppSec Story

I've seen some interesting behavior in apps that use your email as a username.

I own a domain that I use for all my business correspondence. Let's call it http://nopsdomain.com 

The http://nopsdomain.com  is configured with a username wildcard. It will accept all addresses at that domain, and funnel it into one inbox. So [email protected], will end up in the same inbox.

This allows me to give each company their own unique address.

[email protected]
[email protected]
[email protected]

Would all be valid. I set this up as an anti- #spam mechanism. So if get spam at that address, I can easily black hole it all, and know who leaked.

The beautiful part is I can make up those address on-demand So when I'm standing at the grocery register, I can give the cashier a [email protected] address, without having to pre- #program anything.

I get, "do you work here?" all the time.

When I sign up for a website, I use the domain of the website as the "company" portion of my email scheme. When some #webapp creates that entry in the #database, the DB or app will sometimes append and increment a number to the username, when there is a collision.

This gives us a channel to repeatedly probe the database username entries, via guess and check. We get the output of our tests, by searching through the web app for our username, to see if it has been mutated or not. Often this happens in welcome emails.

So I'm interested in buying an #AR9 #pistol, and saw this sick little receiver set from http://newfrontierarmory.com 

But it's sold out. So I signed up for the "remind me when in stock" feature with a [email protected] address.

(we needed 1 gun pic in this thread)

But the welcome email gave me this!!! They set my username to be frontierarmory6. The 6 tells me that there were already 6 users: frontierarmory through frontierarmory5. So we collided the name of the email, with other users in the database.

"Admin" is also common username that sees this collision issue. When testing for this, I'll often use [email protected]

Here in this welcome email, we see that there are *13* (possibly 14) other admin accounts in this particular web application. Often these are test accounts.

But I have also seen this collision issue trigger other logical bugs. In one vulnerable app, the collision invoked the password reset mechanism, and sent *me* the reset notification. Account takeover. That one was bad, but specific to the vendor - so not widespread.

9 times out of 10 when you see this issue, it's simply username enumeration, which is usually not a big deal.

But, if those accounts have weak credentials...

I'm hoping to run into a case where it lets me enumerate other fields in the database - then it gets extra fun.