1. Identify and explain the purpose of the binary.
  2. The-binary appears to be principally a remote-attack access vehicle, intended to provide remote command execution and reporting to the attacker or program which placed it. It is possible that the supplied binary also includes facilities for talking to copies of itself located on other compromised systems, however I did not find any substantial evidence of such behavior.

    In order to be of maximal use to an attacker of course this code needs to run with r

    execve("./malcode", ["./malcode"], [/* 13 vars */]) = 0
    personality(0 /* PER_??? */)            = 0
    geteuid()                               = 501
    _exit(-1)                               = ?
    

  3. Identify and explain the different features of the binary. What are its capabilities?
  4. The binary opens a raw network socket using protocol 11 (NVP or network voice). This socket is used as a control link for a remote attacker. The control link uses a simple encoding to hide its traffic from casual inspection.

    Once activated over this control channel, the binary will accept commands over the open socket, and will open connections to send its responses using essentially the same socket interface.

    The choice of IP numbers for this reporting is, as near as I can tell randomly selected at activation and does not change within an instance. It seems likely that this method was chosen by an attacker who has the ability to sniff packets traversing his target's network connections.

  5. The binary uses a network data encoding process. Identify the encoding process and develop a decoder for it
  6. The binary accepts and transmits data in the following form:

    bytevalue(s)useage
    0002|03command
    0100n/a-fill?
    0200-ffstop-difference
    03??unknown?
    04-stopencodedpayload/
    command

    The test-data provided by the challenge includes control packets sent to the binary. These seem to consist of 2 'wakeup' commands, followed by a shell-command. The shell command will be run anytime it is asked for, however the network-replies are only initiated if the 'wakeups' have been sent priorly.

    The easiest way to decode the incoming data is to modify the test system to force the malware to show it's plaintext. Observing that the malware executes its commands using 'csh' I accomplshed this by replacing /bin/csh with the following shell script.

    echo $$ $* >> /root/.log
    exec $3 $4 $5

    Analysis of the data flowing in and out of the malware showed that the encoding consisted of "plainbyte=this byte+const - (prior byte+const)modulus 256". In order to fulfill the requirements of the challenge / contest I wrote the following 'C' program. Using this will require extracting the data from a network sniffer and stripping off the IP header.

    
    /* the-binary-decode.c */
    #include 
    
    void main (){
      int s,c,i,l,o,t;
      c=getchar();
      c=getchar();
      l=getchar();
      s=getchar();
      c=getchar();
      o=c-72;
      putchar(o);
      t=c;
      while ((c=getchar()) != EOF){
        if (c-t == l) { /* */
          break;
        }
        if ( t <= 136 ){
          t+=256;
        }
        i=(c-(t+136))%256 - 143;
        putchar(i);
        t=c;
      }
    }
    
    

    Intererestingly this does not correctly decode the network-replies provided as check data. I am not certain whether this is due to an error in the binary's encoder (What I take to be a stop byte is encountered in the message body), or whether I missed a nuance of the encoding. At any rate, fiddling with the input is adequate for this data, and the decoder works correctly on the data which I generated from the binary in live operation.

  7. Identify one method of detecting this network traffic using a method that is not just specific to this situation, but other ones as well.
  8. The binary's traffic can be captured with the snort rule:

    alert ip any any <-> any any (msg:"Illegal protocol"; ip_proto: 11; )

    Better would be a rule which captures all unused protocols (252/254) within most LAN environments.

    Another approach would be to watch for identical-content packets in general. The binary sends identical content packets to several locations (as a solution to using a , so an IDS configured to notify of duplicated packets would be a workable solution.

  9. Identify and explain any techniques in the binary that protect it from being analyzed or reverse engineered.
  10. On execution the binary takes some steps to make its presence less likely to be observed. It starts by immediately executing a fork() which is probably intended more to make program tracing difficult. The next step it takes in hiding itself is to overwrite the name in the process table as "[mingetty]". This seems to only affect the 'ps(1)' command, lsof for instance, and most of the entries in the /proc/[pid] tree see the correct command name.

    The binary may undertake additional methods such as overwriting its data in memory. However in keeping with minimizing expenditure I did not undertake a disassembly analysis at the level to find this.

    The use non-connected sockets makes it easy for the attacker to spoof the source IP address. This may provide a degree of anonymity, or this attack may be specifically intended for cases where the attacker has the ability to sniff packets traversing the targets connection.

    The choice of libc 5.3 may be intended to make reverse-engineering more difficult. I suspect that available decompliers are more focussed on current versions of Linux / gcc.

  11. Identify two tools in the past that have demonstrated similar functionality.
  12. Adore, RST (remote shell trojan)

Bonus Questions: The bonus questions are open ended questions. It is used when submissions are too close together to tell apart. The bonus question is then used to identify a winner when entries are tied for a position.

Copyright © 2002 FW Systems LLC, All Rights Reserved