SEC Consult recently disclosed a security flaw impacting prominent and widely used email systems and software, significantly impacting the email industry. Despite this being a known, long-standing, and well-documented issue, several commonly-used email services and software were susceptible to this exploit. Let’s explore the situation, the problems this can cause, and why this matters both to all email systems; senders (such as ESPs) as well as receivers (such as mailbox providers).
The researchers showed that some software allows a bad actor to inject a specially crafted email message concealing a second message hidden inside the body of the original message – hence the name SMTP ‘smuggling’. This passes into the inbound SMTP server, which interprets the text as a separate second message. The exploit leverages a combination of two things:
- Insufficient handling of problematic end-of-message-like sequences in the sending software (such as dot-stuffing), and
- Relaxed interpretation of line feeds in the receiving software (very common, as it helps with compatibility for non-conforming clients)
What are the security implications?
Failure to detect and prevent this exploit in your email infrastructure software can result in your systems being exploited to target other email systems. The SEC paper showed how one very large email service (until it was corrected earlier this year) could be used to smuggle a message that claims to be from any other sender on their platform – such as the important-looking admin@domain.tld – to any recipient on their platform. This deceptive message will successfully pass SPF checks because that sender’s address is on the same email platform. Furthermore, the researchers demonstrated the ability to spoof any of approximately 1 million customer domains at that provider because the smuggled message will get an SPF “pass”.
How you’re protected with Halon
Halon follows the RFC standard for dot-stuffing, ensuring that any attempted threat message cannot pass through unchanged. In other words, if you are using Halon, you are protected against a bad actor trying to send through your platform as a channel for this purpose.
In addition to the critically important handling of problematic end-of-data sequences before sending messages (such as the dot-stuffing that Halon does), there is a question of how strict email servers should be as they speak with sending servers when receiving messages. Strictly following the RFCs has the benefit of reducing the avenue for future exploits like SMTP smuggling. Nevertheless, most receiving email servers today employ a more relaxed and forgiving parsing of SMTP which provides compatibility with all the non-conforming applications out there. Releasing a software update making the parsing more strict could break a lot of things. With that said, email software developers including Halon are now looking to make stricter RFC conformance the default for new installations, while making it optional for existing systems.
Additionally, Halon supports the BDAT/CHUNKING standard. It is a great SMTP protocol extension, which avoids the core issues altogether. This enables receivers to advertise that senders can be precise about the length of messages they are sending. Senders who support this are helping to avoid this type of vulnerability. With BDAT, whatever goes in as one message, will be treated as one message. This is enabled in Halon by default.
The long view
For a protocol that’s more than 50 years old, it’s fascinating to me that new exploits are being discovered and discussed. This is just further proof that email as a key communication tool is definitely not dead or dying!
Another facet of this story is that vulnerable systems have been running inside your data centers for years, perhaps decades, without any sign of a problem until now. It shows you can’t ignore them, thinking that you’re safe. It’s a bit like having a shiny new front door with the best security you can afford, while your back door has a rusty old lock that’s easily broken.
If you are running old legacy email software, now is a good time to look again at your infrastructure to see if it needs a refresh or replacement. Finally, I highly recommend reading the SEC Consult article; it provides a good overview of the issue.