Hackers Beware

As you can see, most of these backdoor programs for Windows operating systems have similar features. The thing to remember is not only how easy they are to use but how powerful and feature rich they are.

After an attacker successfully compromises a system, to preserve access so he can get back in, he creates backdoors on the system. This enables him to quickly acquire access to any system that he previously compromised. As we covered in this chapter, there are basic listening agent backdoors, in which an attacker just opens a port on a victim’s machine. Trojans are a way to embed a backdoor in an innocent-looking program with the goal of having a victim run it, which in turn will call the covert program and create a backdoor on the given host. Rootkits are a version of backdoors that create Trojan files out of standard system programs. We also covered remote control backdoor programs for NT operating systems.

As you can see, it is critical for companies to know what backdoors are and how they work, so they can detect them on their systems. Ideally, with proper security, an attacker should never be able to gain access, and therefore, would not be able to install backdoors on the system. Because this is not reality, after an attacker does install a backdoor, it is critical for a company to detect it as soon as possible, and not only close down the backdoor, but fix the vulnerability that allowed the attacker to gain access in the first place. Only by adhering to the rule, “Prevention is ideal, but detection is a must,” is a company able to properly protect against the perils of the Internet. Because creating a backdoor is only effective if an attacker can hide his tracks, we will cover this topic in Chapter 16, “Covering the Tracks.”

Chapter 16. Covering the Tracks

WHEN AN ATTACKER SUCCESSFULLY BREAKS INTO a system, one of his goals is to preserve access, so he can get back into the system whenever he wants. In certain cases, such as espionage, someone wants to get into the system, obtain some piece of information, and never get back in again. However, in most cases, an attacker wants to preserve his access. If a hacker spent a lot of time and energy researching a site and obtaining access, he would not want to do the same amount of work each time he wanted to re-enter. As we have seen in Chapter 15, “Preserving Access,” there are a lot of tools a hacker can use to preserve access. A key part of preserving access is covering the attacker’s tracks or, essentially, hiding the fact that he was ever there.

If a hacker can get into a system and put in a backdoor, but the administrator detects that this occurred, then the attacker’s access will be short lived. If the administrator is able to detect the backdoor, he will obviously remove it, preventing the hacker from easily re-entering the system. This is why covering one’s tracks is so important from a hacker’s point of view. If an attacker can hide the fact that he was on your system, and you cannot detect what he did, then he will continue to have access.

On the other hand, if you can better understand the ways attackers cover their tracks, you have a better chance of determining whether your system was breached. Remember, the bottom line when it comes to security is: Prevention is ideal, but detection is a must. From a security standpoint, you must be able to detect an attacker. This creates a chess match between the attacker and the security administrator. The attacker is going to try to cover his tracks and hide what he did. The security administrator has to look for clues to see whether his system was really breached. “The Cuckoos Egg,” by Cliff Stoll, is an excellent book that shows some of the fun you can have when you try to track down an attacker on your network. This chapter shows you the ways an attacker covers his tracks, so you can be better prepared to protect your systems.

How To Cover One’s Tracks

After an attacker has gained access and accomplished what he wanted to do, one of the last steps he performs is covering his tracks. This involves

going back into the system and hiding evidence that he was ever there. To do this, there are four main areas an attacker is concerned with:

•Log files— Most systems contain log files or audit trails that list who gained access, and for how long. Depending on the level of logging, it could also indicate what they did and what files they accessed.

•File information— To gain access or to put a backdoor on a system to preserve access, attackers usually have to modify or recompile key system files. When an attacker does this, key file information, such as date and file size, tends to change, which could indicate that an attacker was on the system.

•Additional files— In most cases, during the process of gaining access or after an attacker has gained access, he’ll usually load additional files to the system. These files can take up a large amount of space and can be used to either preserve access on the current system or, in many cases, to attack other sites. In the case of the latter, the attacker needs all his tools loaded onto the system, which could take considerable space.

•Network traffic— When an attacker breaches a network, most of the time he does it over a network or through the Internet. This means an attacker has to be able to cover his tracks on the network. Because most networks are running network-based Intrusion Detection Systems (IDS), any suspicious-looking network traffic is flagged. This means that an attacker either has to search and eliminate the IDS records, which is very hard to do because they are processed in real time, or mask his traffic, so it looks like normal traffic on the network.

This chapter covers each of these areas in depth and shows what an attacker has to do to cover his tracks.

Log Files

Log files provide a listing of exactly what was done on a system and by whom. In terms of detecting an attacker on a system, they provide an invaluable tool. To detect unusual activities using a log file, two things have to be done: logging has to be turned on and the log files have to be checked. Unfortunately, most administrators do not turn logging on, and those who do, do not check it on a regular basis. So, even if an attacker does not cover his tracks, he still has a low chance of detection.

The more sophisticated attackers will not take a chance and will go in and clean up the log files. There are two basic ways an attacker can cover his tracks in terms of a log file. The easiest way is to go in and delete the entire log file. This can set off a red flag if an administrator knows that the log file had a large number of entries, and suddenly, there are only a few

entries. Also, most systems put an entry in the log file after the file has been cleared or deleted. The second way an attacker can “doctor” the log files is to access the log file and only delete the entries that pertain to what the attacker did. Depending on which operating system is being attacked, this has various levels of difficulty. Because UNIX and NT environments handle logging differently, each will be covered in a separate section. In each section, we cover how auditing works, what an attacker can do to cover his tracks, and things you can do to protect against it.

Linux Log Files

This section is based on the RedHat Linux operating system. Although some of these commands are the same for different variants of UNIX, they might be different depending on the version of UNIX you are using.

On Linux-based UNIX systems, the audit information is kept in several files on the system. The main configuration file for the syslogd daemon that controls logging on Linux machines is /etc/syslog.conf. This file controls most of the logging for applications, such as mail and news, and some standard systems messages. Some of these files are in ASCII format (readable text) and can be edited by hand. From a system and access standpoint, the more sensitive files are logged to standard binary files, which means the content can only be viewed using special programs. The following are the five main files used for logging on a Linux system:

•/var/run/utmp— Tracks who is logged into the system.

•/var/log/wtmp— Tracks who has logged in and out of the system.

•/var/log/btmp— Tracks failed logon attempts.

•/var/log/messages— Keeps messages reported from the syslog facility.

•/var/log/secure— Tracks access and authentication information.

Let’s briefly look at each of these files and show what type of information is stored in each and how the data is accessed.

UTMP

UTMP keeps an active log of users who are currently logged into the system. When a user logs on, an entry is added to the UTMP log, which contains the username, terminal, login time, and remote host from which the user is logging in. When the user logs off the system, the entry is removed from the UTMP log. This is important to remember: UTMP only shows users who are currently logged on, it does not show everyone who has been logged into the system. If a user has logged off the system, he will not appear in this log file.

Programs for Accessing UTMP One issue with the UTMP log file is that it is a binary file, which means an administrator cannot directly access it. This can also be a plus because it makes it more difficult for an attacker to manipulate it. Because it is a binary file and cannot be accessed directly, you have to use a program that is supplied with the operating system. There are three common programs that are supplied with the operating system: who, users, and finger.

Who is a program that comes with Linux, which shows you who is logged onto the system. To run it, open a terminal window and type the following command:

who --idle --heading --lookup

The following is what each argument does:

•idle— Adds the information about how long the user has been idle or inactive in hours and minutes. If it has been a long time, then the word old appears instead.

•heading— Prints the column heading at the top of the listing, so you can see what each column is displaying.

•lookup— Attempts to lookup hostnames through DNS and displays the IP addresses.

The following is the output from running the previous command:

Now in this case, if you are the administrator of this machine and the only person with root access, this listing should look very suspicious. Looking at the last two lines, there is a remote user who logged on as eric, and there is also a second connection from the same machine, where the person is logged in as root. Because you are the only one with root access, it looks like someone compromised the machine and gained root access. Also, in this case, because the non-privileged user logged in before the privilege session started, this is probably an example of a privilege escalation attack.

A privilege escalation attack is where the attacker initially gains some access and then uses it to increase his access to root.

By issuing the following command, you will get a list of users who are currently logged on to the machine. It is a very basic command with only two possible options:

•help— Displays basic help information.

•version— Displays information on which version of the command you are running.

To run the command, type users from a terminal window. The following is the output:

[eric@seclinux1 log]$ users eric eric root root

As you can see, in most cases, the who command provides much more detail. In cases where you just want to verify that only certain users are logged on, then the users command might be easier to work with. To find out additional information on the users command, you could also type

info users.

The finger command displays information about which users are currently logged on to the system and is similar to the whois command. To run the command to find out information about currently logged on users, issue the following from the command window:

Finger –s

The –s option indicates that the finger command should display the user’s login name, real name, terminal name, write status, idle time, login time, office location, and office phone number. The following is the output from running the finger command:

As you can see, the output is very similar to the who command output, except that you are provided some additional information, such as name and office information, if it is available.

Another useful command-line option with the finger command is the –l option. This option produces a multi-line format, which displays all the information described for the -s option as well as the user’s home directory, home phone number, login shell, mail status, and the contents of the files .plan, .project, and .forward from the user’s home directory. Some of this information can be useful in figuring out whether or not a legitimate user is logged on. The following is the output from running finger –l:

Last login Sat Aug 5 04:25 (EDT) on 2 from 207.159.90.18 No mail.

No Plan.

WTMP

The WTMP log is very similar to the UTMP except that it keeps a record of all users who have logged in and have logged out of the system. In some cases, this is more valuable then UTMP because you can get a view of everyone who has accessed the system, even if they are no longer logged on. Depending on the installation options and the version of Linux you are running, the WTMP file does not always exist. If this file is not present, then the information will not be logged. If the file is present, then that is all you need to turn the logging on. To determine if the file is present, type ls/var/log/wtmp. If the following message appears, then WTMP is present:

[eric@seclinux1 log]$ ls /var/log/wtmp /var/log/wtmp

If WTMP is not present, then the following message appears:

[eric@seclinux1 log]$ ls /var/log/wtmp

ls: /var/log/wtmp: No such file or directory

In the case where it is not present, you can create the file and begin logging by typing this command: touch /var/log/wtmp. You should then verify whether the correct permissions are set for the file. In most cases, only root should have access to the file. To view the file permissions, type ls –l /var/log/wtmp. To change the permissions, use the chmod command. For example, to only give full root access to the file, type chmod 700 /var/log/wtmp. This enables someone with root access to have read, write, and execute permissions on the file, but anyone else does not have access to the file.

Program for Accessing WTMP To access the WTMP file, you need to use the last command because it is a binary file. This command displays a lot of detail and can be used to show every user who has logged on, only the last x users who were logged on, or information about a particular user ID. For example, if you think a particular user ID has been compromised, you can look for account activity to see whether any unusual behavior is occurring.

The last command searches through the WTMP file looking for all users who have logged in and logged out since the creation of the file. Users who are still logged in will also be displayed. The following is the output from issuing the last command:

wtmp begins Tue Aug 1 06:57:27 2000

The last command also has various options that can be used to change the order in which the columns are displayed. The last command is very useful in determining who has accessed your system, where they came from, and how long they were connected.

BTMP

From a security standpoint, not only are we concerned with successful log on attempts, but we are also concerned with failed log on attempts. Failed log on attempts could indicate that someone is trying to access a system but is in the initial stages and is still not successful. This is the time to catch an intruder—before he becomes successful. After he successfully gains access, it will be much harder. Records of bad log on attempts are kept in the file BTMP, which stores similar information to UTMP and WTMP.

Just like with WTMP, you have to check to make sure the file is created for logging to work. On the Linux 6.2 box I am using, when I tried to access the BTMP file, I received the following message:

[eric@seclinux1 log]$ lastb

lastb: /var/log/btmp: No such file or directory

I then issued the command ls /var/log/btmp and, sure enough, the file was not created. To determine if the file is present, type ls /var/log/btmp. If the following message appears, then it is present:

[eric@seclinux1 log]$ ls /var/log/btmp /var/log/btmp

If it is not present, then the following message appears:

[eric@seclinux1 log]$ ls /var/log/btmp

ls: /var/log/btmp: No such file or directory

In the case where it is not present, you can create the file and begin logging by typing the following command: touch /var/log/btmp. You should then verify that the correct permissions are set for the file.

Program for Accessing BTMP Just like with the other files, BTMP is a binary file and cannot be directly accessed. Therefore, you must use a tool to access the file. The program you use is lastb.

To access the BTMP log and to determine any failed log on attempts to the system, you use the lastb command. The following is the output after typing this command:

This program can provide very useful information, if someone is trying to attack your system. In this case, this file would look very suspicious because there are no accounts created on the system called Karen, Bill, Sally, or Mike, which means someone is just randomly trying common names with common passwords, to see if they get a match. Each of the lines in the above log file show a different user trying to connect to the machine. If a line contains a valid user account, such as eric, that is one thing. However, when you compare this readout to a list of valid account names and find several accounts that do not exist on your system attempting access, something is wrong.

Also, it is important to combine the results of BTMP with WTMP. Otherwise, you do not know whether an attacker successfully gained access. For example, in the previous output for BTMP, there were two failed log on attempts for the user eric. By only looking at BTMP, we do not know whether the attacker became tired and moved on to the next account or if he successfully guessed the password and gained access. Only by comparing or combining BTMP and WTMP together can you get a clear picture of what is occurring on your network.

Messages

By default, the standard logging facility on UNIX machines is syslog, and /var/log/ messages are where any syslog generated messages appear. The syslog contains a variety of messages ranging from what daemons have been started on the system to what actions users have performed. It is useful to look through the syslog when there are unusual events occurring or just to check the security of your system. The following is a small portion of a /var/log/message file:

[root@seclinux1 log]# more messages