If you are responsible for a web server, you already use Transport Layer Security (TLS, the ‘S’ in ‘HTTPS’) to protect your users from man-in-the-middle attackers that could otherwise passively sniff website cookies or actively inject malicious JavaScript.
You are likely also using TLS for other services, such as email or File Transfer Protocol (FTP). Adding TLS to a legacy protocol is known to provide strong confidentiality, integrity, and authenticity. Surprisingly, though, sometimes it can weaken the security of existing services. In the ALPACA attack, we at Ruhr University Bochum, Münster University of Applied Sciences, and Paderborn University have shown that adding a TLS-protected email or FTP server to a network can enable cookie-stealing or cross-site scripting attacks against web servers in the same network, which I’ll elaborate on in this post.
Understanding the drawbacks of TLS
TLS is a security layer between the transport and application layer. It does not protect TCP parameters of the connection, such as IP addresses or port numbers. And it is independent of the application protocol used over the encrypted channel.
Read: Coming of age: a longitudinal study of TLS deployment
To prevent man-in-the-middle attacks, TLS provides certificate-based authentication — the server sends its certificate to the client, and the client verifies the certificate is valid for the hostname of the intended connection. If an attacker redirects the client to a different server, the certificate will normally not match and the client can terminate the connection before any application data is exchanged.
Although this design makes TLS very flexible, it leaves some gaps. If two servers run on different ports of the same host, or if multi-domain certificates are shared between servers, or if wildcard domains are used across subdomains, an attacker can redirect TLS-protected traffic from one server to another. The attack escapes detection by the client if the certificate of the substitute server is also a valid certificate for the intended server.
In 2015, Jann Horn described how a man-in-the-middle attacker can exploit an FTP server for a reflected cross-site scripting attack against a web server. First, the attacker lures the victim user to an attacker-controlled website and creates a carefully crafted cross-origin request to the target website. The attacker then redirects that request to an exploitable FTP server that has a shared certificate with the web server. The request contains a mix of valid FTP commands and JavaScript, tricking the FTP server into reflecting the JavaScript in an error message. This JavaScript is executed in the victim browser within the security context of the attacked website, giving the attacker complete control over it. Jann Horn also described a stored cross-site scripting attack within the same setting.
In our ALPACA attack, we reevaluated the two attacks by Jann Horn and added a third scenario, in which the attacker uploads the victim’s secret cookie to the FTP server (see Figure 1). In addition to FTP, we also analysed if these attacks are possible using the email protocols SMTP, IMAP, and POP3. We evaluated 24 FTP and email servers and found that 12 of them allowed at least one attack in at least one browser.
We also scanned the Internet for web servers that share certificates with FTP or email servers. We found 1.4M web servers with this vulnerable configuration. Of these, we identified 114k web servers where the FTP or email server is one of the 12 exploitable from our lab evaluation, allowing the ALPACA attack.
1 in 25 email and FTP servers in APNIC region are exploitable in ALPACA attacks
In the interest of this blog post, we also looked at the IP addresses of FTP and email servers with valid certificates within the APNIC region. The APNIC address space contains 13% of all such FTP and email servers (RIPE: 35%, ARIN: 48%).
Of all FTP and email servers in the APNIC region, 4.24% are exploitable in the ALPACA attack setting (RIPE: 2.54%, ARIN: 2.16%).
Although certificate hygiene can prevent cross-protocol attacks, in practice it is not always possible or practical for site operators to use a separate hostname and certificate for each service. On the other hand, sanity checks at the application layer can only prevent those cross-protocol attacks we already know about.
Apply strict ALPN and SNI validation to prevent cross-service attacks
To prevent all cross-protocol attacks at the TLS layer we recommend server operators of email, FTP and other TLS-protected services apply strict validation of the Application Layer Protocol Negotiation (ALPN) extension. The ALPN extension allows the client to send a list of intended protocols, and the server selects one of these protocols or terminates the connection. This way, any attack that tries to redirect traffic from a server speaking a different protocol will be prevented.
Strict ALPN validation can be added to application servers with a software update. Because web browsers already send the ALPN extension to negotiate different versions of HTTP over the same port, all attacks against web browsers can be mitigated this way. For legacy clients that do not yet send ALPN extensions, servers can make an exception to preserve backwards compatibility.
In addition to ALPN, strict validation of the Server Name Indication (SNI) can add defence-in-depth to prevent any type of cross-host attacks.
Marcus Brinkmann is a PhD student at the Horst-Görtz Institute for IT Security, Ruhr University Bochum, Germany.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.