
Abusing Gmail to get previously unlisted e-mail addresses - TjWallas
https://blog.0day.rocks/abusing-gmail-to-get-previously-unlisted-e-mail-addresses-41544b62b2
======
socket0
I'm going to have to agree with Google here, in that this isn't an exploitable
security vulnerability. Knowing that the mailboxes famous.celebrity@gmail.com
or controversial.journalist@gmail.com exist doesn't bring me any closer to
exploiting the knowledge. I don't know that Famous Celebrity is in fact THE
famous celebrity. I don't know whether Controversial Journalist still reads
mail sent to that account. Most importantly, I don't learn anything I couldn't
have learned by sending messages to every likely permutation of
famous.celebrity@gmail.com. This won't teach me anything particularly useful
for spearfishing, as I'm just throwing out a net hoping something gets caught.

~~~
qb45
To verify the existence of a single account all you need to do is go to
gmail.com and attempt logging into it. It's that simple. Sometimes you will
even see the profile pic so you know who this user is or claims to be.

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.

~~~
puddintane
This feature really grinds my gears. They should at least allow a feature to
disable showing the picture/name until the user has logged in. In some cases
I'm handing out my email to avoid handing out my actual identity because I
don't want to be spammed or followed. Until then I will continue to use a
false name and photo under my accounts signed up to google (apart from the one
work email I have thru them).

~~~
ggambetta
AFAIK the picture is only shown if Google is reasonably confident that it is
actually _you_ trying to log in.

~~~
qb45
> AFAIK the picture is only shown if Google is reasonably confident that it is
> actually you trying to log in.

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.

~~~
ggambetta
IP is a factor, but it's actually much more sophisticated than that :)

------
laurencei
I see companies trying to solve a similar issue on their password reset forms.
They ask you to enter an email address - then give you a reply "if that email
exists, we have sent a password reminder there".

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.

~~~
Xylakant
Do the same thing on the signup page: If the email is already registered just
progress the same way - send an email to that address and notify them that
they already have an account.

~~~
shinratdr
Which is great for most accounts, but what about a primary?

How do you sign up for Gmail without an email account in this case?

~~~
Xylakant
well, obviously this will not work for a primary account. It also adds
friction the signup process, leading to lower conversion rations. But for some
use-cases that may be a valid trade-off. Think dating sites, ..., stuff where
knowing that a certain email is subscribed already may be embarrassing or
worse (gay dating websites in certain countries).

~~~
shinratdr
Oh absolutely, it's a good system and many sites already utilize it.

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.

------
netsec_burn
This isn't an issue, you can do the same thing with the main login form and a
number of undocumented APIs. I've never seen anyone else acknowledge
"confirmation of email address existence" as a security issue and I don't see
why Google should be the first.

~~~
JimDabell
> I've never seen anyone else acknowledge "confirmation of email address
> existence" as a security issue

It's usually called "username enumeration" and there's plenty of pen testing
firms that include this as a standard part of their process.

~~~
inyorgroove
How do you prevent username enumeration when you want to have a username taken
feature in the sign up process? I suppose a way to handle that would be to
throttle the number of times such an IP can make those requests per month or
something. This still will not prevent a motivated attacker, or the casual use
to check if one or two usernames are registered.

~~~
JimDabell
In most cases, you can use an email address as the account name, and send a
confirmation email containing a link they can use to sign up.

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.

------
tyingq
There's a more API friendly endpoint to do this that returns a nice JSON
response, like this:

    
    
      {"input01":{"Valid":"false","ErrorMessage":"That username is taken. Try another.","Errors":{"GmailAddress":"That username is taken. Try another."},"ErrorData":[""]},"Locale":"en"}
    

See:
[https://gist.github.com/saml/2268291](https://gist.github.com/saml/2268291)

~~~
nailer
Checked and it still works too. Ported to node and added to:
[https://github.com/mikemaccana/is-gmail-account-
valid](https://github.com/mikemaccana/is-gmail-account-valid)

------
Dru89
From what I can tell, this is a useful first step towards credential stuffing.

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.

------
jsjohnst
Wouldn't a similarly effective method be to script SMTP and see which ones get
rejected as envelope to addresses?

~~~
smnscu
Sure, but I imagine there is some form of rate limiting on that, whereas the
point of the article is that they found an endpoint without rate limits.

~~~
jsjohnst
There might be a rate limit, but it's definitely possible to use this method
and get higher than the ~40k a day that the author attained.

------
lxchase
Email enumeration is often determined to be a UX choice rather than a security
issue. I've explored this in the past with the idea of doing this to popular
sites to build a demo/psychographic profile of an email address. Had a MVP
hosted but not working at the moment. I remember sites included FB, Sephora,
Home Depot, CafeMom, ESPN. Most have a XHR call to an API that determines if
email exists or a message saying "Your password is incorrect".

~~~
forcer
That is very interesting! I wonder if some companies already doing that to
"qualify" email addresses for sending spam, or more ethicaly enhancing their
own email lists with this.

e.g. checking if my customers use competitors

------
nailer
I got bored over lunch and made this a node module:

[https://www.npmjs.com/package/is-gmail-account-
valid](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)
        })

------
nubela
Is there something like this for Outlook?

------
therealmarv
Thanks Google :( I think they should at least put a rate limiter to that
endpoint.

~~~
WrtCdEvrydy
Nah, it's not a security bug, that means we can exploit it.

~~~
mkosmo
Makes me wonder what they require to classify the bug as a security bug.
Perhaps it gets classified otherwise since there's no data leakage other than
an address? The existence of an address isn't exactly confidential.

~~~
djhworld
I guess the authors idea of

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

~~~
mkosmo
Agreed, a popped account is a bad thing, especially if it's published as such.
A larger risk would be somebody popping one of the compromised-credential
repositories. Then you've got both username and password. But here we're
effectively seeing a slow-scale brute force...

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.

