Gmail login failure with sslstrip

[imported_waxgibbons]

I'm using sslstrip 0.3 along with arpspoof on BT4-pre final. When I go to test the connection, the victim will log in to gmail, the password is sniffed successfully, but the victim is returned to the login page. It works correctly on yahoo mail or paypal, but other pages like google adsense don't even load at all for the victim until sslstrip is disabled (and the iptables rules cleared).

Anyone else had any problems like this?

[Gitsnik]

Yes, it is referred to as server side checking (or one of a hundred other things). A quick google will find you the reasons why, or you can take a look at some of the code used to see if there are any functionality changes doing it for you.

Make proper use of a more complex arp spoofing program to fix the problem (and create a new one!)

[imported_waxgibbons]

Any recommendations of more sophisticated arpspoofing tool? I have tried Ettercap for the ARP cache poisoning, but run into the same problem.

[opreat0r]

Just pass the sslstrip option to drop when it has a "SECURE POST" this works great you have to watch it and re run it if you dont get what you want. IE multi paged logins Banks etc where the login is 2-3 pages deep ..

[redss]

What is this sslstrip option to drop upon making a "SECURE POST"? I don't see it listed in the command line options or anywhere in the source code.

[propercoil]

sslstrip.py -p -f -l 8080

(-p only SSL POST, -f favicon)

[redss]

Not in version .4 that I have -- the -p option only affects how much data is logged, it doesn't cause it to drop out of stripping SSL after a secure post.

Although Moxie alluded that there was such an option in the version that he presented in DC, and it would certainly make the attack far more transparent.

At any rate, using the sslstrip -p option with gmail still doesn't work when the gmail "always use https" setting is set, and also it continues stripping SSL from a paypal session beyond the secure post.