Chapter 10: Sniffing and Evading IDS, Firewalls, and Honeypots

Sniffing is an old method with new technology. Back in the day—before smartphones—we had telephones. There was a method used to tap into the phone line and listen in on conversations. You could record traffic, as well as intercepting data going across the line.

This required you to select a target and then connect with a listening or recording device. This was typically achieved by unofficial or official channels—depending on the legality—as well as a direct line mechanism. You could also use radio wiretaps. The whole purpose here was to listen in on conversations or record data that was flowing.

An attacker can intercept and read any network packet containing plaintext information. This information could include usernames, passwords, personal codes, banking information, or anything else valuable to the attacker.

Packet sniffing has the same concept as wiretapping—just on a different platform. Instead of listening to audio, we're listening to ones and zeros. The attacker's goal is to look at all traffic and packets that go across your network.

By the end of this chapter, you should understand what a sniffing attack is and its role in extracting meaningful insights from the complex and large sets of data all around us.

We will cover the following topics in this chapter:

• What is sniffing?
• Types of sniffing
• Hardware versus software sniffing
• Dynamic Host Configuration Protocol (DHCP) assaults
• Media access control (MAC) attacks
• Address Resolution Protocol (ARP) poisoning
• Domain Name System (DNS) poisoning
• Detecting sniffing methods
• Evading intrusion detection systems (IDSs)
• Moving around firewalls
• Honeypots

What is sniffing?

Using sniffing tools, an attacker can monitor and capture packets passing through a network and spy on what is going on with internet activity.

Let's talk more specifically about what sniffing is and how to leverage it in an attack.

There are two types of wiretaps out there, as outlined here:

• Active wiretapping allows an attacker to manipulate and force themselves into the middle using a Man-in-the-Middle (MITM) attack, which allows the attacker to record and monitor traffic. As an active channel, it can allow the attacker to change the data flowing through or inject information. When it comes to ethical hacking, active means we're going to do something extremely aggressive by forcing a communication. You can see a depiction of a MITM attack in the following diagram:

Figure 10.1 – MITM attack

• Passive wiretapping allows an attacker to eavesdrop or listen into conversations—nothing malicious; it's only for gathering information. We can use passive tapping to record that same information, but we're not manipulating anything or anyone.

Is this legal? Well, it depends on your environment, so you should always know the rules. Lawful interception or wiretapping is implemented by lawful authority via a warrant or if you have an agreement with a company and you're doing a penetration test with them.

Most of the time, these activities are extremely useful for things such as management, protection, and even monitoring infrastructure. Lawfulness is always determined by whether there is permission granted.

Lately, the big thing is terrorist activities being monitored around the world. We have government agencies sniffing or looking at the network passively for certain keywords or key traffic that flows through the internet, which could then raise flags if certain criteria are met.

There's a lot of debate as to whether governments should be involved in this kind of thing. I find it hard to debate because I see it as a catch-22. I understand the reason behind it, but I also like my privacy. Whatever you do, know the rules of your environment.

If you're thinking we have a switch network, well, trust me—I can get past that.

The concept here is that the attacker is going to try to look at information that passes through a segment by monitoring both hardware and software. Software will be our protocols, while hardware will be network devices.

If the attacker can compromise one of these devices, they can start monitoring all the information that's flowing through it. And what is the attacker looking for? Well, believe it or not, there are some applications that transmit passwords and usernames in cleartext. Guess what? Email is cleartext. And you'd be surprised how many times people send credit card information over email. If the web application is not locked down correctly, we may be transmitting in cleartext, and of course, any type of sensitive data will be a treasure chest for an attacker.

Sniffing dangers

So, how dangerous is this? Very dangerous because it's on your network—it's all there for them. And what can I see as I'm sniffing?

Well, I can see things such as this:

• DNS traffic
• A client machine requesting a DNS name resolution to a DNS server
• Email traffic
• File Transfer Protocol (FTP) passwords
• Web traffic
• Telnet passwords
• Router configuration
• Chat sessions

I'll also be able to see Telnet passwords if it's not properly locked down; unless you're using FTPS—the secured FTP—the password and username are going to go across as cleartext. I might also be able to pick up router configurations, as well as email traffic. And I'm not just talking about the emails themselves, but everything dealing with your email system. Exchange servers communicate with other Exchange servers, and all that traffic—if you don't lock it down—could expose quite a bit about your infrastructure. We all know that HyperText Transfer Protocol (HTTP) is cleartext, and as a matter of fact, there's a big push now to make everybody go HTTP Secure (HTTPS). I agree. Most chat session environments can be sniffed, as well as System Logging Protocol (syslog) traffic.

Syslog can be used for system management and security auditing, as well as getting general information and looking at analysis and debugging messages. Now, think about that going across cleartext; not just software, but devices can have their own syslog files that are going to report back to a syslog endpoint. That can be printers, routers, and so on, and typically, these logs have information such as timestamps, hostnames, and even the Internet Protocol (IP) address of the device.

How is this done? Well, it's à la mode. See, I had the Big Mac earlier, and now I want some ice cream! What I mean by à la mode is this: you have a network interface card (NIC) that is hooked up to a switch, which is then hooked up to multiple systems that are out there. This is the standard network environment.

Typically, a network card operates by sending data from one location to another, and normally, a network card picks up all traffic it sees on the network and just simply disregards or dumps the packets that are not destined for its IP address, but it still sees it.

We can change the way the NIC is going to work by placing it into promiscuous mode. This causes the network card to pass all the traffic it sees to the central processing unit (CPU) rather than discarding the frames that are intended only for that NIC. In non-promiscuous mode, the network card does not have as much fun. No—the NIC receives a frame and will drop it unless the frame is addressed to that NIC's MAC address.

There are many operating systems (OSs) that require admin-level or superuser privileges to enable promiscuous mode, and normally, a network card only sees traffic that's on the same port, especially if it's in a switched environment.

I know I just mentioned something as ancient as the video cassette recorder (VCR), but that was the problem with the hub. It transmitted data through all the different ports. A lot of companies have moved to switched environments that are used to combat the use of promiscuous mode; if I did the same, I'd only be able to see data that was still destined for myself.

Next, let's talk about some options we can use when sniffing.

Types of sniffing

So, what are the different types of sniffing? Please don't say, "It depends whether you're trying to figure out a scent or whether you have a cold." To us, sniffing is where we talk about the actual vectors available to us, and there are several different vectors we can look at.

Spoofing attacks

In this type of attack, the attacker pretends to be someone else by modifying or falsifying the information or data. By doing so, they can gain access to the resources or even steal personal information.

These types of attacks can be done in several different ways. The attacker can use an IP address that's associated with a victim, which would allow them to send out fraudulent emails or set up websites, try to get passwords or account information, and so on. There is no limit when it comes to spoofing attacks and what attackers can accomplish. You can even set up a fake access point for wireless connectivity and pretend to be legitimate users connecting through illegitimate connections.

DHCP starvation attack

In a starvation attack, we deplete the number of IP addresses by chewing up everything except the DHCP server. So, you've got your DHCP server and it's going to have a scope or multiple scopes representing different subnet ranges. In this case, we're going to go with 192.168.0.1, all the way up to 254. It's just simply a list or a database of IP addresses it can issue out to client machines. Now, as the network comes up, a client makes a request, and that information is passed through the switch, and then sent to the DHCP server to get their IP address. We'll talk more about this later in the chapter.

DHCP server attack

In this type of attack, the attacker will set up their own DHCP server. Matter of fact, as an attacker, I'll use these two techniques together. I'll set up a rogue DHCP server, do a starvation attack, and have everybody start getting their IP addresses from my rogue DHCP server. This will allow me to do fun things such as a denial-of-service (DoS) attack because now, they don't have a legitimate gateway where I could then implement DNS poisoning. We'll also talk more about this later in the chapter.

MAC flooding attack

You might think MAC flooding is what happens at an Apple store when Macs go on sale. To help you understand this better, let's figure out what a switch does. Now, a switch has a MAC table inside of it, and a MAC address is associated with network cards on nodes—or computers if you think of them that way—or printers. The switch keeps a list of the MAC addresses that are in each physical port on the switch, and this allows us to reduce broadcast traffic on our network. It also protects us from sniffing attacks.

