Hackers Beware

The following is a listing from a Windows machine:

Volume in drive C has no label

Volume Serial Number is 07CF-091C

Directory of C:\

As you can see, both contain similar information, such as the size of the file and date and time it was last modified. For example, if we know that a file came installed with the base operating system, it should not be modified in the course of using the system, and all of a sudden it has a last modified date of yesterday, then that would raise some suspicion. Also, if the size of a file drastically changes, this could also indicate signs of an attack.

Attacker’s Standpoint

Based on the previous information, it is critical for an attacker to make the system look like it did before he gained access and planted his backdoors. Therefore, any files that were modified need to be changed back to their original attributes. From a date standpoint, this can be as easy as going into the system, changing the date back to the date the file was originally last modified, and then accessing the file. Because the system does not know that the current date is wrong, it will set that date as the file modification date. Now, if you go in and reset the date to the real date, anyone looking at the last modified date of the file will think that it has not changed.

From a UNIX standpoint, there are several tools from ftp://ftp.technotronic.com/

unix that enable you to modify the file attributes. One program called fix.c enables you to change the checksum and other attributes of the file. Also, several of the rootkits discussed in Chapter 15, “Preserving Access” have these tools built in. The thing to remember is that the information listed, such as file size and date, is just attribute information contained within the file. You can change the file size to say the program is 1 MB when in reality it is 15 MB. Most of the UNIX rootkit programs not only create backdoors, but they also hide their tracks all in one step.

From an NT standpoint, there are not as many tools for covering one’s track. As we pointed out with the date example, there are some basic things that can be done. It would also be fairly straightforward to write programs that would modify the key file information and hide one’s tracks.

Protecting Against File Information Changes

Protecting against an attacker who is trying to cover his tracks by changing file information might seem like a hard task, but if you have the proper tools, it can be fairly straightforward. One way to detect whether an attacker has changed the file information is by calculating a cryptographic hash on the file. We covered hashes when we talked about password cracking in Chapter 9, “Microsoft NT Password Crackers” and Chapter 10, “UNIX Password Crackers”. A cryptographic hash is a calculation that is made against the entire file and encrypted. This has two powerful features. First, if the file changes in any way, shape, or form, the hash will be different. So, even if an attacker tries to fool you by resetting the date and file size, the hash will be different and you can detect this. One question that might come to mind is, “What stops the attacker from changing the hash?” That brings up the second feature. Because the hash is encrypted through a one-way function, an attacker cannot modify it without knowing the encryption information, which is not simple. Also, if

the hashes are stored offline or on another system, then it also makes it more difficult for an attacker to modify this information.

One popular program that can be used for this purpose is tripwire. It is available at http://www.tripwiresecurity.com. Tripwire works with most operating systems, such as NT and most variants of UNIX. Tripwire will automatically calculate cryptographic hashes of all the key system files or any file that you want to monitor for modifications. Then it will periodically scan those files, recalculate the information, and see if any of the information has changed. If it has changed, then someone has modified the file, and you may have detected an intruder. One common mistake is to monitor files that periodically are changed or updated by the system. In such cases, after the system has modified the file, tripwire will determine that the file has changed and an administrator may think that his system was compromised when in reality it was the normal operation of the system. So, by carefully picking which files are scanned, tripwire can help minimize the number of false alarms generated.

There are also other programs, such as sysdiff for NT, that take a snapshot of the system, and then each time it is re-run, it tells you what files have changed. In UNIX, the diff command enables you to compare two files at a bit-by-bit level to see if any file has been changed.

Additional Files

In most cases, when an attacker breaks into a machine, he uploads files to either gain additional access on the machine or to attack other machines. Often an attacker will break into a machine not for access to the data, but for access to the computer’s resources. If a company has several high-speed workstations and high-speed connections to the Internet, it makes a good site from which an attacker to launch other attacks. In such cases, he would upload large numbers of tools to this site, so he could have access to them when he needed them.

One company complained that its users kept using up all its disk space and it had to add 10GB of space on a weekly basis. This did not make sense because its users stored very little information on the servers. After some investigation, I found over 70GB of hacker tools and data from other companies loaded on its servers. It turned out that attackers were using its site as a launching pad to break into other systems. The funny thing is, if the attackers did not use as much space as they did, there would be a good chance they would never have been detected. The only thing that tipped their hand was that the administrators were getting tired of adding new hard drives to the system.

From an attacker’s standpoint, their goal is to hide the fact that additional files have been added to the system. The following are some ways that they can do this:

