Hacker News Reader

Comment by TheDong | Hacker News Reader

Let me get this straight:

Your attack is "I can spoof an email from address". Is that not true for literally anything that accepts email?

The person who receives your spoofed message gets a link to the original message (message-url) and can download it, right? Can't they download it and validate spf, dkim, sender ip, whatever else?

This really sounds like it's working as intended. You asked to receive email. You receive email. You can perform filtering on the email to get rid of spam if you want.

You said "If that address is handled via an inbound route to a webhook [and they don't do any validation] [then phishing is trivial]"

Is that not identical to "if a company runs an SMTP server, you send a spoofed email, and they don't do any validation then phishing is trivial"?

View on HN

> Is that not identical to "if a company runs an SMTP server, you send a spoofed email, and they don't do any validation then phishing is trivial"?

Yes. Except in this case, the company is paying Mailgun to process inbound mail and attach SPF/DKIM/DMARC headers, which they don't do. And this is counter to their own API spec.

If you are running your own SMTP server, then you wouldn't be relying on headers from Mailgun.

Essentially though you are right, using Mailgun is akin to having an SMTP server without any spam protection in place, and limited ability to put that spam protection in place. You are better off running the server yourself.

The point here is that Mailgun customers won't be aware of this, and as such, it's a vulnerability.

"I can spoof any email address" leads to an open relay elevated to mailgun's exit ips, presumably with authentication headers added by mailgun's dkim-enabled servers. because it is possible (and likely) that many users will have an inbound email trigger some form of outbound email.

Essentially, vulnerability reporter is saying "hey, you've created a landmine field of open relays, which hackers only have to discover to abuse" and mailgun is saying "no we haven't, our USERS have created those"

that is why this is different from 'literally anything that accepts email.'

Ehhh, mailgun is NOT relaying the mail.. Their MTA is accepting the message and re-publishing it via a webhook HTTP post to the mailgun user's configured webhook URL(s).

right... and if any single user's implementation has inbound mail cause outbound mail, merge variables or multiple RCPT lines will likely cause this user to be an arbitrary mail relay using that user's auth.

Not sure how that would be the fault of mailgun or how spf/dkim validation enforcement on their end would help with poor design decisions of their clients.

If I'm reading this right, the recipient has to be a mailgun user, and the sender has to be another (yet spoofed) mailgun user.

The sender can be anyone. They don't need to be a mailgun user.

The recipient has to be a mailgun user, yes.

Reply on news.ycombinator.com