Task I - Detecting Backdoors on a System.

The following task requires that you work with a partner. One of your hosts will be "compromised" with some back doors. Another will be a "clean" system. The instructor will designate which host is compromised (denoted by an x) and which is clean (denoted by a y). Working with the clean system, you will attempt to locate as many backdoors as possible on the compromised system. 

1)Using the find command, check the compromised host for .rhosts files.

	[x] # find / -name .rhosts

2)Using the find command on both hosts, check the compromised host for SUID bits and character/block device files. Use the clean host as a baseline. Substitute "hostname" for your hostname.

	 # mkdir /var/tmp/diffs
	 # cd /var/tmp/diffs
	 # ls /usr/bin >> ls-bin.clean
	 # ls /usr/sbin >> ls-usrsbin.hostname
	 # ls /sbin >> ls-sbin.hostname
	 # find /usr -mtime -1 >> find-mtime-usr.hostname
	 # find /sbin -mtime -1 >> find-mtime-sbin.hostname
	 # find / -perm -4000 >> find-perm.hostname
	 # find / -type b >> find-type-b.hostname
	 # find / -type c >> find-type-c.hostname

3)Using the tar command, create an archive of the compromised server files and using the scp command, copy them over to the clean host. Since, the secure shell has remote root access disabled by default, use the account alice to transfer the archive to the clean host.
	
	[x] # cd /var/tmp/diffs
	[x] # tar cvf ../diffs.hostname.tar ./*
	[x] # su alice 
	[x] $ scp diffs.hostname.tar clean:/var/tmp
The authenticity of host 'clean' can't be established.
RSA key fingerprint in md5 is: 22:f4:85:bb:4f:f8:2a:3a:f5:9c:75:9c:be:26:8b:e4
Are you sure you want to continue connecting(yes/no)?yes
Warning: Permanently added 'clean,12.22.215.128' (RSA) to the list of known hosts.
diffs.hostname.tar   100%************************| 64000       00:00  

4)On the clean host, extract the archive directly into the /var/tmp/diffs directory.

	[y] # cd /var/tmp/diffs
	[y] # tar xvf ../diffs.hostname.tar
	
5)Perform a series of comparisons using the diff command to detect if any suid bit files or device files have been placed on the compromised host.
	[y] # diff find-mtime-usr.compormised find-mtime-usr.clean
	[y] # diff find-perm.compromised find-perm.clean
                80,81c80
	     < /sbin/lp
	     < /export/home/alice/.pinerc
	[y] # diff find-mtime-sbin.compromised find-mtime-sbin.clean 
	      1,2d0
	      < /sbin
	      < /sbin/lp
	[y] # diff ls-sbin.compromised ls-sbin.clean
	      12d11
	      < lp
	[y] # diff find-type-b.compromised find-type-b.clean
	[y] # diff find-type-c.compromised find-type-c.clean

	<<output ommitted>>

	     < /proc/533/fd/11
               < /export/home/bob/.netscpe

6) Answer the following questions:

What are the names of the SUID bit programs on the compromised host? The names are /sbin/lp and /export/home/alice/.pinerc.
What shell are the SUID bit programs copies of? /bin/ksh

[x] # ls -l /bin/ksh /sbin/lp   
-r-xr-xr-x   3 root     bin       201016 Apr  6 14:55 /bin/ksh
-r-sr-xr-t   1 root     other     201016 Sep 13 09:35 /sbin/lp

[x] # ls -l /bin/ksh /export/home/alice/.pinerc 
-r-xr-xr-x   3 root     bin       201016 Apr  6 14:55 /bin/ksh
-r-sr-xr-t   1 root     other     201016 Sep 13 09:36 /export/home/alice/.pinerc

What are the names of the block/character device files on the compromised host? /export/home/bob/.netscpe
What device does this file read? /dev/dsk/c0t0d0s0

[x] # ls -l /export/home/bob/.netscpe 
crwxrwxrwx   1 root     other    136,  0 Sep 13 09:52 /export/home/bob/.netscpe

Task - Installing the Command Line Solaris Fingerprint Database Utilities

In this task, you will configure the CLI to the Solaris Fingerprint Database. You will then submit md5 signatures via the sfpC.pl and sidekick.sh scripts to sunsolve.sun.com.

1)Check to see that the Solaris Fingerprint Database package has been installed. If not, install it.

	# pkginfo | grep SESsfp

