The Reverse Challenge: Answers to the Questions
1. Identify and explain the purpose of the binary
The purpose of the binary is to enable a backdoor DDoS handler/agent. After being installed and executed as root it runs as a daemon that provides remote execution capabilities to a remote machine through a covert channel with a suitable client, as well as a bunch of services that can be used to initiate diverse kinds of Distributed Denial of Service (DDoS) attacks.
2. Identify and explain the different features of the binary. What are its capabilities?
The binary is able to:
-
Hide itself. It must be installed as root, but after that it performs several actions to avoid being detected:
- Change its name as [mingetty].
- Open a socket attending a non standard protocol (0xB), such as TCP or UDP, that are the only ones checked in many tools.
- Encrypt the data being transmitted to and from itself.
- Act as a DDoS handler and agent: it can generate different DDoS attacks as TCP SYN flood, ICMP flooding, UDP flooding.
- Executes arbitrary commands (obviously as root).
- Retrieve the output of an arbitrary command.
- Of course, it uses the IP spoofing mechanism to forge the source IP address.
- Established itself as a backdoor in the system it is running. It provides a remote shell in a TCP port.
The network data encoding process is not a simple substitution function.
The functions to encode and decode the data are both included in the binary (at addresses 0x0804a194 and 0x804a1e8 respectively).
Encoding function
The function encrypts an array of cleartext data (clear[]) and puts the result in another array (cipher[]) both with a length of size.
After a thorough analysis we determined that the encoding formula goes like this:
cipher[i]=clear[i]+cipher[i-1]+23-(256*N)
where:
- i goes from 0 to size-1, being size the number of bytes of both arrays
- cipher[i-1] is assumed to be 0 for i=0
- N is the smaller factor among 0 and 1 such that ciphertext[i]<=255
The assembler code performs this encryption following the steps depicted in the attached graphic. The yellow colour highlights the positions that are modified on every step.
The steps are then:
Step 1:Before the loop: loads byte 0x80675e5 into clear[0]. Let i=0
Step 2: Calculates the first byte of cipher (cipher[0]) using clear[0] (as stated in the formula). Replaces the byte loaded before with cipher[0] using sprintf(cipher, "%c", cipher[0]).
Step 3: Enters the loop to calculate cipher[i] using cipher[i-1] and clear[i] as stated in the formula and puts it in its place. Increments i and repeat until i equals size.
Decoding function
The function decrypts an array of ciphertext data (cipher[]) and puts the result in another array (clear[]) both with a length of size.
After a thorough analysis we determined that the decoding formula goes like this:
clear[i] = cipher[i] - cipher[i-1] - 23d + (N*256d)
where:
- i goes from 0 to size-1, being size the number of bytes of both arrays
- cipher[i-1] is assumed to be 0 for i=0
- N is the lowest positive number such that clear[i]>0
The assembler code performs this decryption following 5 steps depicted in the attached graphic. The yellow colour highlights the positions that are modified on every step.
Before the loop: loads byte 0x80675e5 into clear[0]. Let i=size-1
Step 1: Calculates the last byte of clear (clear[i]) using cipher[i] and cipher[i-1] (as stated in the formula)
Step 2: Copies clear[] into a temporary buffer (let it be called "temp")
Step 3: Puts the calculated value clear[i] into clear[0]
Step 4: Copies the elements of temp into clear shifting them one position to the right.
Step 5: Calls sprintf(clear, "%c%s", clear[i], temp); This overwrites the contents of clear[] with the same contents it had but interpreted by sprintf(). Decrements i and returns to step 1 until I equals 0.
This function is used every time it receives a packet and it satisfies 3 conditions:
1) ip protocol must be 0x0b
2) first data byte equals 0x02
3) size of data is greater than 200 bytes
At that point this function is called with the following parameters:
cipher = data received excluding the first two bytes (0x02 and the next byte)
size = number of data bytes received -2
clear = empty array that will be used ever after as the "decoded" received data.
We have developed C functions to encode and decode in the file r_ciphering.c.
We could suppose that the binary analyzed appeared in the system mainly via two ways:
- Through a directly exploited vulnerability in one of the system services or daemons, that allows a hacker to have system control, at least for copying "the-binary" in some file system with root privileges. Another similar way to be introduced in the system is through a rootkit.
- Through a Trojan file, whose purpose is supposed to be a different one, but besides, places "the-binary" in the file system. A typical way of propagating Trojans nowadays is through the electronic mail system.
We found interesting to comment out more than just one unique defense method, so based on the capabilities of the binary file analyzed the following procedures and methods could be used to detect and defend against it:
1. Control the privileges needed by it: due to the fact that this kind of binary Trojans will try to establish its own communication channels, they need root privileges to manage RAW sockets, so they can only be activated in two ways:
- Executed directly by root: root should be conscious about all the power and permissions it has in the system, so it should carry on very specific and controlled actions.
- Executed by another user, but in this case, the binary needs to be setuid and owned by root: the typical system audit analysis will show the whole list of setuid/setgid files inside the system, alerting of its presence.
2. File integrity check: through the usage of integrity tools, as Tripwire (http://www.tripwire.com), it can be analyzed the presence of new files in the system. For example, it can be used to control the presence of new and unexpected executable files, as "the-binary".
3. Process monitoring: it is very important to have a minimum control of what is the typical process snapshot in a system, mainly based on the purpose this system was think of. The users typically execute new and different commands, but in a well-known system, 90% of the developed tasks are always similar and involves the same processes, so it is not so difficult to find relevant differences.
In this analysis, "the-binary" is hidden using a Unix common name as "[mingetty]". But it should be taken into account that it is different from the common mingetty processes executing in Linux:
root 1333 1 0 May24 tty6 00:00:00 /sbin/mingetty tty6
The "ps" command output under Linux can be forged to show a different command name through the argv[0] argument manipulation, but other commands, as for example "lsof", could be used to get more accurate information. The following example explains how both system tools work:
[root@reverse /]# cd REVERSE/
[root@reverse REVERSE]# ./the-binary
The "ps" Linux command is not telling the truth, because it shows the binary as "[mingetty]":
[root@reverse REVERSE]# ps -ef | grep mingetty
root 1047 1 0 04:14 tty1 00:00:00 /sbin/mingetty tty1
root 1048 1 0 04:14 tty2 00:00:00 /sbin/mingetty tty2
root 1049 1 0 04:14 tty3 00:00:00 /sbin/mingetty tty3
root 1052 1 0 04:14 tty4 00:00:00 /sbin/mingetty tty4
root 1053 1 0 04:14 tty5 00:00:00 /sbin/mingetty tty5
root 1054 1 0 04:14 tty6 00:00:00 /sbin/mingetty tty6
root 1424 1 0 04:20 ? 00:00:00 [mingetty]
But the "lsof" Linux command can be used to get the real binary name. See the first column:
[root@reverse REVERSE]# lsof -p 1424
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
the-binar 1424 root cwd DIR 8,2 4096 2 /
the-binar 1424 root rtd DIR 8,2 4096 2 /
the-binar 1424 root txt REG 8,2 205108 214302 /REVERSE/the-binary
the-binar 1424 root 0u raw 2207 00000000:000B->00000000:0000 st=07
[root@reverse REVERSE]#
The reason for this is that both tools get the information from a different place inside the Linux "/proc" filesystem. The "ps" command extracts the information from "/proc/PID/cmdline" file, while the "lsof" command gets it from "/proc/PID/status" (look the "Name:" entry).
[root@reverse proc]# pwd
/proc
[root@reverse proc]# cd 1424
[root@reverse 1424]# ls -l
total 0
-r--r--r-- 1 root root 0 May 14 04:27 cmdline
…
-r--r--r-- 1 root root 0 May 14 04:27 status
[root@reverse 1424]# cat cmdline
[mingetty]
[root@reverse 1424]# cat status
Name: the-binary
State: S (sleeping)
Pid: 1424
PPid: 1
…
CapEff: 00000000fffffeff
[root@reverse 1424]#
4. Temporary files: the program execution involves the creation of temporary files to store information. In the binary analyzed, one of the temporary files created is "/tmp/.hj237349". Of course, it is difficult to create a general method for detecting specific files, but when known, it is very easy to have a special monitoring process, or even a system IDS trying to control a well-known signature. This method is similar to the general virus detection method based on specific facts.
5. Network communication channel: all the advanced Trojan binaries, back doors, remote control tools, or DDoS agents, whatever we want to call them, use a communication channel to be able to take advanced actions. This channel allows the remote control of the "agent" and the execution of activities. The main purpose of this channel is not to be detected, so they are typically implemented in very common protocols, as ICMP, UDP or TCP, trying to simulate the permitted traffic, or on the other hand, as it is the case, in not very used protocols running over IP.
The binary analyzed uses the 0xB protocol, known in the standard definitions, the "/etc/protocols" file, as the "Network Voice Protocol":
nvp 11 NVP-II # Network Voice Protocol
This protocol is defined in RFC 741, "Specifications for the Network Voice Protocol (NVP)" (ftp://ftp.isi.edu/in-notes/rfc741.txt).
As can be supposed, the forged protocol implemented in the communication channel is not related at all with the identification code used in the standards.
To be able to detect the network activity associated to the control channel, the network filter mechanism in place, typically screening routers or firewalls, must follow a recommended rule: "least privileges needed". Lately it will be analyze the behaviour of this protocol using two common firewalls available for the Linux platform: iptables and Checkpoint Firewall-1 (see item number 7).
Something interesting about this protocol is that, given the fact it is not working with source and destination ports (it is not UDP or TCP), all "the-binary" processes running in the same system will receive the packet arriving to it.
6. Network activity flows: finally, once the remote "agent" has received the control commands through the communication channel, it will carry on some activities. Typically, if this agent needs root privileges to run (remember for example the usage of RAW sockets), the activities won´t be related with the same system in which it is running, but with other remote systems that will be attacked from there.
All this network traffic associated with these actions can be detected and monitored by security software, as for example IDS, and prevented by filtering devices.
6.1.- Detection of dangerous network traffic:
One of the most accurate and useful IDS solution under Linux is Snort (http://www.snort.org).
Snort is an open-source NDIS, Network Intrusion Detection System, that analyze network traffic crossing the wire and alerts based on the comparison of the packet format, contents and sequences with a well-known database signatures representing each of the different identified attacks.
The Snort rule, tested with Snort version 1.8.6, for detecting the control channel associated to the "the-binary" is:
alert ip any any -> any any (msg:"the-binary control channel detected!!"; ip_proto: NVP; dsize: > 180; content: "|02|"; depth: 1;)
The alert method configured in Snort, will show a message like the following:
[**] [1:0:0] the-binary control channel detected!! [**]
05/28-22:11:43.434470 192.168.1.15 -> 192.168.1.254
NVP TTL:64 TOS:0x0 ID:2322 IpLen:20 DgmLen:201 DF
As can be seen in the rule, it is checking the three main aspects checked by "the-binary" to interpret a network packet received:
- IP protocol: 0xB (NVP)
- Packet size greater than 200, that is, 20 bytes from the IP header + 181 or more bytes in the IP payload.
- Content checking: first byte in the payload must be 0x2.
Following the same phylosophy, similar rules could be added to detect the channel between the handler and the agents, where the first HEX value is equal to 0x03. In this case, the size checking should be analyzed, but it seems it should be always greater than 400:
alert ip any any -> any any (msg:"the-binary handler-agent channel detected!!"; ip_proto: NVP; content: "|03|"; depth: 1;)
An IDS like snort could also be used to check the network traffic associated to the DoS attacks and other activities:
- DDoS attacks:
- UDP packets to DNS port (53). [CASE 3 and 4]
- TCP packets to DNS port (53). [CASE 8]
- ICMP packets. [CASE 4]
- Activating a TCP Telnet port (23281) in listening mode. [CASE 5]
As has been said, different rules for each of this traffic flows can be added to Snort. Some examples are:
- Detect the establishment of a connection to the back-door listening in port 23281:
alert tcp any any -> any 23281 (msg:"the-binary 23281 back-door!!"; flags: S;)
- Detect the establishment of a DNS TCP connection. Not a very common situation unless you have DNS master and slave server transferring DNS zones between them:
alert tcp any any -> any 53 (msg:"the-binary TCP DNS DDoS!!"; flags: S;)
Finally, due to fact that "the-binary" has a hard-coded password, "SeNiF", used in CASE 5, it is possible to scan network packets looking for this string pattern, what will indicate a new connection establishment to the system were this agent resides. In this moment the incident response team could try to follow up the connection this packet is coming from; just for curiosity ;-)
6.2.- Prevention of dangerous network traffic:
The typical DDoS attacks are based on flooding a target system or network. To succeed most of them uses a method known as IP spoofing, and exploitable due to the design details of the TCP/IP protocol family. "the-binary" is not different from others in using this vulnerability, so the main defense against it is the usage of ingress filters. This solution is detailed in RFC 2267, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing" (ftp://ftp.isi.edu/in-notes/rfc2267.txt).
The egress or ingress concept depends on the side from which the filter is analyze, that is, from the company point of view (egress) where the spoofing agent is running, or from the ISP point of view (ingress) which is providing the network access.
If the company has used egress filters just to allow traffic originating from its IP addresses range, only the spoofed packets matching these addresses (just a few) will be successful. This defense will prevent others from receiving the forged packets, but the company device where the filter is applied will be congested trying to route (and filtering) all the traffic.
Apart from that, it is not possible to distinguish the real traffic form the forged one once traveling through Internet, and will be really dangerous if the destination port of every packet is a port where a service is being offered, for example DNS queries used by "the-binary".
It must be taken into account that for an IDS, like Snort, to be successful on detecting the big DoS traffic flows, it must be placed before filtering will take place, cause if it is outside the filter device, there won´t be any evidence of the attack and therefore, the later forensic analysis and incident response action will be less efficient.
7. How
iptables and Checkpoint Firewall-1 could detect and filter protocol 0xB used in
the control channel:
7.1.- Linux netfilter/iptables filtering system:
Using the following simple rule set to define which traffic is allowed and denied in the firewall system, we are able of detecting the control channel used by "the-binary":
# We set the default action for all the input traffic as DROP.
iptables -P INPUT DROP
# We accept all packets from previously established TCP connections.
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# These are the only allowed connections through the firewall: SSH and HTTP protocols.
iptables -A INPUT -p tcp --dport ssh -m state --state NEW -j ACCEPT
iptables -A INPUT -p tcp --dport http -m state --state NEW -j ACCEPT
# We do detailed logging of all the not accepted network traffic
iptables -A INPUT -p all -j LOG --log-level debug --log-prefix "FIREWALL " \
--log-ip-options --log-tcp-options
# These two rules are configured to behave as if no firewall were in place.
iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset
iptables -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
Once the Linux netfilter/iptables has been started and it is filtering the network traffic, you can see the applied security policy based on the configured rules:
[root@firewall /]# iptables --list
Chain
INPUT (policy DROP)
target prot opt source destination
ACCEPT all
-- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp
-- anywhere anywhere tcp dpt:ssh state NEW
ACCEPT tcp
-- anywhere anywhere tcp dpt:www state NEW
LOG all
-- anywhere anywhere LOG level debug tcp-options
ip-options
prefix `FIREWALL '
REJECT tcp
-- anywhere anywhere reject-with tcp-reset
REJECT udp
-- anywhere anywhere reject-with icmp-port-unreachable
Chain
FORWARD (policy ACCEPT)
target prot opt source destination
Chain
OUTPUT (policy ACCEPT)
target prot opt source destination
If the attacker tries to connect to "the-binary" using the control channel based on the 0xB protocol, the following messages detecting this traffic are logged by the firewall:
May 19 11:28:57 firewall kernel: FIREWALL IN=eth0 OUT= MAC=00:10:a4:ed:97:97:00:a0:cc:59:a2:ea:08:00 SRC=192.168.1.15 DST=192.168.1.254 LEN=1500 TOS=0x00 PREC=0x00 TTL=64 ID=19836 DF PROTO=11
In case you were using a rule allowing all the IP protocols, you can use a explicit rule to filter "the-binary" traffic:
# DROP "the-binary" protocol 0xB:
iptables -A INPUT -p 0xb -j DROP
7.2.- Linux Checkpoint Firewall-1:
Checkpoint Firewall-1 is the most used firewall nowadays in the computer industry. This is the reason why, apart from the default netfilter/ipchains Linux firewall, we have analyzed it to see how it behaves against "the-binary" traffic:
It has been tested in a simulated network where "cache1" is the border firewall and "cache2" is an internal system, where the only allowed protocol to it are ICMP, telnet and FTP, and anything else is dropped.
We also wanted to test what happened if NAT is also in place, therefore, "cache2" (the internal IP address) has been NAT´ed to an external and public IP address: "NAT-cache-2". As will be expected, NAT is not a constraint to be able to accept or deny the used IP protocol.
When a packet trying to send a command to "the-binary" crosses the firewall, it is detected (see the highlighted line in the log bellow):
It should be considered that if you use a rule where the destination service allowed is "Any", this is allowing any IP protocol, and not just ICMP, UDP and TCP, as could be think of.
In this situation, you are allowing "the-binary" 0xB protocol, and Firewall-1 doesn´t detect it (see the highlighted line in the log bellow, showed up because we configure logging in an ACCEPT rule, number 2 above):
Several techniques are used in this binary:
- Static linkage.
- No debug information and stripped.
- Consecutive forks
- Ciphered communication
- Especific client
Static linkage
Code re-utilization is one of the Holy Grails of programming and one of the best ways to achieve it is by using dynamically loadable libraries, also called shared objects.
Instead of putting a copy of every function you use in your programs inside of the binary, a reference to a library and a function name is stored. When the program is loaded in memory the programmer has the option to get these libraries and their functions loaded automatically or do it explicitly.
The procedure to do that is very well established and requires, among other things the name of the library and the name of the function to be stored in the binary.
There are tools, like ltrace, which allow intercepting and recording the calls to the libraries. Analyzing a binary with this information would ease the task, mainly if it is linked with known libraries, like the libc.
To make analysts' lives harder, the person(s) who programmed this binary has linked the program statically (avoiding also in one-shot possible incompatibilities with some systems that use a very different version). ltrace couldn't get any useful data from the binary.
Even though, many of the functions included in the binary were libc functions, identifying them as such wasn't trivial and several approaches were used.
No debug information and stripped
Including symbol names in the binary (invoking gcc with the –g option) makes using Gdb, or any other debugger, easier and more understandable, but also provides an easier interface for the analysts to access to the data structures and the functions used inside the program. This and other information can be removed by using the tool strip. This information would have been very helpful during the analysis phase.
Consecutive forks
One of the most common utilities to run against a binary, to get some ideas about what it does, is strace (or the corresponding one for your platform: tusc for HP-UX or truss for Solaris). This utilities print every system call made by the binary with some info about their parameters, and the return code. One of its options is trace the child processes. To be able to do this the utility must get the PID of the new process from the return value of the fork() function. This doesn't happen immediately after the call since it is usually the child process the one that gets scheduled first. Once it gets scheduled and gets the PID, the utility must call ptrace() to attach itself to the new process. If this is done twice, the second one right after the first, chances are good that the child process has some time during its quantum to execute the second fork, which will remain unseen from the main process. Of course, this also applies to gdb and fenris.
Ciphered communication
All the communication between the-binary and its clients and handlers is ciphered. We spent quite a long time to decipher the data, as well as the algorithm to encrypt/decrypt it.
Especific client
Due to the fact that "the-handler"expects to receive the commands to be sent using protocol 0xB, telnet or netcat utilities cannot be used to talk to it. An especific client must be developed to check the effects of the incoming packets to the binary.
6. Identify two tools in the past that have demonstrated similar functionality.
"The-binary" analyzed can be mainly classified as a DDoS, Distributed Denial of Service tool. The main goal of this type of attacks is to consume the target resources, typically the network bandwidth (Net Flooding), using to achieve its goal a great number of systems generating forged and artificial traffic. These methods are used in combination with other hacker methods, as IP spoofing.
The most common topology [1] used to orchestrate DDoS attacks has three main levels:
- The client or attacker that controls the attack.
- The handler or intermediate system acting as a relay of the commands sent by the client to all the potential attackers systems, also known as agents. It is capable of controlling multiple agents.
- The agent is the compromised system that is really sending the attack traffic flows directed to the intended victim. This host is from which the network packets originate.
In order to be able to launch a powerful attack, hundreds or thousands of host should have been compromised. To be able to compose a big topology as the one showed, he process of compromising a system should be automated. The different phases involved in the process are:
1. Scan hosts for a known vulnerability to be capable of introducing the agent into.
2. Compromise hosts and install the DDoS tool.
3. Use these hosts to scan and compromise more systems.
The propagation model taxonomy [2] could be defined based on three different models: central source, back-chaining and autonomous propagation.
The typical operating system to be compromised have changed through the time, mainly based on the network bandwidth associated with systems, from the various Unices available at universities, to the Windows home system using xDSL access technologies [2]. Not only systems but network devices are also the target of these DDoS deployments.
The main features implemented in "the-binary" are:
- 1) the DDoS streams of packets originating from this agent.
- 2) the usage of a covert channel used to send commands to this agent from remote locations, and from it acting as a handler to other remote agents.
It is a good idea to summarize some brief information at this point about the most common and well-know DDoS tools available "in the wild". Apart from the DDoS tools analysis, we are going to introduce the covert channel tools, due to the previous features commented.
1) DDoS tools:
The three most common protocols used in the different flooding procedures used by the DDoS tools are TCP, UDP and ICMP. "the-binary" is capable of using any of them.
The most complete DDoS tools available in Internet are: [3]
- Trinoo [4]
- TFN, Trible Flood Network [5] and its variants (TFN 2K)
- Stacheldraht [6] and its variants (STv4, ST v2.666)
- mstream [8]
There also exist other less known or just, more basic and smaller tools, as shaft [7], synk4 [9], neptune [10], smurf [11], that implements basic features as ICMP flooding, TCP SYN Floods, complemented with IP spoofing methods.
A brief summary of the main tools is presented:
- Trinoo: (the oldest one)
The same binary can run as a master or slave. It uses authentication based on password (crypt()). It was propagated initially exploiting a buffer-overflow. There is a Windows version called WinTrinoo. Master processes have a list of the agent host they can control, communication is not encrypted and the default communication ports were:
TCP: 1524 27665 (client-master)
UDP: 27444 31335 (master-server)
- TFN and TFN 2K:
The control channel used is based on ICMP packets: echo-request and echo-reply. It is very similar to "the-binary" because allows DDoS attacks based on UDP, TCP, ICMP and smurf. It also provides a shell through a TCP selected port.
In TFN 2K, clients and servers communicate through not fixed ports: these can be selected at execution time, randomly inside the program, and they are a combination of ICMP, TCP and UDP.
It also is capable of encrypting its communications, trying not to be detected by IDS systems checking well-known patterns in the packets payload
- Stacheldraht:
This tool is an advanced version of the previous ones. It allows the creation of a telnet encryption session between client and servers. The default ports used were (if not modified):
TCP: 16660 65000
ICMP echo-request and ICMP echo-reply
- mstream:
This is a beta version based on the source code of "stream2.c", a classic DoS tool. The communication channel used is based un UDP protocol.
It includes different options that allow controlling the DDoS topology of all the handlers and agents involved in the attack network. One of the most advanced management features it has is the session notification mechanism that allows other attackers to know if a new session with the tool has been established.
The default ports used were:
TCP: 6723 15104 12754
UDP: 9325 6838 7983 10498
Last and new type of DDoS attacks is knows as DRDoS, Distributed Reflection Denial of Service [12]. The goal of DRDoS is also bandwidth consumption.
The typical DDoS attack pattern, for example, the TCP SYN Flood, is based on sending thousands of packets to the same destination IP address from multiple sources. If the source IP address is the real agent IP address, the system will be identified as the attacker, and the attack can be identified easily, and combated by filtering by the source IP address. The source IP address can be spoofed just to hide the attacker identity, being more difficult, almost impossible, to differentiate between real and forged traffic.
In these new DRDoS attacks, the pattern used is based on sending packets with the target system as the source IP address, and the destination IP address being real Internet powerful systems. When these packets arrive to all the real Internet systems, they all reply to the target host. The target host will receive all the packets almost at the same time. To be able to use it, you must have the capability of creating RAW sockets.
- If it is based in he UDP protocol, as "the-binary" case 3, to amplify the attacker power, the request should be small and should have an associated response as bigger as possible. For example, the attacker goal should be to send a small 45 bytes packet, and obtain a response going to the target of big packet streams ("N" times bigger that the request). "the-binary" tries to used DNS recursive SOA queries for this purpose.
- If it is based in the TCP protocol, the amplification wave is triggered by the TCP retransmission algorithm. When a packet is not acknowledged, the TCP stack will resend it up to four times.
2) Covert channel tools:
The goal of a covert channel is to provide a communication tunnel in which it is possible to send control commands, typically to a shell at the other side [13], without being discovered. The main problem these tools might fight against are the filtering devices between the attacker and the target host.
The covert channels tools try to masquerade its proprietary protocol inside any of the allowed protocols in the network, as ICMP, UDP DNS queries, or even using more advanced methods setting commands in the TCP protocol header, in the fields that are not used cause they are reserved for future implementation.
The most well known tools "in the wild" are:
- Loki (ICMP). Later improved with the usage of the UDP protocol.
- Daemonshell (UDP, TCP and ICMP)
- Rwwwshell (HTTP)
- AckCmd (TCP ACK packets)
"The-binary" implements its own control channel through the usage of the 0xB IP protocol, and it has the capability of providing a remote shell protected by a password.
The next evolution in the communication channel is based on the usage of IRC, chat, channels. If you don´t filter the IRC associated ports, cause you allow your users to communicate through the chat system, it is very difficult to control that an agent is using an IRC channel to receive control commands and take actions based on them. This situation is very common in all the home users systems connecting to Internet through an ISP.
Summarizing, "the-binary" implements most of the well-known DDoS and covert channel features already implemented in the past in other tools, as multiple flooding mechanisms based on TCP, UDP and ICMP protocols, back-door control channel providing a remote shell, protection through communication channel encryption, both handler and agent roles in the same binary, and a big set of configuration options at execution time to configure IP addresses and ports in packets (including IP spoofing) and to control the behaviour of the different actions it can perform.
DDoS REFERENCES:
[1] DDoS News Flash:
http://www.cisco.com/warp/public/707/newsflash.html
[2] CERT Trends in Denial of Service Attack Technology
[3] DDoS tools and concepts:
http://staff.washington.edu/dittrich/misc/ddos/
http://www.hackingexposed.com/tools/tools.html
http://securityportal.com/research/ddosfaq.html
http://www.cert.org/reports/dsit_workshop.pdf
[4] Trinoo:
http://staff.washington.edu/dittrich/misc/trinoo.analysis
[5] TFN:
http://staff.washington.edu/dittrich/misc/tfn.analysis
http://packetstorm.securify.com/distributed/TFN2k_Analysis-1.3.txt
TFN defense tools:
http://www.keir.net DDoSPing
http://www.nipc.gov find_ddos
[6] Stacheldraht:
http://staff.washington.edu/dittrich/misc/stacheldraht.analysis
http://staff.washington.edu/dittrich/misc/sickenscan.tar
[7] shaft:
http://netsec.gsfc.nasa.gov/~spock/shaft_analysis.txt
[8] mstream:
http://staff.washington.edu/dittrich/misc/mstream.analysis.txt
[9] synk4: TCP SYN Flooding (by Zakath).
http://www.cotse.com/sw/dos/syn/synk4.c
[10] neptune: : TCP SYN Flooding.
ftp.infonexus.com/pub/SourceAndShell/Guild/Route/SYNFloodProject/SYNfloodProject.tgz
[11] Smurf: ICMP broadcast flooding:
CA-1998-01: Smurf DoS attacks: http://www.cert.org/advisories/CA-1998-01.html
[12] DRDoS
attacks:
[13] SANS Covert shells:
http://www.sans.org/infosecFAQ/covertchannels/covert_shells.htm
It is a very skilled person with a good knowledge of the necessary techniques to avoid detection, as well as a good level of TCP/IP.
The only two hints we found inside the binary were:
· This person might have some relationship with the University of Soutern California since the domain usc.edu is the only non toplevel or country domain used for the attacks among the main the ones.
· The password used for the backdoor is SeNiF. Looking for Senif in Google we found that is a common last name. But this might have many other meanings.
2. What advancements in tools with similar purposes can we expect in the future?
Several things can be done to make the analysis task more difficult and improve the capabilities of the binary. Some of them are:
· Include useless code
· Strong cryptography
· Self modifiable code
· Spoiling function signatures.
· Kernel modules
Include useless code
Adding code that does nothing useful between the useful lines would complicate the analysis phase.
Strong cryptography
Although being able to control the binary with a debugging tool would make difficult to keep something really secret inside the program. The difficulty of the analysis task would have grown a lot. Some parts, such as getting to know the format of the packet sent to the binary would have lasted very much longer.
Self modifiable code
There are many disassemblers, which help to translate the opcodes to mnemonics that are easier to understand. These tools get the byte codes from the text sections of the ELF file and, on demand, from the data section. However, if some part of the data is modified (decrypted or simply XORed) while in memory and then executed as code, the task of the disassembler gets very complex.
Spoiling function signatures
The best techniques for function identification use a number of bytes from the beginning of the function to create a signature and then compare it with a database.
Introducing virtual NOPs (instructions that do nothing) and changing the order of some operations (when possible) would make the identification method become u
Kernel modules
Including some functionality inside a kernel module would make the analysis phase very much more complicated and would allow hiding more information to the desired users (everybody but the intruder) and stronger capabilities.
Dynamic remote shell port
"The-binary" can provide a remote shell through a well known TCP port where it listens for incoming connections. An improvement could be to allow the change of this port number dynamically, at execution time. With this mechanism, it will be more difficult to detect and filter it.
Notify sessions
From the attacker point of view, it will be interesting to have a method of being notified about new connections tried against the agent, a method used in the mstream DDoS tool: http://staff.washington.edu/dittrich/misc/mstream_analysis.txt
Wether you get the proper password or not, all currently connected users are informed of the new session, so owner hacker will be notified of other parties (hackers or response incident teams) trying to connect to the agent.