Answers to the Challenge questions

Identify and explain the purpose of the binary

This binary is a Linux backdoor and Denial of Service tool.

Identify and explain the different features of the binary.

Please refer to the technical description. We summarize here roughly the functionalities we found:

 

-         Backdooring compromised Linux systems

o       Remote “blind” command execution

o       Remote backdoor detection

o       Remote command execution with output

o       Remote DoS processes management (termination)

o       Remote bindshell activation on an high TCP port, 23281, with password (SeNiF).

-         Setting up a Denial of Service outpost

o       SYN flood

o       UDP DNS flood

o       Misc. UDP/ICMP/TCP flooders (not fully investigated, not fully identified)

Identify the network data encoding process.

The network data encoding process is an obscure shuffle and arithmetic obfuscation. It is trivially decrypted with the following code snippet:

 

        for(i=0;i<size;i++) {

                if (i > 0)      d = data[i] - data[i-1];

                else            d = data[i];

 

                d -= 23;

                while (d < 0) d+= 256;

                b1[i] = (unsigned char)d;

        }

                        (data = original data, b1 = unencrypted data)

 

Note that the obfuscation algorithm is a bit broken since if the initialization byte is null, parts of the original input is present verbatim in the output ciphertext because of the n-1 -> n propagation.

 

Identify one method of detecting this network traffic.

It is possible to detect such network traffic by detecting IP-PROTO-11, which should usually be pretty rare.

 

(from the technical advisory: )

 

Network signatures can be installed on certain machines (also called NIDS) to detect attempts to use the backdoor. These signatures could determine attempts at contacting the compromised system again or contacting other backdoors on the network.

 

Signatures can be based on:

-         IP PROTO 11

-         (optional) DATA[0] = 02 (command) or 03 (reply), DATA[1] = 00

-         (optional) PKT LEN > 200

 

Warning: We did not verify whether the 0200 signature was a standard ip proto 11 signature (Voice over IP) or if it is actually a backdoor signature as we suspect.

 

A basic Snort rule (please also refer to the supplied snortrules.txt file):

alert ip any any -> any any (ip_proto: 11; msg:”IP-PROTO-11: possible backdoor traffic”;)

 

Another Snort rule checking for the 0200 signature:

alert ip any any -> any any (ip_proto: 11; offset: 0; content: “|0200|”; msg:”possible DoS/Backdoor traffic”;)

Identify and explain any anti-reversing techniques in the binary

(from the Technical advisory: )

 

When run, the backdoor hides itself by changing its program name to “[mingetty]”, name of a rather standard getty-replacement for Linux consoles. It does this by erasing its argv[0] with the words “[min” “gett” “y]”. Note that this does not hide the whole word mingetty from a strings output, so we do not know exactly whether the author was trying to hide the string by doing the 3 copies (usual method) or whether it was just a convenient construct.

 

We also noted that there is no real anti-debugging trick implemented in the binary. For example, no ptrace() prevention is done at all, so it is possible to debug (strace, gdb, …) the binary at will.

 

However, we also noted that the binary is statically linked, which renders disassembly and debugging a bit harder, mostly because of the volume of the built-in libc routines.

 

As a side note, the libc version used is Linux libc 5.3.12, an old (1998) version of the Linux (pre-glibc) libc. We can thus deduce that the author compiled it on an old machine or wrote it awhile back.

 

To conclude this paragraph, we can say that there is no real anti-debugging/anti-reversing trick used. Most problems we encountered while reversing the binary were related to compiler optimization, static linkage and poor coding. 

Identify two tools in the past that have demonstrated similar functionality

-         TFN2K (http://packetstormsecurity.org/distributed/TFN2k_Analysis.htm)

-         Stacheldraht (http://packetstormsecurity.org/distributed/stacheldraht.analysis)

Information about the Author

Even if interesting malicious ideas are to be found in this tool, many hints allow us to say that this tool was developed by someone not familiar with C Unix development. In the technical advisory, we describe lots of places where weird constructs are used (for example, system() of a shell, sprintf(“%c%s”, …), strange and useless parts in the network coder/decoder). These oddities are probably not anti-reversing tricks; many tricks would have been far more efficient and easier for the author.

 

Also, the communication mechanism involving IP protocol 11 is pretty sloppy, whereas something like masquerading legitimate DNS traffic would have been lots more difficult to filter out.

What’s next?

Heh, next they will probably use the conclusions of the HoneyNet projects to develop better/scarier tools J (j/k!!!)