I'm not sure I understand the issue. What are you doing with the emails received via webhook that SPF/DKIM is needed? Are they being imported into a CRM and re-displayed?
I treat any email message sent to the subdomain(s) configured for sending transactional / marketing messages as untrusted and act accordingly.
Mailgun: Public Security Disclosure
21–30 of 31 posts
Re: Mailgun: Public Security Disclosure
#22Let 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 rece…
"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 t…
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).
Re: Mailgun: Public Security Disclosure
#23Just did a quick reading of their docs. They seem to provide raw headers in the JSON payload, and if they don't, they also have another mechanism where you can do the MIME parsing yourself. https://documentation.mailgun.com/en/latest/user_manual.html... Either of those two should allow you to do the SPD/DKIM/DMARC validation on your own. I wouldn't call this a security vulnerability. At best, is a lack of functionali…
a lack of security functionality by default is categorically a vulnerability. you are mincing words. having a redis exposed to the internet is a vulnerability, even though theoretically you could use lua scripting yourself to do some kind of authentication for every request. same stretch of logic applies there...
The mouse and keyboard are a vulnerability.
This definition makes the word pretty meaningless. I'd stick to things not doing what they promise to do. To do email doesn't require handling these other, tacked on later, protocols as well. They probably also fail to scan for Nigerian king scams but that isn't really a problem email solves so we don't fault them for it.
Re: Mailgun: Public Security Disclosure
#24Do you know if they verify the sender for ARF (abuse) emails that should be coming from the recipient's hosting provider e.g. yahoo. If not this could potentially be used for targeted denial of service by submitting fake spam reports on behalf of other recipients to add them to the suppression list?
If you look at the headers of email originating from mailgun, you will notice several headers they've added that include unique identifiers that identify the sending account and recipient.
ESPs receive FBLs/ARF from email providers through various delivery methods, "webhooks", ARF via SMTP..
So to pull off an attack someone would need to generate matching identifiers and know where to deliver the ARF with the forged data..
Re: Mailgun: Public Security Disclosure
#25This is a bit weird.
A friend reported a similar vulnerability at our company about 2 days ago.
Basically there was a insecure SMTP server that you could use to send emails from anyone (internal) to anyone (internal or external).
Literally every employee/contractor on the company network had access to exploit the vulnerability. All you had to do was know how to use the Send-MailMessage function in powershell or something similar.
We work at a publicly traded company, so you could imagine how bad this could've been.
I have no idea if they're using mailgun though. But I wonder if this is related or merely a coincidence?
Note: I'm being intentionally vague about the details for obvious reasons.
Re: Mailgun: Public Security Disclosure
#26I just implemented a custom little SMTP server with full DMARC authentication yesterday. If what you describe is true, then it’s truely baffling to not acknowledge that as a vulnerability. Aren’t the customers paying to not have the hassle of implementing these things? ^^
Exactly this!
Re: Mailgun: Public Security Disclosure
#27I'm not sure I understand the issue. What are you doing with the emails received via webhook that SPF/DKIM is needed? Are they being imported into a CRM and re-displayed? I treat any email message sent to the subdomain(s) configured for sending transactional / marketing messages as untrusted and act accordingly.
Yep - there are a number of scenarios:
- CRM system (obviously an issue) - Inbound email automation (eg. action based on reply from user / admin / etc)
But really, any inbound action where you don't want someone to be able to trivially spoof the sender, when the sender has SPF/DKIM/DMARC all configured.
For people using Mailgun purely for marketing email purposes, this is unlikely to be an issue, as you're unlikely to be using inbound routes for automation/processing.
Re: Mailgun: Public Security Disclosure
#28This is a bit weird. A friend reported a similar vulnerability at our company about 2 days ago. Basically there was a insecure SMTP server that you could use to send emails from anyone (internal) to anyone (internal or external). Literally every employee/contractor on the company network had access to exploit the vulnerability. All you had to do was know how to use the Send-MailMessage function in powershell or somet…
I don't think this is related.
The issue here is with inbound emails using Mailgun's inbound routes functionality.
Protecting your sending servers from abuse isn't an issue with Mailgun as far as I'm aware.
Re: Mailgun: Public Security Disclosure
#29Earlier quoted context omitted.
"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 t…
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.
Re: Mailgun: Public Security Disclosure
#30Did you ever find an alternative vendor that did this correctly in a manner that you were satisfied with?