11–20 of 25 posts
Earlier quoted context omitted.
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...
Earlier quoted context omitted.
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…
Earlier quoted context omitted.
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…
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:
250 2.1.0 Ok
RCPT TO:
250 2.1.5 Ok
DATA
354 End data with .
From: President Barack Obama
To: willvarfar
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.
$Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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: 250 2.1.0 Ok RCPT TO: 250 2.1.5 Ok DATA 354 End data with . From: President Barack Obama To: willvarfar Subject: LOLOL This is an account hijack!…
Earlier quoted context omitted.
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 i…
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.
Earlier quoted context omitted.
$ 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: 250 2.1.0 Ok RCPT TO: 250 2.1.5 Ok DATA 354 End data with . From: President Barack Obama To: willvarfar Subject: LOLOL This is an account hijack!…
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.
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
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 i…
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 no…
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.