Protecting Your Network Against Spoofed IP Packets

By: Brien M. Posey

These days, the vast majority of administrators go to great lengths to protect the files on their network. Typically, elaborate firewalls are used to keep outsiders away from file servers. The files residing on those servers often lie behind an intricate permissions scheme and are often encrypted. Complex auditing mechanisms might even monitor access to files. The point is that in this day and age, most administrators take security very seriously. What you might not realize though is that all of this security can be easily undone through the simple action of a user accessing a file through legitimate means. In this article, I will show you how this is possible and what you can do to fight back.Encrypted Files on the Network

Let’s pretend for a moment that you use the Encryptable File System (EFS) to encrypt all of the files residing on a particular server. Now let’s pretend that a user with legitimate access needs to open one of those files from their workstation. When the user opens the file, security is briefly compromised. The reason for this is that the file must travel over the network. This is a problem because when a user accesses an encrypted file, the file is decrypted at the server level, not at the workstation level. This means that the file has been decrypted before it ever arrives at the user’s PC. Anyone on the network with a little bit of know-how can use a protocol analyzer to intercept the file in transit and gain access to the information contained in the file.

The reason that this type of exploit works has to do with the way that networking works at the most basic level. On many types of networks, all of the computers on a network segment share a common connection medium. When a computer transmits a packet to another computer, all of the computers on the segment receive the packet. Each computer checks the packet’s destination address to see if it is the intended recipient of the packet. If the destination address doesn’t match the computer’s address, then the computer assumes that the packet is intended for someone else and ignores the packet.

Protocol Analyzers

When a computer runs a protocol analyzer though, the protocol analyzer places the computer’s network card into promiscuous mode. This means that the computer does not ignore packets, regardless of the intended destination. The protocol analyzer then displays the contents of each packet on the screen. Every protocol analyzer is different, but most of the time protocol analyzers will allow users to filter out unwanted packets and reconstruct packet streams. The result is that a user who is running a protocol analyzer can get their own copy of a file that is being transmitted, they can read E-mail messages, and do just about anything else that they want.

Obviously, the idea that a user on your network can use a protocol analyzer to snoop the contents of packets that are flowing across the network isn’t exactly a comforting thought. In reality though, the damage that a user can do with a protocol analyzer is a whole lot worse than what I have already told you about. Yes, a user who’s equipped with a protocol analyzer can steal files in transit, read E-mails, see the contents of the Web page that you are looking at and things like that, but they can also steal your online identity.
Identity Theft

Think about it for a moment. Files, E-mail messages, and Web pages aren’t the only things that flow across the network. Authentication credentials are also transmitted across a network. Imagine for a moment that you are logging on to a FTP site. As you type your password, the password is not displayed on the screen. You see a dot or an asterisk in place of each character. As soon as you press enter though, your password is transmitted to the FTP server. If someone is watching the login process with a protocol analyzer, they won’t see your password represented as dots or as asterisks. They will see your password spelled out in plain text.

OK, in all fairness, it isn’t always that easy to steal a password. A generic FTP session transmits the password in clear text, but most modern authentication mechanisms encrypt the password prior to transmission. When the server receives the password, it is decrypted and checked for accuracy. If you were to watch an encrypted password be transmitted, the protocol analyzer wouldn’t show you anything but a long string of hieroglyphics.

The good news is that having the password encrypted makes it difficult, if not impossible, for someone with a protocol analyzer to steal the password. The bad news is that the user doesn’t have to steal the password. The user can steal your identity through the use of a replay attack.

Replay attack

Here’s how it works. The person with the protocol analyzer recognizes an authentication packet, but can’t read the password contained within it because the password is encrypted. Just because the password is encrypted though, it doesn’t mean that the password isn’t there. The packet still contains a password and that password exists in a form that is perfectly acceptable to the server that authenticates the password. That being the case, the user makes a copy of the authentication packet and changes the packet’s source address to match the address of the computer that they are using. They then use the protocol analyzer to transmit the modified authentication packet to the server that handles authentication for the network. The server receives the packet and sees that it contains a valid set of authentication credentials. The server therefore assumes that the user whose identity was just stolen is logged in at the hacker’s machine. To put it simply, the hacker is logged in as the user whose identity they stole, and they never even had to figure out the victim’s password to do it.

