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

We will be using ARP and iptables on a Linux machine to accomplish most of the stuff. It’s an easy and fun way to harass your friends, family, or flatmates while exploring the networking protocols.

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 or Hack Community 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:

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:

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:

and verify that the original IP address 192.168.0.200, and the gateway address 192.168.0.1.



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:

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 192.169.1.1 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:

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.

Thanks....