MITM with SSLstrip - Tor

[imported_onryo]

Well I am quite happy to say that I gott SSLstrip working quite nicely on my network. It is amazing that I do not get a certificate warring when I go into my gmail and SSLstrip picks up all my confidential info. SSLstrip works fine over my wpa connection. Can surf around like SSLstrip not there and it picks up all my SSL info at facebook, gmail, mysite, etc.

Being the curious person that I am, I pushed the Tor button in my Firefox and surfed into my gmail. Using Tor this time I got a real https connection to gmail that was Tored. I thought about it for a moment but could not figure out why. I guess Tor bypassing SSLstrip is a good thing but I am sill wondering what’s going on. At Black Hat DC 2009 Feb 16-17 Marlinspike said it worked fine for him.

This is my setup.

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

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

# python ./sslstrip.py -p -f -l 8080 (-p only SSL POST, -f favicon)

# arpspoof -i ath0 -t (targert IP) (router IP)

# cat sslstrip.log | grep (ie my email address etc)

BT4 doing the sniffing and a eeepc doing the surfing. Using 802.11g wpa


Anybody got any clues?

Best to you all
Onryo

[Relentless]

That's good to hear, I have tested SSL Strip only in VMware and managed to get it to work between a BT3 Vmware and Freesbie(BSD) Vmware; however, when I tried it on my network it does not work, I am not sure if it's because of my network setup (I have two default gateways, one is a Wireless Bridge running DD-WRT amplifying my wireless signal with the same SSID as the Linksys Wireless Router, but with a different IP from Linksys; in addition, I am using the same SSID as the bridge, the same is also true for encryption WPA and the channel) or if Open DNS does anything to hamper this.

Will test later to find out what the true source of the problem is...

[imported_onryo]

That's good to hear, I have tested SSL Strip only in VMware and managed to get it to work between a BT3 Vmware and Freesbie(BSD) Vmware; however, when I tried it on my network it does not work, I am not sure if it's because of my network setup (I have two default gateways, one is a Wireless Bridge running DD-WRT amplifying my wireless signal with the same SSID as the Linksys Wireless Router, but with a different IP from Linksys; in addition, I am using the same SSID as the bridge, the same is also true for encryption WPA and the channel) or if Open DNS does anything to hamper this.

Will test later to find out what the true source of the problem is...

Can't wait to hear what you find out. A few of us were just taking about this and it does not make seance. So far all protocols I have tried out *seem* to work in Firefox except Tor.

Best to ya
onryo

[imported_blackfoot]

You seem to suggest in this repeat post that you have this working over a wpa network. This is a level III redirect mitm-type sniffer exploit.

This summary (below) is that which is required for a full mitm over wpa:

That you have equipment using a wpa-encrypted wifi connection to an AP, which you then force to dissociate and reauthenticate with an attacking machine. You then connect to the AP from the attacking machine (using wpa), flood the channel and use arpspoof to force the target machine to preferentially authenticate with your attacking machine (using wpa) which then handles all inbound/outbound requests, without the AP forcing a reconnection!

I doubt very much that you have done that! After all my coding of a level II station-to-station attack system I do not believe it possible. Any affirmation otherwise would promote a useful debate.

I rather suspect you are simply sniffing your own traffic and/or with a hardwire mitm at the router, albeit with original transmissions over wifi. This is not a realistic mitm attack as we know it here. It is rather, an internal proxy redirect.

I urge you to resist oversimplifying and over-claiming use of these exploits in these forums as serious reinvestigation takes a good deal of time.

I do however believe it is a worthy proof-of-concept and investigation is useful, (but not simply sniffing your own output).

[hawaii67]

With

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

you are redirecting just traffic for port 80 to sslstrip.
Using Tor means you are likely using a local proxy like privoxy too, which is listening on a different port than 80.

[opreat0r]

hawaii67 is right you are only fwding port 80 so if you tunnel over anything but port 80 then it wont pick it up!

[imported_onryo]

You seem to suggest in this repeat post that you have this working over a wpa network. This is a level III redirect mitm-type sniffer exploit.

This summary (below) is that which is required for a full mitm over wpa:

