Hackers Beware

The message file is ASCII-based and can be viewed by typing the more /var/log/ messages command. You can also use the grep command to find activities that contain a certain key word. For example, if I want to see anything that was done by user John, I would type the following command: moremessages | grep john. The following is the output:

[root@seclinux1 log]# more messages | grep john

Aug 5 06:44:55 seclinux1 PAM_pwdb[13976]: authentication failure; (uid=0) -> jo

hn for login service

Aug 5 06:44:56 seclinux1 login[13976]: FAILED LOGIN 2 FROM 10.159.90.18 FOR john,

Authentication failure

In this case, John had several failed logon attempts. It is important to note that you need root access to view the messages file.

Secure

The following log file is ASCII text and can be read with the more command. It contains information about any connections that were made to the box and where they came from. This is sometimes a good starting point to see if anyone from an unknown location is accessing the machine. The following is the output from the file:

Attacker’s Standpoint

We have just covered the key log files in UNIX and what information they store. Remember, the goal of an attacker is to cover his tracks. If these files stay untouched after an attacker accesses the system, they provide

an easy tool for an administrator to determine that unauthorized access was gained and what the attacker did. Therefore, from an attacker’s standpoint, he wants to clean up the files and hide what he did. With the ASCII files, the attacker can directly access the files but he needs to have the proper permissions. Both the messages and secure log file allow only root access, which makes it harder to accomplish. With the binary files, the attacker cannot directly read these files, however, he can always delete them if he has proper authority. Based on this information, it seems like it might be hard for an attacker to cover his tracks, but unfortunately for us, there are several programs available that help an attacker clean up the log files. Most of these programs are available from ftp://ftp.technotronic.com/unix/log-tools. The following is a listing of several of these programs:

•Chusr.c— Can be used to clear an entry from the UTMP file.

•Cloak.c— Wipes away all presence of a user on a UNIX system.

•Cloak2.c— Newer version of cloak that performs a better job of cleaning up WTMP and UTMP files.

•Displant.c— Cleans up and removes all traces from a UTMP file.

•Hide.c— Cleans up and removes all traces from a UTMP file.

•Invisible.c— Hides the attacker’s traces as root on a system.

•Lastlogin.c— Removes the last log on for a particular user.

•Logcloak.c— Another rewrite of cloak.

•Logutmpeditor.c— Edits entries in the UTMP file.

•Logwedit.c— Cleans up and removes all traces from the WTMP file.

•Marry.c— Removes entries and cleans up log files.

•Mme.c— Enables you to make changes and remove entries from the UTMP file.

•Remove.c— Removes entries from UTMP, WTMP, and lastlog files.

•Stealth.c— Cleans up and removes entries from UTMP files.

•Ucloak.c— Another version of cloak that removes all presence of a user.

•Utmp— Removes UTMP entries by name or number.

•Wtmped.c— Enables you to overwrite the WTMP file with one of your choosing.

•Zap.c— Remove entries from WTMP and UTMP file.

•Zap2.c— An updated version of zap.

As you can see, there are several programs that attackers can use to hide their tracks from the log files in UNIX. Some of these programs have been around for a while and might require modifications to work on certain systems. From an administrator’s perspective, all is not lost. We will look at some things you can do to minimize the chance that someone can modify your log files and hide their tracks.

Protecting UNIX Log Files

We have covered the key log files and what an attacker will do to try to cover his tracks. Now we will shift our attention to things you can do to protect your log files from being modified. Remember, if an attacker can successfully modify the log files and hide his tracks, then he wins. If you can carefully guard your log files, so attackers cannot successful modify your files, and you can detect what they have done on your system, then you win. When it comes to security, the saying, “It doesn’t matter if you win or loose but how you play the game” does not hold true. It is all about winning and staying in business.

The following are some of the key things that can be done to protect your log files:

•Set proper permissions on log files.

•Use a separate server.

•Make regular backups of the log files.

•Use write once media.

•Encrypt the log files.

•Review the log files on a regular basis.

Set Proper Permissions If someone does not have permission to access or read a file, it makes it much harder for them to delete or modify it. If possible, read and write access should be limited to root. This way, unless an attacker gains root access, he will have a much harder time accessing the files. If an attacker does gain root access, then you have other problems, but the other steps listed in this section will help you protect against that threat. To see what permissions are assigned to a file, issue the ls-l command followed by the file name. The following is the output when I type ls –l/var/log/*tmp:

In this case, root and the group root belongs to has read and write access, and the world has read access. Ideally, you want the permissions to be:

This way, only root has access. In UNIX, the file permissions consist of three sets of permission symbols, and each set has three letters. The first set is the owner of the file, the second set is the group the user belongs to, and the third set is everyone else. Each set has three possible options for access: r, which is read, w, which is write, and x, which is execute. If everyone had full access, then the permissions would read:

To remove access, you just replace the letter with a– (dash). So, if we wanted to give the owner, which is root in this case, full access, the group it belongs to read and execute permissions, and everyone else read permissions, the access would look like the following:

When you change permissions on a file, you have to be very careful that the system still works. If a key process or daemon cannot access a file that it needs to run, the system might not work properly.

Use a Separate Server A fairly easy yet effective way to protect your system is to use a separate server to store your log files. This way, if an attacker breaks into your system, he would not be able to change the logs because they are stored on a different system. He would have to break into a separate system to change the logs. The more systems an attacker has to break into the harder it is. Also, if you combine this with several of the other steps in this section, you would still be able to determine what an attacker has done.

There are some companies that use what is called a honey pot. A honey pot is a system that is setup to lure attackers into your system, so a company can watch what they are doing. It could also be used to lure attackers away from a company’s sensitive resources. I have found that anything that is used to draw attackers to a company’s site and raise their visibility with attackers is a bad thing, but your mileage might vary.

Make Regular Backups Not only should your key data be backed up on a regular basis, but your system logs should also be backed up. If an attacker can go in and delete a weeks worth of logs and there is not backup, you could loose a lot of valuable information. I like to backup the log files to several places across the network and some on removable media. This way, the chance of all of them getting destroyed is low. The other reason I do this is for consistency checks. There is a good chance

that if an attacker tries to cover his tracks, he might miss one of the files. This is especially true if you do a chain backup where you backup system A to system C, D, and E, and then system C backs up those same logs to system F, and so forth. Now an attacker has to be very careful to make sure he gets all the copies. If he misses one and you periodically run a check against all the files to make sure they are the same and one is different, you have a really good idea that there is a problem.

Use Write Once Media Ideally, you want to send your log files to write once media. This is media that can only be written to once, and there is no way to delete the information after it is written. If the log files are written as soon as they are created, this makes it much more difficult for an attacker to go back after the fact and destroy the log files. What some attackers do is as soon as they compromise the system, they immediately turn logging off, so even if it goes to a write once media, there is nothing to be written. In such cases, it is very important that you review your logs carefully looking for unusually behavior or lapses in the log file, which could indicate that logging has been turned off. I know of a couple of companies that have printers to which all their logs get printed. This way, from a legal standpoint, there is no doubt in anyone’s mind that these events really happened. Also, unless an attacker has physical access, it makes it virtually impossible for them to change the logs.

Encryption If you encrypt the log files on the fly, then it is almost impossible for an attacker to modify the files. Because the key is not stored on the system, the only way to break the encryption is to brute force it, and we know that is no trivial task. One of the key points with encryption is that it does take additional processing power. Also, you have to make sure you keep the key secure with limited access. On the other hand, you want to make sure enough people have access to it, so just in case someone loses it or leaves the company, you are not left with a bunch of encrypted files that no one can access. I was involved in a case where all we had were encrypted files and no way to decrypt them. Trust me, it is very hard to convict someone on this type of evidence.

Review the Log Files We have covered several steps that should be taken to protect your log files, but they are all useless unless you have some system in place to review the log files. What good is having log files if you never look at them or review them? You must review the log files on a regular basis, looking for any unusual activity and taking necessary actions.

The one key point of this section is that you have to perform most, if not all, of these steps to protect your log files. If you only do one of these steps, it is better than nothing, but not ideal. The more things you do to preserve your log files, the better chance you have of detecting an attack. Remember defense in depth. No single mechanism will protect your

network, but by combining multiple measures together, you have a much better chance of having a secure network.

NT Logging

NT system logging is done through the NT Event Logger. The NT Event Logger keeps three separate logs: system, security, and application. Each log is stored in a separate file, but they are viewed through the same program. NT creates two sets of files during its logging process. It creates

.log files, which are buffer files that contain the most recent events. Periodically, these buffer files are written to .evt files, which is what the event log viewer uses. Based on this, the following are the files used by NT in logging:

•system.log

•security.log

•application.log

•sysevent.evt

•secevent.evt

•appevent.evt

To show you how this process works, let’s use the Event Viewer, which is located under administrative tools. Figure 16.1 shows the main screen in Event Viewer.

Figure 16.1. Main screen for EventViewer.

This screen can be used to view the three different types of audit files that NT maintains.

The system enables you to delete the .log files but not the .evt files. Figure 16.2 shows the message that is received when you try to delete the sysevent.evt file.

Figure 16.2. DOS window showing the error message when trying to delete an

.evt file.

Also, it is important to note that Event Viewer is not very functional for processing large numbers of log files. In such cases, dumpel.exe can be used to create an ASCII copy of the Event Viewer log files. This way, the logs can be processed with Perl scripts or imported into a database program for easier analysis.

Attacker’s Standpoint

From an attacker’s standpoint, there are fewer things that can be done to cover his tracks in NT. Very recently, programs have been released that enable an attacker to modify the log files while the system is running. One such tool is Clear Event Log 1.0. This is a tool designed to clear the system, application, and security event logs. The program clears either one or all of the event logs as specified on the command line. This program clears the entire log. The command-line syntax is clearEL <log>. Replace log with either system, application, security, or all. This tool is found at http://duke.net/eventlog. With this tool, however, an attacker cannot selectively remove certain entries; it deletes the entire log. To selectively remove entries, WinZapper can be used.

WinZapper is a tool that an attacker can use to erase event records selectively from the Security Log in Windows NT 4.0 and Windows 2000. The tool can be downloaded from http://ntsecurity.nu/toolbox/winzapper/. To use the program, the attacker downloads the zip file and extracts the files. To run the program, the attacker runs winzapper.exe and marks the event records to be deleted, then he presses “Delete events and Exit”. Next, he reboots Windows to re-enable the event logging system. (He can’t use the Event Viewer again before rebooting.) Figure 16.3 shows the main screen for WinZapper.

Figure 16.3. Main screen for WinZapper.

Even without access to these programs, the attacker still has some things he can do to cover his tracks. First, with administrative access, it is simple to turn auditing off. A hacker could just use “user manager for domains” or a command-line utility. He could also pull up Event Viewer and clear the logs. The only drawback to that is that an entry stating the logs have been cleared is posted in the audit file. So, if someone is watching, it could tip your hand. As you can see, these type of actions are not very sophisticated.

As we have seen in the previous section, an attacker cannot delete the event file because the NT system is running, but if he has physical access, there are some things he could do. First, as soon as he gets access, he would copy the event files because at this point they have minimal information about the attack. He would than run the attack. After he is done, he would boot the machine into Linux or another operating system. At this point, because the NT system is not running, he could delete the event files and replace them with the copy that he made, which contains minimal evidence of his attack. This does require rebooting, but it is not beyond the scope of a determined attacker. A program that can be used to create a Linux boot disk can be found at http://home.eunet.no/~pnordahl/ntpasswd/bootdisk.html.

Also, linnt is a great program for modifying passwords or other information on an NT system. Linnt creates a Linux-bootable floppy that allows access to the NT system.

Protecting NT Log Files

A key way to protect NT log files is to limit physical access to the machine. One of the few ways that an attacker can access the log files is if he can reboot the machine. If he cannot gain physical access, then he cannot do this. Most of the same things you do to protect UNIX log files, you would

do to protect NT audit files. The following are some of the key things you can do to protect NT log files:

•Set proper permissions on log files.

•Use a separate server.

•Make regular backups of the log files.

•Use write once media.

•Encrypt the log file.

•Review the log files on a regular basis.

There are also various third-party tools that enable NT to support syslog and, therefore, make it easier to send the log files to a separate server. Two main products are:

•SL4NT at http://www.netal.com/sl4nt.htm

•Kiwi’s syslog at http://www.kiwi-enterprises.com

I have found that if you have both NT and UNIX machines sending all your audit data to the same machine, it makes it easier to administer.

File Information

File information can provide another key that someone has gained unauthorized access to a system. In most cases, when an attacker puts in a backdoor he has to modify some key system files. The thing to remember is that there are files on a machine, regardless of the operating system, that are critical for the operating system to work properly, and they should never be changed. To put in a backdoor or gain access, an attacker sometimes has to modify these files. Therefore, it is critical that if an attacker wants to cover his tracks, he has to make sure he hides this fact.

Let’s briefly look at some of the file information that has to be changed. The following is a file listing from a UNIX machine: