SMTP Smuggling
SMTP Smuggling is a technique that allows you to send e-mail from almost any e-mail address by hiding another e-mail message in the data flow of an e-mail communication. Basically, another e-mail is injected into the message by exploiting interpretation differences in the SMTP protocol. Since the main message successfully passes security checks such as SPF, DKIM and DMARC, the injected message is delivered to the recipient boxes without any warning.
For a better understanding of the subject, we will first explain what SMTP is and what security measures it has. Then we will talk about SMTP Smuggling and how it bypasses the security measures that SMTP has.
In 2022, America’s Cybersecurity & Infrastructure Security Agency assessed federal and critical infrastructure partners, which revealed that 84% of employees took the bait by either replying with sensitive information or engaging with the malicious links embedded in a spoofed email.
What is the SMTP?
SMTP (Simple Mail Transfer Protocol) is the communication protocol used to transfer e-mail messages from one domain to another over the Internet. E-mail servers and other message transfer agents use SMTP to send and receive e-mail messages.
When you want to send a message from a mail user agent (MUA: Thunderbird, Outlook, Windows Mail, etc.) or simply an e-mail client, the application connects to your domain’s SMTP server, also known as mail transfer agent (MTA), and forwards the message to it. The server searches for the appropriate e-mail server for the domain name at the recipient’s address and sends the e-mail to that server.
The connection from a MUA to an MTA takes place as follows,
- The user sends an extended “hello” (EHLO) command that forwards the e-mail domain to the server.
- The server checks the e-mail processing requirement and responds with a response containing SMTP capabilities or supported features.
- The client then sends the “mail FROM” and “rcpt TO” commands with the necessary information to the server. These commands allow the client to identify the sender and recipient e-mail addresses. The server acknowledges both of these SMTP commands with a status code 250.
- Then the “DATA” command is sent to the server, indicating the start of the actual e-mail communication.
- A “Continue” response is received from the server. This is followed by the message headers “Subject”, “From”, “To”, followed by the message body and the end of data sequence “<CR><LF>.<CR><LF>” (where CR stands for Carriage-Return and LF stands for Line-Feed) or \r\n.\r\n, indicating the end of the message.
- Finally, the client terminates the connection via the “quit” command.
For clarity, we can think of e-mail as a letter in an envelope. While the sender and recipient address information written on the envelope is used as directions for the post office (in this case the post office is the SMTP protocol), the information written in the letter is the information in the DATA section. That is, the part that the reader e-mail client will see.
So, in e-mail communication, can the sender of the message add a fake address to the “From” header to make the recipient believe that the message is from someone else?
This is possible if the server does not have any security mechanisms. For this reason, e-mail spoofing was a big problem in the past before security mechanisms such as SPF, DKIM and DMARC were implemented. Today such misleading messages will be rejected by a well-configured server or at least marked as spam.
How SPF, DKIM and DMARC Help Prevent Email Fraud?
Since SMTP did not have a security mechanism when it was introduced, e-mail forgery was extremely easy. Various measures were developed to prevent this situation. These measures include SPF, DKIM and DMARC.
- SPF (Sender Policy Framework) is the most common e-mail authentication mechanism. It works by allowing sender IP addresses in special SPF/TXT DNS records. When SPF is implemented, the incoming SMTP server retrieves the domain from the address specified by the outgoing server in the “mail FROM” command, extracts the DNS records of the domain and checks whether the request comes from an IP address listed in the SPF record. However, the problem with SPF is that it does not perform any validation on the “From” header in the DATA section. So even if the email has a valid SPF record, the “From” header in the DATA section may have a random value.
- Domain Keys Identified Mail (DKIM) signs outgoing emails, including “From” headers, using a private key. Receiving servers authenticate the sender using the public key stored in the DNS records of the sending server. Again, the domain to be checked is not the domain in the “From” header of the DATA command, but the domain inferred from the “mail FROM” SMTP command. Therefore, even if an e-mail has a valid SPF record and a valid DKIM signature, it may still contain a forged “FROM” header.
- Domain-based Message Authentication, Reporting & Conformance (DMARC) verifies whether the “FROM” domain of the email complies with SPF checks and/or DKIM signatures. When DMARC is properly implemented, if there is a mismatch between the “mail FROM” and the “FROM” domain, the email will fail the DMARC check. Unfortunately, DMARC is not widely used.
What is the SMTP Smuggling Attack?
SMTP smuggling originated when researchers tested whether some common attacks that work on other protocols, such as HTTP, could also work on the SMTP protocol. SMTP smuggling takes its core concept from another class of attacks known as HTTP request smuggling, in which attackers trick a front-end load balancer or reverse-proxy into routing specially crafted requests to a back-end application server to be processed as two separate requests instead of one.
The new attack was designed by Timo Longin. Traditionally, the end of the DATA section in an SMTP conversation is indicated by the string “<CR><LF>.<CR><LF>” (more simply, Enter . Enter)”. The researchers considered the possibility that outgoing and incoming SMTP servers may interpret the end-of-data sequence differently. This is because if the SMTP servers have a different understanding of where the message data ends, the attacker could potentially go outside the message data. Worse, this could allow arbitrary SMTP commands to be set, or even to send separate emails.
Firstly, the researchers investigated whether there were any SMTP servers that defined the end of the DATA sequence differently. They found that some SMTP servers specified the end of the DATA section with the sequence “<CR><LF>.<CR><LF>.<CR><LF> or \r\n.\n\r”, while others specified it with “<LF>.<LF> or \n.\n”.
More unusual DATA end variations such as “<LF>.<CR><LF>, <CR>.<CR>.<CR>, <CR>.<CR>, <CR>.<LF>, <CR><LF>.<CR><LF>.<CR>” or “<CR><LF>\x00. <CR><LF>\x00.<CR><LF>” (where \x00 represents a null byte) were then tested to see if outgoing servers filtered out unusual data endings, and it was found that some outgoing servers did not filter out these variations.
As a result of the reconnaissance, they were able to find the DATA end sequence that allows them to send two e-mail messages in a single message. The “<LF>.<CR><LF>” sequence turned out to be effective on a special SMTP server called NemesisSMTPd, which hosts about one million domains and is used by e-mail services provided by Ionos (e.g. GMX).
Like GMX and Ionos, another SMTP provider that allowed outgoing emails with “<LF>.<CR><LF>” was Outlook and Microsoft Exchange Online. In this case, it meant that attackers could forge valid messages from millions of domains that listed Exchange Online’s SMTP servers in their SPF records.
However, the impact was more limited because Outlook and Exchange Online used the BDAT SMTP command to send messages by default. This is an SMTP feature that specifies the full message length in bytes instead of relying on end-of-data sequences, making SMTP spoofing impossible. However, it has a fallback mechanism because not all receiving SMTP servers support BDAT. If the incoming SMTP server does not specify BDAT support by returning the CHUNKING property, DATA is used as a fallback.
For an incoming SMTP server to be vulnerable to spoofing via Exchange Online messages, it must meet the following two conditions: It must not support BDAT and it must interpret “<LF>.<CR><LF>” as an end-of-data sequence. This was true for Fastmail and continues to be true for hundreds of thousands of Postfix and Sendmail deployments. After being notified about this issue, Microsoft has fixed the problem and messages with the string “<LF>.<CR><LF>” are no longer allowed through Outlook and Exchange.
During the investigation, while testing unusual end-of-data sequences against incoming SMTP servers for Alexa’s top 1000 domains, it was discovered that several well-known domains accepted “<CR>.<CR>” as an end-of-data sequence. These domains included Amazon, PayPal, eBay, Cisco, IRS, IMDb, and Audible.
All of these areas use the Cisco Secure Email Service, either with on-premises Cisco Secure Email Gateway deployments or the cloud-based Cisco Secure Email Cloud Gateway. Cisco Secure Email Gateway can be thought of as a proxy server that checks emails for malicious content before forwarding them to the user’s actual SMTP email server. The software has a configuration option with three settings for handling messages containing carriage return (CR) or line feed (LF) characters: Clear, Deny or Allow.
The behavior of the default “clear” setting consists of converting bare CR or LF characters into CRLF characters. That is, <CR>.<CR> is converted to <CRLF>.<CRLF>, which is a valid end-of-data string for all SMTP servers as it is equivalent to <CR><LF>.<CR><LF>. Therefore, if you are running an SMTP server that only accepts <CR><LF>.<CR><LF> as the end-of-data string and you have Cisco Secure Email Gateway with default settings in front of it, you are vulnerable to SMTP smuggling.
In contrast to other responsible parties, Cisco has stated that this is not a bug/vulnerability, but a feature of the software, and has not made any corrections at this time. To take precautions against this situation, Cisco Secure Email Gateway users should change this setting from “Clear” to “Allow”. Thus, messages containing “<CR>.<CR>” will be forwarded to SMTP servers unmodified and SMTP servers will reject these messages.
Outgoing SMTP servers that do not filter “<CR>.<CR>” and allow outgoing emails containing this string include Outlook/Exchange Online, iCloud, the local Microsoft Exchange server, Postfix, Sendmail, Startmail, Fastmail and Zohomail.
SMTP Smuggling CVEs in the Wild
CVE-2023-51764, CVE-2023-51765 and CVE-2023-51766, have emerged as mandatory vulnerabilities that pose critical security risks in the Exim mail transfer agent. These are due to certain SMTP configurations in Exim, making it easier for an attacker to inject unauthorized emails and bypass other security mechanisms such as the Sender Policy Framework. The primary exploit occurs with Exim in relation to the PIPELINING and CHUNKING features that enable sophisticated attacks on email server integrity. These vulnerabilities can only be addressed by updating Exim as soon as possible, and more security patches need to be uniformly applied to servers to ensure the highest level of protection against potential exploits.
If we discuss the effects on a global scale, SMTP Smuggling incidents first emerged through GMX and Ionos e-mail services. It was found that SMTP smuggling was allowed from approximately 1.35 million different domains, originating from domains that redirected MX records to Ionos.
Similarly in Exchange Online, it allowed smuggling from any domain that redirected SPF records to Exchange Online via the “<LF>.<CR><LF >” end-of-data sequence. This had implications for millions of domains worldwide, including some very high-value Microsoft-owned targets such as microsoft.com, msn.com, github.com, Outlook.com, Office365.com, openai.com, etc.
Particularly in relation to these vulnerabilities, let’s take a look at the points that can be detected by attackers through Shodan.io. By searching for specific configurations and version numbers that may be vulnerable to these CVEs, Shodan can provide discoveries for Internet-connected devices where exposed and therefore potentially vulnerable Exim servers can be found.
For example, we can start our search by typing “vuln:(“CVE-2023-51764” OR “CVE-2023-51765” OR “CVE-2023-51766”) or “Exim smtpd” in the search field in Shodan. Of course, you will need to have an authorized account “Akademic” or “Small Business API subscription” for these research results.
You can overcome this part with a simple Google dorks. By using the “search query” strings in the URI, some results can be reached with customized searches.
Let’s continue with a Shodan query:
Detections that the vulnerability may already be present have already been provided by Shodan sensors. With the help of different customized queries, relevant detections can be easily provided for targets that have already been pre-studied.
As you can see, the “Pipelining” and “Chunking” features are active.
Time Flow of Attack Vector
Experts from across the globe provided evidence of relevant violations and some interaction with affected organizations. Below is the sequence of events for the remediation of the breaches:
| 2023-06-07: | First outbound SMTP smuggling proof of concept (GMX) |
| 2023-06-08: | Discovery of outbound SMTP smuggling in Exchange Online |
| 2023-06-20: | Discovery of SMTP trafficking from Cisco Secure Email (Cloud) Gateway happened. |
| 2023-06/2023-07: | Development of tools, analysis of possible scenarios, further research provided. |
| 2023-07-26: | Contacting MSRC |
| 2023-07-27: | Contacting Cisco |
| 2023-07-29: | Contacting GMX |
| 2023-08-10: | Troubleshooting of the issue by GMX took place. |
| 2023-08-17: | Contacted CERT Coordination Center (CERT/CC) to discuss further with Cisco. |
| 2023-08-23: | Microsoft responded and rated the vulnerability with a medium risk. |
| 2023-09-13: | CERT/CC acknowledged the incident |
| 2023-10-16: | SMTP smuggling fixed in Exchange Online |
| 2023-11-29: | CERT/CC authorized public disclosure of SMTP smuggling as no software vulnerabilities were identified. |
| 2023-12-05: | Informing CERT.at and CERT-Bund about the planned release, providing a draft blog post, warning about Cisco configuration was realized. |
