Scan of the Month #16 - Decrypt and analyze an encrypted file found on a compromised system.


Thank you for that exciting challenge. The decryption was just the prelude to an interesting investigation. Now the answers ...

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

xor every byte by 255

2. How did you determine the encryption method?

guessed :-)

This was the first thing I thought of when I first downloaded the encrypted file. However, that was not the first thing I did:
 

  • download somefile.tgz (435 bytes)
  • download somefile.zip (411 bytes) - himm ... .zip is smaller does this mean anything ???
  • extract .tgz and .zip and check that the contents are identical :-)
  • somefile (532 bytes) - small for a binary perhaps a shell script???
  • file and strings commands (obviously) did not reveal anything useful.
  • hexdump -e '"%07.7_ax  " 16/1 "%02x " "\n"' somefile
    • 0000000  a4 99 96 93 9a a2 f5 99 96 91 9b c2 d0 9b 9a 89
    0000010  d0 8f 8b 8c d0 cf ce d0 9d 96 91 d0 99 96 91 9b
    0000020  f5 9b 8a c2 d0 9b 9a 89 d0 8f 8b 8c d0 cf ce d0
    0000030  9d 96 91 d0 9b 8a f5 93 8c c2 d0 9b 9a 89 d0 8f
    0000040  8b 8c d0 cf ce d0 9d 96 91 d0 93 8c f5 99 96 93
    ...
    00001e0  d0 8f 8b 8c d0 cf ce d0 9d 96 91 d0 8f 9e 8c 8c
    00001f0  88 9b f5 8c 97 9a 93 93 c2 d0 9d 96 91 d0 8c 97
    0000200  f5 f5 8c 8a a0 8f 9e 8c 8c c2 93 cc cc 8b 97 cb
    0000210  87 cf 8d f5
  • No obvious pattern, however these are all large numbers (not ASCII)
  • I had MATLAB open on my desktop so I decided to check the histograms
  • It was getting late so I decided to sleep on it ...
  • At midnight the pattern hit something inside and I woke up! The histogram pattern was just a mirror image of a normal histogram of an ASCII text! This is what you woud get with a bit flip. Continuing from where I left off, I tried the xor-by-255 method that I have been putting off as too simple ...
  • Yes! it worked!

    •  

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

    The MATLAB command char(df') converted the decrypted array into a string:
    [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

    A single line using perl can accomplish the same thing:
    $ perl -e 'while(<>){s/(.)/chr(ord($1)^0xff)/eg; print;}' <somefile

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

    It is a rootkit configuration file. It lists the ports and files that must be hidden by the trojaned binaries. It also contains paths to executables ie. /dev/pts/01/bin/netstat. This turns out to be a wrapper (see bonus question below) that calls the original binary hidden in the given path and filters the results. The encryption may serve two purposes:
     
  • It may prevent some users from modifying the rootkit (extremely low level kiddies?)
  • It may prevent/slow-down discovery by administrators/analysts (the filename, which is probably uconv.inv, is visible inside the wrapper binaries, so people may want to check it out)

    •  

    5. What lesson did you learn from this challenge?

    In the previous Scan of the Month, the rootkit installation locations was modified by the attacker but the original paths remained hard-coded inside the binaries, making the rootkit non-functional. I think this is an attempt to prevent similar happenings. And to create easy to configure rootkits for Windows kiddies. Soon these things will be plug-and-play :-).

    The next lesson is about obfuscation - it does not work. If you really need to encrypt something use a proven algorithm.

    Finally, do not ignore your instincts even if it looks too simple to be true.
     

    6. How long did this challenge take you?

    The decryption took about 15-20 minutes. The following search for the rootkit information is spread over a few days.
     

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

    This is the question that took most of my time. I have searched the internet for some of the keywords found in the configuration file. My first hit was a google search on tcp port 47018 which lead me to http://www.securityfocus.com/archive/75/172558 - Matt Power's post on snmpXdmid Solaris remote root compromise. He described a rootkit that closely matched the configuration file. He did not describe the configuration file probably because it was encrypted. The next link was the CERT Advisory on snmpXdmid. It also described a similar rootkit. A followup to Matt's post from Roberto http://www.securityfocus.com/archive/75/173002 expanded on the matter:
    Hi,
    I have seen this kit on my Sun 5.8 machines as wel.. i
    found a README with it..
    Here is some more information about it and where it
    came from..

    pasted below :

    X-ORG Internal Release ONLY! Don't Spread!
    by JudgeD/Danny-Boy

    Version 2.3DXE
    --------------

    * Variable sshd port ( Inspired by t0rnkit 8 )
    * New Setup Wrapper to allow user define variable (thanks Tragedy/Dor )
    * ps trojan for Solaris 5.7 & 5.8
    * lsof ( Inspired by t0rnkit 8 )
    * wget ( Included for convinient )
    * Support to download extra tools from a remote sites.
    * Support for all versions of Solaris ( from 5.4 > )

    Greets: X-ORG, etC!, bH, torn, dor, _random,
    Annihilat, W_Knight, Omen, APACHE
    DR_SNK, Cvele, angelz, sensei and
    #etcpub@IRCNET

    Searching for an other keyword, uconf.inv resulted in an other interesting thread, this time from Focus-Sun mailing list: http://www.securityfocus.com/archive/92/178904 this post describes another Solaris rootkit, with the following README:
      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

    Again Tragedy/Dor. Unfortunately, searching for tragedy/dor did not lead to the rootkit itself. A reply to this message by Casper Dik confirms that rootkit moves the binaries to a safe place (/dev/pts/01/bin) and replaces them with wrappers.The wrappers check the configuration file to determine their behaviours). It appears that there are several groups that use the New Setup Wrapper to create custom rootkits.
     

    Analysis by Can E. Acar