Organizations take great care to make sure that all of their web data is delivered through HTTPS with strong TLS, and solid cryptographic implementation.
More and more businesses know that they must deliver web content through HTTPS only, and that they need to implement trustworthy certificate authorities, secure their public key infrastructures, and carefully monitor their TLS certificates. Strong web encryption is a must to make sure that data traveling between web servers and web browser endpoints cannot be intercepted by cyber attackers.
It used to be that usually only web sessions with very sensitive data, such as credit card numbers for e-commerce and authentication credentials, were deployed through HTTPS. For example, most of a website’s web pages would be delivered through HTTP, but HTTPS would be used when a customer enters their financial information in order to make a purchase. But now we must understand that all web content should be delivered through HTTPS, because letting any data transfer through plaintext is a man-in-the-middle attack risk that can also threaten ciphertext.
Implementing strong encryption is great! But often when ciphers are so complex that it’d take cyber attackers months or longer to crack, they’ll find ways to bypass encryption altogether. The toughest door lock is useless if a window can easily be broken! Well, security researcher Piotr Duszyński found one such very breakable window that could make your HTTPS implementation easy to bypass.
You know what 301 HTTP redirects are, right? Organizations are replacing HTTP with HTTPS at a rapid pace, and that particular HTTP function is the one that Google officially endorses for directing your users’ browsers to your HTTPS webpages. “Redirect your users and search engines to the HTTPS page or resource with server-side 301 HTTP redirects.” That’s great. But it also means that the massive transition from HTTP to HTTPS makes the exploit Duszyński discovered applicable to likely millions of websites worldwide.
It’s a web cache poisoning attack that can make a cyber attacker’s web server the one a user is directed to when they try to access your legitimate HTTPS webpage.
SSL/TLS Certificates and Their Prevalence on the Dark Web
Here’s what he discovered
First of all, a cyber attacker can attempt a man-in-the-middle attack through client domain hooking. This is how Duszyński described it in another one of his whitepapers: “Browser sends HTTP request which is intercepted by an attacker and redirected to the proxy... Proxy inspects the incoming request (including context data) and forwards it to the relevant server on victims’ behalf. The server responds with a resource that contains multiple URLs with a number of different domains and URL schemes (E.g. HTTP and HTTPS).
Proxy inspects the incoming response and replaces all occurrences of FQDNs (fully qualified domain names) with a single, attacker-controlled, domain.” That’s what could be used to accomplish the first step in this web cache poisoning attack that he describes here: “Browser sent a single non-TLS request that was intercepted by an attacker either through a network-based MITM or ‘DNS Cache Poisoning’ attack.”
And these are the next steps
“Reverse proxy responded with an HTTP 301 that will be cached indefinitely by the browser, unless dictated otherwise by the ‘Cache-Control’ header (30 days in this example response).
Browser followed the redirect chain to the TLS service and from now on it will interact with all services through an attacker-controlled domain only—this applies to the current browsing session only though.”
From that point on, with your legitimate TLS certificates in the user’s web browser, when they try to visit your HTTPS webpages they’ll be directed to the cyber attacker’s webpages! All kinds of cyber attacks can be deployed from malicious webpages. Malware files can be sent to your users’ endpoints, often running only in memory. Phishing attacks can grab your users’ sensitive credentials and other data. Cyber attackers could completely control their victims’ PCs and mobile devices, all from their own malicious webpages.
This HTTP 301 redirect exploit can be especially dangerous, because web content can be delivered through mobile apps as WebViews and the like. The user may not see an address bar, just an app on their phone that doesn’t present as a web browser. This is very common in mobile app development for both Android and iPhones.
How can this particular exploit be prevented?
First of all, configure your web servers to prevent HTTP traffic by default. Enforce ATS mechanisms for iOS and forbid all plaintext traffic for Android apps. Define valid HSTS headers in your services and add your domains to HSTS preload lists. Finally, disable JavaScript if it isn’t used.
Oh, the growing pains of migrating from HTTP will continue to hurt! But when HTTP is banished from the web, we’ll all be safer.