Honeynet Scan of the Month 28

May 2003

Michael Capp

myntric<@>ameritech.net

Dedication: This analysis is dedicated to my very near future wife, to whom I love with all my heart and will be married to on Saturday, May 24^th, 2003 who stands by me and encourages me as I spend numerous hours pursuing my passions.

Table of Contents

1. Challenge & Analysis Overview... 5

Binary Verification.. 5

Tools. 5

2. Questions. 5

a. What is the operating system of the honeypot? How did you determine that?. 5

a. How did the attacker(s) break into the system?. 6

b. Which systems were used in this attack and how?. 8

c. Create a diagram that demonstrates the sequences involved in the attack. 8

d. What is the purpose/reason of the ICMP packets with ‘skillz’ in them?. 8

e. Following the attack, the attacker’s enabled a unique protocol that one would not expect to find on an IPv4 network. Can you identify that protocol and why it was used?. 8

f. Can you identify the nationality of the attacker?. 8

3. Bonus Questions. 9

a. What are the implications of using the unusual IP protocol to the Intrusion Detection industry? 9

b. What tools exist that can decode this protocol?. 9

4. References. 9

1. Challenge & Analysis Overview

Members of the AT&T Mexico Honeynet captured a unique attack. As common, what is interesting is not how the attackers broke in, but what they did afterwards. Your mission is to analyze the network capture of the attacker's activity and decode the attacker's actions. There are two binary log files. Day1 captured the break in; Day3 captures some unique activity following the compromise. The honeypot in question is IP 192.168.100.28. Make sure you review the challenge criteria before submitting your write up.

Binary Verification

Tools

