Its not tough to Hijack / Capture / Sniff Wifi Traffic on almost any network as long as you are connected to it. Once you apply all the correct tricks, all future traffic for Wifi clients i.e. laptops, mobiles will be routed from your PC, giving you every bit of information about what others are doing on the network.
How to hijack/ capture/ Sniff HTTP traffic
Warning: Do not attempt to do this on a Public Wifi or a Corporate Wifi. Doing so could lead you to serious consequences. In no way is Taranfx responsible for any harms. This is solely intended for fun @ home.
Lets take 3 PCs into reference for our activity:
- Real gateway router: IP address 192.168.0.1, MAC address 48:5d:34:aa:c6:aa
- Fake gateway: A Laptop PC called hacker-laptop, IP address 192.168.0.200, MAC address c0:30:2b:47:ef2:74
- Victim: a laptop on wireless called victim-laptop, IP address 192.168.0.111, MAC address 00:23:6c:8f:3f:95
The gateway router, like most modern routers, is bridging between the wireless and wired domains, so ARP packets get broadcast to both domains.
Step 1: Enable IPv4 forwarding
Unless IP forwarding is enabled, hacker-laptop won’t receive all the network traffic because the networking subsystem is going to ignore packets that aren’t destined for us. So step 1 is to enable IP forwarding. To enable it, set a non zero value like:
root@hacker-laptop:~# echo 1 > /proc/sys/net/ipv4/ip_forward
Step 2: Set routing rules
We want to set rules so that all traffic routes through hacker-laptop, acting like a NAT router. Just like a typical NAT, it would rewrite the destination address in the IP packet headers to be its own IP address.
This can be done as follows:
tarranfx@hacker-laptop:~$ sudo iptables -t nat -A PREROUTING \
> -p tcp –dport 80 -j NETMAP –to 192.168.0.200
The iptables command has 3 components:
- When to apply a rule (-A PREROUTING)
- What packets get that rule (-p tcp –dport 80)
- The actual rule (-t nat … -j NETMAP –to 192.168.0.200)
What above command does: If you’re a TCP packet destined for port 80 (HTTP traffic), actually make my address, 192.168.0.200, the destination, NATting both ways so this is transparent to the source.”
Step 3: Adding IP adddress to interface
The networking subsystem will not allow you to ARP for a random IP address on an interface — it has to be an IP address actually assigned to that interface:
taranfx@hacker-laptop:~$ sudo ip addr add 192.168.0.1/24 dev eth0
and verify that the original IP address 192.168.0.200, and the gateway address 192.168.0.1.
taranfx@hacker-laptop:~$ ip addr
3: eth0: mtu 1500 qdisc noqueue state UNKNOWN
link/ether c0:30:2b:47:ef2:74 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.200/24 brd 192.168.1.255 scope global eth0
inet 192.168.0.1/24 scope global secondary eth0
inet6 fe80::230:1bff:fe47:f274/64 scope link
valid_lft forever preferred_lft forever
Step 4: Responding to HTTP requests
hacker-laptop would need a HTTP server setup. t could be any damn server, I used Apache for ease of use. Here you can get creative, e.g. respond with random pages for specific URLs or define a local URL e.g. http://fun
Step 5: Test pretending to be the gateway
Most of the things are already done and our hacker-laptop is ready to pretend as the Wifi Gateway, but the trouble is convincing victim-laptop that the MAC address for the gateway has changed, to that of hacker-laptop.
The solution is to send a Gratuitous ARP, which says “I know nobody asked, but I have the MAC address for 192.168.0.1”. Machines that hear that Gratuitous ARP will replace an existing mapping from 192.168.0.1 to a MAC address in their ARP caches with the mapping advertised in that Gratuitous ARP.
There are lots of command line utilities and bindings in various programming language that make it easy to issue ARP packets. I used the arping tool:
taranfx@hacker-laptop:~$ sudo arping -c 3 -A -I eth0 192.168.0.1
We’ll send a Gratuitous ARP reply (-A), three times (-c -3), on the eth0 interface (-l eth0) for IP address 192.168.0.1.
This can be then verified on the victim’s machine using “arp -a” command
Bingo! victim-laptop now thinks the MAC address for IP address 18.104.22.168 is 0:30:1b:47:f2:74, which is hacker-laptop’s address.
If I try to browse the web on victim-laptop, I am served the resource matching the rules in hacker-laptop’s web server.
That means all of the non-HTTP traffic associated with viewing a web page still happens as normal. In particular, when hacker-laptop gets the DNS resolution requests for Google.com, the test site I visited, it will follow its routing rules and forward them to the real router, which will send them out to the Internet:
The fact is that hacker-laptop has rerouted and served the request is totally transparent to the client at the IP layer and victim-laptop has no clue.
Undo the changes
So, you had enough fun and wish to revert? Here we go:
taranfx@hacker-laptop:~$ sudo ip addr delete 192.168.0.1/24 dev eth0
taranfx@hacker-laptop:~$ sudo iptables -t nat -D PREROUTING -p tcp –dport 80 -j NETMAP –to 192.168.0.200
To get the client machines to believe the router is the real gateway, you might have to clear the gateway entry from the ARP cache with arp -d 192.168.0.1, or bring your interfaces down and back up.