Intercepting and redirecting traffic from VMWare Workstation

After some time I decided to try again sslstrip (note that there is enhanced version of sslstrip on GitHub). First, I tried to do everything on a single host, i.e. sslstrip is running on a same machine as is browser whose traffic I wanted to intercept. It turned out that this isn't so easy because there is no rule for iptables that would allow me to differentiate traffic of Firefox and SSLStrip.  Because of that fact, if I were to redirect traffic that tries to go the port 80 on the Internet so that Firefox's traffic goes to SSLStrip, I would also redirect traffic from SSLStrip to itself creating infinite loop. For some reason filtering based on PID, a.k.a. process identified, isn't possible. It used to be possible, but then it was removed. There are two solutions to overcome the problem of running everything within a single OS:

1. Run SSLStrip as a separate user (or Firefox as a separate user). IPTables allows match on UID, or
2. Run Firefox or SSLStrip in a separate network namespace.

Instead, I decided to use VMWare Workstation (I had a version 11.1.2 when I wrote this post) and to intercept its traffic. The reason I chose VMWare was that I had one virtual machine already running at hand. But it turned out that it isn't so easy, either. In the end, the problem was caused by my lack of understanding on how VMWare Workstation works. Additional problems were caused by delays that happen after changing network parameters, i.e. it takes time that the changes take effect and thus to be observable.

So, the main problem was that traffic generated by the virtual machine isn't intercepted by standard Netfilter rules when default configuration is used along with NAT networking. To see why, look at the following figure which show logical network topology:

The figure shows that traffic from Guest OS goes to virtual switch (vswitch) and then to the external network bypassing Host's netfilter hooks. So, even though there is vmnet8 in the host OS and traffic can be seen on the given interface, it doesn't go through standard NETFILTER hooks. Actually, vmnet8 is Host's interface to virtual switch. Also, if you take look at how the network is configured within Guest OS you'll note that the gateway address is set to x.y.z.2 while IP address of vmnet8 is x.y.z.1.

The behavior when the gateway is x.y.z.2 is:

1. If you try to filter packets going from Guest OS to the Internet using iptables you won't succeed. I tried to put DENY rule in filter table of all chains and it didn't work. Actually, nothing will work as netfilter hooks aren't called at all.

So, the trick, in the end, is to change default GW on Guest OS so that traffic is routed to HostOS where you can then manipulate it. In that case you'll have to also:

1. enable IP forwarding (/proc/sys/net/ipv4/ip_forward) on Host OS.
2. Activate NAT or masquerade for outgoing traffic if you want guest machine to communicate with the outside world!

Note that you can observe some delay between setting some parameter/behavior (like adding NAT rule) and the time the behavior starts to be observable, i.e. it works. Anyway, at this point you can redirect network traffic, in other words, you can then use netfilter hooks.

So, to finish this post, you should start SSLStrip and add the following rule on Host OS:

iptables -A PREROUTING -t nat -i vmnet8 -p tcp \
        --dport 80 -j REDIRECT --to-port 10000

And then try to access, e.g. http://www.facebook.com. Be careful that you didn't previously access Facebook because in that case browser will know it must use https and it won't try to use http, even if you typed it in the URL bar. If this happens than just clean the complete browser history and try again.

How to fix weak DH key in Zimbra 7

I just had to fix a problem of weak DH keys in Zimbra 7. Namely, Firefox and Chrome, after upgrade, don't want to connect to servers that use DH keys less than 1024 bits. This means that IMAP won't work either, as it uses SSL/TLS too (or at least it should ;)). Note that the solution is to upgrade to newest Zimbra version, but for me at the moment there is no way I can upgrade my server, i.e. the upgrade is planned but currently it isn't possible. Googling around gave nothing for Zimbra 7, but only for Zimbra 8. In the end, it also turned out that in order to fix the length of DH keys it is necessary to have Java 8, while in Zimbra 7 Java 6 is used.

After a lot of search, the solution turned out to be easy. The key is to disable cipher suites that use DH keys. I managed to do that using the following commands:

zmprov mcf +zimbraSSLExcludeCipherSuites TLS_DHE_RSA_WITH_AES_128_CBC_SHA
zmprov mcf +zimbraSSLExcludeCipherSuites TLS_DHE_RSA_WITH_AES_256_CBC_SHA
zmprov mcf +zimbraSSLExcludeCipherSuites TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
zmprov mcf +zimbraSSLExcludeCipherSuites TLS_DHE_RSA_WITH_DES_CBC_SHA
zmprov mcf +zimbraSSLExcludeCipherSuites TLS_DHE_RSA_WITH_DES_CBC3_SHA
zmprov mcf +zimbraSSLExcludeCipherSuites TLS_EDH_RSA_WITH_3DES_EDE_CBC_SHA
zmprov mcf +zimbraSSLExcludeCipherSuites SSL_EDH_RSA_WITH_3DES_EDE_CBC_SHA
zmprov mcf +zimbraSSLExcludeCipherSuites TLS_DHE_DSS_WITH_AES_128_CBC_SHA
zmprov mcf +zimbraSSLExcludeCipherSuites TLS_DHE_DSS_WITH_AES_256_CBC_SHA
zmprov mcf +zimbraSSLExcludeCipherSuites SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
zmmailboxdctl restart

After that, Webmail worked again. You can check supported ciphersuites using sslscan command, i.e. in my case after the given change I got the following ciphersuites:

$ sslscan webmail:443 | grep Accepted
    Accepted  SSLv3  256 bits  AES256-SHA
    Accepted  SSLv3  168 bits  EDH-RSA-DES-CBC3-SHA
    Accepted  SSLv3  168 bits  DES-CBC3-SHA
    Accepted  SSLv3  128 bits  AES128-SHA
    Accepted  SSLv3  128 bits  RC4-SHA
    Accepted  SSLv3  128 bits  RC4-MD5
    Accepted  TLSv1  256 bits  AES256-SHA
    Accepted  TLSv1  168 bits  EDH-RSA-DES-CBC3-SHA
    Accepted  TLSv1  168 bits  DES-CBC3-SHA
    Accepted  TLSv1  128 bits  AES128-SHA
    Accepted  TLSv1  128 bits  RC4-SHA
    Accepted  TLSv1  128 bits  RC4-MD5

Even though Webmail worked, Thunderbird didn't connect. Using Wireshark I found out that Thunderbird, for IMAP connection, tries to use EDH-RSA-DES-CBC3-SHA. I tried to disable that ciphersuite on the server side, but no matter what I've tried, it didn't work. In the end I disabled that cipher on the client side. I opened Thunderbird's configuration editor and there I manually disabled given cipher by setting configuration setting to false.

Few notes about sslstrip tool...

I decided to test sslstrip tool. The idea was that I'll use it to demonstrate to users that they should take a note if there is https when they are accessing some site where they have to type password or some other sensitive data. To create test network I used Windows 7 running within VMware Workstation and using iptables I redirected traffic from virtual machine to local port 80 where I started sslstrip tool. But, no matter what I did, it didn't work. It seems that when VMWare is used iptables redirection  doesn't work as expected. In other words, it seems that netfilter hooks aren't placed within vmware network stack.

I managed to get around that issue by modifying hosts file within Windows. Namely, you should open file C:\Windows\System32\drivers\etc\hosts and add the following line there:

192.168.x.1     www.facebook.com facebook.com

The exact IP address is the one assigned to vmnet8 interface on host operating system. Now start Firefox as usual and type in the URL bar:

http://www.facebook.com

Note that I'm explicitely telling Firefox to use http, not https. Anyway, after I did it this way everything worked as expected.

The next "problem" you migh have is that no matter what you do, the site you access automatically switches to https. The reason is HSTS. It is used by server to inform Web browser that it should be accessed only through SSL connections. For this reason sslstrip doesn't work with sites that use HSTS, like Google  and Twitter. But, it doesn't mean that those sites are completely protected. If the client is accessing those sites for the first time or the client never used https to access them, then HSTS can be prevented. The point is that HSTS information is transferred only via https connection. Anyway, to get around this clear history (i.e. go Tools then Clear Recent History... and select to clear everything).

And, for the end, I don't think that it is necessary to enable forwarding in the Linux kernel in order for sslstrip to work, i.e. the following command is unnecessary:

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

Namely, the kernel isn't doing forwarding of IP packets in order for this to work. sslstrip acts as a proxy and thus kernel isn't doing any relaying. But, in case you are diverting only a part of the traffic, e.g. only HTTP, and the kernel is handling the rest, i.e. DNS, then forwarding is necessary in the kernel.