Challenge Answers
By Craig Smith
1. Identify and explain the purpose of the binary.
The purpose of the binary is to remotely control this machine through
stealthy network means. It is meant to be a single binary that can be
communicated with over a covert channel and instructed to do many different
task both on the local machine and on remote machines. A large focus
seemed to be on stealth.
2. Identify and explain the different features of the binary. What
are its capabilities?
The binary has many different features and capabilities. After executing
this binary it forks off a process that forks off a daemon process that
listens to a raw network socket. This process hides it's true name and
shows up as "[mingetty]". The raw socket that it listens on
is not a standard socket such as TCP or UDP but a covert channel. Most
public covert channel applications use ICMP or IGMP but this one uses it's
own RAW IP protocol. The protocol number it binds with is protocol 11.
The reason it uses a RAW protocol is an attempt to bypass firewalls and
perhaps to help obfuscate it's communications further.
When the intruder is communicating with this daemon they can initiate a fully
interactive shell with the system. This shell executes the default /bin/sh
and unsets the HISTFILE variable which disables command logging by BASH.
This shell actually is a forked process on another RAW port. It requires a
password to open the SHELL. The password it needs is "TfOjG". If the
password is not right it sends back a "fffb01". The
daemon also has the ability to execute individual commands on the system with
out initiating a fully interactive shell. It does this by calling "/bin/csh
-f -c "%s" 1> %s 2>&1". Where %s is substituted with the command
to run.
The binary also exhibits the capabilities of opening the following socket
types: TCP, UDP, RAW IP, Protocol 11 and Protocol 255. These connections
appear to be used solely for outbound connections. This makes for more than
just a covert backdoor but also a tool or utility to communicate with
other systems.
While debugging the program I noticed that my debugger would mis-interpret
some instructions and cause the executable to crash. I was unable to conclude
if this code was intentionally placed to foil debuggers or merely a coincidence.
3. The binary uses a network data encoding process. Identify the
encoding process and develop a decoder for it
Unfortunately my debugger (gdb) seemed to get a bit confused at this level
and review the raw assembly dump provided by objdump became a bit confusing
here. So I was unable to determine the encoding method or decoder for
this network protocol. As of 5/29/02 I noticed that the snort.log containing
a few encoded packets was put on the web. Using this I was able to locate
the encoding algorithm (Function starts 0x804a194). The algorithm
basically subtracts 17*char_position. After unwrapping the packet with
this algorithm it appears to check to see if the value is null. If not
I believe it does the following:
mul 0x41c64e6d to the value
add 0x3039 (12345) to it
and then and's 0x7fffffff to it
This happens at 0x8055e38, but I'm not really sure about this. At any rate
I decided to stop analyzing the encoding and built a decoder for what I
understood. This decoder is included but it more of a proof of concept
app than a tool. Usage: decoder.pl snort.log
4. Identify one method of detecting this network traffic using a
method that is not just specific to this situation, but other ones
as well.
The quickest and most obvious method is to check for protocol 11 traffic.
Since this should be very rare if not completely non-existent at this time,
you could use the protocol as an identifier. Here is a snort rule that
would detect this traffic:
alert ip $EXTERNAL_NET any -> $HOME_NET any (msg:"Protocol 11 Traffic. Possible Covert Channel communications"; ip_proto: 11; )
Although this method would work it has its problems. The above signature
may be too general. It would be better to also identify other sections in the
traffic that this particular binary uses to ID it's own packets. This would
allow a security professional to better assess the threat and help limit
false positives.
alert ip $EXTERNAL_NET any -> $HOME_NET any (msg:"Protocol 11 trojan, Client to Server command"; ip_proto: 11; content: "|0200|"; depth: 2; )
alert ip $EXTERNAL_NET any -> $HOME_NET any (msg:"Protocol 11 trojan, Server outbound communication"; ip_proto: 11; content: "|0300|"; depth: 2; )
5. Identify and explain any techniques in the binary that protect it
from being analyzed or reverse engineered.
There is a strange .init section that I haven't seen in many other
binaries, though I must confess I don't dissemble tons of them. I notice
that within GDB the section after it receives a protocol 11 packet GDB will
misinterpret the assembly code and crash the executable. I could not find
any evidence to conclude that this was intentional. It does appear that
objdump could properly decode it though. The binary also encrypts and pads
most of its packet payload. The encryption technique does not appear
to be an advance algorithm but more of an encoding method.
6. Identify two tools in the past that have demonstrated similar
functionality.
The first public tool that works similar to this binary is a utility
called Loki. This utility was first described in a popular internet
security zine known as phrack. The topic was first discussed in a story
published in Nov of '96, Phrack 49.
Actual example code was later published in the same zine in
Phrack 51, published in July '97. The published code was technically version to of the Loki application.
This application can communicate via ICMP and UDP packets. It would hide
it's communications in ping request/response packets and DNS request packets.
It also had capabilities of using encryption within the packets. It's method of
forking processes to get a daemon process listening on a raw socket is
almost identical to this binary.
Another very similar application is one written by s0ftpj known as 007Shell.
This is a spin off of Loki's utility but uses only ICMP replys and pads
the size so that it appears to be more like a normal ICMP packet. This
utility doesn't try and use encryption in the packets. The author of 007Shell
, FuSyS, also wrote an article about this tool in BFI (NOTE: It's in Italian).
Bonus1 What kind of information can be derived about the person who
developed this tool? For example, what is their skill level?
The developer is rather skilled in C development and has experience in
the subject of covert channels and trojans. This seemed to be a culmination
of many common trojans and attacks lumped together in one convenient yet
stealthy binary. I would say that this intruder is rather skilled or
was handed a nice little binary by someone who was skilled.
Bonus2 What advancements in tools with similar purposes can we expect in
the future?
I expect that the binary will display even more functionality and greater
control of the environment. It would not be a far stretch of the imagination
to see a utility very similar to this one as a kernel module instead of
a simple process. That would enable a much greater possibilities in stealth
and control. Also I suspect an improvement in encryption algorithms for
both the binary and the packets themselves. Self-encrypting binaries on
Linux are still rare but are slowly becoming more prevalent.
Back to Index