• Kali Linux installed on a laptop
• A USB wireless network interface card that supports promiscuous mode in Kali—I recommend Alfa cards

An attacker needs to be aware of methods for remote compromise: attacking the VPN, wireless infiltration from a distance using high-gain antennas, and so forth. However, the pen tester can never forget the big picture. This is a field where it's very easy to get caught up in the highly specific technical details and miss the human element of security design.

There's a design flaw concept that pen testers like to call the candy bar model. This simply refers to a network that is tough and crunchy on the outside, but gooey on the inside. In other words, it's a model that emphasizes the threats of the outside world when designing the security architecture, while assuming that someone who is physically inside company facilities has been vetted and is therefore trusted. The mindset here dates back many years; in the earliest days of what became the internet, the physical access points to the network were inside highly secure facilities. Packets coming in over the network were safely assumed to be from a secure environment and sent by an authorized individual. In today's world, a packet hitting the border of a company's network could be from an authorized individual on a business trip, or it could be from a clever teenager in Thailand eager to try out some newly learned tricks.

The candy bar model will come up in later chapters when we discuss other network attacks. Once you crack that outer shell, you'll often find that the path forward seems paved especially for you—and a successful compromise will inform your client of the devastating consequences of this mistaken assumption.

How you social engineer your target is a subject for another book altogether, but for the purposes of this discussion, let's assume that you have physical access to network drops. Not all physical access is the same, though: if you convinced your target to hire you as a full-time employee, then you'll have constant physical access. They'll even hand you a computer. However, what's more likely is that you've exploited a small gap in their physical security stance, and your presence can be undetected or tolerated for only a short period of time. You've snuck in through the smoker's door after striking up some conversation with an unwitting employee; you've been given permission to walk around for an hour with a convincing-looking contractor uniform and clipboard; or (my personal favorite) you've earned trust and affection by bringing in a big box of doughnuts for the people expecting an auditor's visit based on a well-scripted phone call. We'll demonstrate how to set up a Kali box to function as a rogue wireless access point while impersonating the MAC address of a VoIP phone.

You've found an unoccupied cubicle with an empty desk and a generic IP Phone. The phone is plugged in and working, so you know the network drop is active. We'll drop our small laptop running Kali here and continue the attack from outside.

First, we've unplugged the IP Phone so that our bad guy can take the port. We're going to clone the MAC address of the IP Phone on our Kali box's Ethernet port. From the perspective of a simple MAC address whitelisting methodology of NAC, this will look like the phone merely rebooted. 

I use ifconfig to bring up the interface configuration. In my example, my Ethernet port interface is called eth0 and my wireless interface is called wlan0. I'll note this for later, as I will need to configure the system to run an access point with DHCP and DNS on wlan0, while running NAT through to my eth0 interface. I can use ifconfig eth0 hw ether to change the physical address of the eth0 interface. I've sneaked a peek at the label on the back of the IP Phone – the MAC address is AC:A0:16:23:D8:1A.

So, I bring the interface down for the change, bring it back up, then run ifconfig one more time to confirm the status of the interface with the new physical address:

Two handy tools in the Kali repository are dnsmasq and hostapd:

• dnsmasq is a lightweight network infrastructure utility. Completely free and written in C, this is a nifty tool for setting up a quick and dirty network on the fly, complete with DHCP and DNS forwarding. In our example, we're using it as a DHCP and DNS service for the wireless clients who connect to our access point (which would be you and your colleagues, of course).
• hostapd (host access point daemon) is, as the name implies, access point software for turning your ordinary wireless network interface into an access point and even an authentication server. You can confirm that whatever Wi-Fi card you're using supports AP mode with this command:

# iw list |grep "Supported interface modes" -A 8

If you see AP in the results, you're good to go. We use apt-get install hostapd dnsmasq to grab the tools.

First, let's configure dnsmasq. Open up /etc/dnsmasq.conf using the nano command:

 

You can see that the configuration file has everything you need to know commented out; I strongly recommend you sit down with the readme file to understand the full capability of this tool, especially so you can fine-tune your use for whatever you're doing in the field.  Since this is a hands-on demonstration, I'm keeping it pretty simple:

