Connections between email clients and servers provide two ways to be protected with TLS: While implicit TLS
encrypts the connection from the start and runs on a separate port, STARTTLS
provides a mechanism to upgrade existing unencrypted connections to TLS.
Sometimes STARTTLS is seen as an opportunistic encryption mode that provides TLS protection
only when available. This is trivially vulnerable to downgrade attacks. However, modern email clients
usually have the expectation that STARTTLS is enforced, and when enabled, no unencrypted communication
is possible.
Upgrading connections via STARTTLS is fragile and vulnerable to a number of security
vulnerabilities and attacks. We found more than 40 vulnerabilities in STARTTLS implementations. We
conclude that these vulnerabilities are so common that we recommend
avoiding using STARTTLS when possible.
Attacks
We assume a Meddler-in-the-Middle (MitM) attacker who can modify connections established between an
email client and the email server of a provider.
Stealing Login Credentials with SMTP and IMAP via Command Injection
In 2011 Postfix developer Wietse Venema described a bug
in STARTTLS implementations that allowed
injecting plaintext commands that a server interprets as if they were part of the
encrypted connection. This works by sending additional commands with the STARTTLS command to the
server in the same TCP segment.
We found that despite being known since 2011, this vulnerability is still very common. We found
15 vulnerable implementations, and in scans, 2% of all mail servers showed this vulnerability.
This command injection can be used to steal credentials with the SMTP and IMAP protocols.
Our attack requires a Meddler in the Middle (MitM) attacker that can modify network traffic and has
login credentials for their own account on the same server. The attacker can inject commands
that authenticate them and then start sending (SMTP) or storing (IMAP) an email.
The login credentials sent by the victim will be stored in the email that the attacker
can access.
The command injection can also be used for a cross-protocol attack to serve HTTPS content with
the mail server's certificate. Detailed descriptions of these attacks can be found in our paper.
Mailbox content forgery via Response Injection
We discovered an attack similar to the command injection in email client applications.
We call this a response injection.
This bug affected many popular mail clients, including Apple Mail, Mozilla Thunderbird, Claws Mail, and
Mutt.
By injecting additional content to the server message in response to the STARTTLS command before the TLS
handshake,
we can inject server commands that the client will process as if they were part of the encrypted connection.
This
can be used to forge mailbox content.
IMAP connection downgrade via PREAUTH and credential-stealing with REFERRAL
In the IMAP protocol, a server can signal the client in the first message that it is already authenticated
via
the PREAUTH command. The protocol forbids using the STARTTLS command in an authenticated state. Therefore, if
a client application accepts PREAUTH, it cannot enforce STARTTLS.
A Meddler in the Middle attacker can use this to prevent STARTTLS from upgrading the connection and force
a client to an unencrypted connection.
This vulnerability was originally found in
Trojitá in 2014. We discovered that multiple other
email client applications were vulnerable to the same bug.
This bug is especially severe in combination with the IMAP features Login Referrals and Mailbox Referrals.
These commands allow a server to instruct a client to log into another IMAP server. By using PREAUTH to
prevent an encrypted connection, an attacker can use referrals to force a client to send credentials to an
attacker-controlled server.
Fortunately, the referral features are not supported by many clients.
We found only one client - Alpine - vulnerable to this combination of PREAUTH and referrals.
Additional Attacks
We found additional attacks, whose security impact may vary for implementations.
Please see our paper to learn more about these attacks.
Conclusion
All vulnerabilities described here rely on the transition of an insecure connection to a
secure connection.
Implicit TLS does not have such a transition and is therefore not vulnerable to any of these attacks.
We therefore consider implicit TLS a more secure option than STARTTLS.
We also point out that STARTTLS always introduces at least one extra connection
round trip. So implicit TLS generally provides better performance.
Impact
The demonstrated attacks require an active attacker and may be recognized when
used against an email client that tries to enforce the transition to TLS.
We have informed all popular email client and server vendors and most issues are already
fixed.
We think that the demonstrated attacks would be difficult to execute on a large scale, and we
primarily expect them to be used in targeted attacks.
As a general recommendation, you should always update your software and (to also profit from faster
connections)
reconfigure your email client to use implicit TLS only (see below).
Recommendations
For Email Client Users
If possible, we recommend that users check and configure their email clients to use SMTP, POP3 and IMAP with
implicit TLS on dedicated ports, i.e., SMTP/Submission on port 465, POP3 on port 995, and IMAP on port 993.
This is in line with already existing recommendations in
RFC 8314 and was already recommended
by security professionals before.
Some mail service providers, notably Microsoft and Apple, do not support implicit TLS for SMTP/Submission.
We recommend that users ask their mail service providers to offer the more secure implicit TLS option.
For Application Developers
Both email server and client applications should offer implicit TLS by default.
In the long term, software developers may decide to not support STARTTLS at all and thus simplify both
their code and configuration dialogs and files.
We recommend auditing all applications supporting STARTTLS - both on the server and the client side -
for the bugs discovered.
Most importantly, applications need to ensure that no unencrypted content gets processed as part of an
encrypted connection.
IMAP applications must make sure that they do not allow PREAUTH in combination with STARTTLS.
We provide the EAST toolkit, which allows testing
applications.
For Mail Server Administrators
Make sure your server supports implicit TLS for all supported protocols.
If possible, consider disabling STARTTLS for IMAP, POP3 and SMTP submission.
If you really need to support STARTTLS, we recommend testing your server with our tool for the command
injection vulnerability for all supported protocols.
If your server software is vulnerable, you should ask your vendor for a security update.
FAQ
Isn't STARTTLS insecure anyway?
STARTTLS is used in two "modes", "opportunistic", and "enforced".
Email clients must authenticate themselves with a username and password before submitting a new email or
accessing existing emails.
For these connections, the transition to TLS via STARTTLS must be strictly enforced because a
downgrade would reveal the username and password and give an attacker full access to the email account.
How can I test if my software is vulnerable?
We provide the EAST toolkit that allows testing email clients
and servers.
Testing an email client is more complex, and we refer to EAST's Fake Mail Server component.
Are other protocols with support for STARTTLS or similar mechanisms affected?
We expect to see similar vulnerabilities in other protocols using STARTTLS, e.g., XMPP, FTP, IRC, or LDAP.
Thus, our recommendation to avoid STARTTLS and use implicit TLS when possible applies to those protocols as
well.
We encourage security researchers to look for such vulnerabilities in other protocols.
Some protocols only support STARTTLS and provide no implicit TLS mechanism.
We recommend that standards bodies define implicit TLS modes for these protocols and that future protocols
do this by default and avoid STARTTLS completely.
What about communication between email servers (MTA to MTA)?
Traditionally, STARTTLS between email servers only protects against passive attacks and is vulnerable to
active attacks such as STARTTLS stripping.
Thus STARTTLS vulnerabilities do not give an advantage to the attacker.
However, efforts like MTA-STS and DANE provide authentication mechanisms for MTA
to MTA connections.
Therefore, server software should be investigated for STARTTLS vulnerabilities as well.
Particularly relevant are the buffering bugs, which can happen both for the sending (response injection) and
receiving (command injection) side of a mail server.
We have found and reported some vulnerabilities in server software during our research.
Currently, there is no standardized way to use implicit TLS for MTA to MTA connections.
Therefore, it is not possible to avoid STARTTLS without changes to the protocol specification.
Sebastian Schinzel, @seecurity, schinzel@fh-muenster.de
Reported Vulnerabilities
The following is a list of all STARTTLS-related vulnerabilities we found during our research.
None of the issues would be present if implicit TLS had been used exclusively.
Due to different kinds of reports, not all issues are publicly documented.
All issues were reported more than 90 days ago.
Email Clients
As an end user, make sure to use the newest version of your email software.
The following list serves as a quick check if your client is still affected.
We found 320.000 vulnerable email servers in an Internet-wide scan and conducted a coordinated disclosure
involving different CERTs.
It is impracticable to inform and keep track of the update process of all mail service providers on the
Internet, and thus we identified and prioritized popular mail service
providers.
We only list these in the following table.
Server issues are generally more severe than client issues.
Unfortunately, no client configuration prevents server issues from being exploited, not even the usage of
implicit TLS.
Thus, you must ensure that your server (or your mail service provider) is not affected by STARTTLS issues.
