What I think the 'SMTP Smuggling' attack enables

December 22, 2023

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.


Comments on this page:

(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.)

I disagree. The first mail server is also accepting a message with a non-CRLF LF, which violates RFC 5322: https://datatracker.ietf.org/doc/html/rfc5322#section-2.3

 o  CR and LF MUST only occur together as CRLF; they MUST NOT appear
    independently in the body.

The standard compliant way to deal with this is to refuse the message.

This problem is nothing new. djb did this properly in qmail back in the 90s: https://cr.yp.to/docs/smtplf.html

The SEC Consult blog post describes that DKIM only (without additional DMARC configuration) does not prevent the SMTP Smuggling attack:

The same goes for DKIM (DomainKeys Identified Mail) as well. DKIM allows signing the message data, including the From header. This signature can then be verified by the receiver with a public key that resides in the DNS. However, it is not enforced, which domain holds the public key (see figure 5).

By cks at 2023-12-23 14:03:49:

Oops, I keep making the same mistake when I talk about this, because I just assume something about using DKIM. In practice, to care about DKIM signatures, you have to care about DMARC like alignment, not merely DKIM by itself. Spammers and other bad people can and do DKIM sign their own email with arbitrary domains, so the pure presence of a DKIM signature is no use at all; you have to care about its alignment with the From: in order to reduce forgery. So it was in that sense I meant that if you only used DKIM you were safe; you have to use 'DKIM plus some form of alignment', but you have to anyway to use DKIM in any meaningful way.

(This is unlike SPF, where you can in theory use SPF alone (but in practice you'll wind up rejecting various good email because, for example, it was forwarded).)

PS: Given all of the things that are routinely done to email, my view is that you can't use the presence of a DKIM signature that doens't verify as a negative sign. I suspect you'll reject a certain amount of good email even if you check DMARC policies and only reject if they say to.

Written on 22 December 2023.
« Systemd will block a service's start if you manually restart it too fast
A DKIM signature on email by itself means very little »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Fri Dec 22 21:49:58 2023
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.