SMTP Smuggling – Spoofing Emails Worldwide
sec-consult.com
sec-consult.com
This will still break DKIM (no signing for the fake second message, and even the first message's signature is going to be corrupt?), so a restrictive DMARC policy (p=reject; adkim=s) should mitigate this even if the server software is vulnerable, right?
And if someone tries to force a server to send email for an unauthorized source (e.g. make mail.example.org send a bogus mail for ycombinator.com) - well, this sucks in terms of potentially having to get the vulnerable host out of DNSBLs, but email is still not gonna get through (because of SPF) and I hope RBLs are gonna have a bit relaxed attitude towards this in the next few weeks?
(I don't seriously believe someone's not checking SPF, DKIM or DMARC those days - they're basically three cornerstones of modern mail server auth)
This isn't how DMARC works. Valid SPF OR DKIM will validate a message. So unless you drop your SPF policy DMARC will still pass. And unfortunately if you don't have a good SPF policy many mail servers will send your messages to the spam folder, so there isn't a good way to have only DKIM set up.
There are some discussions about requiring DKIM independent of SPF, but nothing published (nevermind adopted) yet.
Well, guess I have something to do for Christmas... (I run a non-Postfix MTA, gotta try to test it and see if I can implement a patch if it's vulnerable.)
Though I'd be interested to work out (or, be told!) how this might affect this vulnerability. I always assumed that most mail servers both check against SPF records and verify DKIM signatures if both are present, rather than it being a this-or-that thing, so DKIM offering some mitigation is not undone by the presence of SPF.
Not helped by O365’s previous stance of delivering DKIM failures to junk, although I understand they have or will soon reject them
As others have mentioned, this is not how DMARC works.
But I'd like to add to this that this is also not how 'adkim' works. It won't protect you from this particular attack.
adkim=s adds a strict alignment requirement for DKIM, meaning that the DKIM signature is not to be considered aligned unless the domain matches up to the subdomain level. The default 'relaxed' (adkim=r) alignment requirement allows you to use subdomains with a DKIM key placed under the administrative domain (aka 'root' or 'apex' domain) and vise-versa.
Unless you know exactly what you are doing and you have a situation where you do not control subdomains of your own domain, you probably don't want to use adkim=s.
Must have been a real thrill too the moment that email from “admin@outlook.com” went through and passed all SPF checks!
This is very much work in progress, and not documented yet. But it does detect the postfix issue.
http://www.postfix.org/smtp-smuggling.html
Others are even calling for the cancellation of the 37c3 talk: https://gay-pirate-assassins.de/@moanos/statuses/01HJ8D8XQ7Z...
I mean, c'mon... They did all that research and they expect me to believe they didn't understand the potential impact so they deferred to someone else's judgement? That's the excuse, seriously?
Besides, what would have been the harm in reaching out to projects like Sendmail and Postfix and ask them for their opinion? I'm more inclined to trust the judgement of the Postfix project then of Cisco.
[1] https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-...
The disclosure did go to the parties who he (or SEC Consult) seemed vulnerable.
If anything it just shows that Wietse have a way better understanding of SMTP than most of us normal humans.
> This might not seem bad at first, but looking at affected SMTP software on the Internet is a different story. After testing some popular e-mail software in their default configuration, it turned out that Postfix and Sendmail fulfil the requirements, are affected and can be smuggled to. Speaking globally, this is a lot (figure 31)!
It seems like Postfix was properly identified as a party to this issue.
https://www.mail-archive.com/postfix-announce@postfix.org/ms...
Add me to the list of people who are annoyed that they didn't give due notice to the Postfix maintainers.
> A short-term workaround can be deployed now, before the upcoming long holiday and associated production change freeze.
> NOTE: This will stop only the published form of the attack. Other forms exist that will not be stopped in this manner.
Kinda yes, kinda no. It seems the more relevant quantity is the software that is running (e.g. Cisco, Postfix, etc), rather than who hosts it. Even in a world where email was far more decentralized, this would still be a problem, perhaps even more so as there'd be a much longer tail for mail systems to be updated.
I don't agree.
The great thing about consolidating email services is that a fix for a vulnerability will typically be rolled out quickly, thus protecting the vast majority of email users from this particular attack.
Whereas with self-hosted/on-premise SMTP services we'd be chasing this for years and years. There are so many ancient, unmanaged and otherwise badly configured SMTP servers out there...
The difference here is that for the engineers that work for the large email service providers, it is their full-time responsibility to deliver email service. Whereas for the self-hosted solution, it is often a burden to the IT admin who doesn't get time/budget or have the knowledge to tend to the SMTP service. SMTP is often viewed as a set-and-forget type of thing, that can be set up in less than an hour, but it definitely is not.
I'm all for open-source, self-hosting and keeping control over your own resources, but for email (other than your private email address maybe) just outsource that to one of the well-known providers and focus on your actual job.
However not giving a large well established OSS project such as Postfix a notice upfront is not really a classy move.
> As part of a non-responsible disclosure process, SEC Consult has published an email spoofing attack that involves a composition of email services with specific differences in the way they handle line endings other than <CR><LF>.
https://www.mail-archive.com/postfix-announce@postfix.org/ms...
> 451 Bare line-feed; see http://haraka.github.io/barelf/
For example, Ubuntu 20.04 (LTS) is on 3.4 and 'smtpd_forbid_unauth_pipelining' is not available at all.
But for inbound connections from other smtp servers this actually makes sure the exploit works 100%, the smtp server behind the gateway has zero chance to detect the attack since it now gets a proper EOD sequence with another mail after. Just wow that they couldn't understand that this is a bad default.
Yeah, that's the result in this case. In other cases, not allowing malicious weirdness to pass may prevent a whole host of vulnerabilities from being able to reach your system at all.
Trade-offs. In this case, it happened to make you vulnerable. Which is better may only be clear with hindsight and experience, but I can see their reasoning.
However, their job being to provide additional security, by not fixing the issue (they can leave other "cleaning" rules in place, just this one needs to be forwarded either literally or rejected) they're imo defeating the purpose of their product insofar as I understand
From postfix - “Days before a 10+ day holiday break and associated production change freeze, SEC Consult has published an email spoofing attack that involves a composition of email services with specific differences in the way they handle line endings other than <CR><LF>.
Unfortunately, criticial information provided by the researcher was not passed on to Postfix maintainers before publication of the attack, otherwise we would certainly have convinced SEC Consult to change their time schedule until after people had a chance to update their Postfix systems. ” - https://www.postfix.org/smtp-smuggling.html
I'm sick of this trend of successful attacks being basically free marketing, while successful defences and maintainers working long hours for free to keep open source software secure never receive any praise.
> Unfortunately, criticial information provided by the researcher was not passed on to Postfix maintainers before publication of the attack, otherwise we would certainly have convinced SEC Consult to change their time schedule until after people had a chance to update their Postfix systems.
Maybe it will come out that somehow they messed up and the postfix crowd didn't get the memo when they were supposed to, but otherwise this is almost malicious in its negligent attitude.
Seems like they got too excited by having such an increduble exploit and got ahead of themselves? Either way, good way to create unnecessary grudges and resentment.
Not pointing fingers, but without looking at the actual email, the fault could lie on either side. "Missing critical information" is the excuse anyone would use after ignoring an important disclosure.
From the wording of postfix's announcement, it's possible they did disclose the vulnerability itself, but witheld some kind of important information, whatever that means. Or else we have to take for granted that the postfix crew are lying about it.
Either way, why would you publish literally right before Christmas? People need time to check if they're affected and update or patch systems. At best it's highly inconsiderate, and it seems more negligent than inconsiderate.
That does not excuse how they handled the disclosure to the opensource projects, which it appears they haven't handled well.
It allows someone to fake the sender, and have the fake bypass the signature schemes that are supposed to prevent fakery. But it's not that incredible; those signature schemes are addons for SMTP, which has always allowed this kind of fakery.
That is: I'm not exactly bowled-over to learn that it's possible to fake the sender of an email.
https://www.securityspace.com/s_survey/data/man.202311/mxsur...
In the article they even mention that postfix is affected, and show it as being the most used mail server online, by a large margin.
My employer (me included) does similar disclosures to vendors and open source projects. Being paid is never a condition for doing responsible/coordinated disclosure. I can't speak for others but, given the extortion allegation risk, I have trouble imagining this is how it went down
Much more common is being afraid it leaks due to patches landing too early or people talking, and so limiting it to the biggest vendors out there. In this case, I'd say they could definitely have done more coordinated disclosures without risking that...
This allows you to relay arbitrary commands via this SMTP server and submit another email. An outbound relay may pass SPF (unlike your IP). A vulnerable inbound server may let you bypass certain checks (such as SPF, but perhaps also a malware filter) because the server you're talking to is trusted by the internal receiving server.
As an outbound example, Microsoft wouldn't allow you to pretend to be admin@hotmail or admin@another_customer_of_hotmail's when logging in with your regular user account and submitting an email, but this attack lets you submit two emails appearing as one to their initial system, so only the first one is validated.
¹ the article starts with a TL;DR but that doesn't actually mention what the vulnerability is, only how cool and widespread it is (I agree that it is cool and widespread, but that's not a TL;DR of a technical article, that's a dumbed-down executive impact overview). It then goes on a 1700-word lecture on how email and http works before telling you more about the issue.
...with every other sentence ending in an exclamation mark.
It's a very badly targeted article. It reads like celebrity gossip, but the subject matter isn't for the kind of people that read that stuff. The people who are interested in this subject don't need their bottoms wiped for them.
I bailed out halfway through. I still don't know what servers are vulnerable.
Lately it hasn't been as easy I think.
If a message arrived and such settings aren't properly configured, many email providers will reject the message on the assumption that it's malicious.
https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-...