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