•Set the hidden attribute for a file— All file systems enable the creator of a file to hide the file. This is usually done by setting a bit on the file that marks it as hidden. When a file is hidden, if you know that it is there, you can access it, but it will not show up when you perform a standard or typical directory listing or search.

•Rename the files— On most systems, there are system directories that contain a large amount of files. For example, /etc on a UNIX machine or windows on an NT machine. If an attacker picks file names that are similar to other files in the directory, there is a good chance they will go unnoticed. This only works if you have a small number of files you are trying to hide. If you are trying to hide 2,000 files, then this could look unusual.

•Create hidden partitions or shares— On a hard drive, you can create multiple partitions or shares, if there is additional space. In a lot of cases, administrators only check the main partitions and, therefore, if an attacker can create an additional partition, there is a good chance it might go unnoticed. This technique works very well when an attacker has to hide large amounts of information.

•Modify the free space utility— One of the problems with most of these methods is that even if an administrator cannot find the files, if he runs a utility that tells him how much free space he has left on the system, he could become suspicious of why all his hard drive space is being utilized. In such cases, if an attacker could upload a Trojan version of this program, it can lie to the user about how much space they have left. Now this only works to a point, because if the administrator tries to use the space, he will notice that it is not available. And, if one maintains tripwire hashes of standard system programs, it would detect this immediately.

•Use steganography tools— Steganography or information hiding enables an attacker to hide information within another file. So, if an attacker has sensitive information that he wants to hide on a system, he can use these tools to embed his data within other files on the system. The following site contains additional information and a large number of tools that can be used for steganography: http://members.tripod.com/steganography/stego/software.html

Protecting Against Additional Files

From an administrator’s standpoint, the best way to protect against this is to know what is on your system. Periodically, you should run a program that checks for the amount of free space, and if you see this change drastically, then you might have a problem. This program should be verified by a program such as tripwire to make sure it has not been

replaced with a Trojan version. The key thing to remember is that you will never be able to know every single file that is on your system, but if you look for things in your audit trail, such as creation of new directories and uploading of files, they can help give you an idea that there might be a problem.

Covering Tracks on the Network

So far in this chapter, we have looked at how an attacker would cover his tracks on individual systems, such as Windows and UNIX platforms. With the rise of network-based intrusion detection systems and firewalls, attackers also want to hide their tracks on the network. If they can either hide their traffic or make it look like other traffic on the network, so it is not as suspicious, their traffic might slip by undetected. There are three main programs an attacker can use to hide his tracks on a network. The first two programs try to mask the traffic to look like legitimate traffic, and the third program actually hides the data within a packet. The following are the tools:

•Loki

•Reverse www shell

•Covert TCP

Loki

Loki, pronounced “low key,” enables an attacker to mask his traffic to look like other network protocols. Basically, an attacker is tunneling his traffic over protocols that are allowed on a given segment. Loki is available from http://www.phrack.com. The main protocol that is often used to tunnel traffic is ICMP, which is what ping uses because on most networks, there is a high amount of ICMP traffic. If an attacker is sending data back and forth in ICMP packets, it might go unnoticed. Another protocol that is used to mask the real traffic is DNS or UDP port 53. Whenever a user types in a domain name, such as www.newriders.com, it generates DNS traffic because the system has to resolve the host name to an IP address. Therefore, most network segments have a high amount of DNS traffic, so this is another way an attacker can hide on a network.

Protecting Against Loki

There is no straightforward way to protect against this attack. Because ICMP and DNS traffic does not normally have large payloads, if an attacker is transferring large amounts of data, this could indicate a problem, however, this requires close analysis of network traffic.

This section, if nothing else, should emphasize the need for secure systems. Ideally, you want to prevent an attacker from compromising a

machine in the first place. Because this is not always possible, truly knowing your systems and knowing what is normal behavior is key. If unusual traffic is being generated by a machine or if the machine is acting unusual, it should set off a flag. Also, giving users the least amount of access they need to do their jobs, which is known as principle of least privilege, will help minimize the potential damage an attacker can cause. Even if an attacker can compromise a machine, he will be severely limited on what he can do.

Reverse WWW Shell

Reverse WWW Shell is available from http://r3wt.base.org. The concept behind this program is very simple. After an attacker compromises a machine, he would load reverse WWW Shell on the machine. At regularlyscheduled intervals the compromised system would phone home to make a connection to the machine specified by the attacker. The system connects to the remote machine on port 80 with a source port greater than 1024, so from a network analysis standpoint, it looks like a user surfing the web. Not only will this get by network intrusion detection systems, but firewalls that allow outbound surfing but deny incoming sessions would still allow this traffic.