With a typical MAC flood, the switch is fed a ton of Ethernet frames, and each frame contains different source MAC addresses sent by the attacker. The effects of this on the switch can vary depending on what the attacker is trying to accomplish. However, the big goal for most attackers is to force a legitimate MAC address out of the MAC table and inject a rogue MAC address to force traffic to go to a specific system they may be using for monitoring or for sniffing.

DNS poisoning

DNS poisoning is simply what it sounds like. It poisons the DNS entry, which resolves a name to an IP address. If I can tell you Citibank's IP address is my malicious website versus you going to Citibank's site, and I can inject that, I'm going to have a lot of fun with you. This is especially true if my malicious website looks just like Citibank's, including a username and login entry.

ARP poisoning

ARP poisoning is very similar to what we see with MAC flooding, but with ARP poisoning, we're going to try to associate the attacker's MAC address with the victim's address. This way, the traffic that is destined for the victim gets sent to the attacker instead.

Password sniffing

As the name suggests, password sniffing is the ability to sniff packets going across, looking for passwords that are being transmitted in cleartext or without any type of encryption. In cases where passwords are encrypted, the attacker can use a decryption algorithm to try to decrypt that password, and I'm guessing you know what's going to happen after that, right?

Switch-port stealing technique

This is extremely useful to sniff in a switched environment when ARP poisoning can't be done. It floods the local area network (LAN) with ARP packets. The destination MAC address of each stealing packet is the same as the attacker's, while the source MAC address is one of the victim's MAC addresses. By doing this to the switch, it steals the port from the victim.

What does this accomplish? All the packets destined for the victim's MAC address are received by the attacker, and when the attacker receives the packet of the stolen host, they stop the flooding process and perform an ARP request for the real destination of the packet. When they receive the ARP reply, they know that the victim has taken back their port, so the Ether cap can resend the packet to the destination as is. After that, we just loop that process over and over. It's quite tricky.

Hardware versus software sniffing

You may be thinking, how do we sniff? Well, we have both hardware and software solutions to deal with. I'm going to warn you ahead of time, the hardware side is not cheap. On the hardware side of things, we have protocol analyzers. These devices are designed to monitor network traffic. This would be the poor man's version:

Figure 10.2 – Various sniffing devices

I had an opportunity to play around with one, the Fluke pictured in the middle and at the bottom in the preceding figure. It's such a fantastic little device. They're not only used to monitor but also analyze the data. With the Fluke, we can see how long the cable run is. If there were a break, we would see how far down the cable it was broken. You could also analyze the top protocols being used on the network. A multi-port testing system device such as the N2XN5540A would allow you to monitor and verify the performance of networks and devices.

Again, as mentioned earlier, not only can we analyze data, but we can also capture data and play it back later if we want to. The attacker can see the individual data bytes of each packet as it passes through the cable.

These devices are very expensive, and most run-of-the-mill attackers won't have that type of budget. The cheaper alternative is software. One of the more popular products out there is Wireshark, originally known as Ethereal. It is a cross-platform product that uses Packet Capture (or PCAP) as an application programming interface (API) that captures live network packet data to capture your packets. If you know me, you know I believe nothing is for free, but trust me—this product is completely free. It supports being able to look at data from Ethernet to the Institute of Electrical and Electronics Engineers (IEEE) 802.11 PPP, as well as running from a graphical user interface (GUI) or a command-line interface (CLI).

I had an opportunity to see Laura Chappell, the Wireshark expert, in a presentation, and she blew me away at how quickly she was able to recover passwords and look at the data. It's kind of where I got my start. This was back in the old days when Novell had a big market share of the networking world. That just tells you how old I am, right?

In your immediate future, you will see some questions concerning some of the filters for Wireshark, so I highly recommend you study up. You don't need to dive in too deep—just look at the basic ones out there. And there are other products out there such as OmniPeek, which has a nice little GUI.

There's also SoftPerfect's Network Protocol Analyzer (NPA). Microsoft has its own product too: the Microsoft Network Monitor. If you saw it a long time ago, it's gotten a facelift, so you may want to look at it again.

And just to use my favorite word, there are a plethora of network sniffers out there that are used for the dark side. Some of them are extremely small—they can run off Universal Serial Bus (USB) drives, Raspberry Pis, and Cain and Abel, which happens to be one of my favorite ones because it's quick and dirty.

We also have AirSnort, which I'm sure you can figure out. There's one called Snort. AirSnort was Snort for Wi-Fi. Snort was extremely powerful. I used it with my internet service provider (ISP) service as well. It's so powerful—it sniffed the traffic, and if we saw DoS attacks coming in from a specific address, we had a Snort rule that executed off and automatically blocked that IP address at the router.

Now, not all of these are used for the dark side—I just want you to know there's a wide variety of products out there used for both good and evil, therefore bringing balance to the force. See how I got that one in?

Sniffing mobile apps

There may be situations where you may not have access to a laptop or you're just trying to be a little bit more discreet in your pen test, or the attacker's trying to be a little bit more discreet instead of walking around your environment with a laptop. That's okay. If you don't have one, there are mobile apps out there.

What I find interesting is, I looked on the Apple Store and I couldn't find anything that wasn't rated anything higher than one star, which is kind of weird. But then again, I'm not an Apple guy, so maybe you can find some of your own products out there for the Apple side.

On the Android side, though, there are a plethora of options, and that's one of the reasons I prefer Android. One of the most popular ones is Wicap 2, and it comes in two different versions. There's the demo version, which is just a demo of their product. It gets really good reviews and has a good following. However, it requires rooting of your phone.

This company also makes a full product, which is the one that really gets rave reviews. It comes at a price, but it's extremely popular as far as its ratings are concerned, and a lot of people have good things to say about it.

Another one is PCAP, and it's kind of scary. Not only does it work as a network sniffer, but it also includes Secure Sockets Layer (SSL) decryption, which it does through a MITM attack. It does not require root access, which could be why it's a little more popular as well, but the interface is very similar to what we see coming from Wireshark.

Once you learn one sniffing technique, you'll see similarities through the different product lines out there. Again, mobile apps are an option to go with when you're trying to sniff a network.

Next, let's take a deeper look into what DHCP assaults are.

DHCP assaults

DHCP Assaults sounds like a cool title for a movie, doesn't it? DHCP is such an integrated technology throughout our network infrastructure, it is an extreme target for an attacker to get to because we can control so many things when it comes to the use of this technology.

So, what is DHCP and what is it for? If you don't know what it is, I'll give you a quick overview of what it's designed to do.

DHCP is a specialized server role we install on a server. We do this because any computer that needs to connect to the network or gain access to resources, whether internal or external (such as the internet), needs some way of connecting, and we do that via IP addresses.

DHCP oversees assigning IP addresses to computers as they hit the network. It does that by creating a scope—basically, a database of IP addresses.

One of the main responsibilities of the DHCP server is to keep track of which computer has which IP address. This way, we don't get a lot of duplication going on.

DHCP is what we refer to as a client-server model, and being a protocol, it has its own set of messages it exchanges between the client and the server as they're trying to get an IP address. Once we assign an IP address to the client machine—workstations, printers, your cell phone, tablet, or other servers—there are certain servers we want to make sure are statically assigned an IP address. That would be, obviously, the DHCP server itself. You can't really get an IP address from yourself when you haven't even fired off yet, so the other thing we do, besides assigning IP addresses, is assign other Transmission Control Protocol (TCP)/IP settings.

Those settings would include things such as a DNS server. Where do I go to discover what Yahoo.com is equated to as far as an IP address? Or, where do I go to find out where the bat cave is located as far as an IP address is concerned?

Another type of setting we could assign would also be a default gateway, which is: how do I get out of this network? If I'd like to go to Yahoo, I've got a DNS server that tells me Yahoo is equal to this address, but how do I get there from here? That's what the default gateway is designed to do.

Now, granted—you could type these on individual computers if you would like, but imagine being an IT person in charge of 50 computers (which is actually a low number), and you must go type in the IP address, the DNS IP, the default gateway, and a subnet mask. Typing in that information over and over, even just 50 times, let alone thousands of times, could lead to a serious illness that's out there that I want to draw your attention to: fat fingers, which is something I have. I don't know how many times I've fat-fingered an IP address; I'll reverse it—instead of typing in 192, I'll type in 129, just because I'm going so fast and typing in that information over and over.

