Hijacking browser TLS traffic through Client Domain Hooking
I am releasing a paper that describes a new variation of a man-in-the-middle (MITM) technique which, under certain circumstances, allows to permanently hijack browsers encrypted HTTP communication channel flow and compromise its confidentiality and integrity.
The technique has been named as “Client Domain Hooking”, since it relies on a particular way of achieving client-side communication endpoint persistency by forcing an application to communicate only through a chosen attacker-controlled domain through a single intercepted HTTP request and without breaking applications functionality. This technique was originally implemented in the ‘Modlishka’ reverse proxy.
The described approach, although very similar to the previously published techniques, has few extra benefits:
- HTTP traffic flow does not have to be constantly redirected to the proxy through a network layer MITM attack (e.g. a single intercepted non-TLS HTTP request will be sufficient to hijack current browsing session and all of its future, arbitrary, destination domain requests).
- reverse proxy server can be located in an arbitrary location (both Internet and Intranet)
- TLS layer will be trusted by a client without a requirement of installing any additional CA certificate.
- Proxied web applications will be nearly identical as the real ones.
- Intercepted HTTP connections rely on ‘bogus’ domain names that can be spotted by the user.
This paper also contains conclusions from a review of the current security posture of browser-based (desktop and mobile) applications and Top 1000 Alexa web applications from the HTTP Strict Transport Security (HSTS) security mechanism perspective.
As it appeared, 80% of the reviewed web applications did not use the HSTS mechanism.
You can find the paper here:
‘Hijacking browser TLS traffic through Client Domain Hooking - Piotr Duszynski.pdf’
Along with the paper, I have released an updated version of the ‘Modlishka’ tool was released, with capabilities to diagnose browser-based client applications from the described attack perspective. Developers should find this tool helpful in pin pointing and fixing relevant security issues in their applications.
You can also find example attack scenarios in the following “post”.