What is SMTP Smuggling and how can you deal with it?

There are quite a few articles on DevCentral discussing HTTP Request Smuggling (by myself and other authors) and SMTP Smuggling is very similar in concept – so if you haven’t read up on HTTP Request Smuggling already, I’d encourage you to do so. Still, I’ll try and cover SMTP Smuggling well enough here that those articles aren’t an absolute pre-requisite!

The SMTP Protocol

Much like HTTP, SMTP comes from a simpler time – a more naïve time, you might say – when clear-text protocols ran the world. As such it has been extended and progressed over the years but remains backward compatible with that very first implementation from 1982. These days you’ll most often see it encapsulated in TLS (either SMTPS or SMTP with STARTTLS), but in its most basic form an SMTP conversation looks something like this (“>” denotes something the client sends, “<” denotes something sent by the server):

TCP connection begins

< 220 email.example.com ESMTP SendMail
> HELO sender.example.com
< 250 Ok
> MAIL FROM:<sender@example.com>
< 250 Ok
> RCPT TO :<recipient@example.com>
< 250 Ok
> DATA
< 354 End data with <CR><LF>.<CR><LF>
> Subject: Test email
> From: Example Sender <sender@example.com>
> To: Example Recipient <recipient@example.com>
> Email body goes here
> .
< 250 Ok <UUID>
> QUIT
< 221 Bye

 

There are actually a lot more possible commands and responses than shown here, but in its very basic form, the conversation above would result in a single email being sent from the Mail Transfer Agent (MTA, usually an SMTP server like Sendmail) at sender.example.com to the MTA at email.example.com.

You can see above also the clear delineation between commands that the receiving MTA needs to interpret (all uppercase and each one receives a numerical response code) and commands inside a data block which are intended to be interpreted by the Mail User Agent (MUA, an application like Outlook that you read the email in). Everything after “DATA” and before the “<CR><LF>.<CR><LF>” is essentially ignored by the MTA and is left for the MUA to deal with (actually it will also be parsed by the Local Delivery Agent or LDA, though in many common scenarios the MTA & LDA are effectively the same application such as Exchange).

.. you might already be able to see where we’re going with this.

Where does one email end and another start?

Just like how an HTTP client tells a server where the message ends with Content-Length or Transfer-Encoding headers, the MTA helpfully told us how to end the email – it should end with <CR><LF>.<CR><LF> (or in another notation, 0x0d 0x0a 0x2e 0x0d 0x0a), and that’s exactly what we did.

But remember, SMTP is an ancient protocol, and in simpler times we liked to play fast-and-loose with protocols. Some MTAs didn’t send the full sequence to end the DATA block and, instead, preferred Unix line endings (<LF>.<LF> or 0x0a 0x2e 0x0a) and so MTAs quickly became more permissive in their handling of line endings to ensure they would inter-operate. In simpler times that’s how we fixed compatibility problems – I’d like to think that now, in 2024, we’d make sure all MTAs followed the RFC rather than allowing broken ones to talk to us but perhaps I’m too optimistic!

So what’s the problem?

Imagine that your sending MTA only accepts <CR><LF>.<CR><LF> as a line ending, but the receiving MTA more liberally accepts <LF>.<LF> as line endings; what would happen if the sender constructed an email body which contained <LF>.<LF>? The sending MTA would see just one email body, but the receiving MTA would see two. Let’s just show the sending side messages here for clarity:

HELO sender.example.com<0d><0a>
MAIL FROM:<sender@example.com><0d><0a>
RCPT TO:<recipient@example.com><0d><0a>
DATA<0d><0a>
Subject: Ah ha!<0d><0a>
From: Example Sender <sender@example.com><0d><0a>
To: Example Recipient <recipient@example.com><0d><0a>
Email body goes here<0a>
.<0a>
MAIL FROM:<theceo@example.com><0d><0a>
RCPT TO:<hr@example.com><0d><0a>
Subject: Give that man a raise!<0d><0a>
From: The CEO <theceo@example.com><0d><0a>
To: HR <hr@example.com><0d><0a>
Please give this man an enormous raise, he deserves it!<0d><0a>
I suggest 50%!<0d><0a>
Best Regards,<0d><0a>
CEO<0d><0a>
.<0d><0a>
QUIT<0d><0a>

I’ve represented the line endings with <0d> for a carriage return and <0a> for a line-feed. You can see that the first email ends with <LF>.<LF>, and in our example here the sending MTA ignores this and sees only one email – the email is a bit weird because it contains SMTP commands, but the MTA doesn’t know that because it doesn’t look. The receiving MTA, meanwhile, is more permissive and so ends the first email after “Email body goes here” and sees two emails – voila, smuggling!

Smuggling, what is it good for?

Just like HTTP Request Smuggling, SMTP smuggling is good if you want to sneak a message through that would otherwise have been rejected by a protection mechanism like SPF or SKIM. The most obvious use is in constructing more convincing phishing emails which will appear to be very legitimate indeed (and pass all the security checks), though I’m sure attackers will find new and novel uses for the technique as time passes.

If you want to know more – like which email systems are known to be susceptible – then I’d highly recommend reading SEC Consult’s original research disclosure. They go into the SMTP protocol and smuggling techniques in more detail than I have here and have a full run-down of the systems they’ve tested against and the outcomes they had.

How can F5 help?

Great news! F5 products can help here – BIG-IP AFM has Protocol Inspection functionality which can block many SMTP smuggling attempts under the “Malformed SMTP PDU” inspection:

 

You just need to ensure that Action is set to Reject or Drop for that inspection and that your inspection profile is associated with your SMTP Virtual Server. The BIG-IP AFM Operations Guide has more documentation on how to use Protocol Inspection.

 

Note: The only caveat to the above is that the Malformed SMTP PDU inspection cannot block or drop SMTP requests where the line ending is <CR>.<CR> which is a known smuggling technique against Cisco Secure Email Gateway – if you use Cisco Secure Email Gateway as your receiving MTA then you should follow the advice in SEC Consult’s blog and change CR & LF Handling to Reject.

 

I hope that helps shed a little light on SMTP Smuggling as well as your options for preventing it in your network using F5 products!