Since the hacker is impersonating a legitimate user, there is always the chance that the user whose identity was stolen could log in while the hacker is logged in as them. Sometimes, the hacker will launch a denial of service attack against the user that they are impersonating. This keeps the victim from logging on until the hacker is finished with what ever it is that they are doing.
How do I Protect the Network?

So I guess the million dollar question is how can you protect your network against this type of attack? There are a couple of different things that you can do. The first thing that you need to do is to have a system in place to catch anyone who is using a protocol analyzer on your network. At first it might seem impossible to catch someone using a protocol analyzer since a protocol analyzer passively listens to network traffic.

The Bait

The key to catching someone using a protocol analyzer is to watch DNS name resolutions. You can setup a bait machine on your network. The machine doesn’t actually have to do anything other than run Windows. The catch is that you must not tell anyone of this machine’s existence. Since nobody knows that the machine exists, and the machine isn’t doing anything, then nobody should have any reason to communicate with the machine. However, because the machine is running Windows, it will send out the occasional packet. Normally, the machines on your network will be completely oblivious to this packet. However, a protocol analyzer will notice that traffic is coming from an unknown host on the network. The protocol analyzer will then perform a DNS query to try to determine the machine’s identity. Normally, nobody should have any reason to be making DNS queries regarding your bait machine, so these types of queries are almost always indicative of someone running a protocol analyzer or other hacking tool.

IPSec

Another way that you can defend your network against these types of attacks is to use IPSec to encrypt network traffic. I’ve already shown you how encryption can be circumvented, so you might be wondering what makes IPSec any different.

The difference is that IPSec’s whole job is to secure data flowing over the network. Before a session can even be encrypted, IPSec insists on mutual authentication. What this means is that if Computer A wanted to securely transmit a packet to Computer B, IPSec would require both machines to prove their identities before it would permit the session.

IPSec also takes measures to insure that packets are not tampered with in transit. Earlier I explained how the source address of a packet could be modified by a hacker. A hacker can change much more than a packet’s address though. For example, imagine that a hacker knew that Computer A was going to be sending an important E-mail message to Computer B. The hacker could run a denial of service attack against Computer B to prevent them from receiving the message. Meanwhile, the hacker intercepts the message and changes it to make it look like the guy at Computer A said something completely different than what the original message said. The hacker then ends the denial of service attack against Computer B and sends the modified packets. The result is that the person at Computer B receives a fraudulent E-Mail message that looks authentic.

IPSec can protect against packet modification. IPSec calculates a check sum value based on the packet’s original contents. If the packet is modified, then the checksum value becomes invalid and IPSec knows that the packet has been tampered with.

IPSec even protects against replay attacks. Each IPSec packet is assigned a sequence number. If a hacker attempts to replay an IPSec encrypted packet, then the sequence number will not fit into the current packet sequence and IPSec will know that the packets are invalid.

As you can see, deploying IPSec on your network can greatly enhance your network’s security. Before you deicide to deploy IPSec though, there are a few things that you need to know. First, IPSec requires your network to have a certificate server in place. Windows Server 2003 can be configured to act as a certificate authority, but you will need a dedicated server. Technically, a dedicated server isn’t an absolute requirement for a certificate authority, but running any other services on a certificate server is an extremely bad idea from a security standpoint.

Another thing that you will need to know is that IPSec does place an additional burden on your network. Extra CPU cycles are necessary to perform the encryption and decryption process, and IPSec encryption usually increases the volume of traffic that’s flowing across your network. One way of easing this additional burden though is to use IPSec enabled NIC cards. These NICs offload the encryption and decryption process from the machine’s CPU.

One last thing that you need to know about IPSec is that not every operating system supports it. IPSec was first introduced in Windows 2000. Older Windows operating systems do not support IPSec.

Conclusion

In this article, I have explained some different ways that hackers can exploit the traffic that’s flowing across your network. I then went on to explain how you can use bait machines and IPSec encryption to counter these techniques.

1.) Protecting Your Network Against Spoofed IP Packets - Brien M. Posey
2.) Pivoting BOUNCEr - pbounce 0.1 released - Meder Kydyraliev
3.) TCP and IP Options - Don Parker
4.) Coping with A Major Security Breach? What’s your Contingency Plan? - Martin Allen
5.) Caveat Lector: Authentication, the Forgotten, Should-be Predominant - Justin Troutman
6.) Malware – future trends - Dancho Danchev