- June 16, 2021
- Posted by: administrator
- Category: Security News
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, FTPS, 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 1.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.
NOTE:: This article is copyright by arstechnica.com and we are using it for educational or Information purpose only