The Honeynet Project’s Reverse Challenge

Submission by mrpiggy AT xs4all DOT nl, 24/05/2002

 

 

Dear reader,

 

This is my submission for The Honeynet Project’s Reverse Challenge 2002. It is very short and probably not detailed enough. Yes, even the use of English could be better. But I don’t care so why should you? By submitting I want to thank The Honeynet Project team members for the challenge and letting me have a lot of fun and late hours. So here you go guys, thank you plenty!!

 

Cheers,

 

MrPiggy

 

 

Tools used:

 

-          IDA for disassembling and analysing the code

-          GDB for debugging the binary on an egress filtered vmwared redhat box

-          Dress (part of Fenris) for un-stripping the binary

-          Perl for creating a client & sniffer (included at the bottom as canon fodder)

 

 

Answers to the questions:

 

0x01: Identify and explain the purpose of the binary

 

It's a slave program, which implements several remote access and denial of service tools. When started as root it quickly turns into a background process awaiting commands from its master. It tries to hide itself by changing its process name to ‘[mingetty]’. Commands and output are sent encrypted using a custom IP protocol. To cloak the IP address of the master, the slave is capable of sending data to decoy addresses.

 

 

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

 

The slave has the following capabilities. The numbering corresponds with the command ids used in the network packets. See 0x03 for more info on the packet structure.

 

 

(1) Echo command. The slave sends the received command back to the master (and decoys if cloaking was set up).

 

(2) Configure cloaking mode. This defines how the slave sends data back to the master. Cloaking is only used for commands #1 and #3. Three modes are available:

   

 Mode 0: No cloaking. Slave sends data to an IP address specified by the master.

 Mode 1: Slave sends data to an IP address specified by the master and nine random decoys.

 Mode 2: Slave sends data to ten IP addresses, all specified by the master.

 

(3) Execute command. Slave executes a specified command and sends the output back to the master (and decoys if cloaking was set up).

 

