Abusing Gmail to get previously unlisted e-mail addresses(blog.0day.rocks) |
Abusing Gmail to get previously unlisted e-mail addresses(blog.0day.rocks) |
The OP found a way to discover 40000 new addresses of random people per day by brute forcing through a dictionary-generated list of plausible candidates.
Use it for Nigerian scams, Viagra ads, account hijacking, anything you please.
if it was your account
The problem is these sames sites have a self-signup, using a unique email as your login. So you can already find out if an email address is in use or not.
If you've going to 'leak' the data one way or another, dont sacrifice UX for the sake of it.
How do you sign up for Gmail without an email account in this case?
That's not great for all use cases, though - if I'm just trying to check out of a store, I don't want to have to bounce to my email to confirm stuff.
It's usually called "username enumeration" and there's plenty of pen testing firms that include this as a standard part of their process.
Every guide to setting up an email server starts with "turn SMTP verify off if your server has insecure defaults"
{"input01":{"Valid":"false","ErrorMessage":"That username is taken. Try another.","Errors":{"GmailAddress":"That username is taken. Try another."},"ErrorData":[""]},"Locale":"en"}
Requests against endpoints like this are going to be unauthenticated, since by their very nature they happen before the user is actually authenticated against the system. So you can burn through a few thousand (or hundred thousand) possibles and find out which ones actually have accounts.
From there, you can use one of many other email/password dumps and try authenticating. Hitting an endpoint where you can use an email and password is (hopefully) going to be much more guarded and will start blocking IPs when the rate or variance is too high.
That being said, I don't really know how you can stop the first step. There are plenty of answers here that say you should just let them "sign up" and then send them an email if they already have an account. But what happens if your signup process includes something like accepting payment? Obviously you don't want the user filling out all of that information again.
>RCPT TO: <someaccountthatdoesnotexist@gmail.com>
550-5.1.1 The email account that you tried to reach does not exist. Please try
550-5.1.1 double-checking the recipient's email address for typos or
550-5.1.1 unnecessary spaces. Learn more at
550 5.1.1 https://support.google.com/mail/?p=NoSuchUser j63si2824869ybj.160 - gsmtp
>RCPT TO: RCPT TO: <john.baker@gmail.com>
250 2.1.5 OK j63si2824869ybj.160 - gsmtpe.g. checking if my customers use competitors
https://www.npmjs.com/package/is-gmail-account-valid
const isGmailAccountValid = require('is-gmail-account-valid')
isGmailAccountValid('some.username', function(err, result){
console.log(err, result)
})If the account already exists, you send an email saying something like "Hey, you tried to sign up but you already have an account. If you need to reset your password, follow this link." If the account doesn't already exist, you send the normal "follow this link to confirm your account" email.
From the attacker's point of view all they get told is "Check your email to continue" whether or not the account is already registered, so it doesn't leak this information.
This isn't always suitable – a mail provider like Gmail is an obvious example – but it would work for the vast majority of websites / web applications.
To be honest, I don't really rate username enumeration as a severe problem for most projects – obviously it's a problem if you can determine whether an email address is registered on, e.g. Ashley Madison or similar though. But it's simply not the case that "nobody else acknowledges it as a problem" – it's a very widely used test, even if the severity is usually considered low.
I only mentioned the Gmail example because that's what the article was about, it sounded like you were suggesting a solution for that scenario.
1. Checking if an email address exists
2. Running it against a known dump of leaked data, with passwords etc
3. Try logging in to google account with the leaked password, hoping the user reuses passwords
Google encourages their users to use 2FA and has other measures to detect when logins are coming from unknown locations, so I guess they figured the risk of this was pretty low
Everybody should enable 2FA, and use the strongest 2FA you can. Buy a yubikey or other U2F key and use it for everything possible. And webdevs, please start supporting U2F in addition to RFC 6238 TOTPs. It's really not that hard.
I didn't know about this feature, but I often saw pictures of people I know when I tried. Apparently, it seems that for example just sharing IP address is sufficient to trigger this reasonable confidence. Not sure what other ways there may be. But indeed, it didn't work for a few random strangers from LKML I just tried.