Scott Diamond
diamond@cs.wisc.edu

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

The file was encrypted using a bitwise xor of the data with all ones.


2.How did you determine the encryption method? 

I discovered that the file had be XOR-ed after printing out the characters from 
the file in decimal format and sorting the result.  I noticed that only a few of 
the possible 256 values were used.  If the file was encrypted with a strong 
algorithm I would have expected it to  have a broader distribution such as using 
values between 0 and 133 that are not present in the file.  XOR is a standard 
way of obfuscating data and explain the upward shift of the ASCII data.  I tried 
a bit wise XOR of the file with all ones and recovered the clear text.


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

To Decrypt I modified my original Java program that I was using to inspect the data 
in integer form to print instead (data XOR 0xFF) and print to standard out as
characters.

The clear text was then found by running
%Java Hex somefile
[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

This is the Java program I used to decrypt the data.

// Scott Diamond
// diamond@cs.wisc.edu
// XOR the data and print to standard out
// Input is from the first file given on the command line

import java.io.*;
import java.util.*;

public class Hex{
    public static void main( String[] args){
        String curr; // current line
        File myFile = new File(args[0]);
        int count;
        int ones = 0xFF;
        int temp;

        try{
            if(myFile != null && myFile.canRead() && myFile.isFile()){
                BufferedReader file = new BufferedReader(new FileReader(myFile));

                while((curr = file.readLine()) != null){
                    char[] arr = new char[curr.length()];
                    curr.getChars(0,curr.length(),arr,0);
                    for(count=0;count < arr.length;count++){
                        temp = ((int)arr[count]);
                        //System.out.print(" " + temp); // Print the data as integers
                        System.out.print(((char)(temp^ones))); // XOR with one and print as character
                    }
                }
                file.close();
            }
        }
        catch(IOException e){
            e.printStackTrace();
        }
    }
}



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

This is a configuration file for a root kit and shows what to filter out for the commands find,
du, ls, ps, netstat, lsof.  Also given are the location of the original binaries.  It was encrypted 
to avoid being intercepted in clear text by a network sniffer and also to make to harder to detect 
once installed.  Viewing the file will not yield any interesting information.  The configuration file 
is similar to the one mentioned in CERT Advisory CA-2001-05 Exploitation of snmpXdmid.  It appears that 
the root kit used in the compromise of the systems in this advisory is the same as the one received 
by the IDS.  Ports 47018 and 6668 are filtered out as in the advisory with net_filters=47018,6668.
However the telnet back door does not appear to be implemented on 2766.  The location /dev/pts/01/bin/
is the location of the orginal system files in the advisory and is pointed to in the configuration 
file.


5.What lesson did you learn from this challenge? 

I learned about available rootkits and their capabilities.


6.How long did this challenge take you? 

It took 10 hours.

Bonus Question: 
This encryption method and file are part of a security toolkit. Can you identify this toolkit? 

I searched on google for the configuration file uconf.inv and found the following link.
http://archives.neohapsis.com/archives/sf/sun/2001-q2/0088.html
A readme on the compromised machine at this link gives.
There was a README in the directory which states: 

   This is: SunOS Rootkit v2.5 (C) 1997-2001 Tragedy/Dor 
   If you find this file, most likely your host has been hacked by a user 
   of this rootkit. If you want information about this tool, removal  instructions 
   or such, please email bert.smith@mbox.bol.bg 
   The author takes NO RESPONSIBILITY for anyone who misuses this tool. 

   Please quote the following version number in any emails.. if the rootkit  wasnt 
   installed the version will be in a file named "iver" 

   17645914 

It looks like an updated version of the Universal Rootkit do to the similarities of the 
configuration file somefile with urk.conf.  They have the same section names and variables 
and in the same order. 

%cat urk.conf 
[file]
find=/usr/man/man1/xxxxxxbin/find
du=/usr/man/man1/xxxxxxbin/du
ls=/usr/local/bin/ls.gnu
file_filters=xxxxxx,yyyyyy,aaaaaa,mmmmmmmmm

[ps]
ps=/usr/man/man1/xxxxxxbin/ps
ps_filters=nedit,bash

[netstat]
netstat=/usr/man/man1/xxxxxxbin/netstat
net_filters=innu.org

[login]
su_pass=h4x0r
su_loc=/usr/man/man1/xxxxxxbin/su
ping=/usr/man/man1/xxxxxxbin/ping
passwd=/usr/man/man1/xxxxxxbin/passwd
shell=/usr/man/man1/xxxxxxbin/bash