Hackers Beware

The rpc.statd server is an RPC server that implements the Network Status and Monitor RPC protocol. It is a component of the Network File System (NFS) architecture.

The logging code in rpc.statd uses the syslog() function. It passes the function as the format string user supplied data. A remote user can construct a format string that injects executable code into the process address space and overwrites a function’s return address, thus forcing the program to execute the code. The attacker will have root privileges because the rpc.statd requires root privileges for opening its network socket, but it does not ever release these privileges. This enables the remote user to execute his code with root privileges.

How To Use the Exploit

Download one of the given codes and use it to exploit the given vulnerability.

Signature of the Attack

Watch for a server on the vulnerable server list.

How To Protect Against It

Download and install the proper patches for the version of Linux you are running. For example, for RedHat Linux 6.2, go to the following sites:

•RedHat Linux 6.2 sparc:

Red Hat Inc. RPM 6.2 sparc nfs-utils-0.1.9.1-1.sparc.rpm ftp://updates.redhat.com/6.2/sparc/nfs-utils-0.1.9.1-1.sparc.rpm

•RedHat Linux 6.2 i386:

Red Hat Inc. RPM 6.2 i386 nfs-utils-0.1.9.1-1.i386.rpm ftp://updates.redhat.com/6.2/i386/nfs-utils-0.1.9.1-1.i386.rpm

•RedHat Linux 6.2 alpha:

Red Hat Inc. RPM 6.2 alpha nfs-utils-0.1.9.1-1.alpha.rpm

ftp://updates.redhat.com/6.2/alpha/nfs-utils-0.1.9.1-1.alpha.rpm

Additional Information

Additional information and the source code can be found at: www.securityfocus.com.

Summary

As you can see, there are a wide range and number of exploits available for UNIX operating systems. The key thing to remember is that most of the exploits are against applications or scripts installed on the system.

Therefore, it is critical to carefully check UNIX systems to make sure that only the minimum amount of software is installed for the system to function properly. Any extraneous software on the system could be used to exploit and compromise the machine

Chapter 15. Preserving Access

IN MOST CASES, AFTER AN ATTACKER MAKES THE EFFORT to break into a system, he wants to be able to get back into the system whenever he wants. For example, if an attacker breaks into a site, to use it as a launching pad to break into other systems, he wants to be able to break back in with ease to access his tools after they are loaded on the system. A common way to do this is to create a backdoor into a system that only he knows about. Therefore, it is critical that he not only create ways to get back in, but that he also cover his tracks. What good is creating a backdoor if the system administrator can quickly find it? In this chapter, I will cover backdoors and in Chapter 16, “Covering the Tracks,” I will look at how attackers cover their tracks. The key thing to remember is that backdoors do not exploit any weaknesses in the operating system. An attacker already has to exploit a vulnerability and gain access before he can load one of his programs. With that said, even though backdoors do not exploit vulnerabilities, they do create new vulnerabilities on the system by giving an attacker a way back in that did not exist previously.

So, if we lived in an ideal world where all systems were secure, then we would not have to worry about an attacker preserving access because he would not be able to gain access in the first place. Because this is not reality and attackers can gain access to a large number of machines, it is critical for administrators to understand the techniques attackers use to create backdoors into the system, so they can properly defend against these attacks.

This chapter helps illustrate why it is so important for you to understand what is running on your system and to review the log files on a regular basis. If an attacker is able to compromise your system once, he can cause damage, but if he is able to get back into your system whenever he wants, you have a much bigger problem. An administrator must not only detect when unauthorized access has occurred, but he must also detect when a backdoor has been added or additional ports have been opened. This is why I emphasize one of my mottos: “Prevention is ideal, but detection is a must.” If a company is connected to the Internet, it will never be able to prevent every attack; but to have a secure network, it is critical to detect attackers before they create backdoors into the system. If the attacker is able to create a backdoor, a company must know what to look for, so it can detect the backdoor as soon as possible and minimize the potential damage.

In most cases, an attacker creates a backdoor by opening an additional port on the system that he uses to gain access at a later time. Remember that ports are the doors and windows into a system, are the way computers communicate with each other. Something as simple as a port scan of all the open ports on a system, including the high ports, can quickly reveal that a new port is open and someone has compromised the machine. If, however, a port scan is not performed on a regular basis, the backdoor could easily go undetected.

A common way that attackers install backdoors on a system or network is through the use of Trojan programs. A Trojan program has the capability of penetrating a company’s defenses, sneaking inside the network, and creating a backdoor on an unsuspecting victim. With traditional backdoors, an attacker needs some way to gain access, so he can install the program. A Trojan program provides the means for doing this. Let’s look at how these programs work, and then we will cover some programs used to create a backdoor on a system by opening up a port. One Trojan program is called netcat.

Backdoors and Trojans

In its simplest sense, a backdoor is a way for an attacker to get back into a network or system without being detected. A backdoor is a hidden passage way back into a system that requires minimal effort to exploit. As we stated earlier, after an attacker performs reconnaissance by scanning and successfully exploiting a system, he wants to make it easier to get back in at a later time. One of the most common ways to create a backdoor is by opening up a port that has a listening agent attached. These programs are covered next. An open port is fairly easy to detect, if a company is looking in the right places. If a company runs a port scan against every system and scans for open ports from 1 through 1023, and an attacker has port 5050 open, then it will never detect the attacker. This

is why it is critical to scan the entire range of ports 1 through 65535, and not only do this once, but twice. Why twice? Once for TCP and once for UDP? Because more and more companies are scanning for TCP ports and not for open UDP ports, attackers are now using UDP ports to hide.

We can see that it is fairly easy to create a backdoor on a system after access has been obtained, but wouldn’t it be possible to create a backdoor without gaining full access? Well, yes, there is a way through the use of Trojan programs. A Trojan program or Trojan horse works similarly to how it was used a long time ago. I am sure that everyone has heard the story, so I will paraphrase. A group of people wanted to gain access to a castle, but it was fortified and properly guarded, which made it difficult to attack out-right. So, someone said, “What if we indirectly attack it?” So, they built this big wooden horse and presented it as a gift. The recipients were so amazed by this big horse that they brought it into the castle. They were so taken aback by the outward appearance, that no one looked at it closely. If they did, they would have seen the inherent danger that lied within. The horse was filled with soldiers, and when the people in the castle went to sleep, the soldiers climbed out of the wooden horse and attacked the castle from the inside. As you can see, this trick of using Trojan-type programs has been used for a long time, but it is also highly effective today on the Internet.

Based on this example, you can see that a Trojan program consists of two main parts: an overt program and a covert program. The overt program is the part that everyone sees. This piece is meant to be interesting or exciting enough, so that when someone sees it, they automatically run the program without thinking about it. The covert piece is the program that does the damage. When the overt program is openly running, the covert program is secretly running behind the scene doing all sorts of damage. The covert program can really do anything—launch an attack, delete a hard drive, or open a backdoor. With most Trojan programs, the covert piece installs a piece of software that creates a backdoor on the victim’s computer.

One of the main reasons why Trojan horse programs are so popular on the Internet is because they are highly effective. Most users forget about the dangers of the Internet when they open email attachments or download software from the web. They think the software is harmless and never stop to think about the dangers that might lie below the surface. Another problem is that Trojanized programs spread like wild-fire on the Internet because they usually come from trusted sources. When I receive a cool program, what do I do? I send it to all my friends who forward it to all their friends. So, in the course of a couple of days, this program can infect thousands of computers all over the world. The next time you receive a cool program, such as gerbil bowling or a dancing Santa, you might want to think twice before you run the program. Is it really worth

the potential risk? (As a side note, if you have not seen gerbil bowling it is this bizarre program that is floating around the Internet. When you run it, these little gerbils run around your screen and line up as bowling pins and you use the mouse to knock them down with a bowling ball.) I am not saying that this program has a Trojan horse installed in it, I am just emphasizing how easy it would be for someone to do something like this.

To emphasize this point, I was once asked, “What would be a quick and easy way for an attacker to compromise as many machines as possible with the least amount of effort?” I thought for a while, and my answer was to use a Trojan horse. Develop a cool program that has an easy-to- use GUI that everyone would like. Build or find the program and install a Trojan horse into the program. Then put it on the Internet, and send it to a couple hundred people. You would be amazed not only by how quickly the program would spread through the Internet, but also by how many people would run the program.

When we cover the section “Back Orifice” later in this chapter, we will cover wrapper programs, which show you how easy it is to create a Trojan program. But first, let's look at a real example. There was a program floating around the Internet that claimed to turn a CD-ROM drive into a CD writer. As you can imagine, when CD writers first came out, they were very expensive. So now users had a way to turn their CD into a writer through this free software. Most users questioned it, but figured, “What the heck, it is worth a shot.” Unfortunately, the program was a hoax and had a Trojan horse program that, in most cases, deleted the victim’s hard drive.

Let’s look at one more example to show the devastating impact Trojan programs could have on a company. Microsoft fell victim to a Trojan horse program in late 2000 that entered the company through email. The program was believed to be QAZ.

QAZ

QAZ is a fairly straightforward program that enters a network through email. It hides itself on the victim’s computer by hiding in the notepad.exe. It does this by renaming notepad.exe to note.com and then copies itself to notepad.exe. You might be asking yourself, “Well won’t this be obvious because now when someone tries to run notepad, it will not work?” Actually, QAZ is a little smarter than that. When someone tries to run notepad, QAZ not only starts its own program, but then it calls the real notepad.exe, which is stored in note.com. So, from the user’s standpoint, everything is working properly. QAZ creates a backdoor on port 7597 and also emails the victim’s IP address back to the attacker. Well, you can be pretty sure that it is not the attacker’s real email

address, but an address that they have compromised. So, if a company runs port scans on a regular basis, it can detect this port is open.

QAZ is also a worm that tries to spread itself through the system. It does this by looking for network shares, and when it finds shares, it overwrites notepad on the remote system. So, not only does QAZ create a backdoor, but it also has a mechanism for spreading throughout a network very quickly. I am starting to see this more as new tools are released. They perform several functions within one program to give potential attackers a lot of power.

Now let’s look at an easy way to create backdoors on a system using a listening agent.

Backdoor Listening Agents

In this section, we will look at generic programs that can be used to create backdoor listening agents. Then, we will look at more customized tools that not only give an attacker access, but enable him do whatever he wants on the victim’s system. A backdoor listening agent is a program that opens a port on a victim’s machine and then listens on that port for someone to connect. When someone does connect to the port, it either runs a third-party program or gives the attacker command-line access. The following are the programs we will look at:

•Netcat

•Tini

Netcat

Netcat is often considered the swiss army knife of security tools. It has a lot of features and functionality, but in its most basic form, it is a program that enables a system to either push data to another machine or receive data from another system. When it is receiving data, it is basically just listening on a specific port waiting for a remote system to attach to that port. As you can see, this can be used to form the basis for a backdoor listening agent. Not only can you tell netcat to listen on a specific port, but you can tell it what program to run when a user attaches to that port. In most cases, when an attacker creates a backdoor, he wants to acquire a command prompt, so he can issue whatever commands he wants on the remote system. So, for our example, we will use netcat to listen on port 5555 and run the command prompt for the corresponding operating system that we are running it on. Netcat runs on both UNIX and NT. The following are the commands used to create a backdoor listening agent with netcat on either operating system:

• nc -l -p 5555 -e /bin/sh (for UNIX)

•nc -l -p 5555 -e cmd.exe (for NT/2000)

On either operating system, an attacker would install the netcat software and run the above command, and with minimal effort, an attacker is able to create a backdoor listening agent on whatever port he would like.

Tini

Tini is similar to netcat in that it is used to create a backdoor listening agent on Windows systems. It has less features and is not configurable, but as its name states, it is very tiny. One of the main advantages of tini is that it is only 3 KB in size. It takes minimal bandwidth and space to get on a system, and after it is running on a system, it takes up little space on the hard drive. The program is available from http://ntsecurity.nu/toolbox/tini. What makes the program so small is that it is written in assembly language. From an attacker’s standpoint, the main drawback is that it always listens on port 7777 and runs the command prompt when someone attaches to this port. This makes it easier for a victim system to detect because if a company finds out port 7777 is open on a system, it has a really good idea that tini is running. It is much harder for a victim to detect netcat because an attacker can have it listen on whatever port he wants and can change it periodically.

Rootkits

Rootkits are very common with UNIX operating systems, but there is some ongoing work to build rootkits for NT systems. Contrary to the name, rootkits do not enable an attacker to gain root access; however after an attacker has root access, it enables him to get back into the system as root whenever he wants. One way to look at rootkits is that they trojanize key system files on the operating system. For example, login is the program that users utilize to log on and authenticate to the operating system. If an attacker gains access to the system, he can replace the login program. If he just over writes it, then it would be fairly obvious that someone messed with the system because legitimate users would not be able to gain access. However, what if an attacker used the original login program as the over program but added a covert feature? In its most basic form, the covert feature could be that the system automatically allows someone to have root access without providing a password when they connect to the system and provide a certain user name. For a list of several rootkits, visit this web site http://packetstorm.securify.com/UNIX/penetration/rootkits.

There are two general types of rootkits: file-level and kernel-level rootkits. I cover both types in detail and highlight the benefits and weaknesses of each type.

File-Level Rootkits

As you can see, rootkits are very powerful and are an easy way for an attacker to plant a backdoor on a system. The most basic type of rootkits are ones that go in and modify key files on the system. The legitimate program is replaced with a Trojan version. Usually, the legitimate program becomes the overt program and the backdoor becomes the covert function. Some of the common files that are often trojanized with UNIX rootkits are:

•login

•ls

•ps

•find

•who

•netstat

The actual list of files is a lot longer, but this sample gives you an idea of the type of programs an attacker goes after. The programs are often replaced with Trojan versions, which an administrator would use to monitor the system. Therefore, if these programs are modified, the administrator is provided with false information and is not able to detect the attack. However, because most rootkits replace ls but not echo, an easy way to see if a system has been compromised is to run ls and echo; if you get different results, you know you have a problem. You can imagine that as attackers realize this, the newer version of rootkits will also have Trojan versions of echo.

As you can see, if an attacker can trojanize every command that a user normally issues, not only can he create backdoors into the system, but he can hide his tracks. Therefore, with rootkits, you get a two-for-one deal. Not only can an attacker get back into a system whenever he wants, but it makes it very hard for a victim to detect it. For example, let’s look at how an attacker would create a rootkit to preserve access and cover his tracks. First, he would install a version of login that worked as designed, but whenever someone used a user ID of evileric, it would automatically log that person in with root access. One problem with this is if an administrator issues the who command while an attacker is logged in, he will see evileric and get suspicious. So, the attacker would create a Trojan version of who that, whenever it saw evileric logged onto the system as a user, it would ignore that line and not display it on the screen. Now you can start to see the power of rootkits. Even though evileric is logged into the system, the administrator would not know about it because the program is filtering out certain information. Rootkits basically provide false information or lie to the administrator to hide what an attacker is doing.

Defending Against File-Level Rootkits

What we just described are generic file-level rootkits. To install themselves, they actually modify the key system files. This makes them fairly easy to detect, if a company is running a program, such as tripwire, on its system. Tripwire is a great program for detecting file-level rootkits. Tripwire is a program that runs a cryptographic hash against a file, so if the file has been modified in any way, the hashes will be different, and tripwire will set off an alert. The only way two hashes can be the same is if the two files that produced the hashes are exactly the same. Because file-level rootkits modify the file, the two files are not the same, and therefore, the two hashes will be different. Now by using tripwire, an administrator can easily spot the use of a file-level rootkit on his system. As long as he runs tripwire on a constant basis, whenever a file changes in any way, including when a Trojan is installed, tripwire will be able to detect it.

Now after reading this, you might think that rootkits are an annoyance, but with proper security, they can be detected and stopped. This is true of file-level rootkits, but now attackers are increasing the stakes and making the good guy’s job more difficult with the introduction of kernel-level rootkits.

Kernel-Level Rootkits

File-level rootkits operated at the application level are fairly easy to detect. Kernel-level rootkits operate at a much lower level on the system, the kernel. By attaching to the kernel, kernel-level rootkits do not actually modify any key system files on the system. So now tripwire will not be able to detect any changes because the files do not actually change. By operating at the kernel-level, an attacker can intercept system calls without modifying any files on the system. This gives you the power of rootkits and all the same features without the weakness of file-level rootkits.

One way to understand kernel-level rootkits is this: If an attacker wanted to intercept and listen to your phone calls, he could gain access to your house and install a device on your local telephone. Because an attacker is actually modifying your phone, it is fairly easy for him to do, however, it is also easy for you to detect. If you look at your phone or examine it closely, you will notice that it has been modified. This is equivalent to filelevel rootkits. On the other hand, if an attacker knows that all your calls have to through a junction box, which is usually located on a telephone pole or underground, and he gained access at that point, it would be very difficult for you to detect because he is modifying something outside of your immediate control. An attacker can still listen in on your calls and have the same level of control, but because he is not doing it at the termination point (your phone), but instead farther down stream, it is more difficult to detect. This is the same thing that kernel-level rootkits

do. Instead of operating at the application level and modifying the actual programs that users run, the attacker is leaving the program unmodified and is operating downstream at the kernel. This is just as effective because all calls the applications make must go through the kernel.

Defending Against Kernel-Level Rootkits

Defending against kernel-level rootkits is difficult to do. This is an area where I really want to stress good security. If a company has proper defense mechanisms and enforces a principle of least privilege on all systems, then the attacker cannot install a kernel-level rootkit, as long as he cannot get root access. Another option is to run some of the commands that an attacker would use to control a rootkit, and if they work, then a company knows it has been compromised. As you will see with kernel-level rootkits, an administrator can act as an attacker and issue the same commands that an attacker uses because the control programs are not password-protected. If the system actually responds, then you know you have been compromised. Likely, the best protection, but of course not the easiest, is to run a monolithic kernel that does not allow loadable kernel modules on your key systems.

Now let’s look at rootkits for both NT and UNIX operating systems.

NT Rootkits

Most of the rootkits that exist are for UNIX environments. Some work is being done to develop an NT rootkit, but the product is still in beta form and is available from http://www.rootkit.com. It is currently in active development, and the latest version is Build 0.43. The latest version is only available in source form, but early versions are available in binary. The current version does not use a loadable kernel module; it utilizes a direct patch to the NT kernel, however the tool is evolving into a kernel module-based tool that enables an intruder to hide his presence on a system. Some of the basic features it offers are the following:

•Registry hiding features

•Direct access to any of the network cards installed on the system

•Execution redirection

Now let’s look at some of the more powerful rootkits that exist for UNIX systems.

UNIX Rootkits

A large number of file-level and kernel-level rootkits are available for the UNIX environment. The following are a list of several of these programs: