8

I've been following this guide: https://www.cybrary.it/0p3n/using-sslstrip-in-kali-linux/ and others too, ex: official Sslstrip one: https://moxie.org/software/sslstrip/ without any success.

I'm using:

5.2.0-kali2-amd64 #1 SMP Debian 5.2.9-2kali1 (2019-08-22) x86_64 GNU/Linux
sslstrip 0.9 by Moxie Marlinspike

and arpspoof.

I am running first:

echo "1" > /proc/sys/net/ipv4/ip_forward

iptables -t nat -A PREROUTING -p tcp  –destination-port 80 -j REDIRECT –to-port 8080

Then arp spoofing:

arpspoof -i <interface> -t <targetIP> -r <gatewayIP>

Then sslstrip: 

sslstrip -w testfile.txt -l 8080

Then I'm going to my target machine, iPhone running Safari browser. I'm deleting all cache and temp. I'm browsing to non-HSTS preloaded websites (linkedin.com , zsecurity.org ). I'm not specifying https:// , but simply the domain name (ex: linkedin.com). They still load in https.

I tested this multiple times on another client running Windows and Internet Explorer. Same result, I cannot have the target forced to http.

The testsfile.txt from sslstrip is empty. I was expecting the client would open http web-pages.

What am I doing wrong?

schroeder
  • 123,438
  • 55
  • 284
  • 319
lorelou
  • 81
  • 2
  • I want to add some potentially helpful information. I'm running the procedure above, then I'm opening my Wireshark. My belief is: my target-client should be arp spoofed and re-route its traffic to my Kali. Hence I should see requests for linkedin and zsecurity in my Kali. I cannot find those requests in my Wireshark capture. I can see that some traffic is being redirected from my iPhone's ip to my Kali, but not the requests for those web pages. Could this be the problem? I'll now post some examples in my next comment. – lorelou Sep 17 '19 at 09:02
  • Examples packets from Wireshark on my Kali. 192.168.0.171 = Kali doing the arp spoofing. 192.168.0.248 = iPhone is target-client. 92 5.679089437 192.168.0.248 93.184.220.29 TCP 78 54205 → 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=128 TSval=1042927190 TSecr=0 SACK_PERM=1 [...] 95 5.683192043 192.168.0.248 93.184.220.29 HTTP 368 GET /MFYwVKADAgEAME0wSzBJMAkGBSsOAwIaBQAEFN%2BqEuMosQlBk%2BKfQoLOR0BClVijBBSxPsNpA%2Fi%2FRwHUmCYaCALvY2QrwwIQDHmpRLCMEZUgkmFf4msdgw%3D%3D HTTP/1.1 – lorelou Sep 17 '19 at 09:26
  • I believe the above comment shows packets with source ip of iPhone are going through my Kali. There is no DNS traffic for linkedin nor zsecurity though. No HTTP traffic either. No mentions of them at all. If I search for ARP traffic, I can find such messages: [Duplicate IP address detected for 192.168.0.1 () - also in use by (frame 9)]. I believe this message to be normal, as I'm arp-spoofing. – lorelou Sep 17 '19 at 09:34
  • You should Setup your own local server to test more completely. You are probably running awfoul of the strict-transport-policy header – Conor Mancone Sep 17 '19 at 10:17
  • Could you elaborate some more? I'm testing this in my own network, own router, all devices are my own. What did you mean by setup my own local server? Maybe a vm running in the same Kali client? – lorelou Sep 17 '19 at 13:40

2 Answers2

3

First of all: What sslstrip does is it replaces https-links with non-https-links on hijacked non-https- websites. E.g. when the victim visits a http-only search engine via an insecure public wifi, the attacker can use sslstrip to replace https-links in the search engine- results with http-only links.

I guess that the websites you are targeting (e.g. linkedin) always redirect to https, regardless of what the victim attempted to open. And won't allow http-connections in the first place.

And last but not least, like others already mentioned in the comments, the target websites most likely set a strict-transport-security header in the first response (or even an OPTIONS response, which can be easily overlooked), which will prevent the browser from allowing http-only connections.

Martin Fürholz
  • 795
  • 9
  • 21
1

I think deleting cache and tmp should not be sufficient to remove the HSTS entries. For the safari browser e.g. there is the file "~/Library/Cookies/HSTS.plist" where HSTS is safed. You would need to remove this file when testing from a desktop.

state
  • 21
  • 1
  • Hi state, Thanks for contributing. I'm not browsing to HSTS web-sites. You can check here: https://hstspreload.org/?domain=linkedin.com In my iPhone i'm going to Settings > Safari > Clear History and Website Data ("Clearing will remove history, cookies and other browsing data. [...]" ). Then I'm checking the Advanced > Website Data menu, I'm making sure all data's been erased from there. In my Windows desktop I'm going to IE's internet options and deleting all history, temp, cache. – lorelou Sep 17 '19 at 08:55
  • 4
    @lorelou HSTS is more than just the preload list. There is also the `strict-transport-security` header which is set in the response from the server. LinkedIn sets it to one year. It would not show it in the browser preload list. I don't know where the browser stores it but you probably can't clear it. This is likely the answer. – Conor Mancone Sep 17 '19 at 10:16
  • Hi @ConorMancone , thanks for pointing this out. I checked the web-dev-tools for linkedin.com and found the header "strict-transport-security: max-age=2592000" in response to the 301 moved permanently. This appears only on linkedin.com though and not on zsecurity.org, there is no such header there. Nonetheless I'm unable to downgrade the latter from https to http. – lorelou Sep 17 '19 at 13:38
  • @lorelou Yes, that `strict-transport-security` header enables HSTS on the site even if it isn't on the pre-load list. As a result if you had previously visited a site that returns that header, sslstrip is impossible. That would explain linked in, but obviously not zsecurity.org. – Conor Mancone Sep 17 '19 at 13:49