Monday, October 26, 2015

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. 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.

Monday, October 5, 2015

VMWare Workstation 10/11 on Fedora 23 Beta

UPDATE. Take a look at the comment by Vincent Cojot below for a solution on how to run VMWare Workstation/Player on Fedora 23. Take care only to go into /usr/lib/vmware/lib instead of /usr/lib/vmware as pointed out by wolf (comment after), but other than that, everything works! Note that you must not change and/or set LD_LIBRARY_PATH as first suggested by this post!
I decided to upgrade one of my laptops from Fedora 22 to the newest Fedora 23 Beta. The upgrade process went smoothly but when I tried to run VMWare, it just silently failed. Googling around for Fedora 23 and VMWare Workstation didn't help. Then, I stumbled on this thread, about the problem that VMWare installation has with GCC 5.1 used on SuSE. Turns out that the same version is used on Fedora 23, so I tried the solution from a given thread which suggest the modification of LD_LIBRARY_PATH due to the missing symbol in system provided library gtkmm:
$ export LD_LIBRARY_PATH=/usr/lib/vmware/lib/$LD_LIBRARY_PATH
$ vmware
(vmware-modconfig:11918): Gtk-WARNING **: Unable to locate theme engine in module_path: "adwaita",
(vmware-modconfig:11918): Gtk-WARNING **: Unable to locate theme engine in module_path: "adwaita",
/usr/share/themes/Adwaita/gtk-2.0/gtkrc:1163: error: unexpected identifier `direction', expected character `}'
/usr/share/themes/Adwaita/gtk-2.0/gtkrc:1163: error: unexpected identifier `direction', expected character `}'
(vmware-tray:12017): Gtk-WARNING **: Unable to locate theme engine in module_path: "adwaita",
(vmware-tray:12017): Gtk-WARNING **: Unable to locate theme engine in module_path: "adwaita",
/usr/share/themes/Adwaita/gtk-2.0/gtkrc:1163: error: unexpected identifier `direction', expected character `}'
Basically, this helped a bit because now vmware doesn't fail silently. Yet, it still doesn't start. In the end, it seems that the problem is a bit more complex, as explained in this thread, so in case you need VMWare Workstation, don't upgrade yet. :)

About Me

scientist, consultant, security specialist, networking guy, system administrator, philosopher ;)