1. Identify and explain the purpose of the binary.
The binary is an ELF file, implementing a remote backdoor. This backdoor is destined to be uploaded and installed on compromised hosts, where a Linux binary compatible system resides (Linux, FreeBSD, OpenBSD, ...). Once this backdoor is started on such a computer, the user can then remotely executes a set of different functionalities.
2. Identify and explain the different features of the binary. What are its capabilities?
The main feature of the binary is to offer a set of functionalities to the user, through a proprietary protocol. Those functionalities can be classified in 3 categories:
3. The binary uses a network data encoding process. Identify the encoding process and develop a decoder for it.
The backdoor exchange data with a client by encapsulating its data in an IP
payload, and filling the protocol field of the IP header with the value 11.
The payload itself contains a byte representing a signature: this signature
differs according to the direction of the packet. Packets from a client to the
backdoor contains a signature "2", while packets from the backdoor
to the client contains a signature "3". Typically, a client send "commands"
to the backdoor, and the backdoor answers with a set of packets containing "answers".
Behind this signature byte, we find a data block, encoded with a relatively simple algorithm. Those data contains the effective "command" and possible arguments (from client to backdoor), or informations returned by the backdoor (to the client).
4. Identify one method of detecting this network traffic using a method that is not just specific to this situation,
but other ones as well.
On a classical network, only a small subset of all available TCP/IP related
protocols are used. Among those, TCP, UDP and ICMP are the most widespread.
In our case, the backdoor uses a unusual protocol, numbered as 11 in the related IP header field: a traditional NIDS can usually be configured to directly generate an alarm once a packet with an unusual protocol is captured. Moreover, such unknown protocols can be easily blocked by a firewall, avoiding the risk to penetrate further in a network.
Finally, remember us that a well configured firewall must only allow traffic explicitly authorized.
5. Identify and explain any techniques in the binary that protect it from being analyzed or reverse engineered.
Except the strange protocol and its encoding mechanism, we can't truly speak
about explicit techniques to protect it from being analyzed or reverse engineered.
However, the fact that the backdoor communicates with an unusual protocol can make the analysis more difficult. Concerning the binary iteself, the fact that it is statically linked can cause problems for the reverser, especially if the used disassembler can't recognize library signatures.
Concerning the debugging, the architecture used in classical daemons (who consists to forks child processes two times consecutively), sometimes bring to problems, because the debugger needs to follow the creation of child processes and debug them directly at the beginning of their execution. Fortunately in our case, strace worked perfectly.
6. Identify two tools in the past that have demonstrated similar functionality.
What makes this binary original is that it offers remote command execution, combined to DDoS attacks. Most of the existing backdoors only offer remote command execution (traditionally by binding a shell to a predefined TCP port), and let the user upload himself others tools to start a DDoS attack (remember Trinoo and all derived projects). Here, the DDoS attacks are directly included in the binary, and the user can receive the result of command executions through a protocol originally not reserved for such a particular usage. So, it is interesting to have a look at others tools who permit to exchange data using protocols not reserved for this usage.
The first tool to approach such a technic is surely Loki:
it uses the ICMP protocol to create a covert channel and exchange informations.
Now, we can find a lot of other tools using the same technic as Loki
to run shell commands, transfer files, ...
The second tool, , CovertTCP, go a step further, and try to create a covert channel by encoding informations in header fields of TCP/IP protocols.
What kind of information can be derived about the person
who developed this tool?
For example, what is their skill level?
Here, it is interesting to determine the skill level according to 2 different criterions:
int __cdecl f_send_dns_SOA(char source_ip1,char source_ip2,char source_ip3,char source_ip4,int count,int source_port1,int source_port2,int use_hostname,char *hostname)
We clearly observe that each byte of the IP source address is passed as
one argument. This isn't a really powerfull technique... The same mechanism
is used to pass the source port value.
Also, we remark that a flag (use_hostname) indicate if for a given address, we must use the IP address from the byte arguments, or resolve the address from the hostname argument. Wouldn't it have been simplier to pass a null pointer or an empty string as hostname, to obtain the same effect?
Concerning the DDoS commands, we observe a different structure associated to each command. Moreover, those structures usually are different on a relatively small set of bytes or arguments). Without any doubt, it would have been simplier to build a general structure, and use it for each command offered by the backdoor (as usual protocols tend to do).
However, those strange programming skills are perhaps an indication that the person who developed the tool cut and pasted source code from other tools, and tried to adapt all those code extracts into a coherent backdoor. Moreover, the fact that a function is unused (f_ip_checksum()) still consolidates our assumption.
What advancements in tools with similar purposes can we expect in the future?
Different advancements can be envisaged, at the different levels: