Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mailgun: Public Security Disclosure

news.ycombinator.com

Post reply on HN
Print view View original

11–20 of 31 posts

Re: Mailgun: Public Security Disclosure

#11

Post by sandstrom »

Just 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 functionality on their part, where a (reasonable) wish would be that they as a email receiver would perform the SPF/DKIM/DMARC validation and provide the results of that check as headers or other metadata.

Re: Mailgun: Public Security Disclosure

#12

Post by elif »

sandstrom wrote: post #11

Just 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...

Re: Mailgun: Public Security Disclosure

#13

Post by elif »

TheDong wrote: post #4

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 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 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.'

Re: Mailgun: Public Security Disclosure

#14

Post by throwaway2346mg »

elif wrote: post #12
sandstrom wrote: post #11

Just 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...

Agreed. I think the point here is that what % of Mailgun users will be doing this additional processing? I suspect it's basically 0%.

Why? It's not outlined in their specs, their sales copy implies they are handling it, and sensible headers are sometimes there which is extra misleading.

Re: Mailgun: Public Security Disclosure

#15

Post by throwaway2346mg »

Padlock4543 wrote: post #8

I don't fully understand what the role of the inbound service is on "setting headers". I believe SPF/DKIM/DMARC are mostly (not fully) DNS verifications. Shouldn't these be setup by the domain owner (sender/outbound)? Is the problem that they don't do the verifications for SPF/DKIM/DMARC for inbound emails?

> Is the problem that they don't do the verifications for SPF/DKIM/DMARC for inbound emails?

Yes - the result of the checks aren't passed through for inbound emails (when sent to webhooks).

Re: Mailgun: Public Security Disclosure

#16

Post by throwaway2346mg »

TheCycoONE wrote: post #9

Do 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?

I'm afraid I haven't checked this - are you a Mailgun user and want to report back on this? Alternatively, hopefully Mailgun themselves will spot this and can respond directly.

Re: Mailgun: Public Security Disclosure

#17

Post by throwaway2346mg »

As pointed out on Reddit [1], if you want to trivially see companies using Mailgun it's as simple as looking at:

https://securitytrails.com/list/mx/mxb.mailgun.org

https://securitytrails.com/list/mx/mxa.mailgun.org

[1] - https://www.reddit.com/r/sysadmin/comments/14vtszl/comment/j...

Re: Mailgun: Public Security Disclosure

#18

Post by junon »

elif wrote: post #12
sandstrom wrote: post #11

Just 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...

Ehhhh not convinced that's a fair comparison.

In Chalk (node.js library for terminal coloring via escape codes) we had a "vulnerability" reported to us that inputs to our library that had malicious escapes were passed through and thus our library allowed RCE.

Never in the docs did we claim we sanitized inputs, nor should we - the net result is that the library would be slower and bulkier for the 99% case and protect only a fraction of the remainder from any sort of real attack - and those users should probably be doing their own sanitization anyway.

Is that really our fault? No, not really. I don't think that if mailgun doesn't support it, should it be considered a vulnerability. GP had it right - could be a cool feature but this is not some oversight unless they market that as being a security measure.

Re: Mailgun: Public Security Disclosure

#20

Post by lumpa »

Coronon wrote: post #10

I 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? ^^

Your comment was dead, as are all your comments and submissions. Probably another case of a spam filter gone bad. As dang says[1], email hn@ycombinator.com and they'll solve it.

[1] https://news.ycombinator.com/item?id=36577441

Post reply on HN