• I set my interface to wlan0, where the USB wireless card that will play the role of access point is located.
• I set the DHCP range where new clients will be assigned IP addresses when they request an assignment. The format is [bottom address],[top address],[lease time]. The address range here is what would be assigned to new clients, so make sure you don't overlap with the gateway address. You're the gateway!
• DHCP options specification. This isn't arbitrary—these numbers are specified in RFC 2132 and subsequent RFCs, so there's a lot of power here. For our purposes here, I'm setting the gateway with option 3 and DNS with option 6. In this case, they're the same address as we would expect on a tiny LAN like this one. Note the address: 10.11.12.1. That's the gateway that by definition, will be your wlan0 interface. You'll define that address when you bring up the wireless interface just prior to firing up the access point.
• I defined the upstream DNS server; I set it to Google 8.8.8.8, but you can use something different. 
• I did some logging, just in case we need it.

Hit Ctrl + X and confirm the file name to save it. Now, we'll move on to the hostapd configuration. Open up /etc/hostapd/hostapd.conf using the nano command:

Again, this is a tool with a lot of power, so check out the readme file so you can fully appreciate everything it can do. You can create a rather sophisticated access point with this software, but we'll just keep it simple for this example:

• I set the interface to wlan0, of course.
• I defined the wireless driver; this is nl80211, the interface between cfg80211 and user space, and it allows for management of the device.
• ssid is our service set identifier – our network's name. I'm using NotABadGuy because I want to convince the world that I'm really a good guy, but of course, you'll fine-tune this to your needs. There's a bit of social engineering potential here to minimize suspicion on the part of those casually scanning the environment. 
• hw_mode is the 802.11 modulation standard; b, g, and n are common.
• I've defined the channel here, but you can configure it to pick the channel automatically based on surveying.
• macaddr_acl is a Boolean flag to tell hostapd if we're using a MAC-based access control list. You'll have to decide if this is something you need for your purposes. In my example, I've configured encryption, and I like to use randomly generated MACs on my devices anyway, so I'd rather not deal with whitelisting MACs. 
• max_num_sta is one way to keep the population of wireless clients restricted— this is the maximum number of clients that are allowed to join. I set mine as 1 here since I only expect myself to be joining, but you could omit this.
• ignore_broadcast_ssid simply allows you to hide the network. What it really does is cause your AP to ignore probe request frames that don't specify the SSID, so it will hide your network from active scans, but you should never consider a functional access point to be hidden. I want to see it in my example, so I set it to 0.
• The remaining options allow me to configure WPA2 encryption.  

Believe it or not, those are the basics for our quick and dirty access point to the physical network. Now, I'll bring up the wlan0 interface and specify the gateway address I defined earlier. Then I bring up dnsmasq and tell it to use my configuration file. We enable IP forwarding to tell Kali to act like a router with sysctl. We allow our traffic through and enable NAT functionality with iptables. Finally, we fire up hostapd with our configuration file.  

When a wireless client connects to this network, they will have access to the corporate network via eth0; to a MAC filter, traffic coming from that port will appear to be coming from a Cisco IP Phone:

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.

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.

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:

We've seen how network access control systems can employ simple MAC address filtering and captive portal authentication to control network access. Now, suppose that you're coming away from the ARP poisoning attack just described, excited that you scored yourself some legitimate credentials. You try to log in with your Kali box and you're slapped down by a validation check that you hadn't foreseen. You have the correct username and password – how does the NAC know it isn't the legitimate user?

NAC vendors quickly figured out that it was a simple matter for anyone to spoof a MAC address, so some systems perform additional verification to match the hardware address to other characteristics of the system. Imagine the difference between authenticating someone by fingerprint alone and authenticating someone by fingerprint, clothing style, vocal patterns, and so on.  The latter prevents simple spoof attacks. In this context, the NAC is checking that the MAC address matches other characteristics: manufacturer, operating system, and user agent are common checks. It turns out that the captive portal knows this Phil user you've just spoofed, and it was expecting an Apple iPad (common in the enterprise as an approved device). Let's review these three checks in detail.

