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=
<oink>
EOF