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