That you have equipment using a wpa-encrypted wifi connection to an AP, which you then force to dissociate and reauthenticate with an attacking machine. You then connect to the AP from the attacking machine (using wpa), flood the channel and use arpspoof to force the target machine to preferentially authenticate with your attacking machine (using wpa) which then handles all inbound/outbound requests, without the AP forcing a reconnection!

I doubt very much that you have done that! After all my coding of a level II station-to-station attack system I do not believe it possible. Any affirmation otherwise would promote a useful debate.

I rather suspect you are simply sniffing your own traffic and/or with a hardwire mitm at the router, albeit with original transmissions over wifi. This is not a realistic mitm attack as we know it here. It is rather, an internal proxy redirect.

I urge you to resist oversimplifying and over-claiming use of these exploits in these forums as serious reinvestigation takes a good deal of time.

I do however believe it is a worthy proof-of-concept and investigation is useful, (but not simply sniffing your own output).

Agreed but all the same it seems to be working! Please give it a go yourself and see. I tried this on 2 other AP that I dug up out of the closet and almost assure you that this is not a hardwire mitm at the router. I would really like to hear what you find out. Looking at the code it seems that SSLstrip is listening at the redirect (8080) and coping all the data while fooling the host that it is the "victim". SSL info is disclosed. Meanwhile a copy of the data minus the SSL pipe is sent to the "victim" Granted you have to tap into the wpa stream. Still looking into this. I urge you to give it a try and tell us your findings.

Please watch the video from Black Hat 2009 when the author explains how this works plus other "tricks" concerning SSL. One of the most interesting speeches I have ever heard.

http://www.thoughtcrime.org/software/sslstrip/

All the best
onryo

[Relentless]

Courtesy of htons139

http://forums.remote-exploit.org/showthread.php?t=22237

I guess this is the problem I was currently having:"Arpspoof is compiled with "eth0" as the device to use, even if you use "-i eth1" the attack will fail. You have to modify the arp.c file and compile arpspoof again to make it work on other NIC names or search for a compiled binary that has this issue resolved...(qtd in htons139)"

Solution:Use Ettercap instead of Arpspoof outside of Vmware, at least in my case.

[imported_onryo]

Courtesy of htons139

http://forums.remote-exploit.org/showthread.php?t=22237

I guess this is the problem I was currently having:"Arpspoof is compiled with "eth0" as the device to use, even if you use "-i eth1" the attack will fail. You have to modify the arp.c file and compile arpspoof again to make it work on other NIC names or search for a compiled binary that has this issue resolved...(qtd in htons139)"

Solution:Use Ettercap instead of Arpspoof outside of Vmware, at least in my case.

Actually Ettercap has become my tool of choice for almost all MITM attacks. It is really easy to use and flexible. Yeah I remember reading something about the eth0 problem. I was using an AR5001x chip as ath0 with BT4 and it arpspoof worked fine for me. Just got a Alfa and I am still trying to get the darn thing to changemac to 00:11:22:33:44:55 and figure out how to get back into NetworkManager noob problems with the AWUS036H.

[imported_onryo]

Hey ********** (onryo here), By the time that a tor proxy puts
anything on the wire, it is encrypted with three "onion layers" of encryption
for each tor node in its circuit, plus the TLS encryption to the guard node.

So even straight HTTP requests that are routed through the tor network
are essentially embedded within a layer that we can't see or modify as a
local attacker. This is part of how tor provides anonymity -- as a
local observer we can't tell what the content is or where it's going.

When the traffic finally makes it to the final hop in the tor circuit,
though, the data is at that point completely unencrypted and visible to
the exit node. So while the exit node doesn't have any indication of
where it came from, it is free to observe and modify all non-SSL traffic
that is being routed through it. What I presented in DC were results
from running sslstrip on an actual exit node, not on a local network
where tor traffic was originating from. Since tor is a volunteer
network, setting this up on an exit node is not difficult.

I just gave a similar talk in Amsterdam at BH Europe, where I also
presented a tor scanning tool that I've been using to monitor exit nodes
and ensure that they are not running sslstrip.

If you have any other questions, let me know.

- moxie
----------

Thought I would share my mail from moxie
onryo