People's Newsroom

MAN-IN-THE-MIDDLE ATTACKS

In a man-in-the-middle attack (MitM), an active network attacker positions himself in the network, between the victim and the targeted Web application. This position not only allows the attacker to inspect all traffic that is sent between the victim and the target application but also allows modification of the traffic. Such a compromise gives the attacker full control over the user’s actions, with potentially disastrous effects. Note that there are also “legitimate” use cases for performing a MitM attack, such as ISPs injecting advertisements into HTTP responses, or corporations deploying a Web content filter, responsible for filtering unwanted or harmful content.

MitM attacks are more sophisticated than eavesdropping attacks, but also occur frequently on the Web. Little is known about MitM attacks being carried out by small-scale attackers, but they do occur on larger scales, such as for state-sponsored censorship as seen in the Middle East, China, etc. Similarly, the same technology is used for scenarios where user consent is given, such as companies that deploy content filtering on their own networks, as a perimeter security measure. Another known cause is the NSA’s QUANTUM INSERT program, where a MitM attack is used as an attack vector to install malware on the victim’s machine.

Description

The goal of a man-in-the-middle attack is to be able to inspect and manipulate the victim’s network traffic. This allows an attacker to modify legitimate transactions, carry out actions in the user’s name, compromise files that are being sent to and from the victim, etc. TLS-secured connections with validated certificates are designed to withstand man-in-the-middle attacks, but flaws in the supporting systems may allow for subtle attacks to be carried out anyway. These flaws are caused by misplacement of trust in certain parties, or by placing the decision-making burden on the user. Becoming a man in the middle of the network can be achieved at many levels. An attacker can physically place a machine in the network path, forcing the data to flow through this machine, or he can manipulate the network’s parameters, to act as a gateway at the logical level, for example through ARP poisoning attacks. While the technical details on becoming a man in the middle are less important in this context, the impact of a MitM attack on the Web cannot be discarded. Once an attacker positions himself in the middle, inspecting and manipulating traffic becomes straightforward. One common example is in mixed content deployments, where an attacker can manipulate HTTP content that is included by an HTTPS page, resulting in a compromise of the page’s execution context.

Traditionally, TLS is deployed to prevent eavesdropping and MitM network attacks, since it offers confidentiality, integrity, and entity authentication. The confidentiality and integrity effectively prevent an attacker from reading and modifying any network traffic, while the entity authentication property ensures that the involved parties are who they claim they are, thereby preventing a MitM attack within the TLS connection. Even though TLS is designed to counter MitM attacks, in reality, they remain possible for several reasons. In 2009, it is argued that users visiting a secure Web application probably will not type the HTTPS:// part of the URI manually, meaning that the initial request will be made over HTTP. Typically, Web applications then redirect the user towards the correct HTTPS URI, causing a transition from HTTP to HTTPS. Exactly this transition can be exploited by an attacker who sits between the victim and the target application, causing the downgrade of the connection from HTTPS to HTTP, which is called an SSL Stripping attack.

Second, the entity authentication in TLS is based on private/public key pairs, of which the public key is verified by a Certificate Authority (CA), which is part of the Public Key Infrastructure (PKI). Unfortunately, the trust model in this scenario consists of the union of all public keys of CAs registered in the browser. Hence, any CA in the Web’s PKI can issue a certificate for any Web site, in spite of the availability of the technology to constrain the trust in a specific CA. With approximately 1,482 CAs trusted by Microsoft and Mozilla, any Web site is vulnerable to an attack with fraudulent but verified certificates being issued. To make matters even more complicated, browsers have a history of not consistently checking the revocation status of certificates using the Online Certificate Status Protocol (OCSP), and alternatively propose a static list of revoked certificates. Even if they check the status with OCSP, the absence of an answer is ignored, allowing an active network attacker to circumvent the OCSP check.

Third, whenever an invalid certificate is encountered by a browser, the burden of the security decision is placed on the user. Regardless of whether the invalid certificate is caused by an expired expiration date or a complete mismatch with the targeted Web site, browsers show scary warnings, asking the user to decide whether to trust the site or not. Since users also encounter these warnings for legitimate sites, a simplistic MitM using an invalid certificate has some chance of success.

A fourth degradation of the CA system in TLS comes from the deliberate MitM devices, deployed by enterprises and large organizations with the goal of filtering inbound and outbound Web traffic. Reasons to deploy such filtering mechanisms go from offering protection, for example with a Web application firewall (WAF), to preventing employees from accessing sites that are deemed inappropriate, such as social networking applications. The problem with such devices is that in order to perform a MitM function on secure connections, they either have to install their own certificate on a user’s machine, or they have to obtain a valid certificate for every TLS-protected Web site on the Web. The former is a configuration hassle, which only works if you control all the client-side devices as well, and the latter seems impossible. Unfortunately, the system does not prevent collaboration between CAs and vendors of MitM devices, thereby harming the trust placed in the system.