Protecting Against Reverse WWW Shell

To protect against this type of attack, one must look closely at the traffic. If most users go home at 6:00 pm and you notice a lot of web traffic late in the evening coming from a local host, you might get suspicious that something is going on. Also, with normal web traffic, the outgoing web traffic is minimal compared to the traffic coming back from the server. For example, when I surf to a particular site, my browser would issue a get command and then all the contents from the web server would be sent back to my machine. So, the typical pattern is small amounts of data leaving the network going to port 80 and large amounts of data coming back in from port 80. With reverse WWW Shell, the traffic would be different. If the attacker was just interacting with the machine, it would be small amounts of traffic going both ways. Or, if the attacker was gathering data or downloading data off the server, then the profile would be the opposite of normal traffic—large amounts of data leaving the network going to port 80 with smaller amounts of traffic coming back in. So, truly knowing what is normal traffic for a given network could give some indication of a problem, but with high-traffic networks, this might not be feasible.

The other ways to protect against reverse WWW Shell are more general strategies. If an attacker cannot get access in the first place, then he can’t compromise your network.

Covert TCP

The TCP/IP protocols were designed a long time ago before the Internet really took off. Therefore, the designers had to make a large number of assumptions about the type of features and functionality that the protocols would need to handle. Also, a lot of the information that is stored in the protocol headers have minimal checks, therefore, the exact values that are stored in certain fields can be flexible. This leads to an interesting idea. What if we took some of the fields that are not normally used today and combined them with some of the fields that can contain a range of values and then store information in the TCP headers. Remember, because TCP is connection-oriented, there is a lot of overhead in the header, which means there is a lot of room for creativity. This idea of hiding information in the TCP header is based on an area of research known as steganography, or data hiding, and is the concept used for Covert TCP.

Covert TCP is a program that shows that data can be hidden in the TCP header and used to communicate between two systems. Now, if anyone is looking at the traffic, because the data is hidden in the header, it would be hard to detect. Covert TCP proves this can be done using three fields:

•IP identification field

•Sequence number field

•Acknowledgement number fields

Remember, TCP uses the sequence numbers to provide reliable connection-oriented service. So, if we started modifying the sequence numbers for an active session, it would really confuse the two machines. For example, machine B tells machine A that the next sequence number it is expecting is 5501; we embed data in this field, and machine A sends back a sequence number of 1005. This will greatly confuse machine B and will cause a lot of problems. Remember, this tool is more a proof of concept, so it has some limitations. What if we use it for one-way communication? In this case, the sequence number would not be used. So, machine A would send packets to machine B with data stored in the sequence number field and machine B would receive the packets but would keep resetting the connection. Machine B would now receive the message that machine A is sending. If this only happened periodically throughout the data, it would not look that suspicious. On the other hand, if two machines did this all day long, it could draw attention to it.

Another option is: What if we used a field other than the sequence numbers that is not important to the exchange of information? For example, what if we stored information in the source routing field?

Remember, with TCP/IP you can specify the path you want the packets to take through a network, which is known as source routing. Even though very few computers use this field, the space is still available in the header. As you can see, with some creativity, there are plenty of places a

mischievous attacker can hide. As covertness becomes more and more important on the Internet, I think you will see several variations of this type or program emerging.

Protecting Against Covert TCP

Once again, there is no easy way to detect against this type of attack. Looking for suspicious-looking traffic or unusual patterns of behavior can help protect against this. Hopefully, you are starting to see there is no silver bullet and there is no replacement for good analysis and strong security measures.

Summary

As this chapter points out, the main goal of an attacker is not only to gain access but to preserve access. One of the key ways of doing that is to hide their tracks. If an attacker can successfully hide his tracks, then a company has a very low chance of detecting him and stopping the attacker from damaging a company’s system. Therefore, it is key that you detect the attack before an attacker hides his tracks or while he is in the process of doing so. Understanding the ways attackers cover their tracks will help you be better prepared to protect your systems. In most cases, after an attacker is fully entrenched in your system, it is very difficult to track him down.

Chapter 17. Other Types of Attacks

So far we have gone over general types of attacks, such as session hijacking and spoofing, and attacks against specific operating systems, such as NT and UNIX. Now we will cover attacks that are important to understand, but are not covered in other chapters because they affect other services that are critical to the Internet or do not map to other categories of attacks. These include attacks against DNS and SNMP and tools that could represent a threat to your company, such as sniffers. By understanding these and the threat they pose to your company, you will be in a better position to protect against the vulnerabilities exploits:

•BIND 8.2 NXT remote buffer overflow exploit

•Cookies Exploit

•SNMP Community Strings

•Sniffing and Dsniff

•PGP ADK Exploit

•Cisco IOS Password Vulnerability

•Man-in-the-middle attack against Key Exchange

•HTTP Tunnel Exploit

Bind 8.2 NXT Exploit

The early versions of BIND that introduced the NXT resource record extension improperly validated these records inputs. This bug permits a remote attacker to execute a buffer overflow to gain access to a target system at the same privilege level the named daemon is running at, for example, root.

Exploit Details

•Name: BIND 8.2 NXT remote buffer overflow exploit.

•CVE Number: CVE-1999-0833.

•CERT Advisories:

o http://www.cert.org/advisories/CA-2000-03.html

ohttp://www.cert.org/advisories/CA-99-14-bind.html

•Operating System: Systems running BIND 8.2, 8.2.1 with Linux, Solaris, FreeBSD, OpenBSD, and NetBSD UNIX operating systems. Prior versions of BIND, including 4.x, are not vulnerable to this particular exploit.

•Protocols/Services: TCP/UDP, port 53.

•Written by: Robert McMahon.

Protocol Description

The Domain Name System (DNS) is one of the most widespread protocols utilized on the Internet because of its function—resolving domain names to IP addresses. Email messaging and web browsing would be chaotic at best if DNS was denied to public use. DNS is based on a client-server distributed architecture composed of resolvers and name servers. Name servers that perform recursive resolution (as apposed to iterative resolution) are of particular interest because of they are vulnerable to the NXT remote exploit on certain DNS implementations.

DNS uses both UDP and TCP transport protocols. Resolvers and name servers query other name servers using UDP port 53 for almost all standard queries. TCP is used for zone transfers and also for queries of larger size domain names (for example, exceeding 512 Bytes), which has relevance to the this exploit. Earlier versions of DNS were regarded as insecure because there was no ability to authenticate name servers. In an

attempt to make this protocol more secure and permit authentication, DNS Security Extensions were developed. One of these extensions is the NXT Resource Record (RR). The NXT RR provides the ability to securely deny the existence of a queried resource record owner name and type. Ironically, it is this security feature that opens the door for the subject buffer overflow attack and is the reason why earlier versions of BIND were not exposed. The details of the NXT RR and associated data fields can be found in RFC 2065 at http://www.freesoft.org/CIE/RFC/2065/index.htm.

The Berkeley Internet Name Domain (BIND) implementation of DNS is the most popular version deployed on the Internet. The BIND 8.2 implementation of the NXT RR was developed with a programming bug in it that permits remote intruders (through another name server) to execute arbitrary code with the privileges of the user running the named daemon. The specifics on this programming bug are discussed in the following section.

Description of Variants

The version of the NXT exploit addressed in this book was written by Horizon and Plaguez of the ADM CreW, and it can be found at ftp://freelsd.net/pub/ADM/exploits/t666.c. This version has successfully engaged several name servers. Another version of the NXT remote exploit, Exploit for BIND-8.2/8.2.1 (NXT), was written by the TESO group and can be found at http://teso.scene.at/releases.php3/teso-nxt.tar.gz. Because the author “z-” gives thanks to Horizon, it is assumed this code was developed after the ADM-NXT version. Some key differences between the ADM-NXT and TESO-NXT versions, other than the differences due to programming style, are the following:

•The ADM-NXT version was tampered with by the authors to make it harder for script kiddies to employ.

•The TESO-NXT version was designed to run only against Linux and FreeBSD operating system memory stacks.

How the Exploit Works

The BIND 8.2 NXT exploit is based on a buffer overflow of the stack memory. This buffer overflow is possible because of insecure coding practices. Many programmers employ functions that use routines that do not check the bounds of input variables. The reasons for this may be intentional (for example, performance reasons) or possibly just a lack of understanding of secure programming techniques. At any rate, this is an all too common practice, and this buffer overflow can be exploited by a hacker who has access to source code and can run utilities, such as strings, which find insecure routines. Stack memory manipulation is of particular relevance to the BIND 8.2 NXT exploit as well as to other buffer