§ Ethereal/tethereal 0.9.12 (http://www.ethereal.com)

§ tcpdump 3.7.1 (http://www.tcpdump.org)

§ file 4.02 (http://www.gnu.org/directory/text/wordproc/file.html)

§ tcpflow 0.20 (http://www.circlemud.org/~jelson/software/tcpflow/)

Upon successful binary verification, ‘tcpflow’ was used to reconstruct the data streams based on the provided logs and separate these streams into separate files for easier analysis. A detailed description of ‘tcpflow’ from the website is: “… a program that captures data transmitted as part of TCP connections (flows), and stores the data in a way that is convenient for protocol analysis or debugging. Tcpflow understands sequence numbers and will correctly reconstruct data streams regardless of retransmissions or out-of-order delivery.”

Based on the above execution, the following are examples of the file sets that were created based on the stream analysis based upon those extracted from the Day1 logs:

Once the data stream had been briefly examined and separated, Snort and tethereal were used to compile general Summary Statistics on the log files. Certain irrelevant information has been omitted. The results revealed some interesting statistics on this successful attack. In addition to the normal IP traffic generated by an attacker, there appears to be an excessive amount of ICMP and IPv6 traffic, which is unique in this scenario in what the attacker did once the initial attack took place.

2. Questions

a. What is the operating system of the honeypot? How did you determine that?

There are two specific indicators that the honeypot is Solaris/SunOS-based, specifically SunOS 5.8. The first is that the attack that compromised that honeypot is based upon the buffer overflow in the CDE Subprocess Control Service (http://www.cert.org/advisories/CA-2001-31.html) vulnerability (see Question 2 for additional detail). Secondly, after the attacker had exploited the vulnerability above, they executed a ‘uname’, which is used to retrieve and print system information, to retrieve the basic system information with the following results:

a. How did the attacker(s) break into the system?

In the following packet sequence, the attacker sent numerous characters to the CDE service on port 6112 on this honeypot, causing a buffer overflow in the dtspcd process:

The buffer overflow exploit allowed the attacker to execute root privileged commands such as the following retrieved from detailed output via ‘tcpflow’:

Based upon the preceding command, the attacker executed code through dtspcd and added a line to the ‘inetd’ configuration file to create a backdoor that executes an interactive shell. The configuration below is from the ‘inetd’ man page:

The purpose of the argument, ‘sh –i’, is to launch a shell upon a connection directed to port 1524, ingreslock.

The following are excerpts from CERT Advisory CA-2001-31 (http://www.cert.org/advisories/CA-2001-31.html) containing additional information on this vulnerability:

CERT Advisory CA-2001-31 Description – The Common Desktop Enviroment (CDE) is an integrated graphical user interface that runs on UNIX and Linux operating systems. The CDE Subprocess Control Service (dtspcd) is a network daemon that accepts requests from clients to execute commands and launch application remotely. On systems running CDE, dtspcd is spawned by the Internet services daemon (typically inetd or xinetd) in response to a CDE client request. dtspcd is typically configured to run on port 6112/tcp with root privileges.

Immediately following the compromise, the attacker then proceeds to execute both scripted and manual commands in order to retrieve/download rootkits, trojans, and other tools. The following strings have been selected based on their relevance to the analysis and do not represent the data stream(s) in their entirety.

The above command execution retrieves details on the system, creates the initial shell environment and displays the Process Identifier (“PID”) of the “BD”, which in this case I believe is an acronym for “Back Door”. Once complete, the attacker unsets the HISTFILE and DISPLAY and creates a temporary directory to store the downloaded files as you will see in the following:

The above shows the attacker retrieving files from an FTP location and executing both “solbnc” and “dlp”. Upon further investigation, I believe “solbnc” Stacheldraht. Stacheldraht is a distributed denial of service (DDoS) tool based upon the source code of Tribe Flood Network.

Following the above, the user attempts to retrieve an additional file or file(s) using WGET, however, has many problems attempting to execute the program. Following this, the attacker uses a script to remove the logs created during this process.

The attacker now proceeds to replace the ‘inetd.conf’ and kill the process prior to executing a patch entitled “Attivata”, which translated means “Activated”. The instance of ‘inetd’ being killed is also reflected in the following packet, which is notifying the syslog daemon that the process was killed:

In addition to the above activity, a search for the word “trojan” within the Day 1 log data reveals a script had run to execute and install numerous trojans to allow back door entry into the honeypot. The following details the script results:

Interestingly enough, during the procedure where the attacker was trying to install their own trojans, the script that checked for known login trojans detected the following first:

b. Which systems were used in this attack and how?

The first step was to identify the systems that sent and received the most frames and bytes with the assumption that these were involved or used on a regular basis during this attack. The IO-USERS Statistics retrieved via tethereal detail each and every IP Address sequence with the total data retrieved from the log. The following command line was used to retrieve this information:

$ tethereal –nr day1.log –z io,users,ip >> users_day3_log.txt

$ tail –n 252 users_day3_log.txt | more

IO-USERS Statistics

Type:ip

Filter:<No Filter>                        |       <-        | |       ->      | |     Total     |

                                          | Frames   Bytes | | Frames Bytes | | Frames Bytes |

192.168.100.28    <-> 195.130.233.20      64773    8432656    13104   1180790   77877   9613446

205.177.13.231    <-> 192.168.100.28         519      31140    18680   1120800   19199   1151940

192.114.144.52    <-> 192.168.100.28         285      17210     5196    311760    5481    328970

Based on the data provided above and from viewing the remaining information with ‘tcpflow’ and Ethereal, the following addresses were used during and most likely by the attacker. Please note that these were not necessarily involved in the initial attack of this honeypot, but the identification of these addresses provides additional details on traffic patterns.

c. Create a diagram that demonstrates the sequences involved in the attack.

SUMMARY EVENT ANALYSIS DIAGRAM

DETAILED TIME AND EVENT ANALYSIS

d. What is the purpose/reason of the ICMP packets with ‘skillz’ in them?

‘skillz’ packets, when associated with the ICMP protocol, is commonly associated with the Stacheldraht (“German: Barbed Wire”) distributed denial of service (DDoS) tool. While most Trojans of this type utilize TCP/UDP for communications, Stacheldraht utilizes TCP and ICMP. Specifically, the communication between the handler/master control and the agent takes place using the ICMP protocol. For instance, based upon findings by David Dittrich, University of Washington, (http://staff.washington.edu/dittrich/misc/stacheldraht.analysis) the ‘skillz’ text seen throughout this capture is an ICMP_ECHOREPLY packet with an ID field containing the value 666. If the master receives this packet, it sends back an ICMP_ECHOREPLY packet with an ID field containing the value 667 and data field containing the string “ficken”.

Remote control of a stacheldraht network is accomplished using a simple client integrated with symmetric key encryption to provide a reasonable level of secure communications between the handler/master and remote agent.

e. Following the attack, the attacker(s) enabled a unique protocol that one would not expect to find on an IPv4 network. Can you identify that protocol and why it was used?

The following was executed against the data streams output by ‘tcpflow’:

Once the file was retrieved, the following happened:

First, “Inserisci il tuo IPV6”, which roughly translated with the assistance of http://babelfish.altavista.com, is “Insert IPv6” is echoed to the screen. After the preceding text is displayed, the ‘read’ command, based upon the man page entry, reads a line from standard input, which in this case is “ipv6tuo”. Once complete, the text “..Okz” is echoed to the screen.

Following this, “Inserisci l’IPV6 dell’IRCServer”, which again is roughly translated to “Insert IPV6 IRCServer” is echoed to the screen. After the preceiding text is displayed, the ‘read’ command reads a line from standard input, which in this case is “ipv6server”. Once complete, the text “..Okz” is echoed to the screen again.

Finally, the command to create an IPv6 tunnel between the IPv4 (ipv6tuo and ipv6server) addresses is issued and added to the below file. The actual command line reference is as follows:

ifconfig ip.tun0 inet6 addif <my-v6-address> <peer-v6-address> up

Echo “addif ipv6tuo ipv6server up” >> /etc/hostname6.ip.tun0

The tunnel was created in order to communicate on an IPv6 implementation of IRC, of which the conversation(s) the attacker had during this time are captured in Appendix C. The IPv4 IRC sessions are detailed in Appendix A and Appendix B.

In addition, the attacker uses the IPv6 hop-by-hop option type RFC 2460 (http://www.ietf.org/rfc/rfc2640.txt), RFC 2711 (http://www.faqs.org/rfcs/rfc2711.html) that, in summary, informs the router that the contents of this datagram is of interest and to handle the data accordingly. Based upon this option, this hop-by-hop datagram contains a multicast listener discovery message RFC 2710 (http://www.ietf.org/rfc/rfc2710.txt), which enables each router to discover the presence of nodes wishing to receive multicast packets on directly attached links. This entire method is documented in RFC 3056 (http://www.ietf.org/rfc/rfc3056.txt); “Connection of IPv6 Domains via IPv4 Clouds”.

f. Can you identify the nationality of the attacker?

This particular attacker was most likely of Italian origin. This conclusion is based upon the fact that the attacker used many Italian services and domains in the course of this attack and spoke in Italian while chatting on IRC:

www.xoom.it (Web/FTP Storage)

irc.edisontel.it (IRC Server)

bobbinos@tiscalinet.it (Rootkit Email Address)

pasquale.toma@fastwebnet.it (SunOS Rootkit Email Address)

interbusiness.it (ISP Domain used in IRC sessions)

The “.it” Top Level Domain (“TLD”), as referenced by IANA (http://www.iana.org/root-whois/it.htm), registered to the following Sponsoring Organization, providing further indication of the attackers’ origin:

IIT – CNR
Via Moruzzi, 1

Pisa I-56124

Italy

In addition to the above information, the SECHO command issued as noted in Packet 16843 of the Day 3 log indicates the attacker is using Windows NT and mIRC v1.5.61 32-bit.

3. Bonus Questions

a. What are the implications of using the unusual IP protocol to the Intrusion Detection industry?

First and foremost, a majority Intrusion Detection Systems (“IDS”), as they are today are signature-based. This means that each packet that passes through the designated IDS or sensor is inspected and compared against a rule-base or signature file for known exploits, attacks, or other suspicious activity. With the widespread use of IPv4 within the corporate world, most IDS vendors have not yet implemented full decoding of the IPv6 protocol within their product(s). For instance, Snort™, the de-facto standard for open source network intrusion detection, does not yet contain code to decode IPv6 packets as they pass thru the inspection engine.

Secondly, the IPv6 protocol contains many optional extensions and requires complex processing, differing from that of IPv4, that can make it diffcult for signatures to be developed for IPv6, even if the IDS engine contains the support.

b. What tools exist that can decode this protocol?

There are currently very few forensic tools that support the IPv6 standard. The following have been found and used to decode and analyze IPv6 packets with a relatively complete implementation of the protocol:

§ Ethereal >0.3.15 (http://www.ethereal.com)

§ tcpdump >3.5 (http://www.tcpdump.org)

§ COLD >1.0.12 (http://www.ipv4.it/cold/)