DHCP starvation attacks

DHCP starvation reminds me of the famous scene in Oliver! where the little boy goes up and says: More, please. And of course, the word starvation sounds so ominous. The concept is, you have your DHCP server and it's going to have a scope or multiple scopes that represent different subnet ranges. In this case, we're going to go with 192.168.0.1, all the way up to 254. It's simply a list or a database of IP addresses it can issue out to client machines.

As the network comes up, a client makes a request. That information is passed through the switch and then sent to the DHCP server to get their IP address. Along with that information comes information such as its default gateway, the DNS server, and how long the lease is going to be.

It's important to note that with a lease, the client itself will check when 50% of the time to live (TTL) of the lease has been expired back with the DHCP server to find out whether it's okay if it uses that IP address. This is all well and good in a normal environment, but enter our attacking machine, which basically goes and floods the network with DHCP requests or discovers and the DHCP server thinks it's different client machines requesting those IP addresses. In fact, the program is so sophisticated that it shows the different MAC addresses associated with those requests.

What ends up happening? The DHCP server thinks it's sent out all the different IP addresses and the scope is then depleted, meaning the client machine is then denied access to get an actual IP address, or it is starved.

There are several programs you can use to accomplish this type of attack. Two of the more famous ones are Gobbler and Yersinia.

Going rogue

When it comes to going rogue, what we're doing is making sure you understand the standard DHCP environment. What we end up doing is a starvation attack on that machine.

In a rogue attack, the attacker will introduce their own server that's going to issue out DHCP.

So, here, I have my client machines, and we've got our standard nifty little DHCP server that's legit for the network, hooked up with our switch:

Figure 10.3 – Normal network with a DHCP server

Again, normally, they would send their DHCP discovers to the switch, which would then get approved by the DHCP server. However, when it comes to a rogue DHCP server attack, the attacker introduces a rogue DHCP server to the network.

To get the client machines to get their information from the rogue server, they simply must do the starvation attack against the DHCP server—the legitimate one. It goes offline, and then the requests automatically get redirected because the DHCP server is just looking for discovers, and it responds back to the client machines and issues them away from the settings that could compromise the box, as illustrated here:

Figure 10.4 – Attack inserts a rogue DHCP server

For example, I could say your DNS is equal to my attacking DNS server, and in it, I have Citibank is equal to my malicious site that looks just like Citibank or eBay or PayPal or Amazon. I can totally control the environment. If you type in Yahoo, I could send you to Google.

The other result is all the traffic from the client will be sent to the attacker's IP address because I could also list it as the default gateway, which would then allow me to sniff the network. The client will simply assume everything is functioning correctly. I may be forwarding them from my rogue server out to the legitimate sites, but again, I'm going to have all the traffic pass through me.

Sometimes, we get a rogue server on the network nobody meant to get up there. We have a developer or somebody who's doing a test environment who fires up a DHCP server. Them placing this server on the network can interfere with the environment, and this type of attack is also extremely difficult to detect on the network unless you're taking some countermeasures.

Countermeasures

We'll start with stopping a DHCP starvation attack. Considering the attacking machine sends a DHCP discover request to the switch, one of the things we can do is implement port security, a feature of the switch designed to set the maximum number of MAC addresses per port.

If I know I only have five computers down this one line on this switch, I will want to set my port security to 5, which should prevent a starvation attack that would be implemented through that port.

On configuring port security, you will want to reference the manufacturer of your switch, but when we look at one of the most popular products out there, which would be Cisco, the port security is turned off by default. The switch itself must be a level 2 (or L2), and when you need to enable port security, you simply type in switchport port-security, which activates port security.

You can also do things such as setting the maximum to 1, the maximum number of MAC addresses on a switch. You can also specify how many MAC addresses the switch can have on one interface at a time. The number could be anywhere from 1 to 6200 or so.

Something else we can do is set the action that's going to take place when a violation occurs on that interface. The default is to shut down the interface, effectively stopping any traffic from coming from the suspected system, but you can also use switchport. Port security violation is restricted, which just means it discards the traffic and sends a Simple Network Management Protocol (SNMP) message but keeps the port up and running.

We can also use the protected option on the switch, which discards all traffic, keeps the port up, but doesn't send an SNMP message. And of course, shut down does exactly what it says it's going to do.

Another option is setting the aging for port security. This would allow you to set the time, as well as the type for all secure addresses on the port or how long the port stays off. The aging time can go from 2 minutes to almost 1,500—the famous 1,440 minutes or 1,400 and 40 minutes. You can specify the type using absolute or inactive. For absolute aging, all the secured addresses on this port go out exactly after the minutes we specified and are removed from the secure address list. For inactive aging the secure addresses on this port go out only if there's no data traffic from the secured source for that specific amount of time.

To stop a rogue attack, we implement DHCP snooping, a feature that's going to be available on your switch. It stops ports from responding to DHCP offers. For example, if I had a DHCP server and it were connected physically to port 1, I would turn off snooping on ports 2 through 8.

What happens if an attacker manages to build up a DHCP server and puts it under the switch? They won't be able to get any responses or to respond to DHCP discover packets because it's only allowed to go down the ports your legitimate DHCP server is on.

Microsoft also did some interesting things—they started us up with Server 2008. If you had an Active Directory (AD) environment, you had to authorize the DHCP server in AD, which means it would come up. So, if you went and installed DHCP, that was one of the steps you had to do. If you didn't have the rights to do it, even though you had the role installed, it would never actually fire off.

This is great for the Microsoft world, but it doesn't stop somebody from firing up a Linux DHCP server, and that is where I would implement DHCP snooping on my switches.

Let's discuss MAC attacks next.

MAC attacks

If you are from the United States (US) and grew up around McDonald's back in the good old 1970s before it became the worldwide phenomenon it is now, you'll remember their interesting commercial with the phrase describing a Big Mac attack, which was two all-beef patties, special sauce, lettuce, cheese, onions, all on a sesame seed bun. However, we're not talking about food. MAC is short for media access control, and every single NIC we get has a MAC address.

Packets sent on Ethernet are always coming from a MAC address, and they're also sent to a MAC address. I know you're thinking: wasn't that the job of IP? Well, TCP/IP deals with MACs, but when we get down to it, it's the MAC address that is utilized for the transmission and receiving of packets. Each port, whether it's on a NIC or on a printer or a laptop, is going to be unique.

If the network adapter is receiving a packet, it's comparing the packet's destination MAC address to the adapter of this MAC address that's on its own card. If it matches, it then allows the packet to proceed. If it doesn't match, it just drops it.

The MAC address is typically a 12-digit number. As with an IP address, the MAC address also has a syntax to it, in the aspect the first 6 characters are what we refer to as the prefix. Those first 6 characters are uniquely assigned to different vendors. So, in those 12 digits, the first 6 are listed as a prefix, and the prefixes are assigned to specific vendors. As an example, there are several prefixes assigned to Linksys, so if I saw a prefix of a MAC address of 00:13:10 or 00:25:9C or 68:7f:74, I would know this was a Linksys device.

There's a MAC address out there that is unique. It is simply 12 Fs—that is, FF:FF:FF:FF:FF:FF. It is very similar to my report card in high school… It's a broadcast address and addresses every adapter in the network itself.

CAM

CAM is MAC spelled backward, but of course, that's not what it represents. CAM is short for a content-addressable memory table and every switching device it has inside of it. As packets pass through the switch, they include a destination and a source MAC address, meaning this is the destination I'm trying to get to and it's coming from this source.

As traffic passes through the switch, the CAM table simply tracks the MAC addresses' locations and specifies which port each MAC address is assigned to. So, in this case, you can see the switch knows I'm not going to read off the full MAC address here, I'll just do the last two letters, but you'll notice in the following diagram that FF is in the first port and the MAC address ending in TT is in the sixth port:

Figure 10.5 – CAM tables on a switch tracks MAC addresses

Now, when a packet goes through the switch, the switch does a broadcast using the FF:FF:FF:FF:FF:FF MAC address. It shoots out a Bulk API broadcast, trying to find the MAC address that ends with A1. When it reports back, it simply makes a notation in the CAM table, and that note is located on a given port. The CAM table is in the memory of the switch, so if you power off a switch or reboot a switch, the CAM table is cleared out. This feature of a switch, of learning where the different MACs are located, helps us in reducing broadcast traffic, as well as traffic destined for one computer not getting sent to the wrong port—at least, that's the goal.

It doesn't stop with a single switch because most networks have more than one switch. Here, I've got two switches, and of course, each one's going to have its own CAM:

Figure 10.6 – Each device will have its own CAM

In this case here, we're trying to find a destination ending in FF; you can see in Figure 10.7 my destination MAC address and my source MAC address.

If in the actual network environment, the MAC address that's associated with FF is located on the second switch, that switch will know where that MAC address or that computer is located. However, this first router doesn't have any idea where that's located, and so if a computer is trying to send a packet or a piece of data to a machine on the secondary switch and it's located on the first switch, we must somehow resolve this.

Again, the first switch will have MAC addresses for systems that it's aware of, as well as the MAC address of the ports on the switch itself—in this case here, the uplink port:

Figure 10.7 – CAMs track which port a MAC is on

Here, the uplink port is ending in 21, and the switch is smart enough to know that this port is associated with the MAC address over here on the secondary switch in its uplink port:

Figure 10.8 – Uplink ports know where to forward based on the CAM

As the first switch does a broadcast, the second switch responds and says, "Hey, I know about that one, so just forward all the packets to me," and that's what happens.

The CAM table on this first switch says anytime you want to send something to FF, just forward it to 21, and then 21 will take care of it because it has the MAC address of that secondary switch. Now, did I clear up the water there or did I muddy it up?

This is also true with that secondary switch. It would be aware of the ports it's connected to back to switch 1, and this is how we have a fully switched networked environment. The whole process is quite efficient, which should tell you the government is not involved.

Flooding

Now that we understand how a switch works and how packets move across the network, our whole goal is to look at MAC attacks. Part of that attack is referred to as flooding.

You may be thinking it's cool the switch does all that, but as I said before, you can't sniff a network that is switched, and that is true unless you get the switch too full that it can't get any more notations of where MAC addresses are located. This kind of goes back to the old days of what different network devices do, and typically, as we move up the scale in our network device, we start off with a hub and a hub sends a broadcast out to every single port, then we move up to a switch. A switch will do what a hub does, but it does it on steroids, meaning it's going to start monitoring and directing traffic, which is what we saw with that CAM, and then you get into routing.

The overall concept is some switches go backward in time. If I have my switch and my CAM table, and I know where my different MACs are located on which port, a very common trick for an attacker to implement is to fire up their box. If I overload that switch with too many records for it to keep track of what's going on with which MAC, which we call flooding the switch, it does something interesting—it dumbs itself down and becomes a hub.

Every single packet will be broadcasted across all the ports. It's the default feature of most switches, especially consumer-rated switches because you don't want to lose connectivity.

As a side note, there are other ways you can sniff a network on a switch. Besides a MAC attack, there are actual ports on a switch, or a lot of managed switches referred to as Switched Port Analyzers (SPANs) or SPAN ports. These ports mirror and allow an attacker or a network administrator to monitor all traffic going across.

The MAC flooding method is extremely noisy on the network and very easily detected. However, it's only going to be detected by some of the more advanced switches out there, which is why it's always important to know about your inventory and what you've got running where (loading).

Countermeasures

When it comes to protecting yourself, you'll see a lot of repeats of what we've already talked about, and the reason we see this over and over is that it's all done at the network layer. There are some cool things you can use, such as Cisco's port security feature. You can use it to secure a port. So, if you assign a MAC address to the secure port, the port will only forward packets to the machine that's destined on that port.

What's cool about this technology is you can set up alerts to do that. For example, if something suspicious starts happening on the network, such as a MAC address of a machine trying to access a port that doesn't match an identifiable secure MAC address or any type of violations, we can be alerted of those things.

We also have the option of using an authentication, authorization, and accounting (AAA) server, which we often refer to as a RADIUS server.

These servers require computers and users to authenticate themselves and track what they're doing and where they're going automatically. Typically, this is done either by somebody logging in or possibly via a certificate. I had an AAA server with my ISP, and we did it for the accounting portion of it.

If you remember, back in the old days, you got charged for the time you were on the internet, right? As with the old AOL days. We didn't charge people; we wanted to be able to get a breakdown to our users saying, "Hey, this is how much time you spent on the internet; this is how much data you've downloaded through our services," and we were able to do that because we could match that up to the MAC address of their antennas and their routers.

We'll discuss ARP poisoning next.

ARP poisoning

ARP poisoning is a mechanism we can use during the sniffing process, and its capability is quite scary. The concept is… we're going to trick people into doing something or going to a place they don't intend to, and we do this at a computer level.

Growing up, my father would tell me: "You can only trick people for so long, but until then, take advantage of the situation." Of course, he would say this in a light-hearted way—he didn't really believe this. It always seemed to him people were trying to do this to him. He was working for a movie theater chain and his job entailed going to different areas to find where managers and employees were stealing from the company. He always said people thought they could come up with a new way of finding "a way around the system" so that they wouldn't be detected, but technically, it was never a new way. It was just a new path using an old mechanism, and that old mechanism was just theft.

ARP takes us back to the old Network+ days, possibly A+ days, and if you're old enough, you'll remember the old Networking Essentials days. ARP is a protocol that has been around for some time. If you have gone through previous chapters, you'll remember we discussed network cards and how they had a MAC address associated with them. We also talked about how MAC addresses are the true way computers or nodes communicate with each other.

The computer needs to be able to resolve a MAC address to an IP address, which is very similar to what we refer to as name resolution. If you remember, we also mentioned in the other chapters that DNS gives us the ability to resolve a name such as Yahoo.com to an IP address.

Well, because computers or nodes are giving these physical addresses, ARP is what's responsible for resolving it to the IP address.

I know this totally blew your mind, and that's what ARP does for us. It's a protocol designed to map an internet IP address to a physical machine address. Typically, all of this is done via a table. Now, it's not a table such as a spreadsheet, but you can kind of think of it that way. We refer to it as an ARP cache, and because it's cached, it is information that is stored in memory.

Usually, the information does not stay in memory for a long time, which is kind of the downside to it. Besides, it's easily manipulated because when a packet is destined for a host machine on a particular LAN, it arrives at the gateway, which then asks ARP to find the physical host or MAC address that matches that IP address. If it doesn't have it in the cache, it does a broadcast if a node wants to update the switch or the router its MAC address has changed. This is kind of what we're going to do with an ARP poison: we'll trick the switch or the computer into thinking its ARP table is no longer valid.

ARP spoofing

ARP spoofing is another name for poisoning—we use the names interchangeably. This is all under the concept that the machine that sends the ARP request assumes the ARP reply comes from the correct machine, which we know in our case is not going to happen.

Some of you are now thinking: he's about to scare me again. No—it's time to put the big pants on and seek to understand what's happening here.

Here is what we can do to implement this type of attack. We send forged data—or, how I like to put it, forge our way. The attacker can create what we refer to as a malformed ARP reply containing the spoofed IP address and MAC address.

At this point, the target's machine blindly accepts the ARP entry into its ARP table. The attacker then overloads the switch, forcing the switch to go into a new mode, referred to as forwarding mode. They do this by sending a ton of ARP requests and reply packets to the switch.

After doing that, the attacker floods the target's ARP cache with the forged entries, which is what we refer to as spoofing or poisoning the target.

Spoofing or poisoning the target

Spoofing or poisoning the target looks like a complicated technique, but it's not that bad, because guess what? We have some really cool tools out there, including dsniff, which is actually a set of password-sniffing and network traffic-analyzing tools. And it has some other tools in there besides dsniff. There's filesnarf, mailsnarf, messagesnarf, and arpspoof—which simply allows us to poison a target.

Another tool out there is the Ettercap. It's also an open source security tool we can use for MITM attacks, and it does some protocol analysis as well as security auditing.

We also have Cain and Abel, which is a suite of tools we can use to do poisoning.

Again, you can use these tools for good, but remember: all tools can be used for evil.

