From jeffh@zeta.org.au Fri Jun 22 08:49:59 2001 Date: Thu, 21 Jun 2001 18:46:23 +1000 From: Jeffrey Horton To: project@honeynet.org Subject: Submission for scan of the month #16 Solution to Scan of the Month #16
Submitted by Jeffrey Horton <jeffh@zeta.org.au>

Q1.Identify the encryption algorithm used to encrypt the file.

The file has been "encrypted" by complementing each byte of the file. This is easily achieved by XORing each byte of the file with 0xff.

Q2.How did you determine the encryption method?

First, extract the file from the gzipped tarfile: 

	gunzip -c somefile.tgz | tar -xvf -
Use the command: 
	od -x somefile
to get a hexadecimal representation of the file. A portion of the dump is shown below: 
0000000 99a4 9396 a29a 99f5 9196 c29b 9bd0 899a
0000020 8fd0 8c8b cfd0 d0ce 969d d091 9699 9b91
0000040 9bf5 c28a 9bd0 899a 8fd0 8c8b cfd0 d0ce
0000060 969d d091 8a9b 93f5 c28c 9bd0 899a 8fd0
0000100 8c8b cfd0 d0ce 969d d091 8c93 99f5 9396
0000120 a09a 9699 8b93 8d9a c28c cecf 93d3 939d
0000140 9d96 8c8f 8cd1 d390 918c 93d1 8fd3 908d
0000160 d392 939c 9e9a 9a91 d38d 909b d38c 9c8a
0000200 9190 d199 9196 d389 8c8f 919d d39c 8f93
Observe that the high bit of each byte is set. This is a pattern that is most unlikely to be present in the output of an encryption algorithm such as DES. So this file is not the result of applying such an algorithm.

Whatever program uses this encrypted file would obviously need to be able to decrypt it at some later date, which means that the encryption key will be available to an admin, with enough work, to decrypt the file. There isn't much point in using some sort of fancy algorithm in this case.

So the encryption algorithm is probably something simple. A simple algorithm, perhaps the simplest, is XORing each byte of the file with 0xff. A quick program was written to perform this operation: 

#include 
#include 
#include 
#include 

int main( int argc, char **argv ) {
	char 	buf[128];
	int 	bytes, i;
	
	while ( (bytes = fread( buf, 1, sizeof(buf), stdin )) > 0 ) {
		if ( (bytes != sizeof(buf)) && ferror(stdin) )
			break;
		for (i = 0; i < bytes; ++i)
			buf[i] ^= 0xff;
		fwrite( buf, 1, bytes, stdout );
	}
	if ( ferror(stdin) ) {
		fprintf( stderr, "Error reading bytes: %s\n", strerror(errno) );
		exit(1);
	}
	return 0;
}
Inspection of the output revealed ASCII text. This indicates that the correct algorithm has been discovered.

Note that without access to any programs that would have decrypted this file in the course of their work, decryption of the file would have been significantly more complicated had a slightly more sophisticated algorithm been used in the encryption.

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

Compile the program shown above using gcc: 

	gcc decryptor.c
Apply to the encrypted file: 
	./a.out < somefile > decrypted_file
This reveals the following text: 
[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.

At this point, I spent some time conducting net searches for any web pages or newsgroup postings that mentioned similar files, with some success.

The file is part of a security toolkit that as part of its operation replaces system binaries such as find, du, ls, ps, netstat. The original versions are hidden away elsewhere in the file system for later use.

This file identifies the locations of the original system binaries for use by the toolkit's replacement binaries. Additionally, it specifies a variety of filters to be applied by the replacement binaries to the output of the original binaries before this output is displayed to the user. This prevents the user from discovering toolkit files through the use of ls, or toolkit processes by using ps. Any processes set up by the toolkit to listen for remote connections are also concealed from the user by modifying the output of netstat.

Also note the presence of a field in the decrypted file suspiciously titled su_pass. This could be a password that can be employed to gain access remotely via some backdoor installed by the toolkit.

So why was the file encrypted? Obfuscation seems to be the obvious reason. Encrypting a file in such a manner makes determination of exactly how and what a system was compromised more difficult.

Q5.What lesson did you learn from this challenge?

I learnt a lot more about how toolkits such as the one from which this file was taken work. This is useful information, as toolkits such as these will probably become increasingly common.

Q6.How long did this challenge take you?

Bonus question: Can you identify the toolkit?

I can't identify the toolkit exactly. However, the decrypted file does bear remarkable resemblance to one found in a toolkit called "Universal Root Kit", version 0.9.7. Notes included in the package indicate that the author had just added the simple encryption technique with the stated purpose of rendering a configuration file difficult for people to read.

Comments in a newsgroup posting that more closely matched against terms extracted from the decrypted file indicate that this file is likely from this toolkit or a descendant, crossed with another rootkit attributed to "Tragedy/Dor".

THE END