(4) Start a slow DNS response flood. The slave starts sending SOA queries for hard coded domains (‘com’, ‘net’, ‘de’, ‘edu’, ‘org’, ‘usc.edu’, ‘es’, ‘gr’ and ‘ie’) with forged source IP address to a hard coded list of 11.441 domain name servers. Most of these servers are located on high-bandwidth networks all around the world (lots of mil, gov, edu, ac.* and com domains). When a server receives the SOA query it will send the response containing a list of authorative servers for the specified domain back to the source IP, in this case the victim. A typical response is about 500 bytes. Flooding continues until the kill command (#8) is received.

 

(5) Start an ICMP or ICMP flood. Flooding continues until the kill command (#8) is received.

 

(6) Bind a shell on TCP/IP port 23281 for remote access. Access is granted after sending a login password: ‘SeNiF’. The ‘shellbind’ continues until the kill command (#8) is received.

 

(7) Execute a specified command, but the slave will not send any output back to the master.

 

(8) Kill any running flooder (#4, #5, #9, #10, #11 and #12) or shellbind (#6).

 

(9) Start a DNS response flood. Just like #4, but now with variable speed. Tested in a controlled environment the maximum speed was just over 1000 packets per second. The slowest speed possible was 100 packets per second (like #4). Flooding continues until the kill command (#8) is received.

 

(10) Start a slow SYN flood. The slave starts sending TCP/IP packets with SYN flag set to a specified victim IP address. If the victim's IP stack is vulnerable to a SYN denial of service attack it will seize to operate properly. The source IP of the packets can be as specified or random. If the victim is not vulnerable to a SYN flood, it will send back a flood of SYN+ACK packets to the source address, thus resulting in a nice backscatter or focused response. Flooding continues until the kill command (#8) is received.

 

(11) Start a SYN flood. Just like #10, but now with variable speed. Maximum speed in my test lab is near 1000 packets per second. Flooding continues until the kill command (#8) is received.

   

(12) Start a DNS response flood. Just like #9, but this time the SOA queries are not sent to name servers on the hard coded list, but to a specified IP address. Source IP of the DNS packets can be as specified or random. Flooding continues until the kill command (#8) is received.

 

 

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

 

The structure of the packets is as described in diagram below.

 

+-------------+

| IP Header   | 20 bytes

+-------------+

| Packet Type | 2 bytes. 1st byte is ‘type id’, 2nd always 0

+-------------+

| Payload     | 378 bytes. 2nd byte is ‘command id’

+-------------+

| Padding     | random size padding, 0 – 201 bytes

+-------------+

 

 

The protocol id in the IP header is set to 11, which of course is a nice signature for communication from and to this slave.

 

The two bytes right after the IP header are used to specify the ‘type id’. Possible values for the first byte are 0x02 for command and 0x03 for response. So, when the master sends a command it will contain 0x02. If the slave answers it will contain 0x03. The second byte is always 0x00 (nice signature).

 

At offset 22 (starting from zero) the payload starts. The payload is at least 178 bytes long, with a maximum of 378 bytes.

During transport the payload is encrypted, nothing serious really. Check out the Perl code below for the encrypt/decrypt functions. When decrypted, the first byte in the payload can be ignored. Setting this byte to something random makes the encrypted payload look different every time. It is comparable to a seed in serious encryption algorithms.

 

When it’s a command (type=0x02) packet, the second byte contains the ‘command id’, corresponding to the tools described in the previous answer. If it’s a response (type=0x03) packet, the second byte will define if the packet is first in a stream of packets or not: 0x03 for first packet, 0x04 for all others.

 

Right after the payload is a random number of bytes of unspecified values, which we can ignore.

 

The total length of a packet varies from 400 to 601 bytes.

 

sub encrypt {

 

 my @src = map { ord($_) } split(//,shift);

 my @dst = ();

 

 my $n = $#src + 1;

 

 my $val = $src[0];

 $val += 23;

 $dst[0] .= $val & 255;

 

 for(my $i=1; $i<$n; $i++) {

 

  $val = $src[$i];

  $val += $dst[$i-1];

  $val += 23;

  $dst[$i] = $val & 255;

 

 }

 

 return join('', map { chr($_) } @dst);

 

}

 

sub decrypt {

 

 my @src = map { ord($_) } split(//, shift);

 my @dst = ();

 

 my $n = $#src + 1;

 

 my $val = $src[0];

 $val -= 23;

 $dst[0] = $val & 255;

 

 for(my $i=1; $i<$n; $i++) {

 

  $val = $src[$i];

  $val -= $src[$i-1];

  $val -= 23;

  $dst[$i] = $val & 255;

 

 }

 

 return join('', map { chr($_) } @dst);

 

}

 

 

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

 

Look for IP packets with protocol value 11, the 21st byte is 3 or 4, 22nd byte is always 0. Total packet size (including IP header) ranges from 400 to 601 bytes.

 

 

0x05: Identify and explain any techniques in the binary that protect it from being analysed or reverse engineered.

 

The binary was compiled statically, stripped of any symbols and linked to an exotic C library (‘The Linux C library 5.3.12’). With so little info, it just took extra time to understand the inner workings. The binary tries to protect itself from being debugged by forking more than necessary. This way the debugger loses control of the forked child and the code slips away. But having first reverse engineered the (dressed) code and knowing what it was capable off and what not, I just ran the binary and when needed I attached GDB to a child process.

 

 

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

 

Trinoo

http://staff.washington.edu/dittrich/misc/trinoo.analysis.txt

 

Tribe Flood Network (TFN) -

http://staff.washington.edu/dittrich/misc/tfn.analysis.txt

 

 

0x07 (bonus#1): What kind of information can be derived about the person who developed this tool? For example, what is their skill level?

 

It's a quick and dirty tool developed by a single pragmatic person or possibly multiple people each responsible for their part. It's curious why the tool contains two versions of a SYN flooder, one slow one and one with variable speed. They both do the same thing. Maybe it's an revision of an old tool and it still there for backwards compatibility? Who knows?

 

 

0x08 (bonus#2): What advancements in tools with similar purposes can we expect in the future?

 

You have to take a step back to see the whole picture. The master wants to compromise as much systems as he can to build a powerful network of slaves. For the master it's more important to compromise as much system as possible than make its slave more intelligent or stealthy. Power in numbers. Of course, when new and more destructive attack methods is devised we will see new kinds of slaves.

 

 

 

Canon fodder:

 

mrpiggy@trog$ md5sum canonfodder.tgz

570b36b985a551200762c7976608e024  canonfodder.tgz

 

mrpiggy@trog$ tar tfvz canonfodder.tgz

-rw-r--r-- 500/500        8380 2002-05-22 14:49:44 client.pl

-rw-r--r-- 500/500        1267 2002-05-22 14:49:45 sniffer.pl

 

mrpiggy@trog$ encodebase64.pl < canonfodder.tgz

H4sIACCn7jwAA+1a/0/juBLfn/tXzBZ2SR5tSEKhQK88VrD7Dukti+jdk54WtAqNS3OkSZSEA8Tx

v7+xnS9OmrTd7hZOTx4k4nrsmbH9ycw49tB1iBdrgftmdaQbur7b6bzRkbq7xaeum7rZxXK30zW7

htHd0d8wrvEG9BXalNFdFFshwEuo+jvS2tutuyjcuna8rYCELrTvG3cRgSgOnWHcY+WBP7wlSfmM

xAcHF9b96Xmv0WisRcSzjye2EjjejaKqvbwmIvEgCK3HL0Hs+F6RF5KJHxNaat551oRA2+rZI2jf

NovNfD8ejInrFnuTBzJkfW0rJvAX3IcOPkeudfsIQRxt6UUpdHnjk7PBBYkC34vIJ9f37YHr3ytN

w9zWOjvablfb22+2YH+/0PHWcd3jsePayrS8cxwvE4RCNPaH/Zumxv4q9P9+cl7ffEpzpcn/sULH

unbJICDErrC9BebOznwx/yIewaUVDUFRnYI53yPowvJsfzLw78IhUebJGPz3TJz+zII9HfW7/tBy

x34UV8yf2LGoURRS3688eXWa59hdEFNvRyal0fgpYiKXkACMXqMamg3y4MRUWSO6u4akDTw1GjB5

hPXAenR9y4Y+RGNnRNuxagsrPHIvvNDK0w1f0v7h0/MzysVG7UN8j5WnBoATQP8QaCmhIPRjf+i7

tNowWjnDtmw7pLUb2bxuCOzYjyhTF6tiJgVHK1Q6NpOM2BRqn2kxMbNkD3oDi1YNx6Fiqhp96KpG

vGH4GMRKOg1q3oHKEobp4WTi5DxTt9ZYg36ZsO74y+fPH85O4NOH49++XJx+HFS3QwFwetI32HJQ

z8jWIggdL4Ym95SXXrM3tT6JyfRhUFMgJPFd6EFg2bn93ESmwGQKhr43cm6Yry2pKnLmKzWZ0jWI

aA/wmeOODmiNTsHicwaKaoHvuY8MabicYJOR4xEbTs9pW4MijUkosABhDhPrQQPi3IxjCBnskRHR

TqbYKSae0JHx/4F817klYDRy47XU+t50pWF2MwwU5xWlZbjEeSx3NFV4gE6vgrNdy+nUcnZqObu1

nG4tZ6+Ws1/LMfSENQtOHE/bDE9ZcGZQOvqGCMc19UOwHQJNz4+BeP7dzRjlhBi7YxJGGayGkyk/

U4m0bVWjbXHdMrDmOcFlk/Iumyle57wFHe716qK8MApzwVFQZOTD4KPww7g8sj8xQXImiOw+IFTj

b1aMeQ7rrGaKhpa3gVgnke/+SbjkZk/sfs4F00lRuJbDQ8B1fg/6w2jEZ4vXJzUz57WjaujfMss0

6ubwfWaxBT14zqNqNYFHNSA3EZU4yDWgGR/vANR0lqspet/zMWnoP5KIetNmU4OcMolp+0xqL3dM

9SkZrj3teInxj416QQzsKJaawyBNtoSl315w6aNwWFp5eyEsYL8yELCqFgfIa+byyz3tGQiycwBh

UUBPESS4DsxFWy59BfQ2hlZ4+/btLOzsMOxwJ6lhf5xFipdEi5aUEVS0xMarCYhZy0y0SRQ7nkWD

B0dHsvzYxPNFbg6RIjCyXBnBgHooFrBkL4OKawEVWcq+hEeYA4tXwcBCS8mX5vT483mhglqfvPIv

tKj5hml6VRdczl0entJNYUWCK0zBruhvhI3kYqq6TFWy0VxhHOymcTAzNd3cfmcQ3GMGZ9uC2XOz

J86NsJVYTNV+fbwt7GuW8L5zAy9/z5j0v0kwZr1HLH4lZrFG3EbBG+v9CD0x29H1x48Bjpq2mLVK

+6VYTn/kirRSLH/l4L1s4Db0QuQWt/lL4GderJ725TP9b2Wc/S5g1ISE2Vs/XS0FWyEE5+GZfaTD

ofCsrsJ1cwgqFHbontUCj3YW1jhFwVq1J68DQeFrTilEM+/O/PziSLiuQYL4hWSJ4L1YBrcKDPzI

KuvTqzy9nc0fYpoPCp0Q7GrDmIREfUVYFD5uLZfFGUali6iLNZ2V+Yr64PPy/mN1YccwfsT9lCLU

qqBV/Jxb63payXotjrQqF1T7tXZlEepFMfY6KCq7N56ZqD/m5V4DfbM83Pfizyx4upoDlyV83bQb

q0DdNDQrcbj8LheLy2J0+Y8kq0G3WUZ3nQNMB/3a+Xl66pcDVPCRy0H1ej5Up5zl7BNJXWN/aJLe

QoSn+ioOWbDq14//Pv94AZ9+Pzv+7fTLWdVRDD2JYUcw1szTsKrzBN7YJR49dyDeTTwWpwGcESiM

+wsY3X2VHUOJYjY+bMADKMiDNhNDOz3n05q25SNk3xr4OVVq5xF/ZSdWAE+IclyEbyo8Y/LmOrGy

tdVixidvxxF/c5XMbGr0+hqVsEkPDZMdruXSaqz9ql/RAxNasYlZ9Db9gSKwmprO6t/Tl4H2HPmh

Qns7faOH/39Z9+hjc1NlhhakrjtUbCaXiVx32kahlmlLeVdQVidM0R++4ykbG61kDtiry+bgiIc9

OnGvfXfi/4EizxmNSLjSC0Cz7//o5vbutnD/x2Dtja68//MSVLr/M3X5p3DhZ/2vzU18UKdjpS6n

+jJBj9UHQ3x5++yAnRYdD71X0/Xp5RdM4NgNAjDYFZQdHX0+LjtzvkkkG9BoQc+0Merf++EtoAj0

DVijaRqPUxg/Aq6mBW0Do9p7e4LFyyOrl1yHwN+pTx36kwk9hZ7hVwG74Oix+qt5hQZ1Nk16DYPe

suDxdaQ0j7mYA3inmw/sH9qC8TMRj35U+GFcYY4xnUu4TqDYhF9NqFC5iRrTOFMOP4nrpQMaE8sm

4ULjSXq39BYfTDaaX5mMqcFw0XwsSTkdCs/I2G2LKfEmky2aTRuqPEJmOk+w7gC+vrOvvr6LrpjC

QvMWl89kPQNxIyL0h6Q7PXfAAsMBsMiRNW1kTc98SExLAMMaJkxek0ZguiZZmhBa92KKIA4IWSoc

QgehyuN+0jaZCfzF8pcOgzJTxxPuiOWvNnlI2jQvaabDJkzIC2izPkIZ/skFHxQE6y3aQs3ThgRD

i6YN8JPyhnYpb/hJaUM7qxPThrZMGyRJkiRJkiRJkiRJkiRJkiRJkiRJkiRJkiRJkiRJkiRJkiRJ

kiRJkiSpgv4HL/6dBgBQAAA=

 

mrpiggy@trog$ ^D

 

<oink>

EOF