If not installed:

	# cd /usr/local/pkg
	# pkgadd -d sfp*

2)Unpack the example root kit. DO NOT INSTALL IT. This rootkit is a test rootkit for study purposes. Installing it will ruin future exercises.

# cd /usr/local/pkg
# gzip sun2.rootkit.tar.gz
# tar xvf sun2.rootkit.tar
# cd sun2.rootkit

3)Generate md5 signatures for the valid netstat binary and the trojan netstat binary and redirect the output to a file called md5.txt

	# md5 /usr/bin/netstat >> ./md5.out
	# md5 netstat >> ./md5.out
	
4)Verify the signatures in the md5.out file.

	# more md5.out
	MD5 (netstat) = 2f4ec308b282c5c362e9fbd052b961f6
	MD5 (/usr/bin/netstat) = 95c907398946eb99655aca34e081aaa1

5) Submit the md5 signatures to the Solaris Fingerprint Database. Which fingerprint matched?

	# sfpC.pl md5.out

2f4ec308b282c5c362e9fbd052b961f6 - (netstat) - 0 match(es)

Not found in this database.

 95c907398946eb99655aca34e081aaa1 - (/usr/bin/netstat) - 1 match(es)


 canonical-path: /usr/bin/netstat
 package: SUNWcsu
 version: 11.8.0,REV=2000.01.08.18.12
 architecture: sparc
 source: Solaris 8/SPARC
 patch: 109906-06

7)Using the sfpC.pl script, generate signatures of /sbin on both the compromised host and the clean host from the previous task and submit them to sunsolve.sun.com. Use the grep filter to display only those binaries that did not have a matching signature.

	# md5 /sbin/* >> /tmp/md5.out
	# sfpC.pl /tmp/md5.out | grep "0 match"

Why didn't the /sbin/lp show as not having a match? Because the size and bits of the file have not changed. Only the name of the file has changed. 
The output below is the signature of the /sbin/lp binary. As you can see, the name of the file and the canonical-path name do not match. What conclusions can you draw from this? The Sunsolve Fingerprint Database can only detect file size attributes and not permissions or file names.

add15bc85df32635a6ea2b3cc42b1249 - (/sbin/lp) - 1 match(es)

 canonical-path: /usr/bin/ksh
 package: SUNWcsu
 version: 11.9.0,REV=2002.04.06.15.27
 architecture: sparc
 source: Solaris 9/SPARC

	

8)The sidekick.sh script enables you to automate the submission of md5 signatures. Execute the script with the -h option to view the list of automated signatures it checks.

	# sidekick.sh -h
	/usr/local/bin/sidekick.sh

    	-R new-root-dir          Specify an alternate root directory.
    	-r                       Find files commonly found in root kits.
   	-u                       Find files with the set-uid bit set.
    	-g                       Find files with the set-gid bit set.
    	-s                       Find files with the sticky bit set.
   	-U                       Find files with no valid user.
   	-G                       Find files with no valid group.
   	-a                       Find all files. warning: slow and many false 			    positives will ocure
   	-S                       Standalone mode.  sfpC will not be executed.
    	-h                       Display this message.



6) Using the sidekick.sh script, check your host for root kits. It is best to filter the results using the grep command to only show those signatures that did not match. These signatures that did not match could possibly be trojaned programs.

	# ./sidekick.sh -r | grep "0 match"

Task III - Using the chkrootkit program

In this task, you will use the chkrootkit program to automate the detection of rootkits on a server.

1)Check to make sure that the chkrootkit program is installed on your host.

	# pkginfo | grep SESchk

If it is not installed, install the package:

# cd /usr/local/pkg
# pkgadd -d chkrootkit*

2)The chkrootkit script runs a series of tests searching for many common rootkits. Execute the command with the -h option to view all of the options to the script.

	# chkrootkit -h
	Usage: /usr/local/bin/chkrootkit [options] [test ...]
	Options:
       	 -h                show this help and exit
        	-V                show version information and exit
        	-l                show available tests and exit
        	-d                debug
       	-q                quiet mode
        	-x                expert mode
        	-r dir            use dir as the root directory
        	-p dir1:dir2:dirN path for the external commands used by chkrootkit

