reader comments
27 with 22 posters participating
When you visit an HTTPS-protected website, your browser doesn’t exchange data with the webserver until it has ensured that the site’s digital certificate is valid. That prevents hackers with the ability to monitor or modify data passing between you and the site from obtaining authentication cookies or executing malicious code on the visiting device.
But what would happen if a man-in-the-middle attacker could confuse the browser into accidentally connecting to an email server or FTP server that uses a certificate that’s compatible with the one used by the website?
The perils of speaking HTTPS to an email server
Because the domain name of the website matches the domain name in the email or FTP server certificate, the browser will, in many cases, establish a Transport Layer Security connection with one of these servers rather than the website the user intended to visit.
Because the browser is communicating in HTTPS and the email or FTP server is using SMTP, SFTP, or another protocol, the possibility exists that things might go horribly wrong—a decrypted authentication cookie could be sent to the attacker, for instance, or an attacker could execute malicious code on the visiting machine.
The scenario isn’t as farfetched as some people might think. New research, in fact, found that roughly 14.4 million webservers use a domain name that’s compatible with the cryptographic credential of either an email or FTP server belonging to the same organization. Of those sites, about 114,000 are considered exploitable because the email or FTP server uses software that’s known to be vulnerable to such attacks.
Such attacks are possible because of the failure of TLS to protect the integrity of the TCP connection itself rather than the integrity of just the server speaking HTTP, SMTP, or another Internet language. Man-in-the-middle attackers can exploit this weakness to redirect TLS traffic from the intended server and protocol to another, substitute endpoint and protocol.
“The basic principle is that an attacker can redirect traffic intended for one service to another, because TLS does not protect the IP address or port number,” Marcus Brinkmann, a researcher at Ruhr University Bochum in Germany, told me. “In the past, people have considered attacks where the MitM attacker redirects a browser to a different web server, but we are considering the case where the attacker redirects the browser from the webserver to a different application server such as FTP or email.”
Cracks in the cornerstone
Typically abbreviated as TLS, Transport Layer Security uses strong encryption to prove that an end user is connected to an authentic server belonging to a specific service (such as Google or Bank of America) and not an impostor masquerading as that service. TLS also encrypts data as it travels between an end user and a server to ensure that people who can monitor the connection can’t read or tamper with the contents. With millions of servers relying on it, TLS is a cornerstone of online security.
In a research paper published on Wednesday, Brinkmann and seven other researchers investigated the feasibility of using what they call cross-protocol attacks to bypass TLS protections. The technique involves an MitM attacker redirecting cross-origin HTTP requests to servers that communicate over SMTP, IMAP, POP3, or FTP, or another communication protocol.
The main components of the attack are (1) the client application used by the targeted end user, denoted as C; (2) the server the target intended to visit, denoted as Sint; and (3) the substitute server, a machine that connects using SMTP, FTP, or another protocol that’s different from the one serverint uses but with the same domain listed in its TLS certificate.
The researchers identified three attack methods that MitM adversaries could use to compromise the safe browsing of a target in this scenario. They are:
Upload Attack. For this attack, we assume the attacker has some ability to upload data to Ssub and retrieve it later. In an upload attack, the attacker tries to store parts of the HTTP request of the browser (specifically the Cookie header) on Ssub. This might, for example, occur if the server interprets the request as a file upload or if the server is logging incoming requests verbosely. On a successful attack, the attacker can then retrieve the content on the server independently of the connection from C to Ssub and retrieve the HTTPS session cookie.
Download Attack—Stored XSS. For this attack, we assume the attacker has some ability to prepare stored data on Ssub and download it. In a download attack, the attacker exploits benign protocol features to “download” previously stored (and specifically crafted) data from Ssub to C. This is similar to a stored XSS vulnerability. However, because a protocol different from HTTP is used, even sophisticated defense mechanisms against XSS, like the Content-Security-Policy
(CSP), can be circumvented. Very likely, Ssub will not send any CSP by itself, and large parts of the response are under the control of the attacker.Reflection Attack—Reflected XSS. In a reflection attack, the attacker tries to trick the server Ssub into reflecting parts of C’s request in its response to C. If successful, the attacker sends malicious JavaScript within the request that gets reflected by Ssub. The client will then parse the answer from the server, which in turn can lead to the execution of JavaScript in the context of the targeted web server.
The MitM adversary can’t decrypt the TLS traffic, but there are still other things the adversary can do. Forcing the target’s browser to connect to an email or FTP server instead of the intended webserver, for instance, might cause the browser to write an authentication cookie to the FTP server. Or it could enable cross-site scripting attacks that cause the browser to download and execute malicious JavaScript hosted on the FTP or email server.
application layer protocol negotiation, a TLS extension that allows an application layer such as a browser to negotiate what protocol should be used in a secure connection. ALPN, as it’s usually abbreviated, is used to establish connections using the better-performing HTTP/2 protocol without additional round trips.
By strictly enforcing ALPN as it’s defined in the formal standard, connections created by browsers or other app layers that send the extension are not vulnerable to cross-protocol attacks.
Similarly, use of a separate TLS extension called server name indication can protect against cross-hostname attacks if it’s configured to terminate the connection when no matching host is found. “This can protect against cross-protocol attacks where the intended and substitute server have different hostnames, but also against some same-protocol attacks such as HTTPS virtual host confusion or context confusion attacks,” the researchers wrote.
The researchers are calling their cross-protocol attacks ALPACA, short for “application layer protocols allowing cross-protocol attacks.” At the moment, ALPACA doesn’t pose a major threat to most people. But the risk posed could increase as new attacks and vulnerabilities are discovered or TLS is used to protect additional communications channels.
“Overall, the attack is very situational and targets individual users,” Brinkmann said. “So, the individual risk for users is probably not very high. But over time, more and more services and protocols are protected with TLS, and more opportunities for new attacks that follow the same pattern arise. We think it’s timely and important to mitigate these issues at the standardization level before it becomes a larger problem.”
