5

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?

  • 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 at 9: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 at 9: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 (<MAC ADDRESS>) - also in use by <MAC ADDRESS> (frame 9)]. I believe this message to be normal, as I'm arp-spoofing. – lorelou Sep 17 at 9: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 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 at 13:40
0

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.

  • Hi state, Thanks for contributing. I'm not browsing to HSTS web-sites. You can check here: 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 at 8:55
  • 3
    @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 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 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 at 13:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.