How to poison the network via ARP

It's time to break out the brothers! I mean, install and try out Cain and Abel. Cain and Abel gets its name from a biblical story of two brothers, one that slays the other, therefore bad versus good. That's exactly what you see with this product. Sometimes, it's just referred to as Cain because it's mostly evil.

Now, raise your hand and say the oath that you will not do anything with some of these tools, and you will never tell law enforcement that Dale told you it's okay to run this on a live network! This tool can easily spoof and poison a device's ARP table and trick all the devices on the network to send their traffic through an attacker's system. You can see an overview of the tool's interface in the following screenshot:

Figure 10.9 – Cain and Abel interface

Cain and Abel has some additional tools to it that can grab hash tables and crack the different passwords that may pass through, and the good thing is, it's not limited to capturing Microsoft passwords. It can capture some 802.11 captures, Wi-Fi Protected Access-Pre-Shared Key (WPA-PSK) hashes, Cisco IOS-Message Digest 5 (MD5) hashes, and so on.

It's quite an interesting little program, and as I always say, knowing is half the battle. If you do a software inventory scan on your systems and see somebody running Cain and Abel, you will have a good idea of what they're doing with it.

IRDP attacks

Internet Control Message Protocol (ICMP) Router Discovery Protocol (IRDP) spoofing is an interesting routing protocol that allows a host to discover the IP address of active routers and get out to the internet. The routers must be on their own subnet. They do this by listening for router advertisements and solicitation messages on the network. When they discover those messages, they simply record who their router is and put that into their table.

An attacker can add a default routing entry to the system remotely by spoofing a router advertisement message and sending it directly to the victim. What's interesting is that IRDP doesn't require any authentication. The target host will prefer the default route defined by the attacker and update their table so that everything is passed through the router they have defined, even if they're using DHCP and a default router has been provided for them.

This is accomplished when the attacker goes and sets a preference level and a lifetime of the route at a very high level to make sure the target host will choose it as the preferred route. The downside of this one is that the protocol only looks for routers on its own subnet. The attacker must be on the subnet, but it can be done.

Using this type of spoofing allows the attacker to passively sniff the network and to implement a MITM attack, or even a DoS attack. So, yes—this one is not very good either.

Dangers of ARP attacks

So, what kinds of threats do ARP attacks create? ARP poisoning presents different threats.

Let's look at some of the different dangers and risks of ARP attacks, as follows:

• DoS attack: If you were to go through and link many IP addresses with a single MAC address of the target, it would be overloaded with a ton of traffic destined for different IP addresses.
• Voice over IP (VoIP) conversations: We can tap into these as well. If we were to do a port mirror, this would allow us to record VoIP conversations between the two systems.
• MITM attack: The attacker is going to stay right smack in the center between the target and the victim. Again, this is where the attacker's machine is going to be placed in between the two systems, or multiple systems, and intercept all the traffic that's going to pass through.

I was teaching ethical hacking at a school district and a couple of people came from a different school district in Utah, including two gentlemen from the same school district—a boss and his sidekick who were good friends. They were staying in separate hotel rooms, so once the sidekick was back in his room after a lesson on sniffing and a demo, he jumped onto the Wi-Fi network, watched his boss log in to the virtual private network (VPN), and captured his VPN username and credentials. He then went over and showed him what he was able to do. I know what's running in your mind and, no—he didn't get fired.

Of course, he should have had permission to do that, but it was quite interesting. Both came in the next morning kind of perplexed and dumbfounded that this type of information can go across. Again, I'm very leery about what I do on Wi-Fi networks.

• Session hijacking: This can be done actively or passively. Basically, if you're being passive, you ride along in the session and get all the information. Being active makes it possible for you to bump that person off and take over the session they may have created with PayPal or their bank.
• Data interception: You can get IP address ranges, MAC addresses, computer names, and even virtual LANs (VLANs) connected to the switch.
• Connection hijacking: This is where the attacker manipulates the client's connection to take total control of their connection.
• Data manipulation: This is where the attacker decides to manipulate data. If we're able to be the go-between, the attacker can capture and modify packets, or even stop the flow of information between systems, which gets us back to that DoS issue. And, of course, we can also steal passwords.
• A connection reset: You know that ARP entries are stored inside of the cache for a specific period, even if the connection is not active, right? Well, if the host fails to initiate a connection, it should inform the ARP table it needs to delete that information. It stays in that cache to make resolution faster if it needs to talk to that same system.

When we do ARP poisoning, we're technically doing a connection reset so that it deletes that entry—at least, that's what Cain and Abel does. It can tell your Server 2008 R2 box that you need to delete the entry that's in there for the Windows 8 box, and when you do an ARP request, you're going to put it in a particular MAC address.

Countermeasures

There are many things that you can have in place to protect yourself from attacks. You just can't assume anything. One of the things you can do is implement Dynamic ARP Inspection (DAI). DAI is a feature with a lot of different switches and routers. It's a feature we're going to turn on for switches and routers as it looks at or intercepts all the ARP requests and responses that go across the network. Each of these intercepted packets is then verified with a valid MAC address, as well as a valid IP address they've been bound to. Any invalid ARP packages are just simply dropped.

DAI determines whether a packet is valid by looking at a trusted database that's created, and most of your switches and routers have this built in.

We can also take advantage of DHCP snooping. So, those IP addresses are assigned to a system (remember—IP addresses are assigned to machines when they come online), and the DHCP server records the MAC address that the IP address was assigned to. By combining these two features or technologies, we can create a more secure environment.

The long way of doing this is typing them all in by doing static ARP tables, but that's not something I'm really excited about doing.

Other software is out there, such as arpwatch, which is probably one of the more popular ones. It's a software tool that looks at ARP traffic on a network. It logs a pairing of IP addresses and MAC addresses, along with a timestamp of when it was paired up—when those two were paired up—and it will notify an administrator when someone is trying to spoof those paired IPs and MAC addresses.

Next, let's look at DNS poisoning.

DNS poisoning

DNS poisoning is one of my favorite subjects, just in the aspect of how effective it can be. You have nothing to fear… but an attacker with your DNS cache. DNS is simply there because humans are ill-advised and, in some cases, ill-equipped. It's hard for humans to remember a number. Can you imagine if you had to remember the IP address of a website instead of simply typing in a name? We associate and remember names better than we do numbers.

We're all familiar with the Uniform Resource Locator (URL) box where we type in the name of a website we'd like to go to. DNS oversees taking the name and converting it down to an IP address using tables. These tables can be distributed across multiple systems. Some of them are internal, while others are external names.

A DNS server typically hosts these databases. If the DNS server oversees looking at internal names and names of servers in your environment, that would be your internal DNS name server. For a DNS server in charge of looking at publicly available websites such as Yahoo.com, your DNS server is not authoritative for it; it's not in charge of it, so that would be referred to as an external DNS.

The overall concept is when we do DNS poisoning (spoofing), the attacker is simply going to try to get the user to think they're going to gotham.com, but they're going to be sent to a different IP address. You can type in the IP address instead of a DNS name in the URL bar and still get to the same place. Again, DNS is just there to make things convenient for us.

What happens is, a user hops onto their machine. Their computer has been configured to a specific method of DNS name resolution. The user then types in, I'd like to go to gotham.com, and the computer says: I need the IP address to go to www.gotham.com. This request gets forwarded to the user's local DNS server, and that local DNS server says: I'm part of gotham.city. I have nothing to do with gotham.com. I'm not in charge of it because I'm just inside their network. So, I'm going to forward this out, and we're going to forward this to a root server—our servers that are maintained by the internet and have their own records to point requests to the top-level domain.

The root server of the internet knows how to help resolve this whole namespace because .com servers have registered with it, so it tells (in this case) the local DNS server to contact the Component Object Model (COM) servers. COM servers are not aware of www.gotham.com but they are aware of gotham.com, so they have an entry because Gotham has registered their DNS name with—say—GoDaddy, and the local DNS server that would then contact the gotham.com DNS server.

We will then look for—in the case here—an entry for www, which just points to a folder located on a web server somewhere. The Gotham server would then say: I'm aware of www, and it's going to return that information to the local server. The local server will then send it back to the user's computer and say: Here is its IP address—go ahead and communicate with it.

