My Analysis of the Scan of the Month June 2001:


1)	Identify the encryption algorithm used to encrypt the file.
	
	The file "somefile" was encrypted with a an exclusive or, vernam cipher, algorithm using the key of 0xFF, 
	creating a 1's complement of the data in the plain text.

2)	How did you determine the encryption method? 

	The cipher text of "somefile" lacks even the appearance of random data which should be a characteristic
	of a high grade encryption algorithm. All of the high bits in every byte of the cipher text is set. This
	immediately led me to suspect that a simple algorithm was being used. Decrypting with a vernam cipher 
	with a key of 0x80 did not decode to anything recognizable, however using 0xFF as the key yields 
	readable text to what appears to be a configuration file.


3)	Decrypt the file, be sure to explain how you decrypted the file. 

	In order to decrypt the file I wrote a small C program to implement the single key vernam cipher 
	algorithm.  The program in listed below:


		#include <fcntl.h>

		char key[] = { 0xFF };

		main()
		{
			int i,o;

			char buf[1024];
			int n,m;
			int keyIndex=0;

			i = open("somefile",O_RDONLY);
			o = open("somefile.o",O_WRONLY|O_CREAT,0666);

			while( (n=read(i,buf,sizeof(buf)))>0 )
			{
				for( m=0 ; m<n ; m++ )
				{
					if( keyIndex == sizeof(key) )
					    keyIndex = 0;

					buf[m] ^= key[keyIndex++];
				}
				write(o,buf,n);
			}
			close(i);
			close(o);
		}

	The resulting plain text output into somefile.o is listed below:


		[file]
		find=/dev/pts/01/bin/find
		du=/dev/pts/01/bin/du
		ls=/dev/pts/01/bin/ls
		file_filters=01,lblibps.so,sn.l,prom,cleaner,dos,uconf.inv,psbnc,lpacct,USER

		[ps]
		ps=/dev/pts/01/bin/psr
		ps_filters=lpq,lpsched,sh1t,psr,sshd2,lpset,lpacct,bnclp,lpsys
		lsof_filters=lp,uconf.inv,psniff,psr,:13000,:25000,:6668,:6667,/dev/pts/01,sn.l,prom,lsof,psbnc

		[netstat]
		netstat=/dev/pts/01/bin/netstat
		net_filters=47018,6668

		[login]
		su_loc=/dev/pts/01/bin/su
		ping=/dev/pts/01/bin/ping
		passwd=/dev/pts/01/bin/passwd
		shell=/bin/sh

		su_pass=l33th4x0r

4)	Once decrypted, explain the purpose/function of the file and why it was encrypted 

	Although the purpose of the plain text was not initially obvious to me, there are clearly references to
	administrative utilities some of which (su, ping, passwd, lsof, lp utilities) may normally execute with
	elevated privileges. Some research on some of the apparent keywords in this file has allowed me to 
	determine that the file is part of a Rootkit, which once installed replaces numerous system utilities 
	with script/executables which will create back doors into the system and attempt to conceal the presence 
	of the intrusion.
	
	The original name of the file as part of this Rootkit was "uconf.inv". The purpose of the file is to
	configure the various "Rootkit" components to hide themselves. The "[File]" section of file lists the
	replaced versions of the find, du, and ls commands, contains a list of files which are to be suppressed
	from the output of these commands. Similarly the ps_filters, lsof_filters, and net_filters sections list 
	programs, open files, and TCP/IP ports which should be suppressed from output. Finally to su_pass would 
	be a password used by a back door into the system.

	The file was encrypted in order not to draw any additional attention, other than it's presence, to the
	fact that replacement executables for du, ls, netstat, lsof, ping, and passwd were installed on the
	system. As well as possible installation of the additional utilities and libraries: lblibps.so,sn.l,prom,
	cleaner,dos,uconf.inv,psbnc,lpacct,USER, lp,uconf.inv,psniff,psr,sn.l,prom,lsof,psbnc.


5)	What lesson did you learn from this challenge? 

	By studying this scan I have learned to identify an intrusion which has installed a "Rootkit" such as
	this. The Signature of the encrypted uconf.inv which will begin with the hexadecimal bytes: 8C 97 9B 
	CD D3 93 is a clear sign of the intrusion. The presence of the replacement executables which the Rootkit
	will install should also set off security alarms, to alert administrators of an intrusion. 

	Also if an individual such as myself who is not a cryptographer can easily decipher the file, stronger
	measures should be used for any sensitive data which need protection.

	As part of my research to understand this file I came across an log of forensics used in the 
	the detection of an intrusion which utilized such a "Rootkit". These were documented and are available
	at http://www.sans.org/y2k/the_compromise.htm This account clearly illustrates the need for host based
	file monitoring such as tripwire to secure systems, even when fire-walls, network monitoring and other
	network based intrusion detection mechanisms are in place.


6)	Time spent on this challenge:

		I)   Decryption of file:	15-20 minutes.
		II)  Research on the "Rootkit":	30-40 minutes.
		III) Creation of this write up:  60 minutes.

			Total:			~2 hours.

Bonus question:

	I believe that this file is part of the SunOS Rootkit by Tragedy/Dor based on a message from a possible
	victim of a simular attack, which may be read at:

		 http://archives.neohapsis.com/archives/sf/sun/2001-q2/0088.html