Finally, the trust placed in CAs is easily abused when a CA is compromised. For example, the hacking of DigiNotar resulted in the issuing of fraudulent certificates, allowing MitM attacks on secure connections to Yahoo, Mozilla, WordPress, and the Tor project. The trusted roles of CAs can even be further compromised by government coercion to issue fraudulent certificates. This strategy is believed to be common practice in non-democratic countries, but recent revelations seem to implicate that this practice is widely deployed by secret agencies across the world. The essence of the problem with MitM attacks, especially against TLS connections, is the misplaced trust in the system on the one hand, and the burden of the security decision on the user on the other hand. Clearly, blindly including every certificate of a root CA on the Web in the browser has been proven to be a bad idea, and typical Web users are not capable of making technical decisions about trusting a certificate or not.

Mitigation Techniques

For a long, the main mitigation technique for SSL stripping attacks has put the burden on the user, who should detect the presence of the lock icon to indicate a secure connection. One technological solution is provided by the HTTPS Everywhere browser add-on, which forces the use of HTTPS on

sites that support it. By forcing the use of HTTPS, SSL stripping attacks are effectively mitigated, since a direct HTTPS connection will be made. The research proposal HProxy prevents SSL stripping attacks by leveraging the browser’s history to compose a security profile for each site and validating any future connections to the stored security profiles. This approach effectively detects and prevents SSL stripping attacks without server-side support and without relying on third-party services. Finally, the force HTTPS research proposal has resulted in HTTP Strict Transport Security (HSTS), which allows a server to require that browsers supporting HSTS can only connect over HTTPS, effectively thwarting any SSL stripping attacks. A server can enable HSTS protection by including a Strict-Transport-Security response header, declaring the desired lifetime for the HSTS protection. One caveat to HSTS being implemented as a response header is the first contact with a site when it is unknown whether an HSTS policy applies or not. This issue has been addressed by modern browsers including a predefined list of HSTS-enabled sites, effectively avoiding an initial HTTP connection.

Mitigation techniques against MitM attacks on TLS focus on determining the trustworthiness of the presented certificate. Certificate Transparency (CT) aims to maintain a public, write-only log of issued certificates so that either user agents or auditors can detect fraudulent certificates. This would require a user agent to query the log during the TLS handshake, and auditors can query the log offline, to check for certificates being unexpectedly issued for one of their sites. A second approach is based on detecting discrepancies between the currently presented certificate, and previously seen certificates, a technique called certificate pinning or public key pinning. While this approach requires the first connection to be secure, it effectively enables the detection of unexpected future updates. This approach is implemented in the Certificate Patrol browser add-on, and proposals to achieve this at the HTTP, TLS, or other layers have been made. Note that public key pinning does not require a CA-signed certificate, and is compatible with self-signed certificates. Alternatively, Google has taken the approach of hardcoding the certificate fingerprints of Google-related TLS certificates, allowing Google Chrome to detect a potential MitM attack, even with a fraudulent certificate issued by a CA. Naturally, controlling both the services and the client platform is a key to the success of this approach.

Several proposals for alternate schemes to verify certificates have been made and evaluated, but the standardization work on Certificate Transparency seems to be most likely to gain widespread support, which is required for it to become an effective mitigation technique. In addition to CT-like approaches, DNS-based Authentication of Named Entities (DANE) leverages the security of DNSSEC to bind certificates to domain names. DANE is perhaps less suited for the Web due to the current lack of deployment of DNSSEC and a corresponding lack of a well-defined transition path from today’s PKI to a DANE-based PKI.

State-of-Practice

Currently, a large part of the Web still transfers content over HTTP, making a man-in-the-middle attack trivial. In the last few years, major sites have started to switch TLS on by default, which has even increased after the revelations about pervasive monitoring. Adoption of HSTS is still in its early stages, but our July 2014 survey of the Alexa top 10,000 domains shows that 388 already send an HSTS header. Similarly, Chromium’s predefined list of HSTS-enabled sites counts 438 entries. Of the 3,447,719 real-world TLS connections, at least 6,845 (0.2%) used a forged certificate. The authors attribute these forged certificates to adware, malware, and security tools such as antivirus software, parental controls, and firewalls. Finally, in a recent security push by browser vendors, active mixed content is being blocked, preventing a compromise of the execution context through a network-level attack. While modern desktop browsers effectively enforce this policy, mobile browsers still include mixed content without constraints.

Back to top button