Mailgun: Public Security Disclosure

[throwaway2346mg]

TLDR: Inbound email routes don't have SPF/DKIM/DMARC protection, meaning any inbound email sent to a webhook can be trivially spoofed / phished.

Mailgun describe inbound routes as:

"complex incoming messages are simplified and parsed into all of the data you need with Inbound Routes."

Mailgun refers to DKIM/SPF/DMARC with:

"Mailgun leads the charge in email authentication by requiring DKIM and SPF records by default before you can begin sending."

However, nowhere does it say that Mailgun does not provide SPF or DKIM validation checks on inbound emails. Confusingly, these headers appear only for a subset of inbound emails.

Attack scenario:

1) Pick any domain using mailgun for inbound email processing (trivially found via MX records).

2) Spoof an email from any address you want to impersonate (eg. [e-mail]).

If that address is handled via an inbound route to a webhook (eg. CRM system / other), then it will appear as from the spoofed sender without any DKIM/SPF flags. This makes phishing via Inbound Routes trivial.

Requested fix:

Include SPF (X-Mailgun-Spf), DKIM (X-Mailgun-Dkim-Check-Result), and Spam Assassin headers (eg. DMARC_QUAR / DMARC_REJECT / DMARC_NONE / DMARC_MISSING) headers for ALL inbound routes to a webhook. The application can then decide what to do.

Mailgun Response:

"Our security team has confirmed that our routes act as an open relay and that this is not considered a security vulnerability with Mailgun."

Nowhere in the Mailgun documentation / sales pages are inbound routes described like this, and in fact, they pretend to have protection as headers are sometimes present!

Note A: Using throwaway to not give information away for our own exposed systems. Note B: The spoofed email must not trigger above a certain spam assassin threshold (this is fairly trivial to do and openly testable by any attacker), otherwise it might get blocked by higher level Mailgun spam handling.

[1] - https://www.mailgun.com/products/send/inbound-routing/ [2] - https://www.mailgun.com/blog/deliverability/implement-dmarc/#chapter-5

[sylware]

SMTP was designed to work without DNS, you are not forced to pay the DNS mafia. To send and receive emails.

If you pay the DNS mafia, dkim and dmarc are overkill/excessive and SPF is more than enough.

And with an IP only SMTP server, SPF is builtin: the reply-to address must include the same IP than the one use to send the email. No DNS here and still a very good SPF validation.

So, all that has a nasty smell of big email providers trying to give hell to self-hosted people/orgs, or a mistake of admins of big email providers).

You have to tell those admins, and if actually a blockade is detected, you have to go legal.

Additionally, if those are malicious expect them to shadow hire (a) team(s) of hackers to destroy your public servers.

[throwaway2346mg]

I'm not sure if this is relevant in regards to the security disclosure itself. If you're not using Mailgun then this doesn't affect you.

However, with regards to "SPF is more than enough", the fact here is that the SPF header isn't passed to the webhook, so it can't used in a mailgun inbound route.