5 ms·
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 registere
by antoncohen 10y ago
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 10y agoAs mentioned in the article, you can hijack accounts if the recipient has blocked you.
- antoncohen 10y agoIt 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 10y agoWe have different definitions of "hijack" then. I think "hijack" is broad enough to include sending mail as someone, rather than just spoofing them.
- jlgaddis 10y ago$ 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 10y agoThe 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 10y agoDKIM 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 10y ago>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.
- discreditable 10y agoDMARC 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 https://en.wikipedia.org/wiki/DMARC
- gcr 10y ago(pardon, meant to write "originating server" above)