SSL hijacking

What is SSL hijacking?

SSL hijacking is a type of attack where the attacker generates fake certificates for the domains of HTTPS sites the victim attempts to visit. As a result, the victim assumes they have a secure connection to the target site, but in reality, they have a secure connection to a cloned or proxy site controlled by the attacker. SSL hijacking is considered a man-in-the-middle attack (MITM) technique.

Note: While man-in-the-middle attacks are usually considered to be a network security issue, SSL hijacking most often affects websites and web applications (because they use the HTTPS protocol), so it could be considered a web application security issue.

How do SSL/TLS connections work?

All network traffic secured using SSL/TLS (Secure Sockets Layer/Transport Layer Security) is encrypted on the basis of an SSL/TLS certificate. For example, when you visit a secure site using a web browser for the first time, your browser receives the SSL/TLS certificate, verifies its authenticity, and creates an encrypted connection based on that certificate and its security requirements, such as the preferred cryptographic algorithms.

While SSL/TLS can be used for all types of TCP connections, it is most often used for HTTPS to secure access to websites, web applications, and web APIs. To understand SSL/TLS better, you can read a series of TLS security articles on the Acunetix blog.

How does SSL hijacking work?

For SSL hijacking to be possible, the attacker must first use another type of man-in-the-middle attack to intercept the connection between the victim (the user being attacked) and the target (the page under attack). This can be done using, for example, ARP spoofing, IP spoofing, or DNS cache poisoning. When attempting to visit the target site, the victim actually establishes a connection to a server controlled by the attacker. The attacker’s server then relays all traffic to the target and back, allowing the attacker to read and modify information along the way.

However, if the victim wants to use HTTPS when visiting the site, their browser will expect the attacker-controlled site to present an SSL/TLS certificate for the domain under attack. This requires the attacker to generate a fake certificate for the target and send it to the victim’s browser.

Why is SSL hijacking difficult?

The challenge with SSL hijacking is that due to the way public key infrastructure (PKI) works, your browser only trusts certificates signed by a trusted Certificate Authority (CA). If a certificate is not signed by a trusted CA, your browser will show a clear warning and may even refuse to open a page. Operating systems such as Microsoft Windows and Linux come with a built-in set of trusted Certificate Authorities, but you can always manually add new ones.

For SSL hijacking to succeed, the attacker needs to add their CA to the trusted certificate store in your operating system. This part has to be done through other attack vectors and vulnerabilities, such as phishing and cross-site scripting, making SSL hijacking nearly impossible unless combined with other attacks.

Note that even if a malicious hacker cannot find a way to put their CA certificate on your computer, they can still try an SSL stripping attack instead to get your browser to use HTTP connections instead of HTTPS, in effect sending web traffic in plain text.

Example of an SSL hijacking attack

In this example, the target is the invicti.com website, and you are the victim.

1. The attacker makes a targeted phishing attack against you utilizing JavaScript-related vulnerabilities, causing you to download and install their CA certificate. This allows the attacker to generate TLS/SSL certificates that will be accepted by your browser without warning messages.
2. The attacker configures their web server to act as a transparent proxy. It accepts all connections to invicti.com and relays them to the real invicti.com website, and does the same with all the responses from the invicti.com website.
3. Your computer is configured to use the DNS caches of your local provider. The attacker performs a DNS cache poisoning (DNS spoofing) attack against your provider’s DNS cache servers, causing your computer’s local cache to store the attacker’s IP address as the IP of invicti.com. Until this information expires in your local cache, you will be connecting to the attacker-controlled IP address every time you try to visit invicti.com in your browser.
4. Now, when you type https//www.invicti.com in the address bar, your browser looks up the IP address of www.invicti.com in your computer’s local cache and finds the attacker’s IP address. The browser then connects to the attacker’s server and accepts a fake SSL/TLS certificate for invicti.com. No warning is shown because the browser successfully verifies the fake SSL/TLS certificate using the attacker’s CA certificate installed earlier.
5. Your browser creates an SSL connection to the attacker’s server and you now have secure, encrypted communications between your browser and the attacker’s web page. However, all SSL traffic is decrypted by the attacker, logged and then separately relayed to the real Invicti web server via a server-side secure connection. Neither you nor the Invicti web server have any way of knowing that this is a MITM attack.
6. The attacker may use information gathered during the SSL hijacking attack to perform other attacks. For example, they could use the session key from intercepted session cookies to perform session hijacking attacks in the future, potentially allowing them to connect to authenticated areas of invicti.com using your session ID after the MITM attack is terminated.

While invicti.com may not be a lucrative attack target, threat actors can apply the same techniques to any other website or web application to get your authentication information. For example, they could target an e-commerce site where you provide your credit card information, or pick another web application with functionality that stores and transmits sensitive data.

How to detect SSL hijacking?

• The targeted site has no way of knowing it is involved in an SSL hijacking attack. For the target web server, this is a legitimate SSL/TLS connection, with no way of detecting that the connection comes from an attacker rather than the original user.
• If the victim has not installed a fake CA certificate, they can easily detect SSL hijacking attempts. In such cases, the browser warns you that the certificate is not valid and often there is no way to manually override the warning.
• If the victim has a fake CA certificate installed in the system, detecting SSL hijacking becomes nearly impossible. You could still discover that an SSL hijacking attack is going on by closely inspecting the TLS/SSL certificate and checking the issuer, the issue date, etc. In practice, though, you’re unlikely to analyze every single certificate for every HTTPS website you visit, especially for a site you know and use often.

How to prevent SSL hijacking?

• The targeted site has no way of preventing SSL hijacking attacks. For a web server, it’s not possible to distinguish between a connection coming from a real user and one from an attacker’s proxy.
• The victim can only prevent SSL hijacking by making sure attackers cannot use the other two techniques necessary for the attack. In most cases, basic cybersecurity hygiene is enough. If you don’t allow yourself to be tricked into installing suspicious software that smuggles a fake CA certificate into your system, your browser will not be fooled by the attacker’s certificate and will show a warning. By avoiding insecure networks such as public wi-fi, you can minimize the risk of your connections being intercepted in the first place. Another option is to use VPN software.

Note that, contrary to some claims, a web application firewall (WAF) can only prevent SSL hijacking when installed on a separate machine (for example, on the router) or if it uses a different certificate store from that of the main operating system. If you have a WAF that relies on CA certificates in the victim’s operating system for domain authenticity validation, it can be fooled in exactly the same way as the browser.

How to mitigate SSL hijacking?

Once an SSL hijacking attack is successfully executed, there is no way to mitigate it. Sensitive information sent and received from the target site will be accessible to the attacker until the attack is somehow interrupted (for example, if the user removes the fake CA certificate or simply terminates the intercepted connection).

Mitigating all SSL hijacking attempts may also have unforeseen consequences because this technique is often used for legitimate purposes. For example, malware protection software installed on your computer probably uses SSL hijacking techniques to inspect traffic. Otherwise, it would not be able to protect you when you tried to download malware over a secure connection. Some companies use SSL hijacking to control traffic in their internal networks, for example, to check what content their employees are accessing. Parental control software also uses SSL hijacking. This means your system most likely has CA certificates from software that uses such techniques, and if you remove them, this software will stop working.