3)Execute the chkrootkit in default mode on your host, having the script check it for rootkits.

	# chkrootkit
	ROOTDIR is `/'
	Checking `amd'... not found
	Checking `basename'... not infected
	Checking `biff'... not infected
	Checking `chfn'... not infected

	<<output ommitted>>

Task IV - Using Tripwire

In the following task, you will configure the tripwire utility to monitor changes to files.

1)Check to see if the tripwire utility is installed.

	# pkginfo | grep SEStripwire

If it is not installed, install the package:

# cd /usr/local/pkg
# pkgadd -d tripwire*

2) View the default configuration file in /var/tripwire and notice all of the files tripwire checks by default and the associated attributes tripwire should check.

	# cd /var/tripwire
	# more tw.config

	<<output ommitted>>
	
	/dev                    L
	/devices                L
	=/devices/pseudo        L
	/etc                    R
	/etc/default            R
	/etc/dfs/dfstab         R
	/etc/dfs/sharetab       R
	/etc/passwd     R
	/var/adm/wtmpx  L
	/usr/bin        R

	<<output ommitted>>

What does the R or L stand for? Read-only and Log file templates

3) Use tripwire to generate a database of signatures. Be sure to be in the /var/tripwire
directory.

# cd /var/tripwire
# tripwire -initialize

Tripwire(tm) ASR (Academic Source Release) 1.3.1 
File Integrity Assessment Software
(c) 1992, Purdue Research Foundation, (c) 1997, 1999 Tripwire
Security Systems, Inc. All Rights Reserved. Use Restricted to
Authorized Licensees.
### Warning:    creating ./databases directory!
###
### Phase 1:   Reading configuration file
### Phase 2:   Generating file list
### Phase 3:   Creating file information database

<<output ommitted>>

4) Run a standard tripwire integrity check. 

# tripwire
Tripwire(tm) ASR (Academic Source Release) 1.3.1 
File Integrity Assessment Software
(c) 1992, Purdue Research Foundation, (c) 1997, 1999 Tripwire
Security Systems, Inc. All Rights Reserved. Use Restricted to
Authorized Licensees.
### Phase 1:   Reading configuration file
### Phase 2:   Generating file list
### Phase 3:   Creating file information database
### Phase 4:   Searching for inconsistencies
###
###                     All files match Tripwire database.  Looks okay!
###

5) Switch personal identities and become a "blackhat." Assume that you have compromised
the server and you are now going to install some backdoors.

	o Make the wtmpx world accessible.

		# chmod 777 /var/adm/wtmpx

	o Create an SUID shell in /bin.

		# cp /bin/ksh /bin/pageout
		# chmod 6555 /bin/pageout

6) Switch identities back to a system administrator, run a tripwire integrity check to see if tripwire
detected the changes.

# tripwire
Tripwire(tm) ASR (Academic Source Release) 1.3.1 
File Integrity Assessment Software
(c) 1992, Purdue Research Foundation, (c) 1997, 1999 Tripwire
Security Systems, Inc. All Rights Reserved. Use Restricted to
Authorized Licensees.
### Phase 1:   Reading configuration file
### Phase 2:   Generating file list
### Phase 3:   Creating file information database
### Phase 4:   Searching for inconsistencies
###
###                     Total files scanned:            10911
###                           Files added:              1
###                           Files deleted:            0
###                           Files changed:            3
###
###                     Total file violations:          4
###
added:   -r-sr-sr-t root       201016 Sep 13 15:33:22 2002 /usr/bin/pageout
changed: prw------- root            0 Sep 13 15:00:47 2002 /etc/initpipe
changed: prw------- root            0 Sep 13 15:00:47 2002 /etc/utmppipe
changed: -rwxrwxrwx adm        102300 Sep 13 15:00:47 2002 /var/adm/wtmpx
### Phase 5:   Generating observed/expected pairs for changed files
###
### Attr        Observed (what it is)         Expected (what it should be)
### =========== ============================= =============================
/etc/initpipe
      st_mtime: Fri Sep 13 15:00:47 2002      Fri Sep 13 14:51:13 2002      
      st_ctime: Fri Sep 13 15:00:47 2002      Fri Sep 13 14:51:13 2002      

/etc/utmppipe
      st_mtime: Fri Sep 13 15:00:47 2002      Fri Sep 13 14:51:13 2002      
      st_ctime: Fri Sep 13 15:00:47 2002      Fri Sep 13 14:51:13 2002      

/var/adm/wtmpx
       st_mode: 100777                        100644            

7) The tripwire utility was able to locate both "blackhat" changes on the system.