
Gmail Account Hijacking Vulnerability - auza
http://blog.securityfuse.com/2016/11/gmail-account-hijacking-vulnerability.html
======
antoncohen
There is no account hijacking vulnerability here. The researcher was able to
send email as a non-existed Gmail account, they could have just as easily
registered that Gmail account. The only place this becomes a vulnerability is
if the account doesn't exists and you aren't allowed to register it (like
google@gmail.com), or if there is a temporary bounce from a legitimate
account.

Either way, it isn't a hijack, you can just send email from the "hijacked"
account through Google's servers, you can't receive email sent to the account.

~~~
hobarrera
As mentioned in the article, you can hijack accounts if the recipient has
blocked you.

~~~
antoncohen
It still isn't a hijack, it only allows you to send email as that user
_through Google 's servers_. It is always possible to send email as anyone you
want, just change the From address in your mail client [1]. Google attempts to
prevent unauthenticated From addresses going through their servers. So it is a
vulnerability because it bypasses intended restrictions (in some edge cases),
it just isn't a hijack as the post's title says.

[1] Yes, you have SPF and DMARC to contend with.

~~~
willvarfar
We have different definitions of "hijack" then. I think "hijack" is broad
enough to include sending mail _as_ someone, rather than just _spoofing_ them.

~~~
jlgaddis

      $ telnet localhost 25
      Trying 127.0.0.1...
      Connected to localhost.
      Escape character is '^]'.
      220 localhost.localdomain ESMTP
      EHLO jlgaddis
      250-localhost.localdomain
      250-PIPELINING
      250-SIZE 26214400
      250-ETRN
      250-STARTTLS
      250-ENHANCEDSTATUSCODES
      250-8BITMIME
      250 DSN
      MAIL FROM:<president@whitehouse.gov>
      250 2.1.0 Ok
      RCPT TO:<willvarfar@foo.bar.baz>
      250 2.1.5 Ok
      DATA
      354 End data with <CR><LF>.<CR><LF>
      From: President Barack Obama <president@whitehouse.gov>
      To: willvarfar <willvarfar@foo.bar.baz>
      Subject: LOLOL
    
      This is an account hijack!
    
      -BO
      .
      250 2.0.0 Ok: queued as 6AE031F5FE
      QUIT
      221 2.0.0 Bye
      Connection closed by foreign host.
      $

~~~
revicon
The difference between your example and the article's is that in the article's
example the emails are signed with DKIM and SPF by google which marks them as
legit emails vs your example which is not signed.

~~~
gcr
DKIM and SPF are intended only to authenticate the originating saver, not the
actual user account from the originating saver. To my knowledge, there is no
reliable mechanism (beyond PGP and the web of trust) for authenticating that a
certain sender actually sent an email message.

~~~
xoa
> _To my knowledge, there is no reliable mechanism (beyond PGP and the web of
> trust) for authenticating that a certain sender actually sent an email
> message._

You can use S/MIME as well, which has its own tradeoffs like all PKI but also
somewhat more widespread and mildly more seamless support. But your basic,
unless the e-mail is cryptographically signed in some manner there's no
significant authentication for email. If cryptographic signing was more
widespread then issues with spam, phishing/spearphishing, etc could be
significantly reduced simply by virtue of elimination of spoofing. That day
does not seem likely to come any time in the foreseeable future however, given
that if anything end-to-end cryptography in email (be it for signing or
encryption) seems to be going backwards, not forwards. It'll remain an
irritating situation for a long time to come.

------
bramblerose
How is this a vulnerability?

1) Email addresses added to the 'send from' list in Gmail are used to send
emails with an alternative From: address, but they always contain a correct
envelope-from header, so the emails will typically show up as 'Google (sent
by: SuperHacker@gmail.com)', or something along those lines.

2) gmail.com doesn't have a forced-fail SPF record, so one could just send
emails From: google@gmail.com using /any/ mail server, as long as the
receiving mail server doesn't interpret softfail as fail -- and it shouldn't.

------
homakov
Flagged, the title should be "How to take a gmail username, the hard way"

------
hacked-gmail
I'm looking for help. I suspect my google account has been attacked thru some
un-published vulnerability.

An unknown computer is still showing up as gaining access to my google account
AFTER I have done all the typical sanitation events to my google account:
changed password, disconnected all apps and services, and using 2-Step
authentication (even only using the Authentication, not SMS).

When my account was compromised ~10 days ago, the first event in the attack
was some service/app being connected to my gmail account. I regretfully did
not screen shot the event (google only shows the last 10 login-events on the
account).

I suspect some devious 3rd party app was installed/connected to my google
account and is still by by-passing all of the 2-step authentication, and
"disconnect all account" actions I have taken.

UPDATE: Here is URL/info where unknown computer is showing up:
[https://security.google.com/settings/u/0/security/activity](https://security.google.com/settings/u/0/security/activity)

Any ideas? How the hell does one contact google on this?

------
willvarfar
It is sad that the researcher didn't get paid anything, and that many other
'minor' reporters don't get paid anything either.

Presumably the researcher expended a lot of effort probing gmail and was that
time not worth a paltry reward?

vulnerabilities should be better rewarded.

~~~
jlgaddis
I am 100% in support of bug bounty programs and the like but I can completely
understand why they didn't pay for this one.

~~~
captn3m0
Can you elaborate?

~~~
parent5446
Reading a bounce email is not exactly award-worthy pentesting.

~~~
willvarfar
The bounce contained the activation link and code that is used to actually
confirm the mail redirection...

~~~
parent5446
OK, and none of that is significantly complicated to discover, nor is the
vulnerability particularly severe. I don't see any reason for why he should
receive compensation for this, especially considering bug bounties are already
at the company's discretion.

~~~
stcredzero
He basically did their QA work for them, not to mention a part of the work the
developer should have put into thinking about security. It does seem like a
minor vulnerability, but it could still be used to harass someone
significantly. He definitely generated something of value, and he should be
compensated. (Speaking as a veteran dev who knows that good QA can sometimes
be the secret sauce that makes a coding shop into an awesome coding shop.)

~~~
parent5446
Doing work for somebody does not automatically grant you the right to
compensation. He did this on his own accord, without petition from Google.
Google has no obligation to pay him at all.

The reason bug bounties exist is to reward hackers for reporting severe and/or
difficult-to-find security issues, so that they don't publish it before it's
fixed and so the company gets good PR.

In this case, the bug was clearly not that severe, and thus Google presumably
decided it was not worth it for them to issue a reward. There is no right to
compensation here, nor should somebody think they will definitely be paid if
they do a company's work for them.

~~~
stcredzero
_He did this on his own accord, without petition from Google. Google has no
obligation to pay him at all._

Well of course, but my reading of it is still that it's a damn shame he's
getting nothing. Just because someone has no right to something doesn't
necessarily mean they shouldn't get something.

~~~
parent5446
That may be true, but I'd argue there's also a difference between whether
somebody should get something, and whether it's a shame that they didn't. In
this case, maybe he should have gotten something, but the fact that he didn't
is not surprising and should be expected when doing free work.