There are two main parts to a MAC address: the first three octets are the Organizationally Unique Identifier (OUI), and the last three octets are Network Interface Controller-specific (NIC-specific). The OUI is important here because it uniquely identifies a manufacturer. The manufacturer will purchase an OUI from the IEEE Registration Authority and then hardcode it into their devices in-factory. This is not a secret – it's public information, encoded into all the devices a particular manufacturer makes. A simple Google search for Apple OUI helps us narrow it down, though you can also pull up the IEEE Registration Authority website directly. We quickly find out that 00:21:e9 belongs to Apple, so we can try to spoof a random NIC address with that (for example, 00:21:e9:d2:11:ac).

But again, vendors are already well aware of the fact that MAC addresses are not reliable for filtering, so they're likely going to look for more indicators. 

Anyone who has dissected a packet off a network should be familiar with the concept of operating system fingerprinting.  Essentially, operating systems have little nuances in how they construct packets to send over the network. These nuances are useful as signatures, giving us a good idea of the operating system that sent the packet. We're preparing to spoof the stack of a chosen OS as previously explained, so let's cover a tool in Kali that will come in handy for a variety of recon situations: Passive Operating system Fingerprinter (p0f). 

Its power is in its simplicity: it watches for packets, matches signatures according to a signature database of known systems, and gives you the results. Of course, your network card has to be able to see the packets that are to be analyzed. We saw with our example that the restricted network is switched, so we can't see other traffic in a purely passive manner; we had to trick the network into routing traffic through our Kali machine. So, we'll do that again, except on a larger scale as we want to fingerprint a handful of clients on the network. Let's ARP spoof with Ettercap, a tool that should easily be in your handiest tools Top 10. Once Ettercap is running and doing its job, we'll fire up p0f and see what we find. 

We're going to bring up Ettercap with the graphical interface featuring a very scary-looking network-sniffing spider:

# ettercap -G

Let's start sniffing, and then we'll configure our man-in-the-middle attack. Click Sniff in the menu at the top and choose Unified Sniffing. Unified sniffing means we're just sniffing from one network card; we aren't forwarding anything to another interface right now.

Now we tell Ettercap to find out who's on the network. Click Hosts | Scan for hosts. When the scan is complete, you can click Hosts again to bring up the host list. This tells us what Ettercap knows about who's on the network. 

Now, we're doing something rather naughty; I've selected the gateway as Target 1 (by selecting it and then clicking Add to Target 1) and a handful of clients as Target 2. This means Ettercap is going to poison the network with ARP announcements for all of those hosts, and we'll soon be managing the traffic for all of those hosts.

Select Mitm | ARP poisoning. I like to select Sniff remote connections, though you don't have to for this particular scenario.  

That's it. Click OK and now Ettercap will work its magic. Click View | Connections to see all the details on connections that Ettercap has seen so far.

Those of you who are familiar with Ettercap may know that the Profiles option in the View menu will allow us to fingerprint the OS of the targets, but, in keeping with presenting the tried-and-true, quick-and-dirty tool for our work, let's fire up p0f. The -o flag allows us to output to a file – trust me, you'll want to do this, especially for a spoofing attack of this magnitude: 

# p0f -o poflog

p0f likes to show you some live data as it's collecting the juicy gossip. Here we can see that 192.168.108.22 is already fingerprinted as a Windows NT host by looking at a single SYN packet:

Ctrl + C closes p0f. Now, let's open up our (greppable) log file with nano:

Beautiful, isn't it? The interesting stuff is the raw signature at the end of each packet detail line, which is made up of colon-delimited fields in the following order:

1. Internet protocol version (for instance, 4 means IPv4).
2. Initial time-to-live (TTL). It would be weird if you saw anything other than 64, 128, or 255, but some OSes use different values; for example, you may see AIX hosts using 60, and legacy Windows (95 and 98) using 32.
3. IPv4 options length, which will usually be 0. 
4. Maximum Segment Size (MSS), which is not to be confused with MTU. It's the maximum size in bytes of a single TCP segment that the device can handle. The difference from MTU is that the TCP or IP header is not included in the MSS.  

