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
Erwan Legrand
  • 401
  • 2
  • 13
Bruno
  • 361
  • 3
  • 5
  • 1
    Per [this answer](http://stackoverflow.com/a/21321413/721263), 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 '15 at 03: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?](http://stackoverflow.com/questions/9130422/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](https://en.wikipedia.org/wiki/Network_Time_Protocol#Security_concerns) – Bruno Dec 24 '15 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 '15 at 09:28
  • Yes, i've seen it... But like i said, 301 cached redirects doesn't have an expiry date :-( – Bruno Dec 27 '15 at 22:29
  • Could you just mitm and inject a redirect back to `HTTP`? The cached entry is sending it out to receive the fresh HTTPS, but if that page then redirects to non-https is that a possibility? Even if you have a bad certificate would the redirect still happen before an error is displayed? I think I follow your setup, but it may be hard to exactly replicate and test myself. – Eric G Dec 31 '15 at 04:58
  • I don't think so @EricG. If i redirect to HTTP or present a bad certificate it will show the security error page (your computer is under attack bla bla). If a HTTPS connection is requested the only way out is to present a valid certificate. – Bruno Dec 31 '15 at 05:12
  • 1
    Can you capture *any* other plain HTTP request from that user to any page? – Arminius Jan 09 '16 at 08:05
  • If @Bruno could change the computers date, then presumably he could also clear the browser cache, removing the need to change the date. – user1751825 Jan 28 '16 at 04:40
  • @user1751825 I'd assume you'd need to compromise the machine to clear the browser's cache. Since, he's arp cache poisoning, I suppose he could sniff NTP traffic, and spoof the NTP server (if in use) then craft frames to change the machine time without the need of compromising the machine first – Florian Bidabé Feb 03 '16 at 21:20
  • @FlorianBidabe If there is a large discrepency (more than 12 hours) between the computers time and the time from the NTP server the computer will ignore it. Spoofing the NTP server may therefore not be effective. – user1751825 Feb 03 '16 at 23:56
  • You could leverage mixed content issues ? Other than that - have you tried forcing the connection over another port? – KingJohnno Feb 13 '16 at 21:19
  • According to http://stackoverflow.com/questions/9130422/how-long-do-browsers-cache-http-301s it looks like this will be cached for quite a while. Can you trick the user into using a different browser ("Error! This page only works best in IE") or _potentially_ could you flood the browser cache with enough nonsense that it will ditch your HTTP 301 cached entry? – Matthew1471 Mar 06 '16 at 10:48
  • I would just try to strip the cache headers too. Note that Moxie Marlinspike also [mentioned this issie](https://vimeo.com/50018478#t=1951s) in the original Blackhat presentation in 2009. His "solution" was: "Strip all that stuff too." – rugk Mar 15 '16 at 22:12

3 Answers3

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?").

Jeff Ferland
  • 38,090
  • 9
  • 93
  • 171
Erwan Legrand
  • 401
  • 2
  • 13
  • What? That's not true. – forest Apr 11 '16 at 01: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 '16 at 09: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 http://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 '16 at 19:13
  • Chrome treat http://www.target.com/? and http://www.target.com/ as the same URL for URL redirects. – B T Aug 01 '16 at 02:34
  • Well, any URL works, as long as there is no cached response for it. – Erwan Legrand Apr 13 '18 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.

Tim Perry
  • 161
  • 5
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?

Daisetsu
  • 5,110
  • 1
  • 14
  • 24
  • Don't think it works. Last time I checked, synflood blocked all ports even when only one was flooded. – Joshua Oct 08 '20 at 15:18