Layer-2 attacks against the network
The lowest layer of the internet protocol suite is the link layer, which is the realm of adjacent hosts on a LAN segment. Link layer communication protocols don't leave the network via routers, so it's important to be aware of them and their weaknesses when you are attacking LANs. When you join a LAN, even a restricted one outside of the protected network, you're sharing that space with anything else on that segment: the captive portal host itself, other clients waiting to be authenticated, and in some cases, even with authenticated clients.
When our victim joined the LAN, it was assigned an IP address by DHCP. But, any device with a message for that IP address has to know the link layer hardware address associated with the destination IP. This layer-2 – layer-3 mapping is accomplished with Address Resolution Protocol (ARP). An ARP message informs the requester where (for instance, at which link layer address) a particular IP address is assigned. The clients on the network maintain a local table of ARP mappings. For example, on Windows, you can check the local ARP table with the arp -a command. The fun begins when we learn that these tables are updated by ARP messages without any kind of verification. If you're an ARP table and I tell you that the gateway IP address is mapped to 00:01:02:aa:ab:ac, you're going to just believe it and update accordingly. This opens up the possibility for poisoning the ARP table – feeding it bad information.
What we're going to do is feed the network bad ARP information, so that the gateway believes that the Kali attacker's MAC address is assigned the victim's IP address; meanwhile, we're also telling the network that the Kali attacker's MAC address is assigned the gateway IP address. The victim will send data meant for the gateway to me, and the gateway will send data meant for the victim to me. Of course, that would mean nothing is actually getting from the gateway to the victim and vice versa, so we'll need to enable packet forwarding so that the Kali machine will hand off the message to the actual destination. By the time the packet gets to where it was meant to go, we've processed it and sniffed it.
First, we enable packet forwarding with the following command:
# echo 1 > /proc/sys/net/ipv4/ip_forward
An alternative command is as follows:
# sysctl -w net.ipv4.ip_forward=1
arpspoof is a lovely tool for really fast and easy ARP poisoning attacks. Overall, I prefer Ettercap; however, I will be covering Ettercap later on, and it's always nice to be aware of the quick and dirty ways of doing things for when you're in a pinch. Ettercap is ideal for more sophisticated reconnaissance and attack, but with arpspoof, you can literally have an ARP man-in-the-middle attack running in a matter of seconds.
The -i flag is the interface; the -t flag is the target; and the -r flag tells arpspoof to poison both sides to make it bidirectional. (The older version didn't have the -r flag, so we had to set up two separate attacks.)
Here, we can see arpspoof in action, telling the network that the gateway and the victim are actually my Kali box. Meanwhile, the packets will be forwarded as received to the other side of the intercept. When it works properly (namely, your machine doesn't create a bottleneck), neither side will know the difference unless they are sniffing the network. When we check back with Wireshark, we can see what an ARP poisoning attack looks like.
We can see communication between the victim and the gateway, so now it's a matter of filtering for what you need. In our demonstration here, we're looking for an authentication to a web portal – likely a POST message. When I find it, I follow the conversation in Wireshark by right-clicking a packet and selecting Follow, and there are the victim's credentials in plain text:
