10.2 Postattack Cleanup

 <  Day Day Up  >  

The first step after an attack (exploiting the machine and making sure you can access it later) is cleaning up. What needs to be hidden or at least swept under the rug, on a typical Unix machine being exploited over the network via a remote hole? Here is a short checklist.

10.2.1 System Logs

As described in previous chapters, Unix systems log to a set of plain-text logfiles via the syslog daemon. Depending upon how the machine was exploited, its platform (Solaris, FreeBSD, Linux, etc.), and the level of logging that was enabled, there might be evidence of the following events.

10.2.1.1 The exploit attempt itself

Consider, for example, this tell-tale sign of a Linux RPC hit:

 Oct 19 05:27:43 ns1 rpc.statd[560]: gethostbyname error for  ^X ^X ^Z ^Z %8x%8x%8x%8x%8x%8x%8x%8x%8x%62716x%hn%51859x%hn0000\ 22000000000000000000000\ 22000000000000000000000\ 22000000000000000000000\ 22000000000000000000000\ 22000000000000000000000\ 22000000000000000000000\ 22000000000000000000000\ 22000000000000000000000\ 22000000000000000000000\ 22000000000000000000000\ 2200000000000 

The above attack was very common in 2000-2001 and still surfaces in the wild reasonably often. The attacker aims to overflow the buffer in the rpc.statd daemon (part of Unix RPC services) on Linux in order to gain root access. While both successful and failed attacks register in the logs as shown above, the example log signature was generated on a nonvulnerable server.

10.2.1.2 The attacker's accesses before the exploit

Did you snoop around that FTP server before exploiting it? If so, look for the following and clean it up:

 Oct 15 19:31:51 ns3 ftpd[24611]: ANONYMOUS FTP LOGIN FROM 218.30.21.182 [218.30.21. 182], hehehe@ Oct 15 19:33:16 ns3 ftpd[24611]: FTP session closed 

The attacker had to log in to the FTP server in order to launch a privilege escalation attack, which required local privileges. Thus, an access record similar to the above will appear in the logfile, right before the attack.

10.2.1.3 Erasing logfiles

System logs include more than the obvious /var/log/messages or /var/adm/syslog . Make sure you also look through all the /var/log directories for signs of your IP address or hostname. In fact, it makes sense to look for /etc/syslog.conf to confirm what is being logged and where.

Sometimes, a devious system administrator might rebuild a syslog daemon to not refer to the usual configuration file ( /etc/syslog.conf ), but rather to use a cover file instead (or to use both). In this case, snooping can find the location of those alternative logs. Killing the system daemon (as performed by most modern Unix rootkits upon installation) is a good common-sense "security" measure. That is, it adds security to a covert access of a target system. However, if an exploit attempt itself is logged to a remote log server, it might be too late to kill the daemon ”the tell-tale signs are already recorded in the safe location.

Cleaning plain-text logs does not require any sophisticated tools. A text editor, right down to command line-based sed or awk, will do. Table 10-1 lists the available options in more detail, in order of increasing detection difficulty.

Table 10-1. Logfile cleansing actions and countermeasures

Attacker action

Defense countermeasures

Logfiles erased

Highly visible; at least some part might be unerased using raw access to the filesystem, unerase tools (where available), or simple forensic tools

Logfiles wiped (zeroed on disk)

Highly visible; traces might still be found in swap

Logfiles edited and saved

Not very visible (unless a large time period is absent from a logfile); parts might be unerased using raw access to the filesystem, unerase tools (where available), or simple forensic tools

Logfiles edited and appropriate parts zeroed on disk

Not very visible (unless a large time period is absent from a logfile); likely cannot be unerased if the wiping routing works as advertised

In real life, the most common scenario involves either the deletion or editing of logfiles without any additional effort on the attacker's part. Often, the filesystem implementation is somewhat on the attacker's side, and parts of the removed content are simply overwritten on disk by the subsequent disk activity.

10.2.2 Application Logs

Depending upon the location of the entry into the system, various application logs might contain evidence of sudden conquest , preliminary probing, and subsequent system accesses. The simplest example is an FTP log (usually located with other system logs) or web server log (for the case of Apache, usually stored in /var/log/httpd ). Here is an example of a recent SSL worm exploit hit in the Apache logfile:

 [Thu Nov 21 08:04:36 2002] [error] mod_ssl: SSL handshake failed (server ns1. bkwconsulting.com:443, client 24.199.239.142) (OpenSSL library error follows) [Thu Nov 21 08:04:36 2002] [error] OpenSSL: error:1406908F:lib(20):func(105): reason(143) [Thu Nov 21 08:04:37 2002] [notice] child pid 11175 exit signal Segmentation fault (11) 

The above signature was left on a vulnerable Red Hat Linux machine (a "honeypot") exploited by the SSL worm.

This evidence should be cleaned up much like standard Unix logs: simply remove any "suspicious" entries. Since the logs are text files on a disk, the above discussion about evidence removal applies here as well. Overall, if the files are not reliably zeroed out on the disk, there is a chance that the investigators might recover some parts or even the whole log.

10.2.3 Unix Shell History

Another critical evidence source is the Unix shell history . Most shells , such as sh (Free/OpenBSD standard), bash (common for Linux distributions), csh (common on Sun Solaris machines), and tcsh (modern incarnation of C shell), produce and save all executed commands in a shell history file (e.g., .bash_history or .history) by default. These files must be cleaned after a break-in. It is worthwhile to note that bash only writes a new session history upon the session exit; thus, erasing a history file during the session only removes old data, not the data from the currently running session. When the user logs in to the Unix system, his command shell session is started and the recording of the command-line history commences. When the user logs out or disconnects, the shell performs the act of writing the typed commands into a history file. Thus, erasing the file during the session will not have the desired effect of removing the traces of the connection.

Here is an example of a real-life bash shell session history left by a careless attacker on a honeypot:

 cd luckroot ls ./luckgo ./luckgo 66 22 ./luckgo 212 22 cd /blacki ls rm -rf luck.tar. clear uptime cd dos ./vadimI 10.10.10.10 ./vadimI 10.11.12.13 

The commands indicate that an attacker did a fair bit of exploit scanning (using the classic "luck" exploit scanner). He scanned two B-classes (around 128,000 IP addresses). Then he cleaned up some files (rm) and proceeded to "DoS the shiznat" out of his enemies using the antiquated but still deadly (for people with slow connections) UDP flooder "vadim".

It should be noted that even if the attacker's rootkit had removed those lines and disabled bash history, the covert bash monitoring software would have recorded them and sent them to the system for analysis. Thus, the tips outlined below still would not have worked.

Overall, dealing with shell history involves two actions:

  • Preventing its generation

  • Removing existing history

Table 10-2 is a summary of the above actions for commonly used Unix shells.

Table 10-2. Attacker cleanup on Unix shells

Shell

History prevention

History cleanup

bash (Linux)

export HISTSIZE=0

export HISTFILE=/dev/null

export HISTSIZE=0

rm .bash_history

tcsh (Linux)

set histfile=/dev/null

set savehist=0

rm ~/.history

csh (Solaris)

set history =0

rm ~/.sh_history

ksh (Solaris)

set HISTFILE=/dev/null

set HISTSIZE=0

 

Keep in mind that a shell might save the history file after the session is ended; thus, all manipulations of the history file should be done after the session is closed and a new one is opened. It might be wise to set the history file to /dev/null , then log out and erase the old one. Taking these steps assures that a new history is not generated.

Again, since history files are plain-text files located on a disk, the arguments from Table 10-1 apply. Erasing the files might hide them from some investigators, but those with forensic tools have an excellent chance of uncovering them. If higher "security" is desired, the files should be wiped by a wiping tool (simple) or edited with removed parts wiped from the disk (more complex).

10.2.4 Unix Binary Logs

As we will discuss in Chapter 18, Unix systems produce several kinds of binary logs. These are divided into process audit records and login records . The former needs to be enabled on most Unix systems, while the latter are always generated. Many hacker tools are written to " sanitize " login records, which means covertly removing undesirable, implicating records. Common examples of such tools are zap , clear , and cloak .

These tools operate in two distinct ways: they either zero out/replace the binary log records ( stuffing the file with zero records, which is suspicious) or they erase them (making the logfile shorter, which is also suspicious). Both methods have shortcomings, and both can be detected .

Here is how the zap tool zeros out login records in /usr/adm/lastlog on Solaris:

 if ((f=open("/usr/adm/lastlog", O_RDWR)) >= 0) {     lseek(f, (long)pwd->pw_uid * sizeof (struct lastlog), 0);     bzero((char *)&newll,sizeof(newll));     write(f, (char *)&newll, sizeof(newll));             close(f);         } 

Note the commands bzero and write , which do the trick. This code excerpt is quoted from http://spisa.act.uji.es/spi/progs/codigo/ftp.technotronic.com/unix/log-tools/zap.c.

Here is how the cloak tool accomplishes the same goal:

 lseek(fd, size*getuid(), SEEK_SET); read(fd, &l, size); l.ll_time = 0; strncpy(l.ll_line, "ttyq2 ", 5); gethostname(l.ll_host, 16); lseek(fd, size*getuid(), SEEK_SET); 

Notice the use of read and strncpy . This example is quoted from http://spisa.act.uji.es/spi/progs/codigo/ftp.technotronic.com/unix/log-tools/cloak.c.

A nice tutorial on how such tools work is available at http://packetstormsecurity.nl/Unix/penetration/log-wipers/lastlog.txt. This tutorial covers the design and implementation of one log cleaner, with full commented source code in C.

Other tools sometimes can replace the telltale records with supposedly innocent information, but it's easily discovered if a defender knows what to look for.

Overall, few of the tools commonly seen in the wild actually make an effort to make erased logs harder to recover, in part because the disk area where logs are stored has a high chance of being overwritten. In fact, it might be easier to erase the records and then generate a lot of innocent-looking log data in order to flush the disk with it. One log-erasing tool is shroud (http://packetstormsecurity.nl/Unix/penetration/log-wipers/shroud-1.30.tgz). It erases various logs and uses one of the reliable deletion programs (van Hauser's srm) to try to destroy them on disk. Similarly, tools exist that clean process audit records (e.g., acct-cleaner).

Here is an example of some malicious activity recorded by Unix process audit:

 crack           badhacker    stdin     99.90 secs Wed Nov 20 20:59 

It shows that an attacker used the password-cracking crack tool to break passwords. Obviously, if the tool had been renamed , the process audit records would not have shown any mischief.

10.2.5 Other Records

Other records might also be generated on the system. Here is the trick to find them ”it should be done as "root". root access is needed anyway to "correct" the audit records of your presence.

Upon login, create a file using touch /tmp/flag . Then, right before you are about to leave the machine, run find ~ - newer /tmp/flag -print . This command shows files that have changed since your login.

To dig deeper and look for files changed right before the login, mark the time that your session started and run find ~ -mmin 5 -print (if it started five minutes ago or less). These tips are from van Hauser's "HOW TO COVER YOUR TRACKS" guide, available online. Unix systems keep track of timestamps by default; thus, these commands are almost guaranteed to work.

 <  Day Day Up  >  


Security Warrior
Security Warrior
ISBN: 0596005458
EAN: 2147483647
Year: 2004
Pages: 211

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net