Intranet poisoning

This is poisoning from within, and trust me, you need to be afraid. First, we know we have our switch on the network and we have our client machine. In this case, the client machine is making a request for an internal resource called portal.gotham.com. This request gets sent to the switch, and the switch then forwards it via the MAC address, an ARP resolution, to the local DNS server for Gotham. Gotham says: I'm authorized for it. Let me go find that server for you. It then finds the real web server and sends the information or IP address back to the client.

The problem we have here is when the black box comes into effect. An attacker sets up their machine and uses the ARP poisoning technique to look for the identifier (ID) of DNS requests from the internet. This infects the client machine, their target. Instead of going to the Gotham DNS server, the client goes to the attacker's black DNS server, which tells it the IP address—which is, in fact, their own fake website—that the attacker has set up.

If the attacker is good, they'll have a web page just like the real web server. It could be where people type in their credentials, and they're doing this on a fake server. Of course, if the attacker is good, they'll forward that credential back to the real web server after they type in their credentials. This way, the end user will have no idea they have been spoofed or poisoned.

The tools we use for this type of attack include arpspoof, a subcomponent of our DNS spoofing toolset, and of course, we've talked about Cain and Abel before.

Internet poisoning

Internet DNS poisoning is where we really have fun. This is your nightmare scenario because if I accomplish this, I'm going to have the whole network. And there are different ways we can accomplish an internet DNS poison attack.

There are a couple of things that are checked during normal name resolution. First, when you type in www.gotham.com, the first thing the computer does is check its cache to see whether it's been there before. The next thing the computer checks is a file on the local machine called the hosts file. Yes—it is plural, not singular, and there is no extension; it's not a .txt file, but you can edit it with a text file. If there's no entry there, the computer goes off and checks its IP address settings, most of which are assigned by DHCP. However, we can override those settings, and this could be done at the client level or at the server level if the target is a server.

Another mechanism used for DNS name resolution is the local DNS server. The concept—as a matter of fact, this happens with almost all DNS spoofing and/or poisoning attacks—is that the attacker is going to somehow get a piece of malware to modify one of these locations, so as the user gets infected, if the attacker's malware infects the host file, we'll put an entry in there that Citibank.com is equal to the IP address of their hacker's box. Alternatively, as I mentioned before, the attacker can modify the preferred DNS server, so it goes to their black hacker's box and, of course, the local DNS server.

Any of these targets, especially that local DNS server, is a high-value target because instead of just saying, "I want one name going to a particular IP address," we can say "I want all DNS resolution to come to me," and that's because instead of just affecting one DNS entry, we are actually directing all DNS traffic destined for the outside world: Citibank, PayPal, eBay, and so on.

Imagine what would happen if somebody got a hold of the DNS entries on your home router or your business router and says that PayPal is equal to this IP address. Everybody in the network would go to that fake site being controlled by the attacker.

Proxy server poisoning

Proxy server poisoning is a specific technique where the attacker can set up their own proxy server. A proxy server caches up websites or goes out in lieu of a user's request. So, we're going to have our victim's machine in the Internet Explorer (IE) browser settings, which is where we see this. You've seen this before, right? This interface says: use a proxy server for your LAN. It's not used for dial-up or VPN connections. This is telling your browser to go and use this IP address for DNS information. So, the attacker will send a piece of malware—hopefully, to change up these settings on the victim's machine, which would then force all DNS traffic from the victim to go to the hacker's proxy server. This would then allow them to sniff for information such as credit card information and redirect to the legit site.

You can make sure this is disabled, and there are many group policy objects (GPOs) out there or settings we can implement and push out to all of our client machines. One of them is to make sure this setting can't be changed. With Windows 10, there is a section for it. It's no longer a part of IE—it's part of the whole OS.

Poisoning the cache

If you remember how DNS operated, you saw how a client machine goes out to request the IP address of Microsoft.com. You know it's going to make a request for xbox.microsoft.com to the local DNS server. If it doesn't know anything about it, if it's the first time it's seeing this request, the first thing it does is to check its cache to see whether it's been there before from a previous request. It also checks to make sure it's not in charge of Microsoft.com. It's not, so it goes through the process of looking for a COM server. We hit a root server, a COM server, then the Microsoft.com server, and then finally, we get to xbox.microsoft.com, and that information gets sent back to the local DNS server.

The interesting thing is that cache memory has information in there for Microsoft.com, as well as for xbox.microsoft.com and a COM server, because the root servers kept redirecting it around. This is designed for faster name resolution. If somebody else comes online and requests to find office.microsoft.com, we don't want to have to repeat this whole process. Instead, the request hits the local DNS server, which then says: I haven't been to office.microsoft.com, but I do have an entry in here for Microsoft.com. It's still in my cache; I can make a connection directly to it and query the Microsoft.com server to find out where the IP address is for Office.

The problem is the cache is stored in memory on that machine and can be edited and updated at any time. An attacker can simply poison the cache on that server, not making modifications to the database itself or any host files, just the cache. And in doing so, they direct everybody to the wrong or fake site.

This is what drives me bonkers when it comes to malware. Many will get infected, and one of the worst things you could ever do is to be on a server and surf the internet to sites that may be malicious where you might get a piece of malware. An attacker who has gone through all the steps we've talked about will know where your DNS server is and can simply write up a script saying to always inject this domain name to this IP address, and just pop in that DNS cache and keep it refreshed.

So, after hearing this, do you still want to play with me, or do you want to take your ball and go home?

Detecting sniffing methods

There are different ways to detect sniffers on a network. Typically, a sniffer won't leave any type of trace because it doesn't transmit any data—it's only collecting data. So, knowing that, we need to look for devices or network interfaces on our network running in promiscuous mode.

Promiscuous mode simply means as packets go across the network, when they hit a computer, if that packet is not destined for that computer, the normal response is for it to ignore that packet altogether. If the packet goes out and reaches its destination, that computer holds the information or retains the packet. A NIC in promiscuous mode will see the packet, but instead of discarding it, it will add it to its tables or tracking mechanism.

In some cases, sniffers are easier to find because they may be running in active mode. If you remember, passive is just listening while active sniffing is injecting, as with Cain and Abel or dsniff.

When we have attackers who run those types of software programs on their machines, if you know what to look for, you might be able to find them. The big issue we have is with what we refer to as standalone sniffers or hardware-based sniffers, and this is because they neither transmit data traffic nor respond to some of the detection methods we'll be talking about here.

The upshot is most attackers don't like to spend money—they always run pirated software or free software because hardware-based sniffers are relatively expensive.

Various techniques to detect sniffing attacks

There are different ways we can detect sniffers on the network.

Detecting via a ping request

By sending a ping request to a suspected machine with its IP address and incorrect MAC address, the network adapter on a machine that's not in promiscuous mode or just a standard desktop machine will simply discard the packet. However, if we use the same method to a machine running in promiscuous mode, it will respond back; it doesn't reject the packet even though there's a different MAC address listed. So, at this point, I would know this device is running a sniffing program.

The ARP method

If you remember how ARP works, you'll know that ARP oversees remembering IP addresses to MAC addresses. Here, we simply use that mechanism to detect which machines are running in promiscuous mode.

The first thing we do is send out a non-broadcast ARP packet. This is simply an ARP request that has gone out, but instead of having a broadcast MAC address associated with it, we assign a MAC address to it. The machines will then record that information, for each of the nodes on the network. After we've done that, we then send out a ping message. This ping message needs to have an invalid MAC address.

Now, think about what's going to happen. The machines not running in promiscuous mode will simply respond back with an ARP request because they'll be thinking your MAC address was this, as packets come across to make a request to the new MAC address. The box that's running in promiscuous mode because it's absorbing packets is not really verifying; it just responds to the ping reply and we can pick that up on the network. Therefore, it identifies that machine as being a box that shouldn't be doing what it's doing.

Using DNS

If you remember, when we talked about Cain and Abel, one of the options you had was to resolve the IP address to a hostname, and a lot of sniffing programs do that for us automatically. Well, how does it do that? It does that via reverse DNS. Now, knowing that, you can simply look at which machines in your network are doing a bunch of reverse queries to your DNS server. Another way we can do this is by simply sending out an ICMP packet, which would be a ping, and ping a non-existing IP address, so that it goes out across the entire network.

Sniffing attacks countermeasures

Now, let's look at some of my top ways to help protect you from sniffing attacks, starting with the basic ones. Here we go:

• Encryption: This will be at the data level. We want to make sure we protect any confidential information we might have from being detected on the network.
• Static MACs: You can take advantage of gateways or your gateways on the network. This will help you, in as far as not being a victim of a MITM attack is concerned.
• Set physical access level: If you have ports throughout your network infrastructure that are not being utilized, make sure you disconnect them from your patch panels.

I'll tell you a story real fast. I was working on a military base and talking about physical access and security with them. They told me they cut the wires behind the network jack as well as at the patch panel in case somebody plugged in the wrong patch panel, and the network wiring behind the physical jack in the room was totally cut. Curious, I asked, "Okay, so what do you do when you need to hook that up?" They said, "Oh, we just, you know, re-splice it." They had what looked like an extra 10 feet of cabling in the wall so that they could always be pulling it through. And then, of course, if they ever ran too short on cabling, they'd have to run whole new cable lines, which was kind of interesting. That was several years ago. Hopefully, by now, they have policies in place about patch panels.

• Upgrade to IP version 6 (IPv6): Again, one of the biggest advantages for IPv6 is that IP Security (IPsec) is implemented, which means packets are encrypted as they're transmitted. Also, if your network device is supported, switch off network ID broadcasts.
• Set static IP addresses and static ARP entries: Do this on targeted machines to prevent attackers from adding spoof ARPed entries on the network.

How about using HTTPS? There's a big movement today on the internet trying to make it possible for every connection we make to websites to use some type of secure layer or SSL connection. This would help protect our usernames and passwords when we're visiting different sites. However, there are other protocols that are considered more secure than the native protocol itself. Instead of FTP, we can use SFTP, VPNs, and IPsec.

I have already mentioned SSL and TLS, and there's also a case to be made for Pretty Good Privacy (PGP) here, as well as Secure/Multipurpose Internet Mail Extensions (S/MIME), and of course Secure Shell (SSH). All these different protocols will make it extremely hard for a sniffer to pick up your information.

And we can't forget about that wireless stuff, right? We must make sure we're always using some type of encryption protocol such as WPA or WPA2. If not, go ahead and use Wired Equivalent Privacy (WEP) and let me know your Service Set ID (SSID), I'd love to come visit you!

• Direct MAC retrieval: We do this from the NIC instead of getting it from the OS itself. For example, in Windows, we can say we want to change the MAC address; we're not physically changing it on the NIC—we're changing it inside of the OS itself to report back. By implementing this technology, getting the MAC directly from the NIC would help to prevent MAC address spoofing.

And you guessed it—there are several other tools out there we can use to detect whether any of our NICs on the network are operating in promiscuous mode.

Evading IDS

Hackers will attempt to bypass firewalls and network IDSs (NIDSs) when it comes to sniffing. NIDSs function by checking every packet that passes through the network, checking whether it's part of an established connection (such as a web page request) or whether it's trying to establish new network connections (such as someone trying to log in to your wireless router). It generates alerts when it spots any suspicious traffic, which is what an attacker wants to avoid.

Host-based IDS (HIDS)

HIDSs are installed on the host machine and monitor for processes that are attempting to gain unauthorized access or use of data. Again, they generate alerts when they spot anything suspicious.

HIDSs can be very effective with LANs, but most wireless connections do not require a login (such as Wi-Fi), so HIDSs are only applicable if you're on a network you trust.

IPS

An intrusion prevention system (IPS) is yet another solution. These are designed to check packets in real time, looking for any suspicious activity. They allow known good traffic through while dropping anything that appears to be malicious.

