26

I'm doing some pen. tests on a HTTPS (443) server that does not have HSTS implemented (no HSTS headers on response and the address is not on Chrome HSTS preload list).

The problem is that in my scenario the user has visited the web site before, so it has the first HTTP (80) request response cached on Chrome.

Now, when user types in targetaddress.com the browser automatically gets the cached redirect (301 - HTTP to HTTPS location=https://targetaddress.com) making SSLstrip useless.

My workaround for this was to block 443 port on the client side, so the user, not being able to connect to the target, goes and manually clear the browser cache/history in a attempt to restore connection. Then SSLstrip will be effective as it now will intercept/tamper the HTTP request (301 redirect) response.

Are there any other better ways to do this, other than blocking port 443?

Here's the cached redirect:

http://targetaddress.com/
HTTP/1.1 301 Moved Permanently
Date: Wed, 23 Dec 2015 18:31:19 GMT
Server: Apache
Location: https://www.targetaddress.com/
Content-Length: 237
Content-Type: text/html; charset=iso-8859-1
Improve this question
13
  • 1
    Per this answer, if you can modify the computer's date you may be able to force the cached information to be viewed as expire and force the browser to re-request, thereby engaging your SSLstrip MiTM. But that's complicated as it requires access to the target computer. I think you're hosed.
    – Neil Smithline
    Dec 24, 2015 at 3:09
  • Yeah, i'm not sure if this could work @Neil, as the cache doesn't have an expiry date (How long do browsers cache HTTP 301s?). Anyway, to change computer's date, i guess a MITM attempt on a possible NTP query from the victim would be a better approach, as it does not require access to target computer... Wikipedia - NTP - Security concerns
    – Bruno
    Dec 24, 2015 at 12:36
  • 1
    Yep, you could try Jose Selvi's Delorean Exploit. Look up "Bypassing HTTP Strict Transport Security" on Youtube for his Blackhat Presentation. It involves changing the time via NTP.
    – 16b7195abb140a3929bbc322d1c6f1
    Dec 27, 2015 at 9:28
  • Yes, i've seen it... But like i said, 301 cached redirects doesn't have an expiry date :-(
    – Bruno
    Dec 27, 2015 at 22:29
  • 1
    Can you capture any other plain HTTP request from that user to any page?
    – Arminius
    Jan 9, 2016 at 8:05

3 Answers 3

Reset to default
2

If you can make the browser make a request to http://targetaddress.com/whatever . The browser will default make a plain HTTP request, not an HTTPS one as there is no cached response for /whatever, only for /.

This can be achieved in several ways. One way is to MITM between the browser and any website accessible through plain HTTP and insert an <img> tag. Another way is to trick the user to enter targetaddress.com/whatever in the address bar through social engineering.

As soon as the browser makes a clear-text request to the target domain, the MITM has won the game.

HTTP enables a client to perform actions on entities. Which action is performed depends on the HTTP method specified in the request. Which entity the action is performed on depends on the URL specified in the request.

Different URLs can reference the same entity, but the browser does not know this. When a browser caches an HTTP response, it does so for a given URL.

http://www.target.com/ is an URL. http://target.com/ is another one. http://www.target.com/whatever is yet another one. So is http://www.target.com/?.

Now, suppose there is a cached entry for http://www.target.com/ in a browser. Does it implies there is one for any of the other URLs listed above? No, it does not.

Thus, getting back to the question, making the browser send a plain text request in the case where a permanent redirect is returned by a Web application on the HTTP port is a matter of crafting an URL which does not match a cache entry and tricking the user to visit this URL.

Proof this works:

127.0.0.1 - - [13/Apr/2016:10:01:17 +0200] "GET / HTTP/1.1" 301 226 "-" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [13/Apr/2016:10:01:35 +0200] "GET / HTTP/1.1" 301 226 "-" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [13/Apr/2016:10:02:10 +0200] "GET /whatever HTTP/1.1" 301 234 "-" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [13/Apr/2016:10:02:36 +0200] "GET /whatever HTTP/1.1" 301 234 "-" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [13/Apr/2016:10:08:16 +0200] "GET / HTTP/1.1" 301 226 "-" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
127.0.0.1 - - [13/Apr/2016:10:08:25 +0200] "GET /? HTTP/1.1" 301 227 "-" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"

I have been able to make six (arbitrary number) clear text HTTP requests to the same Web site with the same browser even though a permanent redirect is configured for everything. (And no, I did not clear the browser's cache!)

Other obvious ways to work around a permanent redirect include tricking the user into switching to anonymous browser mode (no cache) or switching to another browser ("I have issues when accessing the app with IE. Can you have a look?").

Improve this answer
5
  • What? That's not true.
    – forest
    Apr 11, 2016 at 1:28
  • @forest, what is exactly your claim? If a browser has never made a request for http://targetaddress.com/whatever it has no cached response for this entity/URL.
    – Erwan Legrand
    Apr 12, 2016 at 9:15
  • While this answer is good (I am not the one who downvoted), with SSLStrip you have no way of tricking the user to do anything they don't normally do. You are only latching on to the normal website-you-are-attacking.com being entered by the user into their browser, and if they browser auto-redirects them somewhere becaused of the cached 301, there isn't much you can do about it (as the client won't actually request your server for anything and just go straight to the https server).
    – Fahad Yousuf
    Apr 25, 2016 at 19:13
  • Chrome treat target.com? and target.com as the same URL for URL redirects.
    – B T
    Aug 1, 2016 at 2:34
  • Well, any URL works, as long as there is no cached response for it.
    – Erwan Legrand
    Apr 13, 2018 at 17:13
1

There's more than a few practical routes to getting target users to clear their caches for you, which might be the easiest solution. This may not even be that suspicious, especially for non-technical targets, since it's been a go-to IT problem solving suggestion from everybody for years.

Easiest if you're running/faking a wifi hotspot for the interception. Throw up a 'terms and conditions' page they have to accept when they first connect, then fail to give them access and say "This may be caused by caching problems. Please clear your cache by doing X, Y, Z". Nobody really thinks of caching as a security feature, if they understand it at all. Most people will merrily clear it in return for free internet, and then you're golden.

Improve this answer
0

You could try running synflood against port 443. The client wouldn't be able to connect, and may fail back to port 80.

Just a disclaimer, but I haven't tried this. Anyone want to chime in?

Improve this answer
1
  • Don't think it works. Last time I checked, synflood blocked all ports even when only one was flooded.
    – Joshua
    Oct 8, 2020 at 15:18

You must log in to answer this question.

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