With network access control, authentication is the name of the game. In our first attack scenario, we saw that the network verifies that a device is permitted by MAC address whitelisting. The principle is simple—a list of allowed devices is checked when a device joins the network. Many people, even outside of the field, are familiar with MAC filtering from the common implementation of this technique in SOHO wireless routers. However, you may be surprised at how often the VoIP phone masquerade will work in highly secured environments.
It's Network Security 101: MAC addresses are very easily faked, and networks will take your word for it when you claim to be a particular value. I've had clients detail, at length, the various features of their state-of-the-art NAC, only to look puzzled when I show them I had network access to their server environment by pretending to be a conference room phone. It's important to test for this bypass; not many clients are aware of simple threats.
We're now going to look at another attack that can fly surprisingly low under the radar: exploiting authentication communications in the initial restricted network. We'll be using Wireshark for quick and easy packet analysis in this section; more advanced Wireshark discussion will take place in Chapter 2, Sniffing and Spoofing.
Speaking of security mechanisms that even non-security folks will have some familiarity with, captive portals are a common network access control strategy. They're the walls you encounter when trying to get online in a hotel or an airplane; everything you try to access takes you to a specially configured login screen. You will receive credentials from an administrator, or you will submit a payment – either way, after you've authenticated, the captive portal will grant access via some means (a common one is SNMP management post-authentication).
I know what the hacker in you is saying: When the unauthenticated client tries to send an HTTP request, they get a 301 redirect to the captive portal authentication page, so it's really nothing more than a locally hosted web page. Therefore, it may be susceptible to ordinary web attacks. Well done, I couldn't have said it better. But don't fire up sslstrip just yet; would it surprise you to learn that unencrypted authentication is actually fairly common? We're going to take a look at an example: the captive portal to grant internet access to guests in my house. This isn't your run-of-the-mill captive portal functionality built in to an off-the-shelf home router; this is a pfSense firewall running on a dedicated server.
This is used in some enterprises, so trust me, you will run into something like this in your adventures as a pen tester.
Guests are advised that my cat pretty much makes the decisions around here
What we see here is the captive portal presented to a user immediately upon joining the network. I wanted to have a little fun with it, so I wrote up the HTML myself (the bad cat pun is courtesy of my wife). However, the functionality is exactly the same as you'll see in companies that utilize this NAC method.
Let's get in the Kali driver's seat. We've already established a connection to this network, and we're immediately placed into the restricted zone. Fire up a Terminal and start Wireshark.
Not a lot is going on here, even with our card in promiscuous mode. This looks like we're dealing with a switched network, so traffic between our victim and the gateway is not broadcasted for us to see. But, take a closer look at the highlighted packet: it's coming from the gateway at 10.108.108.1 and going to 255.255.255.255, which is the broadcast address of the zero network (namely, the network we're on). We can see that it's a DHCP ACK packet – an acknowledgment of a DHCP request. So, our victim with an unknown IP address is joining the network, and will soon authenticate to the portal. Though the victim isn't the destination, we'll find the IP address assignment in the DHCP ACK packet:
Wireshark is kind enough to convert that hex into a human-friendly IP address: 10.108.108.36. We're on a switched LAN, so our victim's HTTP authentication is going directly to the gateway, right? Yes, it is, but the keyword here is LAN.
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.
Note
The unqualified term LAN, doesn't necessarily mean that all members of the LAN are in the same broadcast domain, also called a layer-2 segment. For our purposes here, we're talking about hosts sharing the same link layer environment, as the attack described won't work in private VLANs.
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.
Note
We will cover spoofing in more detail in Chapter 2, Sniffing and Spoofing.
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=1arpspoof 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:
