12

I am doing research on bypassing HSTS. I read this guide on bypassing HSTS using SSLSTRIP+, but there are a few things that I don't understand.

First thing to do is to fire up MITMf in SSLstrip+ mode, I'll also be using classic ARP spoofing to become man-in-the-middle:

So now when 192.168.10.23 browses to www.google.com he will be redirected to wwww.google.com!

  1. How exactly is the victim being redirected. Does the DNS packet contain some sort of redirect? Or is it something else that redirects the user to wwww.google.com?

  2. And another thing. Is this figure is still applicable to SSLSTRIP+?

  3. The documentation of the DNS2Proxy tool from LeonardoNve states the following:

    Automatically the dns server detects and correct the changes thats my sslstrip+ do to the hostnames to avoid HSTS, so will response properly.

    What exactly is being corrected here?

Improve this question
1

1 Answer 1

Reset to default
7

This is answered going off the available information you linked to.

How exactly is the victim being redirected. Does the DNS packet contain some sort of redirect? Or is it something else that redirects the user to wwww.google.com?

When the user navigates to www.google.com, sslstrip acting as a MITM will redirect the user to wwww.google.com using HTTP. For example, via a Location HTTP response header:

Location: http://wwww.google.com/

And another thing. Is this figure is still applicable to SSLSTRIP+

That image doesn't seem right for sslstrip or SSLstrip +. As it can't intercept actual HTTPS requests, the request from the client should not be using the HTTPS protocol for the request. It is more like

GET http://facebook.com  ----> sslstrip   ---> https://facebook.com

and it initially prevents HTTPS from the client by changing both links and redirects from HTTPS to HTTP that are returned in any HTTP responses.

What exactly is being corrected here?

It appears that via the configuration of DNS2Proxy you can set how subdomains are resolved. So when www.google.com is redirected to wwww.google.com your *.google.com rule sets the resolved IP address which is returned. So in your config you set *.google.com to the A record for www.google.com.

Having said all this

My conclusion: It doesn't work.

If there is a HSTS rule on the browser already, the initial request to www.google.com will be over HTTPS anyway meaning that it can't be intercepted by sslstrip.

Additionally, if a site is in the HSTS preloaded list (like Google's domains will be in Chrome), it is required that includeSubdomains is specified. Therefore wwww.google.com will only be fetched over HTTPS too.

Improve this answer
5
  • So is this correct? 1. Victim requests www.google.com 2. DNS2PROXY "Lets make fakegoogle.com get data from www.google.com" 3. SSLSTRIP returns header('location: fakegoogle.com'); 4. Victim's browser follows the redirect to fakegoogle.com 5. DNS2PROXY receives fakegoogle.com request and requests the content from www.google.com 6. SSLSTRIP strips the https links from www.google.com 7. SSLSTRIP returns the stripped www.google.com as fakegoogle.com
    – Tijme
    Commented Jun 8, 2015 at 17:08
  • 1
    Yes, pretty much. However, as said I can't see how it would work and what the advantage would be anyway over normal SSL strip.
    – SilverlightFox
    Commented Jun 8, 2015 at 19:38
  • Ok, I just published my blog item. Hope everything is correct :) tinyurl.com/olz9j5u
    – Tijme
    Commented Jun 8, 2015 at 20:03
  • @Rabobank - Does the method really work? Does The browser accepts the redirect from https to http? Shouldn't there be a valid certificate on that redirect? And how does it deal with includeSubdomains?
    – Kobi
    Commented Jun 9, 2015 at 4:54
  • @Kobi I updated the article with an explanation on includeSubdomains. I already wrote that the user needs to initiate the connection with http for both methods. Thanks
    – Tijme
    Commented Jun 9, 2015 at 9:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .