“ Hackers Beware “ New Riders Publishing 650 Jul 30 04:02:01 seclinux1 syslogd 1.3-3: restart. Jul 30 04:02:01 seclinux1 syslogd 1.3-3: restart. Jul 30 04:02:01 seclinux1 syslogd 1.3-3: restart. Jul 30 04:02:05 seclinux1 PAM_pwdb[3637]: (su) session opened for user news by ( uid=0) Jul 30 04:02:05 seclinux1 PAM_pwdb[3637]: (su) session closed for user news Jul 30 04:22:00 seclinux1 anacron[3692]: Updated timestamp for job `cron.weekly' to 2000-07-30 Jul 30 04:59:06 seclinux1 PAM_pwdb[9788]: (login) session opened for user eric b y (uid=0) Jul 30 05:43:19 seclinux1 ftpd[9839]: FTP LOGIN FROM 10.159.90.18 [10.159.90.1 8], eric Jul 30 06:19:43 seclinux1 ftpd[9839]: User eric timed out after 900 seconds at S un Jul 30 06:19:43 2000 Jul 30 06:19:43 seclinux1 ftpd[9839]: FTP session closed Jul 30 06:19:43 seclinux1 inetd[576]: pid 9839: exit status 1 Jul 30 07:47:51 seclinux1 inetd[576]: pid 9787: exit status 1 Jul 31 04:02:00 seclinux1 anacron[10493]: Updated timestamp for job `cron.daily' to 2000-07-31 Jul 31 04:02:03 seclinux1 PAM_pwdb[10602]: (su) session opened for user news by (uid=0) Jul 31 04:02:03 seclinux1 PAM_pwdb[10602]: (su) session closed for user news 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. “ Hackers Beware “ New Riders Publishing 651 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: [root@seclinux1 log]# more secure Jul 30 04:59:02 seclinux1 in.telnetd[9787]: connect from 10.159.90.18 Jul 30 04:59:06 seclinux1 login: LOGIN ON 1 BY eric FROM 10.159.90.18 Jul 30 05:43:08 seclinux1 in.ftpd[9839]: connect from 10.159.90.18 Aug 1 06:57:22 seclinux1 in.ftpd[11292]: connect from 10.224.87.89 Aug 2 03:39:42 seclinux1 in.ftpd[11667]: connect from 10.246.68.46 Aug 3 05:38:08 seclinux1 in.ftpd[12456]: connect from 10.246.68.46 Aug 3 05:38:58 seclinux1 in.ftpd[12457]: connect from 10.246.68.89 Aug 3 09:10:07 seclinux1 in.ftpd[12526]: connect from 10.50.158.38 Aug 3 09:40:16 seclinux1 in.ftpd[12533]: connect from 10.101.38.169 Aug 5 04:21:09 seclinux1 in.telnetd[13626]: connect from 10.159.90.18 Aug 5 04:21:13 seclinux1 login: LOGIN ON 1 BY eric FROM 10.159.90.18 Aug 5 04:25:11 seclinux1 in.telnetd[13695]: connect from 10.159.90.18 Aug 5 04:25:15 seclinux1 login: LOGIN ON 2 BY eric FROM 10.159.90.18 Aug 5 04:40:29 seclinux1 in.telnetd[13760]: connect from 10.159.90.18 Aug 5 06:44:48 seclinux1 in.telnetd[13975]: connect from 10.159.90.18 Aug 5 06:45:23 seclinux1 in.telnetd[13978]: connect from 10.159.90.18 Aug 5 06:50:05 seclinux1 in.telnetd[13982]: connect from 10.159.90.18 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 “ Hackers Beware “ New Riders Publishing 652 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 “ Hackers Beware “ New Riders Publishing 653 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: [eric@seclinux1 eric]$ ls -l /var/log/*tmp -rw-rw-r 1 root root 3072 Aug 5 06:50 /var/log/btmp -rw-rw-r 1 root utmp 4608 Aug 5 07:20 /var/log/wtmp 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: [eric@seclinux1 eric]$ ls -l /var/log/*tmp -rw 1 root root 3072 Aug 5 06:50 /var/log/btmp -rw 1 root utmp 4608 Aug 5 07:20 /var/log/wtmp “ Hackers Beware “ New Riders Publishing 654 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: -rwxrwxrwx 1 root utmp 4608 Aug 5 07:20 /var/log/wtmp 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: -rwxr-xr 1 root utmp 4608 Aug 5 07:20 /var/log/wtmp 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 “ Hackers Beware “ New Riders Publishing 655 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 “ Hackers Beware “ New Riders Publishing 656 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. “ Hackers Beware “ New Riders Publishing 657 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. “ Hackers Beware “ New Riders Publishing 658 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 “ Hackers Beware “ New Riders Publishing 659 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: drwxr-xr-x 4 root root 4096 Jun 23 07:28 skel -rw-r r 1 root root 10731 Feb 25 09:59 smb.conf -rw-r r 1 root root 97 Feb 25 09:59 smbusers drwxr-xr-x 2 root root 4096 Feb 17 17:51 smrsh drwxr-xr-x 3 root root 4096 Feb 21 16:41 sound drwxr-xr-x 2 root root 4096 Jun 23 07:24 squid drwxr-xr-x 7 root root 4096 Jun 23 07:27 sysconfig -rw-r r 1 root root 267 Mar 8 11:26 sysctl.conf [...]... LINNT BD980211 RAWRITE IMAGE DEPLOY IPEYE DAT TXT BAT 7, 798 2,665 291 JPG HTM 27,722 7,416 05-14 -99 11:00a SUHDLOG.DAT 09- 28 -99 12:56a FRUNLOG.TXT 04-16-00 9: 16p AUTOEXEC.BAT 12-20 -99 3:12p Palm 12-21 -99 5:34a ERIC014.jpg 12-21 -99 5:53a Eric Cole's Home 7,416 27,722 1,101,436 14, 291 230 3,488 13,256 8 19, 200 1,382,3 39 1,474,560 13,052 2,002,304 155, 699 32,768 12-21 -99 12-21 -99 01-07-00... 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 “ Hackers Beware “ New Riders Publishing 662 From an attacker’s standpoint, their goal is to hide the fact... 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. .. in the first place, then he can’t compromise your network Covert TCP “ Hackers Beware “ New Riders Publishing 665 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. .. to the BIND 8.2 NXT exploit as well as to other buffer “ Hackers Beware “ New Riders Publishing 6 69 overflow attacks Stack memory is the type of memory that programs use to store the function’s local variables and parameters An important concept regarding stack memory exploitation is related to the return pointer The return pointer contains the address of the place in the calling program to which the. .. are not executed, hackers will use them to create a wide area to return to from a called function The hope is that the series of NOPs will overwrite the return address of the calling function The command the hacker hopes to execute will follow the NOPs If all goes well in this type of exploit, the program calls a function During the execution of the function, the hacker overflows the buffer with a... 00 00 74 68 69 73 69 70 73 70 61 63 65 66 6F 69 6E 61 64 64 72 69 6E 69 6B 6E 6F 77 74 68 69 75 74 61 6E 79 77 61 79 68 6F 72 69 7A 6F 6E 67 69 6E 67 73 6F 61 6C 6C 5E 56 8D 46 08 50 8B 46 “ Hackers Beware “ New Riders Publishing 674 SNORT A White Paper, authored by Lance Spitzner, “Know Your Enemy: A Forensics Analysis” focuses on how SNORT was used as a forensics tool to piece together the actions... by the web browser Its contents are established by the web site by preceding the stored data with a Set-Cookie header, which instructs the browser to store the data on the client system On the client side, whenever a request is made to connect to a web site, the browser checks to see if it has any cookies for that site If it does, the contents of the web site’s cookie are expanded and returned by the. .. Initial visit by the client to initiate how the cookie exploit works Figure 17.3 Client returns to the machine to finish the cookie exploit “ Hackers Beware “ New Riders Publishing 6 79 Signature of the Attack There is no particular signature to buffer overflow attacks Often times they contain a long string of the same character because the hacker does not care if the data that floods the buffer is valid or... relevance to the this exploit Earlier versions of DNS were regarded as insecure because there was no ability to authenticate name servers In an “ Hackers Beware “ New Riders Publishing 668 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 . Directory of C: SUHDLOG DAT 7, 798 05-14 -99 11:00a SUHDLOG.DAT FRUNLOG TXT 2,665 09- 28 -99 12:56a FRUNLOG.TXT AUTOEXEC BAT 291 04-16-00 9: 16p AUTOEXEC.BAT PALM <DIR> 12-20 -99 3:12p. 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. 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