Are there any pitfalls connected to using arpspoof/sslstrip/etercap on Qubes?

[Vít Šesták]

Hello,
I'd like to test something on my tablet and I need to spoof some traffic. On bare-metal Ubuntu, I was successful with arpspoof, sslstrip and modified /etc/hosts (and Nginx). I basically did something like https://wmsmartt.wordpress.com/2011/08/30/man-in-the-middle-attacks-with-sslstrip-and-arpspoof/ and it worked.

I tried the howto in sys-net and it did basically two things. First, it blocked all the networking on my tablet and blocked HTTP for my laptop. While I know the reason for the latter (I did not specify network interface for iptables), I still don't know why it just blocked all the networking. Are there any Qubes-specific pitfalls? I was running all these tools in sys-net, as this VM has direct access to the network and it should work like on bare metal, shouldn't it?

(While I know some basics about network and spoofing there, I am rather interested in higher-level protocols, so there might be some stupid mistake done by me.)

I had similar results with Ettercap.

Regards,
Vít Šesták 'v6ak'

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

It can be some interaction with default iptables settings on Qubes. Take
a look at `iptables -nvL` and `iptables -t nat -vnL`. Especially on the
later one you'll see MASQUERADE for all the outgoing traffic.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVYO4MAAoJENuP0xzK19cs5w4H/2TEMnRAIS64bM9wlFtt7UMH
r5H6eTaxctyn8FpqWkZT/r5SqtUXYjOXki8Pd1450A8VQ/b715zajJKxaRwuqB2E
J1uWSpBcsB3WzeE0+kiV0I2/feKkI7o/jWfNTAdEeatEa8BiO4TA1FAXT6QSxa5J
KamNXq2msIB2lgmeV7EH/wdG4e98eNbHkDc4BCCtTyPxF20O1mAGSyQfWAL5a6rL
UJz6ayomYq7yNWCAyJFSdL8HSoNLBgwyB8AUKTTw7ldQQv0SjlPNc1UVB0li8ZKD
gH8OZCC2Nf6lLGsAHFuCG978RU6Qjg79FP9HyIo9pG7X+FJUUzzLxYgqK83Pu1Q=
=Nsfh
-----END PGP SIGNATURE-----

[Vít Šesták]

Thank you for pointing to iptables rules. This was likely the cause. I was unable to solve it fully, though. The downside of my solution is that I can just choose between a working internet connection for me (the spoofed machine can't effectively access the network) and working internet connection for sys-net the spoofed machine (all VMs except sys-net have networking unavailable).

I just did these steps:
1. Backup iptables rules using sudo iptables-save, piping the output to a file.
2. Remove all the rules (maybe just rules related to NAT would be enough): http://www.adminsehow.com/2009/08/how-to-clear-all-iptables-rules/
3. Perform all sslstrip steps (enabling IPv4 forwarding, arpspoof, one iptables rule and sslstrip itself).
4. Do some adjustments (one might run Wireshark, I did some tuning with Nginx)
5. After everything is done, run sudo iptables-restore < backup-file. Rebooting sys-net would likely do the same job, but I would have to reboot other VMs, too.

Unfortunately, even the inter-VM networking does not work in this case. I wanted to run Nginx in an extra VM connected directly to sys-net, but it was unreachable from sys-net. So, I installed nginx directly to sys-net. It is not optimal, but it is acceptable for me.

As network spoofing is not my daily job, such limitations (e.g. networking in sys-net only during the attack) are acceptable for me.

Regards,
Vít Šesták 'v6ak'