Honeynet Scan of the Month 28
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
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.
§ 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.
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:
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:
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 IO-USERS
Statistics Type:ip Filter:<No Filter> |
<- | | -> | | Total | |
Frames Bytes | | Frames Bytes | | Frames Bytes | 192.168.100.28 <-> 22.214.171.124 64773 8432656 13104
1180790 77877 9613446 126.96.36.199 <-> 192.168.100.28
519 31140 18680
1120800 19199 1151940 188.8.131.52 <-> 192.168.100.28 285 17210 5196
311760 5481 328970
$ tethereal –nr day1.log –z io,users,ip >> users_day3_log.txt
Filter:<No Filter> | <- | | -> | | Total |
| Frames Bytes | | Frames Bytes | | Frames Bytes |
192.168.100.28 <-> 184.108.40.206 64773 8432656 13104 1180790 77877 9613446
220.127.116.11 <-> 192.168.100.28 519 31140 18680 1120800 19199 1151940
18.104.22.168 <-> 192.168.100.28 285 17210 5196 311760 5481 328970
SUMMARY EVENT ANALYSIS DIAGRAM
DETAILED TIME AND EVENT ANALYSIS
‘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,
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.
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”.
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)
email@example.com (Rootkit Email Address)
firstname.lastname@example.org (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
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.
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.
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/)