5. TCP receive window size, usually specified as a multiple of the MTU or MSS. p0f is nice enough to let us know; in this case, the value is the MSS multiplied by 44. 
6. Window scaling factor, if specified.  
7. A comma-delimited ordering of the TCP options (if any are defined). 
8. A field that the readme calls quirks: weird stuff in the TCP or IP headers that can help us narrow down the stack creating it. Check out the readme file to see what kind of options are displayed here; an example is df for the don't fragment flag set.

Why are we concerned with these options anyway? That's what the fingerprint database is for, isn't it? Of course, but part of the wild and wacky fun of this tool is the ability to customize your own signatures. You might see some funky stuff out there and it may be up to you playing with a quirky toy in your lab to make it easier to identify in the wild. However, of particular concern to the pen tester is the ability to craft packets that have these signatures to fool these NAC validation mechanisms.  We'll be doing that in the next section, but for now, you have the information needed to research the stack you want to spoof.

Some budding hackers may be surprised to learn that browser user agent data is a consideration in network access control systems, but it is commonly employed as an additional validation of a client. Thankfully for us, spoofing the HTTP User-Agent field is easy. Back in my day, we used custom UA strings with cURL, but now you kids have fancy browsers that allow you to override the default.

Let's try to emulate an iPad. Sure, you can experiment with an actual iPad to capture the user agent data, but UA strings are kind of like MAC addresses in that they're easy to spoof, and detailed information is readily available online. So, I'll just search the web for iPad user agent data and go with the more common ones. As the software and hardware change over time, the UA string can change, as well. Keep that in mind if you think all iPads (or any device) are created equal.  

In Kali, we open up Firefox ESR and navigate to about:config in the address bar. Firefox will politely warn you that this area isn't for noobs; go ahead and accept the warning. Now, search for useragent and you'll see the configuration preferences that reference the user agent:

Note that there isn't an override preference name with a string data type (so we can provide a useragent string). So, we have to create it. Right-click to create a new preference name and call it general.useragent.override.

The data type is a string, of course, and the value is the user agent data. Keep in mind, there isn't a handy builder that will take specific values and put together a nicely formatted UA string; you have to punch it in character by character, so check the data you're putting there for accuracy. You could pretend to be a refrigerator if you wanted to, but I'm not sure that helps us here:

I've just dumped in the User-Agent data for an iPad running iOS 9.3.2, opened a new tab, and verified what the web thinks I am:

The Website Goodies page is now convinced that my Kali box is actually a friendly iPad.

While we're here, we should cover ourselves from JavaScript validation techniques, as well. Some captive portals may inject some JavaScript to validate the operating system by checking the Document Object Model (DOM) fields in the browser. You can manipulate these responses in the same way you did for the User-Agent data: 

general.[DOM key].override

For example, the oscpu field will disclose the CPU type on the host, so we can override the response with the following:

general.oscpu.override

As before, the data type is a string. This seems too easy, but keep in mind that the only code that will get the true information instead of your override preferences that are defined here is privileged code (for instance, code with UniversalBrowserRead privileges). If it was easy enough to inject JavaScript that could run privileged code, then we'd have a bit of a security nightmare on our hands. This is one of those cases where the trade-off helps us. 

Imagine you're trying to get into a guarded door. The moment you open that door, a guard sees you and, identifying you as unauthorized, immediately kicks you out. But, suppose that an authorized person opens the door and props it open, and the guard will only verify the identity of the person walking through every 10 minutes or so, instead of continuously. They assume that an authorized person is using the door during that 10-minute window because they already authenticated the first person who opened it and propped it open. 

Of course, this wouldn't happen in the real world (at least, I sure hope not), but the principle is often seen even in sophisticated industry-standard network access control systems. Instead of people, we're talking about packets on the network. As we learned from our fingerprinting exercise, the fine details of how a packet is formed betrays a particular source system. These details make them handy indicators of a source. It quacks like a duck and it walks like a duck, so it is a duck and definitely not a guy in a duck costume.  

NACs employing this kind of fingerprinting technique will conduct an initial evaluation, and then assume the subsequent packets match the signature, just like our guard who figures the door is being used by the good guy after they do their first check. The reason for this is simple: performance. Whether the follow-up checks are every few minutes or never will depend on the NAC and configuration. 

