Attacks on Email Sender Authentication | Hacker News Reader

Attacks on Email Sender Authentication

blackhat.com

85 points_wldu13 comments

This talk is from the 2020 Black Hat Conference. The presentation (40 mins) is on YouTube: https://www.youtube.com/watch?v=ar_lVqkWcHk

One of the authors of the research, Jianjun Chen, demonstrates email spoofing using Gmail, Yahoo and Outlook in these short (1 min) videos from 2020.

Email spoofing demos (2020): https://www.youtube.com/playlist?list=PL--A-gWJV1dJ19Syhkzkl...

Status:

- Gmail: "fixed"

- Yahoo: "reported to Yahoo security on Oct 28th, 2019. They disregarded our report."

- Outlook: "reported to Microsoft security on Oct 28th, 2019. They disregarded our report ("Unfortunately your report appears to rely on social engineering to accomplish, which would not meet the bar for security servicing")."

I assume the response from the Outlook team ("social engineering") refers to the fact that body of the email must still contain a phishing link.

SPF/DKIM/DMARC are not intended to authenticate email senders. So it is no great surprise that they don't work for that purpose. SPF/DKIM/DMARC are intended to authenticate email servers.

If you want to authenticate an individual email sender then that sender would sign their email. Just like with paper mail. Sure you can try to determine if the sender is legit by looking at the postmark on the outside of the envelope but that is not what it is for. The result will and can not be reliable.

True, but you're continuing to use confusing nomenclature.

SPF is Sender Policy Framework.

Something like "Originating Entity Policy Framework" might be more correct.

"Sender" refers to the domain, read it as: the sender domain policy allows X and Y servers to deliver emails for this domain (or subdomains). But I agree that is confusing, also I was unaware that only the HELO and MAIL FROM in the envelop are used, I should check my postfix config..

Right, the "Sender" in SPF is the Originating Entity (domain/domain owner), which defines a policy to explicitly bless a set of mailhosts allowed to send messages on behalf of users.

Posted article uses "Sender" for the user, not the entity. Authentication inside the entity is the entity's responsibility. SPF is only concerned with verifying that the mailhosts offering to deliver messages on behalf of entity are allowed to do so.

If you read the paper you will understand that they actually managed to forge what you call "the postmark" to fool the recipient server/software.

Email being a distributed system, the responsibility of identifying the sender is shared, and if implemented property works well.

The job of the client and recipient server is to verify the domain of the sender, according to rules defined by the sender.

The job of the sender server is to authentify the user account.

Implementing things properly is hard...

New and interesting writeup on what ProtonMail flagged to GMail for replaying of email where some empty fields in the original were not DKIM'd and hence injectable

https://news.ycombinator.com/item?id=29942900 (it's not my post, but it was the first one here and deserves a comment or two as it is interesting IMO)

Forgot if it was 2020 or 2021 but one BH talk blew my mind about how insanely complex email displayname and sender format is and how different clients do their own thing.

I think you mean this very amusing video:

https://www.youtube.com/watch?v=xxX81WmXjPg

I've always just checked for an @ and be done.

(2020)

We should never ever rely on emails for anything important. We should always confirm and authenticate important matters with a separate channel like meeting in person or video calling or calling the persons to confirm the veracity of an important action that was written in an email. Unfortunately that is not the case and there are so many such frauds.

The use of email for important matters leads to Business Email Compromise fraud:

https://www.fbi.gov/scams-and-safety/common-scams-and-crimes...

"We should never ever rely on emails for anything important. "

This made me laugh out loud. I don't think "hackers" here on HN realize how much business is done by email these days, including plenty of important business. And no, if you are a CEO, and call your counterparty after your emails to confirm - you're not going to get anything done.

Meanwhile, a lot of these same hackers working in software development put email account control at the root of their trust chains (ie, with an email account I can drive a password reset).

>We should never ever rely on emails for anything important.

Busy people will never get anything done otherwise. Not going to happen.

Reply on news.ycombinator.com