2023-12-22
What I think the 'SMTP Smuggling' attack enables
The very brief summary of SEC Consult's "SMTP Smuggling" attack is that under the right circumstances, it allows you (the attacker) to cause one mail server to 'submit' an email with contents and SMTP envelope information that you provide to a second mail server. To the second email server, this smuggled email will appear to have come from the first mail server (because it did), and can inherit some of the authentication the first mail server has.
(It's important to understand that the actual vulnerability is in the second mail server, not the first one; the first one can and often must be completely RFC compliant in its behavior.)
The obvious authentication that the smuggled email inherits is SPF, because that's based on the combination of the sending IP (the first mail server) and the SMTP envelope sender (and possibly message From:), which is under your control. So you can put in a SMTP envelope sender (and a From:) that claims to be 'from' the first mail server, and the second mail server will accept it as authentic.
(An almost as obvious thing is that the smuggled email gets to share in whatever good reputation the sending email server has with the receiver. This is most useful if you can get a big, high reputation mail system to be the first server, which is possible (or perhaps 'was' by the time you're reading this).)
If you forge email as being from something that has a DMARC policy that passes the policy if SPF passes, you can also get your forged email to pass DMARC checks. The same is true if the second email server happens to be something that imposes its own implicit DMARC-like policy that accepts email if SPF passes and (and possibly that SPF is 'aligned' with the From: message address).
What you can't fully do is inherit DKIM authentication. You can add your own valid DKIM headers to your smuggled email, but you can only do this for domains with DNS under your control (or domains where you've managed to obtain the DKIM signing keys). This probably doesn't include the first email server and its domain, and because the first email server doesn't recognize your smuggled email as an actual email message, it won't DKIM sign the email for you. The only way you can get the domain of the first email server to DKIM sign your second email for you is if the second email server is also an internal one belonging to the same domain and it will DKIM sign outgoing messages. This general configuration is reasonably common (incoming and outgoing email servers are often different), but usually they run the same mail software and so they won't have the different interpretations of the email message(s) that SMTP Smuggling needs.
The result of this is that if the second (receiving) email server doesn't check SPF results and only pays attention to DKIM (which is increasingly mandatory in practice), it's almost completely safe from SMTP Smuggling even if it accepts things other than 'CR LF . CR LF' as the email message terminator. Since SPF breaks things (also), this is what I feel you should already be doing.