We're going to introduce a tool called Scapy to demo this particular attack. As we progress through this book, you will see that Scapy could easily replace most of the tools that pen testers take for granted: port scanners, fingerprinters, spoofers, and so on. We're going to do a quick demo for our NAC bypass here, but we will be leveraging the power of Scapy in coming chapters. 

The details of a TCP handshake are beyond the scope of this chapter, but we'll discuss the basics to understand what we need to do to pull off the masquerade. Most of us are familiar with the TCP three-way handshake:

1. The client sends a SYN request (synchronize)
2. The receiver replies with a SYN-ACK acknowledgment (synchronize-acknowledge)
3. The client confirms with an ACK acknowledgment; the channel is established and communication can begin

This is a very simple description (I've left out sequence numbers; we'll discuss those further), and it's nice when it works as designed. However, those of you with any significant Nmap experience should be familiar with the funny things that can happen when a service receives something out of sequence. Section 3.4 of RFC 793 is where the fun is really laid out, and I encourage everyone to read it. Basically, the design of TCP has mechanisms to abort if something goes wrong – in TCP terms, we abort with a RST control packet (reset). This matters to us here because we're about to establish a fraudulent TCP connection designed to mimic one created by the Safari browser on an iPad. Kali will be very confused when we get our acknowledgment back:

1. Scapy uses our network interface to send the forged SYN packet
2. The captive portal web service sends a SYN-ACK back to our address
3. The Kali Linux system itself, having not sent any SYNs, will receive an unsolicited SYN-ACK

4. Per RFC specification, Kali decides something is wrong here and aborts with a RST packet, exposing our operating system's identity 

Well, this won't do. We have to duct-tape the mouth of our Kali box until we get through validation. It's easy enough with iptables.

iptables is the Linux firewall. It works with policy chains where rules for handling packets are defined. There are three policy categories: input, forward, and output. Input is data destined for your machine; output is data originating from your machine; and forward is for data not really destined for your machine but will be passed on to its destination. Unless you're doing some sort of routing or forwarding – like during our man-in-the-middle attack earlier in the chapter – then you won't be doing anything with the forward policy chain. For our purposes here, we just need to restrict data originating at our machine.

Extra credit if you've already realized that, if we aren't careful, we'll end up restricting the Scapy packets! So, what are we restricting, exactly? We want to restrict a TCP RST packet destined for port 80 on the gateway and coming from our Kali box. For our demonstration, we've set up the listener at 192.168.108.215 and our Kali attack box is at 192.168.108.225.

# iptables -F && iptables -A OUTPUT -p tcp --destination-port 80 --tcp-flags RST RST -s 192.168.108.225 -d 192.168.108.215 -j DROP

Let's break this down:

• -F tells iptables to flush any currently configured rules. We were tinkering with rules for our ARP attack, so this resets everything.
• -A means append a rule. Note that I didn't use the potentially misleading term add. Remember that firewall rules have to be in the correct order to work properly. We don't need to worry about that here as we don't have any other rules, so that's for a different discussion.
• OUTPUT identifies the policy chain to which we're about to append a rule.
• -p identifies the protocol, in this case TCP.
• --destination-port and --tcp-flags are self-explanatory: we're targeting any RST control packets destined for the HTTP port.  
• -s is our source and -d is our destination. 
• -j is the jump, which specifies the rule target. This just defines the actual action taken. If this were omitted, then nothing would happen but the rule packet counter would increment.

The following screenshot illustrates the output of the preceding command:

We're ready to send our forged packets to the captive portal authentication page.

Kali Linux 2018.1 has Scapy ready to go, but it's good to make sure you have all your dependencies in order. My copy of Kali didn't have the Python ECDSA cryptography installed, for example. We don't need it here, but I don't like to have alerts when I fire up Scapy. You can run this command before we get started:

# apt-get install graphviz imagemagick python-gnuplot python-pyx python-ecdsa

You can bring up the Scapy interpreter interface by simply commanding scapy, but for this discussion, we'll be importing its power into a Python script. 

