sslstrip: seemingly unpredictable behaviour

[haemi]

I'm testing the security of an iOS app with sslstrip running on my Kali. My iOS app is installed on several devices, on some of them, sslstrip works as expected (shows login information), on some, it doesn't (although the traffic runs over Kali for sure).

The app in question is developed via phonegap; first, it shows an HTTP-URL, after tapping on the "Login"-Button, it redirects to an HTTPS-URL. Then, after entering the login information and tapping the "submit" button, I sometimes (= on some devices) see the login data in sslstrip-log, sometimes I don't. Even if I reset the device completely and only install the app from the app store the behaviour doesn't change.

What else could determine the success of sslstrip in this case?

[haemi]

further information:

- if the app gets deleted and arpspoof/sslstrip are running immediately (= before first login), everything works as expected
- if the app gets deleted and the user is logged in BEFORE starting arpspoof/sslstrip, problems occur. Login data is NOT displayed, it only works again after setting the device's date to somewhere in 2015. Now, login data is shown again, even after resetting the date to the current date.

[haemi]

analysing in wireshark confirms the assumption: sometimes, sslstrip doesn't seem to be able to strip the 's' part of https, so whenever reading the login data fails, the reason is because the request was sent via HTTPS. What could be the reason for sslstrip to fail if the user logged in before? Even closing the app doesn't change anything in this behaviour...

[sn0wcr0w]

further information:

- if the app gets deleted and arpspoof/sslstrip are running immediately (= before first login), everything works as expected
- if the app gets deleted and the user is logged in BEFORE starting arpspoof/sslstrip, problems occur. Login data is NOT displayed, it only works again after setting the device's date to somewhere in 2015. Now, login data is shown again, even after resetting the date to the current date.

I'm guessing a couple things.. case #1: sslstrip has intercepted the redirect you mention from http -> https and successfully MITM the connection, Case #2 sslstrip wasn't running to capture the original http->https redirect so it wasn't able to act on the clients behalf, since if it misses that transition then it can't MITM the connection. Part of what the server is sending is most likely a session cookie to persist login for some amount of time (maybe 1 year validity?), at that point the client knows that it is logged in and communicates purely over https, which negates sslstrip as well (since there is no http->https transition, unless I'm mistaken in my understanding of how it works)

[haemi]

@sn0wcr0w, I've got the same understanding; I think sslstrip needs the transition from HTTP to HTTPs to work correctly. Something like the session cookie makes sense, but it irritates me that I don't find something with an expiration header of 1 year. Also, I don't understand why it works after I set the date to something in 2015, if I set the date to something in 2014 (september, july, march, ...). Do you have any idea how I could get information about the cookie? Where would I see it?

[brav0hax]

There are new techniques in place to prevent SSLStrip from working, HSTS and certificate pinning

Depending on the site SSL strip may or may not work. You would need to run something like ettercap in order to hope to trick the end user into accepting the certificate.

Also what you may want to try is run sslstrip with the -K switch. This kills any current ssl connections...