Answers to Honeynet's reverse challenge

We kept a log file of our findings in syscalls.txt, which doubles as configuration file for annotate.pl, which is a small perl script I wrote to annotate an objdump -dr disassembly dump of the binary. annotate.pl reads syscalls.txt and keeps a symbol table. Lines starting with a hex number and a colon were put into the table. If the string after the colon looked like a function (i.e. "\w+\(" in perl notation), calls to that address will be rewritten as "call name-of-function". Also, to make reading the disassembly easier, the code changes several of gcc's alignment "multi-byte NOPs" to real multi-byte NOPs, i.e. "nop; nop", "nop; nop; nop" and so on. annotate.pl is also able to annotate local variables in a function, the syntax for that is "funcname/0x8: arg1".

Q1: Identify and explain the purpose of the binary.

The binary does not carry any identifying marks that make for a good name, except for the letters "Gn" (see syscalls.txt for an explanation). Since that is an awfully short name, I hereby call this DDoS tool "Grand Nagus" (same initials, and it like the Star Trek figure it will ruthlessly maim his victims with back stabbing methods for his personal gain).

Q2: Identify and explain the different features of the binary. What are its capabilities?

The binary will answer to commands using protocol number 11 as well. However, it does not just send answers back to the same IP, but it has an internal list of 10 IPs and answers to all of them. One of the commands (2) can be used to set one or all of these 10 IPs (if only one is set, the rest is overwritten with random data). The binary itself does not know itself which one is genuine and which is not. This establishes some basic deniability for the one controlling the binary, because the initial command can be sent with a spoofed source IP and the answer is sent to 9 others as well, so unless the whole transaction is sniffed on his side, he can deny everything. It also makes it possibly to send the command from host a and read the answer on host b, which makes tracing even harder. This is optional, however. The binary can also only answer on one IP.

Over that channel, the binary can be

• discovered and told to return stats (returns some constants and whether an attack is running) [command 1].
• reconfigured (one or all of the IPs can be set, and spread spectrum mode can be enable or disabled) [command 2].
• told to execute a command using /bin/csh and return the first few hundred bytes of the output [command 3].
• told to launch a DNS based flood (see below) [command 4].
• told to to a normal UDP or ICMP based flood. The ICMP packets are "echo request" (i.e. ping) and the UDP packets deliberately have an invalid checksum [command 5].
• told to spawn a password protected root shell on port 23281 [command 6].
• told to execute a command using /bin/csh but throw away the output [command 7].
• told to clean up (kill the process doing the flood attack) [command 8].
• told to do the DNS flood with one more parameter set (whose meaning eludes me so far) [command 9].
• told to do a SYN flood [command 10].
• told to do a variation on the SYN flood where you can set one more parameter (don't know what it does) [command 11].
• told to do a variation on the DNS flood (same attack but use a destination IP that is configured as part of the command) [command 12].

About the DNS based flood

Previous methods of dealing with DDoS zombies focused on looking where the most traffic comes from and severing that link with static routes. With this attack, the traffic comes from the public DNS servers, not from the zombies. You can't sever the links to these important infrastructure components.

Also, since each zombie is seen by each public DNS server only every few seconds, there is no clear signal if looking by volume in the huge amount of normal DNS traffic for these servers. So, basically, you can't do anything if you are hit by this attack. That obviously makes this attack very dangerous.

Q3: The binary uses a network data encoding process. Identify the encoding process and develop a decoder for it

  void decrypt(int len,const unsigned char* code,
               unsigned char* plaintext) {
    int i;
    for (i=0; i<len; ++i)
      plaintext[i]=code[i]-23-(i?code[i-1]:0);
    plaintext[len]=0;
  }

  void encrypt(int len,const unsigned char* plaintext,
               unsigned char* code) {
    int i;
    for (i=0; i<len; ++i)
      code[i]=plaintext[i]+23+(i?code[i-1]:0);
  }

Q: Identify one method of detecting this network traffic using a method that is not just specific to this situation, but other ones as well.

Q: Identify and explain any techniques in the binary that protect it from being analyzed or reverse engineered.

Other than that, the code was not protected. It looked very obfuscated in several parts, but I doubt that was done on purpose. There are much better way to protect a binary from reverse engineering. If the author knew how to do it, he would have done it properly.

The binary sets its argv[0] to "[mingetty]" to avoid detection.

Q: Identify two tools in the past that have demonstrated similar functionality.

Q: What kind of information can be derived about the person who developed this tool? For example, what is their skill level? (Bonus)

Also, the commands are not authenticated by a check sum or cryptographic signature. That means one can accidentally cause random floods to be triggered if one gets the encryption routine wrong.

On the other hand, the DNS flood is a really bright idea. And the spread spectrum stuff is a clever way to protect the identity of the puppet master. This does not fit together very well. I guess that this code is the work of some not very experienced but ambitious kid who got access to the code of one of the existing similar tools and hacked it until it did what he wanted.

Q: What advancements in tools with similar purposes can we expect in the future? (Bonus)