Scapy is a sophisticated packet manipulation and crafting program. Scapy is a Python program, but Python plays an even bigger role in Scapy as the syntax and interpreter for Scapy's domain-specific language. What this means for the pen tester is a packet manipulator and forger with unmatched versatility because it allows you to literally write your own network tools, on the fly, with very few lines of code – and it leaves the interpretation up to you, instead of within the confines of what a tool author imagined.

What we're doing here is a crash course in scripting with Python and Scapy, so don't be intimidated. We will be covering Scapy and Python in detail later on in the book. We'll step through everything happening here in our NAC bypass scenario so that, when we fire up Scapy in the future, it will quickly make sense. If you're like me, you learn faster when you're shoved into the pool. That being said, don't neglect curling up with Scapy documentation and some hot cocoa. The documentation on Scapy is excellent.

As you know, we set up our captive portal listener and OS fingerprinter at 192.168.108.215. Let's try to browse this address with an unmodified Firefox ESR in Kali and see what p0f picks up:

We can see in the very top line, representing the very first SYN packet received, that p0f has already identified us as a Linux client.  Remember, p0f is looking at how the TCP packet is constructed, so we don't need to wait for any HTTP requests to divulge system information. Linux fingerprints are all over the TCP three-way handshake, before the browser has even established a connection to the site.

In our example, we want to emulate an iPad (specifically, one running iOS 9.3.2 to match our user-agent spoof from earlier).  Putting on our hacker hat (the white one, please), we can put two and two together:

• p0f has a database of signatures (p0f.fp) that it references in order to fingerprint a source
• Scapy allows us to construct TCP packets and, with a little scripting, we can tie together several Scapy lines into a single TCP three-way handshake utility

We now have a recipe for our spoofing attack. Now, Scapy lets you construct communications in its interpreter, using the same syntax as Python, but what we're going to do is fire up nano and put together a Python script that will import Scapy. We'll discuss what's happening here after we confirm the attack works:

#!/usr/bin/python
from scapy.all import *
CPIPADDRESS="192.168.108.215"
SOURCEP=random.randint(1024,65535)
ip=IP(dst=CPIPADDRESS, flags="DF", ttl=64)
tcpopt=[("MSS",1460), ("NOP",None), ("WScale",2), ("NOP",None), ("NOP",None), ("Timestamp",(123,0)), ("SAckOK",""), ("EOL",None)]
SYN=TCP(sport=SOURCEP, dport=80, flags="S", seq=1000, window=0xffff, options=tcpopt)
SYNACK=sr1(ip/SYN)
ACK=TCP(sport=SOURCEP, dport=80, flags="A", seq=SYNACK.ack+1, ack=SYNACK.seq+1, window=0xffff)
send(ip/ACK)
request="GET / HTTP/1.1\r\nHost: " + CPIPADDRESS + "\rMozilla/5.0 (iPad; CPU OS 9_3_2 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Version/9.0 Mobile/13F69 Safari/601.1 \r\n\r\n"
PUSH=TCP(sport=SOURCEP, dport=80, flags="PA", seq=1001, ack=0, window=0xffff)
send(ip/PUSH/request)
RST=TCP(sport=SOURCEP, dport=80, flags="R", seq=1001, ack=0, window=0xffff)
send(ip/RST)

Once I'm done typing this up in nano, I save it as a .py file and chmod it to allow execution. That's it – the attack is ready:

The iptables outbound rule is set, and the script is ready to execute. Let it fly:

That's it; not very climactic on this end. But, let's take a look at the receiving end.

Voila! The OS fingerprinter is convinced that the packets were sent by an iOS device. When we scroll down, we can see the actual HTTP request with the user agent data. At this point, the NAC allows access and we can go back to doing our usual business. Don't forget to open up iptables:

# iptables -F

So what happened here, exactly? Let's break it down:

CPIPADDRESS="192.168.108.215"
SOURCEP=random.randint(1024,65535)

We're declaring a variable for the captive portal IP address and the source port. The source port is a random integer between 1024 and 65535 so that an ephemeral port is used: 

ip=IP(dst=CPIPADDRESS, flags="DF", ttl=64)
tcpopt=[("MSS",1460), ("NOP",None), ("WScale",2), ("NOP",None), ("NOP",None), ("Timestamp",(123,0)), ("SAckOK",""), ("EOL",None)]
SYN=TCP(sport=SOURCEP, dport=80, flags="S", seq=1000, window=0xffff, options=tcpopt)
SYNACK=sr1(ip/SYN)

Now we're defining the layers of the packets we will send. ip is the IP layer of our packet with our captive portal as the destination, a don't-fragment flag set, and a TTL of 64. Now, when Scapy is ready to send this particular packet, we'll simply reference ip. 

We define tcpopt with the TCP options we'll be using. This is the meat and potatoes of the OS signature, so this is based on our signature research.

Next we declare SYN, which is the TCP layer of our packet, defining our randomly chosen ephemeral port, the destination port 80, the SYN flag set, a sequence number, and a window size (also part of the signature). We set the TCP options with our just-defined tcpopt.  

Then, we send the SYN request with sr1. However, sr1 means send a packet, and record 1 reply. The reply is then stored as SYNACK:

ACK=TCP(sport=SOURCEP, dport=80, flags="A", seq=SYNACK.ack+1, ack=SYNACK.seq+1, window=0xffff)
send(ip/ACK)

We sent a SYN packet with sr1, which told Scapy to record the reply – in other words, record the SYN-ACK that comes back from the server. That packet is now stored as SYNACK. So, now we're constructing the third part of the handshake, our ACK. We use the same port information and switch the flag accordingly, and we take the sequence number from the SYN-ACK and increment it by one. Since we're just acknowledging the SYN-ACK and thus completing the handshake, we only send this packet without needing a reply, so we use the send command instead of sr1:

request="GET / HTTP/1.1\r\nHost: " + CPIPADDRESS + "\rMozilla/5.0 (iPad; CPU OS 9_3_2 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Version/9.0 Mobile/13F69 Safari/601.1 \r\n\r\n"
PUSH=TCP(sport=SOURCEP, dport=80, flags="PA", seq=1001, ack=0, window=0xffff)
send(ip/PUSH/request)

Now that the TCP session is established, we craft our GET request for the HTTP server. We're constructing the payload and storing it as request. Note the use of Python syntax to concatenate the target IP address and create returns and new lines. We construct the TCP layer with the PSH + ACK flag and an incremented sequence number. Finally, another send command to send the packet using the same IP layer, the newly defined TCP layer called PUSH, and the HTTP payload as request:

RST=TCP(sport=SOURCEP, dport=80, flags="R", seq=1001, ack=0, window=0xffff)
send(ip/RST)

Finally, we tidy up, having completed our duty. We build a RST packet to tear down the TCP connection we just established, and send it with the send command.

I hope I have whetted your appetite for Scapy and Python, because we will be taking these incredibly powerful tools to the next level later in this book.

In this chapter, we reviewed network access control systems and some of their techniques. We learned how to construct a wireless access point with Kali for a physical drop while masquerading as an authorized IP Phone. We learned how to attack switched networks with layer-2 poisoning to intercept authentication data for authorized users while trapped in a restricted LAN. Other validation checks were discussed and methods for bypassing them were demonstrated.

We learned how operating system fingerprinting works and developed ways to research signatures for recon and to construct spoofing attacks for a target system, using the iOS running on an iPad as an example. We reviewed a more advanced operating system fingerprinting method, fingerprinting the stack, and introduced the packet manipulation utility Scapy to demonstrate a stack masquerade by writing up a Python script.  

1. What does apd in hostapd stand for?
2. How can you quickly tell if your wireless card doesn't support access point mode?
3. What does the hostapd configuration parameter ignore_broadcast_ssid do?
4. 255.255.255.255 is the broadcast address of the ____________.
5. You're running an ARP poisoning attack. You know the target and gateway IP addresses, so you immediately fire up arpspoof. Suddenly, communication between the target and the gateway is broken. What happened?
6. What do the first three octets and the last three octets of the MAC address represent, respectively? 
7. The MSS and the MTU are the same size. (True | False)
8. What does the -j flag do in iptables?
9. You have defined the IP and TCP layers of a specially crafted packet as IP and TCP respectively. You want Scapy to send the packet and save the reply as REPLY. What's the command?

Scapy documentation: https://scapy.readthedocs.io/en/latest/.