Gmail Account Hijacking Vulnerability | Hacker News Reader

Gmail Account Hijacking Vulnerability

blog.securityfuse.com

66 pointsauza23 comments

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.

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

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.

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

  $ 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.
  $

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.

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.

>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.

DMARC utilizes DKIM/SPF to validate the From: account. In short, if I send from foo@bar.com, then my message must also pass their SPF/DKIM policy.

https://en.wikipedia.org/wiki/DMARC

(pardon, meant to write "originating server" above)

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.

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

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

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

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.

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.

Can you elaborate?

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

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

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.

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.)

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.

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.

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.

Reply on news.ycombinator.com