The binary hides itself as a '[mingetty]' process and listens in the
background for ip traffic, with protocol 11 (0xb). Via this protocol
it can receive commands from a remote hacker. The hacker can use it
to launch DoS attacks on specified hosts and to execute any command
it likes on the machine on which the-binary is running.
After hiding in the background it listens for commands using a raw socket
with ip protocol 11. There are 13 different commands that can be received,
see the analysis for what they do. These 13 commands include:
- Executing commands optionally sending the results back in encrypted form
- Executing SYN, fragmented IP and UDP spoofed DNS DoS attacks
- Binding a rootshell to a port requiring a password to activate it
The encryption used here is actually very weak, and is only used to make the packets look
less suspicious. The encryption of the incoming and outgoing packets is based on the following
Encoding: e = (plain+last+17h) mod 256
Here plain = the plaintext char, last is the previous encrypted byte (first time 00)
Decoding is trivial: plain = (e-last-17h) mod 256
Constructing a decoder is trivial and can be found in the analysis.html file.
We have to consider 2 types of network traffic here:
1. Traffic on non standard IP protocols
2. Traffic with a spoofed source IP
The first: Traffic on non standard IP protocols can be blocked pretty easily using the firewall and can be
detected by IDS systems such as snort by enabling the
'Non-Standard IP protocol' and 'Unassigned/Reserved IP protocol' rules in bad-traffic.rules.
These rules are present in this file but disabled by default.
Blocking traffic from a spoofed source address: RFC 2827
describes a method which will stop computers on your network from starting
DoS attacks by filtering all packets source addresses in your own network at your router/firewall. There is however
little that you can do to prevent these attacks when the spoofed packet is received because it is impossible to tell
if a packet is spoofed or not.
The-binary protects itself by having a corrupt elf header with no symbols and by using some excessive forking that can trick some debuggers.
The problem with this protection is however that it is completely useless. Strace has no problems with the file and IDA can easily disassemble it.
When we want to use gdb we simply attach to the running process and to debug the parts where it forks off we simply remove the call to the fork code
by replacing it with nops using a hex editor. The question remains why this poor protection was choosen, there are some good protectors for the ELF
format available on protools which could have made it harder to reverse engineer the target.
Some utils very similar to the-binary can be found at:
Packetstorm's distributed attack tools section
Utils that have similar functionality (remote command execution and DoS attacks) include
Tribe FloodNet 2k and Omega. Which can both be downloaded from this webpage. Both of these tools allow a variety of DoS attacks
and remote control of the system and use encryption. Tribe FloodNet 2k appears to be superior to the-binary but is better known so
it will be detected more often than the-binary itself.
Bonus question 1
I have some mixed feelings about the person who developed this tool. I think the attacker is a pretty bad coder, we can see this
for example because there is a lot of useless/duplicate data in the-binary. And some routines (the decryption routine being the most
clear example) are implemented in an almost stupid way. The use of childish encryption ciphers such as the caesar cipher surprise me
because alternatives (for example blowfish) are easily available a slightly modified version of such an algorithm would have been
a lot more difficult to analyze for a reverse engineer.
Bonus question 2
The first advancement to be expecting is I guess worm capability. So that the DDoS slaves will start infecting more machines to add to the
pool of attacking machines and automatically update themselves with new exploits to be able to infect more operating systems.