IPSs are different from firewalls and IDSs because they can stop an attack in progress instead of just trying to detect one after the fact. Another difference between IPSs and firewalls and IDSs is that an IPS will block all bogon traffic (any traffic it doesn't know about). If this kind of blocking occurs, the default response from the attacker will be to turn off whatever service they're using to launch attacks.

How do these different systems work? Well, the easier ones (firewalls and IDSs) will examine packets to determine whether they are allowed to pass or not. They use rules that define specific traffic characteristics, which you create when installing the software on your computer. Firewalls and IDSs are designed to prevent unauthorized network connections, whereas IPSs are designed to catch known bad traffic before it reaches its destination.

If you're using a wireless connection, IPSs are more effective than firewalls and IDSs because they detect known malicious traffic before the client machine can complete its network handshake. Firewalls and IDSs rely on rule-based detection methods, which means they must learn what bad traffic looks like first by intercepting some of it and inspecting the packets. That process can take anywhere from a few minutes to several hours.

Host-based IPS (HIPS)

An IDS monitors an individual system for suspicious activity, whereas an IPS looks for suspicious traffic targeting a particular network and attempts to block it.

An IPS can prevent 100% of attacks in specific environments, but the drawback is that if the source or target computer isn't running an IPS, there could be false positives—events that look like attacks but aren't really.

To bypass firewalls, hackers will try to exploit the security vulnerability of the network protocol that is being used. They can also use ICMP packets instead of using TCP packets because many network administrators trust ICMP traffic and do not bother to protect their networks from these packets. For IDSs, hackers can hide their attacks by modifying data in the packets they send out. In some cases, they will even change the source address as well. Hackers know that it is not possible for most IDSs to evaluate both the source address and data simultaneously.

There are several ways to bypass NIDSs and HIDSs, but one of the most popular is a technique known as ARP cache poisoning.

So, how do hackers evade IDSs?

Some attackers will send out packets with random data to evade IDSs. This is called white noise and makes it difficult for a device to determine whether an attack has happened.

Insertion attack

This is when the attacker inserts extra packets into the flow, such as fake TCP resets, to confuse the IDS. The IDS (being confused) accepts the packet an end system rejects. This allows the attacker to insert data into the IDS. This type of attack is normally only possible in less strict packet processing.

Evasion attack

This happens when the IDS can't determine what the traffic is doing. The IDS might think it's an attack, while it's legitimate packets in a stream. For example, if the IDS doesn't look at all parts of TCP connections but only looks at headers and payloads, then it'll most likely be fooled by the statement "I'm an FTP session" without having any idea how many packets it really consists of.

The IDS can't tell that those packets are spoofed and therefore sees no attacks and lets all packets through to the end system. When this happens, it's called a false negative, while false positives happen when an attacker sends out packets that look like normal traffic but the IDS decides it's an attack. False negatives are better than false positives because at least you can see attacks.

Insertion and evasion attacks are still possible if hackers use uncommon protocols or use old techniques that aren't really used anymore (such as FTP). On top of this, inserting data into the IDS is especially difficult because it will cause an overload for the IDS, which might drop packets.

DoS attack

If an attacker hits your IDS with a DoS attack, the attack could chew up all the resources of the IDS and therefore slow it down so much that it can't do its job. If this happens, the IDS won't be able to distinguish between real attacks and false alarms because it simply doesn't have enough processing power left to check every packet.

In some cases, the IDS is storing activity logs on a drive. If drive space runs out, it's game over. "Why?", you ask. Well, the IDS will no longer be able to store the actual actions/events that the attacker is doing. If the IDS can't see what's happening, it can't stop it.

Note that some IPSs can counter all these types of attacks (at least the basic ones). IPS devices are placed inline between the client and server so that they can detect and stop attacks.

Obfuscating

The technique is used to encode the data so the IDS can't see what's inside but the destination system can still decode the packet. An example of obfuscating is when the attacker encodes the binary data (0s and 1s) using eXclusive OR (XOR).

For example, let's say you've got a string of 10011100, which in hexadecimal would be E4. An IPS could interpret this as code or other malicious stuff. An attacker could use an XOR encoder to turn that string into 4F, which is much harder to detect.

A less-known trick is using subliminal channels. Hackers can encode data inside normal-looking packets (for example, the length of the packet might be slightly larger than it should be). This isn't really used much anymore since newer IDSs are aware of this trick.

Moving around firewalls

Firewalls come in several different flavors. Software- and hardware-based systems are designed to work with different network setups. If you are running a business, for example, your firewall unit will be entirely internal. This means that everything is locked down on one side of the computer's firewall, and everything outside of the network is locked down on the other side. Your firewall will also block all communication between users of your LAN. They do this by locking down your IP addresses so that only certain users can access certain sites based on the specific rules you have established.

Bastion host

These are designed to protect services on other machines and are often used to protect databases. Each time a request comes in, the bastion host checks whether it knows how to communicate with that service (and will allow that service to share back), then passes the request on.

Screened subnet (or demilitarized zone (DMZ))

These are used to protect internal networks with one or more bastion hosts that have access to the outside world. For example, a mail server is in a network. You can lock down specific IP addresses so that only your web server has access to the internet. This way, you know exactly which traffic is coming into your web server and can keep everything organized. A screened subnet is not designed to protect the machine itself.

Multi-homed firewall

These are typically systems with more than one interface and act as a router between networks. They are configured to manage traffic between the networks.

So, firewalls are used to protect our networks from external threats. They can be hardware- or software-based, and they come in different flavors, depending on how they are set up. Firewalls are generally placed in either a DMZ or screened subnet configuration. A bastion host can also help minimize an attack.

Software firewalls

These bad boys are typically installed onto desktops or servers via the OS and control traffic into and out of your network. They can be expensive and take up a fair amount of system resources, so they do not offer much protection for mobile or embedded devices.

Hardware firewalls

This is typically how we see firewalls configured. They're installed on hardware devices and typically run in an application-specific integrated circuit (ASIC) or random-access memory (RAM). These types of firewalls are usually used with larger, more expensive devices.

Application proxy

An application proxy is kind of like a proxy server, but it's designed to allow traffic through for specific services only. Application proxies require fewer resources than full-blown proxy servers, and they come with the added advantage that the user does not need to configure their web browser settings or email client settings because those connections are filtered at the application proxy. Unfortunately, application proxies are only good for traffic that is related to specific applications. This means that if you want to use your web browser to watch YouTube videos, it's not going to work (not right away, at least).

Here is a summary of what you need to know: an IPS detects known bad traffic before the client starts its handshake but doesn't work for unknown threats because it will drop all anonymous traffic.

Firewalls and IDSs detect after the client has completed its handshake so that they can detect unknown threats, but it's not an instant process because the signature of the known bad traffic is needed to be effective.

A few techniques to evade firewalls

An easy way to evade a firewall is by using decoy packets. If you send out packets that look as though they belong together but don't do anything, the firewall doesn't know what it should be looking for. It'll just see a group of packets and accept them (because they look normal).

This is mostly used with encrypted protocols such as HTTPS. Because firewalls can't decrypt the packet, they only know that it's an encrypted stream and will simply let it pass through.

Another way to evade firewall detection is by fragmenting your packets. This is the default fragmentation type in the TCP protocol. If you split packets into smaller chunks, then it's much harder for a firewall to detect that something malicious is going on.

To defeat this technique, all firewalls must be configured to reassemble fragmented packets before processing them to avoid attacks such as session-splicing insertion.

If you want to make sure a firewall or IDS is configured properly, you can send out packets that aren't fragmented. If they're reassembled before being inspected, then you know it works!

The last method is source address rewriting, which basically means that the sender's address in a packet is rewritten to another value. This is mostly used by attackers who want to hide their true location. If you change the sender's address in the IP header, then routers and firewalls will send data back to that address.

To defeat this attack, all firewalls and IDSs must check the integrity of a packet by checking its hashes (in other words, make sure it hasn't been tampered with).

Using ICMP tunneling to bypass firewalls

ICMP is a protocol that's used for some nifty tricks. One of the neatest things it can do is help you bypass firewalls and IDSs. This is done by encoding your packets inside ICMP echo requests (or just ping packets).

If the firewall isn't configured to only pass through valid ICMP packets (most aren't), you can send your IP packets inside an ICMP echo request (ping) packet to an external host. The firewall will most likely let it pass since it looks like normal traffic (it's considered good because the destination address is the target system, not the attacker).

After bouncing through the firewall, another device on the trusted network (such as the DMZ) will send out an ICMP echo reply packet. The attacker can intercept this and extract their original data from the ICMP packet.

Honeypots

In addition to using scanners or IDSs, companies can also install honeypots on their networks to attract external people who just want to get in and break things. Honeypots give security managers and law enforcement an opportunity to get a close-up view of hacker methods and tools. Typically, after hackers enter honeypots through hacking techniques such as software bugs or vulnerabilities, their activities are carefully monitored until they access the systems that they really want or reveal other interesting information.

After falling into a honeypot, hackers find themselves in a special network that may be completely isolated from the company's own network or is set up to mimic certain important servers and services. Then, they can't connect to the usual ports of the usual services, and therefore cannot proceed with their work.

Detecting a honeypot

This is relatively easy. Just become friends with Winnie the Pooh. He'll tell you right away if there's a honeypot nearby. Come on—you knew a joke was coming your way!

Being able to identify and defeat honeypots without being detected is a basic task of a high-level hacker.

Honeypots will capture everything you do, so if you manage to get on a system without being detected it's pretty much game over.

First, the OS is usually outdated (so, unpatched), which means lots of software vulnerabilities can be exploited. Most honeypots are also running custom network services that aren't used anywhere else, which means that exploits can probably be found for those as well.

If you're on a honeypot and start doing some port scanning, the firewall will likely pick it up. This is because honeypots are usually placed in the DMZ where the internal network interfaces are exposed to internet scans.

A better way would be to think of all the things you shouldn't be able to do once inside a network. If you manage to do them, then it's likely that you're on a honeypot.

For example, scanning internal hosts from outside of an organization should never be possible because firewalls block these connections by default. If it does happen, then you must have found a way around the firewall. This would be a red flag, so keep your eyes peeled for more clues!

A quick and easy way to find out if you're on a honeypot is by simply SSHing into the system and checking its uptime. If it's less than 30 minutes, then that might be suspicious (systems usually run for months or years before being rebooted).

Honeypot tools

Yes—there are some tools out there that can help you. Send-Safe Honeypot Hunter (send-safe.com) is a great tool for the job.

It can fingerprint a honeypot system by sending it some specially crafted packets and checking how they're handled on the target machine. If you get an unusual response back, then that's your sign!

If you want to go all out, then use a tool such as Amun, which helps by performing checks on fingerprinted honeypot systems as well.

Note

Honeypots don't have to be connected to the internet; in fact, they can also be used as a defense against attackers who attempt to break into machines via the internet. In those cases, they would be called honeynets as opposed to just honeypots.

Summary

In this chapter, we have defined and introduced what sniffing is and how it can be used in an attack and to protect ourselves from an attack. We discussed the different types of sniffing available to us. We discussed how to leverage sniffing in our efforts to attack actively and passively. We also gave a quick refresher on DHCP and covered a lot of information on ARP. We talked about hardware versus software. We also covered the various types of assaults and attacks, such as DHCP assaults, MAC attacks, ARP poisoning, and DNS poisoning.

Up next, we'll dive into hacking wireless networks and devices.

Questions

As we conclude, here is a list of questions for you to test your knowledge regarding this chapter's material. You will find the answers in the Assessments section of the Appendix:

1. If an attacker is trying to see all the traffic traveling through a switch, which of the following protocols prevents them from seeing any sensitive data?
   1. FTP
   2. IMAP
   3. Telnet
   4. POP
   5. SMTP
   6. SSH
2. Which of the following methods can be used to collect data from a fully switched network or disable some of the switch's traffic isolation features? (Select two.)
   1. ARP spoofing
   2. Promiscuous mode
   3. DHCP starvation
   4. MAC flooding
3. In terms of sniffer discovery on a network, which of the following is true?
   1. Send ARP messages to all systems and wait for NOARP answers to find the sniffer.
   2. Ping all addresses and look for a lag in answers to find the sniffer.
   3. Finding the sniffer on the network is somewhat impossible.
   4. Configure the IDS to look for promiscuous NICs to find the sniffer.
4. Which of the following preventive measures against DHCP starvation attacks are the most effective? (Select two.)
   1. Configuring DHCP filters on a switch
   2. Blocking all UDP port 67 and port 68 traffic
   3. Enabling DHCP snooping on a switch
   4. Using port security on a switch