Scan 27 - April 2003

Author: Diego González Gómez
dggomez@users.sourceforge.net

Table of contents:

• Analysis
      General Approach
      Identifying the suspects
      Discovering the attackers and their methods
      Results

• Questions
      Beginning Questions
      Intermediate Questions
      General Questions

• Conclusion

• References

Analysis:

The first step is to download and verify the binary file:

Then I tried to extract the contents:

It seems to be a tcpdump file, so I can work directly with Ethereal and tethereal. If it were compressed it would occupy 13 MBs.

General Approach

The first step is to take a general perspective of the contents of the binary file. I entered various tethereal commands to obtain summary information which allowed me to view the most significant activity.

The results show that, over the link layer (ethernet), there is only IP traffic. The protocols figured in the next layer are only TCP and UDP.

• UDP: Here, it is used to carry NBNS (NetBIOS Name Service), and DCERPC (DCE Remote Procedure Call) information.

• TCP: Under TCP tree, the most active protocols are: NBSS (NetBIOS Session Service), HTTP and IRC.

Because of those results I decided to get more detailed statistics.

The first command was not really necessary. But the use of NetBIOS appears to be important, and I decided to investigate in more detail SMB protocol activity.

The Server Message Block Protocol (SMB), resides in the application and presentation layers of the OSI model. It is used to implement network session control, network file and print sharing and messaging. File sharing via FTP or NFS plus network printing via LPR may be compared to SMB. They are functionally similar and are protocols found within the TCP/IP suite. SMB requires a transport /session protocol and the early versions of IBM's implementation were closely linked with NetBIOS. In general SMB runs either over the NetBIOS Frames Protocol (NBF), NetBIOS over TCP/IP, or NetBIOS over IPX. [1]

The number of SMB 'Transactions' (641) and 'Session Setup AndX' (198) is significant. We can observe that there are 'Write AndX' and 'Delete' commands too.

The second command displays ip activity in terms of IP addresses. The list of IP addresses is quite long. There are a total of 168 lines. It could be possible that many of the shown IP-related communications were initiated from the honeypot.

Identifying the suspects

After reading again the intermediate questions, I understood that I needed to know what IP addresses attacked the honeypot. So, to obtain the IP source addresses used to access the honeypot (172.16.134.191), I used the tethereal utility with the filter displayed below, and I analyzed the output file with a perl script:

With that command I am filtering all TCP traffic originated from outside (0x02 = SYN flag), and the UDP traffic, since UDP is stateless. I ignore the response activity and all connections initiated by the honeypot. The suspects list contains about 136 different addresses. Below are listed the most significant ones:

24.197.194.106    1231  77.764%
210.22.204.101     105   6.633%
129.116.182.239     10   0.632%
66.139.10.15         6   0.379%
209.45.125.69        6   0.379%
61.111.101.78        5   0.316%
195.36.247.77        5   0.316%
61.150.72.7          4   0.253%
192.215.160.106      4   0.253%
213.23.49.158        4   0.253%
192.130.71.66        4   0.253%
172.168.0.154        4   0.253%

The first is by far the most active, with 77.7% activity. The second one has ten times less active (6.63%) than the primary suspect. And the rest of the IP addresses have less than 1% activity. It does not necessarily indicate that the rest ot the suspects have not been successful in their attacks.

Before analyzing the activity of those IP addresses in depth, I used snort to check how many intrusions it may have detected.

The most important part of the command output is shown here:

========================================================================
Snort processed 54536 packets.
Breakdown by protocol: Action Stats:

TCP:   54350 (99.659%)  ALERTS: 155
UDP:   186   (0.341%)   LOGGED: 56
ICMP:  0     (0.000%)   PASSED: 0
ARP:   0     (0.000%)
EAPOL: 0     (0.000%)
IPv6:  0     (0.000%)
IPX:   0     (0.000%)
OTHER: 0     (0.000%)
========================================================================

It confirms that the most significant concerns are related to TCP traffic, followed by some minor activity of UDP traffic (less than 0.5%). There were 155 alerts and 56 were logged.

A brief exam of the Alerts log file reveals this information:

The snort alerts, helped me to reduce my suspects list. I extracted the suspicious IP addresses from the alert.ids log file and removed them from my suspects list.

Note:
ipstats_mod.pl just makes a list of unique IP addresses from an IP address list.
reducelist.pl removes any corresponding IP address in file A (suspects.txt) from each line of file B (snort_attack_uniq.txt).

I added the 200.74.26.73 IP address to snort_attack_uniq.txt file too. While simplifying (reduce.pl) the snort attackers list, I observed that there were some duplicated IP addresses in snort_attack_uniq.txt. The unique IP addresses numbered 48. All of them are attackers, not suspects, so I removed them from my suspects list and tagged them as attackers.

Then, I had to analyze 'only' 88 (136 - 48) IP addresses. I placed them in a file called suspects_reduced.txt.

Discovering the attackers and their methods

There are a lot of IP addresses to examine if you were to use manually-typed filters in Ethereal. In this case, I wrote a short perl script to simplify the analysis process. It writes a log file with each IP address activity ordered as they appear in my suspects list. I used it to process the less significant active IP addresses, from the fourth must active one till the end of the list. I analyzed the first four IP addresses with ethereal.

Despite the varied capabilities of computer attacks, they usually result in violation of only four different security properties: availability, confidentiality, integrity, and control. These violations are described below:

• Confidentiality: An attack causes a confidentiality violation if it allows attackers to access data without authorization (either implicit or explicit) from the owner of the information.

• Integrity: An attack causes an integrity violation if it allows the (unauthorized) attacker to change the system state or any data residing on or passing through a system

• Availability: An attack causes an availability violation if it keeps an authorized user (human or machine) from accessing a particular system resource when, where, and in the form that they need it.

• Control: An attack causes a control violation if it grants an (unauthorized) attacker privilege in violation of the access control policy of the system. This privilege enables a subsequent confidentiality, integrity, or availability violation.

Therefore a 'successful attack' means a violation of any caracteristic that was mentioned before.

Note: Maybe this section/table seems too long. I have tried to make it as simple as possible, always maintaining the most important information. Nevertheless, due to the nature of the analysis, I had to examine all the discovered suspect IP addresses.

Results

After the analysis of the complete list of suspect IP addresses I have the following results, with some additional considerations:

• There are only two penetration attacks with success, coming from 61.111.101.78 and 210.22.204.101 addresses. Both of them successfully penetrate the honeypot and install at least some type remote administration tools to control it.
   

• The rest of the suspects may be classified in the two following groups:

  • Group One - Unsuccessful Attackers: Its members try to perform well-known attacks, such as overflow attacks, directory traversal, brute force logins, MS-SQL and Code Red worms, but they were not successful in their attempts. They can be classified as attackers.

  • Group Two - Data Collectors: They just send some network packets to get information about the victim (honeypot) with methods like port scans, or nbstat/net commands (I decided to exclude from this group those addresses that performed logins to IPC$, C$, ... share resources, since that resources are not for 'public use', and put them in the first group). It is difficult to determine if the members of this group can be considered as attackers, since they are actually collecting information from their victim, not attacking it. Of course, their behaviour permit us to predict a possible future attack, but not to tag them as attackers.

  The members of these groups can be found easily in the table above.

Questions:

Beginning Questions

1. What is IRC?
IRC is a multi-user chat system, written by Jarkko Oikarunen in 1988. It stands for "Internet Relay Chat", and it is defined in RFC-1459 (updated by RFC-2810, RFC-2811, RFC-2812, RFC-2813). IRC protocol, based on the client-server model, was designed as a replacement for the "talk" program. It is used as a text based conferencing system. [10]

 2. What message is sent by an IRC client when it asks to join an IRC network?
The client sends a TCP SYN packet to the IRC server port (usually 6667). Once connected, to join a channel, the client must use JOIN command using the following syntax: /JOIN #[nameofchannel].

 3. What is a botnet?
A botnet is a network of IRC bots that communicate with one another. A bot [11] is a script run from a client or a separate program. It is normally used to protect channels from takeovers and abusers, and to perform other functions as logging events. In a botnet, the bots share a means of communication whereby all speak to one another and exchange information. [12]

4. What are botnets commonly used for?
They are useful for keeping and maintaining a channel by acting as a group of channel bots that work together with a common goal. With a Botnet, even if an IRC bot dies, there still remains the rest of the bots on the Botnet to continue maintaining the channel and the loss of the one bot means nothing as the other bots do its exact same job.

Unfortunately, many people use bots created with Trojans from computer victims to create really big botnets (sometimes with thousands of bots). They take advantage of botnet's capacities to perform Denial of Service attacks against servers. Because the bots are making many home computers attack, from all over the world, those attacks are called Distributed Denial of Service attack (DDoS).

5. What TCP ports does IRC generally use?
As specified by IANA [13], the TCP ports used by IRC are:

irc 194/tcp Internet Relay Chat Protocol
irc-serv 529/tcp IRC-SERV
ircs 994/tcp irc protocol over TLS/SSL
ircu 6665-6669/tcp IRCU

The most commonly used ports are listed in the last line, from 6665 to 6669.

6. What is a binary log file and how is one created?
A binary log file is a log file format used by tools based on libpcaplibraries like Ethereal, tcpdump or Snort, to log and analyze network traffic. Libpcapsupplies the underlying function libraries and data structures to allow this type of capture. A binary log file represents many advantages over a traditional ASCII file format. For example, it requires less space than text log files (the IP addresses only needs 4 bytes, usually less space than the same representation in text files), and its contents can be accessed more rapidly and analyzed.

To create a binary log file with Snort, for example, it is necessary to use '-b' parameter, like this:
$ snort -b -l blogfile.log

With Ethereal it's sufficient to specify that the output type must be 'libpcap (tcpdump, ethereal, etc).'

Note: This question was already made in SotM23 (number one).

7. What IRC servers did the honeypot, which has the IP address 172.16.134.191, communicate with?
For this question, I used the following filter. It selects the traffic originated from the honeypot using IRC common remote ports:

(ip.src == 172.16.134.191) and ((tcp.dstport >= 6665) and (tcp.dstport <= 6669))

After that, I used a perl script to extract the IP addresses. The IRC servers accessed by the honeypot were:
209.196.44.172
209.126.161.29
66.33.65.58
63.241.174.144
217.199.175.10

8. During the observation period, how many distinct hosts accessed the botnet associated with the server having IP address 209.196.44.172?
I used the following filter with tethereal

(ip.addr == 209.196.44.172)

to obtain the IRC session. At trace number 35794, effectively, begins a long IRC communication. The TCP stream extracted from there is recorded in a file called irc_session.log.

To calculate the number of bots I stripped the log file, leaving only the names from the channel joined, and used 'wc -w [logfile]'command to count the words (3457 different nicknames). After that I only had to count the number of QUITS (222) and JOINS (175) (with 'grep [QUIT/JOIN] [logfile] | wc -l') and make some simple operations:

3457 - 222 + 175  =  3410 distinct hosts accessed the botnet during the observation period.

9. Assuming that each botnet host has a 56 kbps network link, what is the aggregate bandwidth of the botnet?
Assuming each bot has that slow connection:

3410 (bots) * 56 (kbps) = 190.960.000 kbps = 190.960 Mbps is the aggregate bandwith of the botnet.

As comparison, a typical LAN is capable of 10 or 100 Mbps. It helps to give an idea of the power of DoS attacks a botnet can perform.

Intermediate Questions

1. What IP source addresses were used in attacking the honeypot?
As described in the analysis process, the computer attacks, usually result in violation of only four different security properties: availability, confidentiality, integrity, and control. These violations are described below:

• Confidentiality: An attack causes a confidentiality violation if it allows attackers to access data without authorization (either implicit or explicit) from the owner of the information.

• Integrity: An attack causes an integrity violation if it allows the (unauthorized) attacker to change the system state or any data residing on or passing through a system

• Availability: An attack causes an availability violation if it keeps an authorized user (human or machine) from accessing a particular system resource when, where, and in the form that they need it.

• Control: An attack causes a control violation if it grants an (unauthorized) attacker privilege in violation of the access control policy of the system. This privilege enables a subsequent confidentiality, integrity, or availability violation.

Following that description, I have identified the following 117 IP addresses in the SotM27 binary log file as attackers, ordered by address number:
 

The IP address list corresponds to the IP addresses in the analysis table above that match the 'Attack' column. Some of them have been able to glean some information such as remote usernames, domains, group names, etc. but not their passwords or similar critical information. I do not consider that those constitute a successful attack. Nevertheless, all the traffic of a honeypot is considered as a potential intrusion or attack. It hasn't production activity.

2. What vulnerabilities did attackers attempt to exploit?
The attackers attempted to exploit multiple vulnerabilities. I have identified the following ones, trying to order them by popularity:

• MS-SQL Worm propagation attempt (UDP packets to local port number 1434). [8]

• Network.vbs Worm propagation attempt. A brief explication of the attack below. [2]
  Send UDP packets to 137 UDP port, with "CKAAAAA..." data string, probably using 'NBSTAT -A' command.
  Open a TCP session on port 139, and try to connect to \\<COMPUTERNAME>\C share resource (where COMPUTERNAME = PC0191).
  That share resource does not exist, and the honeypot sends RST packets.

• Open TCP session on port 139 (NetBIOS) and 445 (microsoft-ds), and try to open default system share resources like \\<COMPUTERNAME or IP address>\IPC$, \\<COMPUTERNAME or IP address>\ADMIN$ or \\<COMPUTERNAME or IP address>\C$.

• HTTP vulnerability scan, using a script, sending a long HTTP commands list, trying many exploits such as directory traversal for cmd.exe command, get files like user.dat, boot.ini, or autoexec.bat, or overflow web server.

• Repeated failed logins over TCP session on port 139 and 445.

• Open a TCP session over port 80 and send several HTTP GET /NULL.IDA?CCCCCCCC....[buffer with about 240 bytes] commands to perform an overflow attack. [3]

• Open a TCP session on port 80, and try an overflow attack with 'GET /default.ida?NNNN..[buffer]' command. The analysis revealed that it could be probably caused by Code Red worm. [6]

The methods described above were used to attack the honeypot. Nevertheless, I think that the answer is more complete if I describe the most popular approaches used to probe the honeypot. They aren't considered attacks, since they don't exploit any specific attack, such as buffer overflow, directory traversal, brute force login, access to share resources, etc. It indicates that they probably will make an attack in the near future. The methods are summarized here, by order of frequency.

• TCP SYN scans to ports [1-80], 21, 111, 139, 1080, 1433.

• Open TCP session over port 139 and 445.

• Send UDP packets to port 137, probably using 'NBTSTAT -A' or net commands.

• UDP scan from port 28432 to destination port 28431, probably to detect Trojans. [7]

• Open TCP session over port 80 and send commands like 'HTTP OPTIONS / HTTP/1.1' or just default command 'HTTP GET /'.

3. Which attacks were successful?
A 'successful attack' means a violation of any caracteristic that was mentioned in the answer to the first question. The analysis process revealed that there were only two definite penetration attacks with success. Both of them successfully installed at least some type of remote administration tool to control the honeypot.

• The first successful attack is originated from the 210.22.204.101 address. At trace number 1357 the attacker opens a TCP session on ports 139 and 445. \\172.16.134.191\C$. After that, it used it to send and install a remote administration tool developed by Famatech [4] under \WINNT\System32\ share resource.

• The second successful attack came from the 61.111.101.78 address. At trace number 33217, opened a TCP session on ports 139 and 445. Then it opened \\172.16.134.191\ADMIN$ share and sent and installed PsExec tool, an improved version of telnet by Sysinternals [5], under \WINNT\System32\ share resource. Before leaving the honeypot he deleted C$, D$, E$, and ADMIN$ shares with 'net share /delete [sharename] /y' command, and verified twice the closed status of ADMIN$ share. In this way it prevented other attackers accessing the honeypot.

General Questions (not judged)

1. What did you learn about analysis as a result of studying this scan?
I have discovered new methods to analyze network traffic, and a binary log file. For the analysis of big log files it's very useful to find script languages that permit to process text files, such as Perl. I think that to extract all the necessary information, first it's necessary to find an efficient method of analysis. I haven't seen any clear information about analysis methodologies.

On the other hand, I have learned that it's very important to pay attention to the details. There is a lot of information in a network traffic dump file, even in a single packet. It's incredible how much data we can obtain from a short network packet stream. Every network administrator should dedicate every day a little amount of time to analyze in depth the most abnormal network data. Unfortunately in most times there isn't sufficient time to do that and is almost impossible to detect some short attacks between great amounts of normal traffic. I can only see a solution by well knowing the own network 'normal' traffic, and having an excellent domain with the use of filters.

2. How do you anticipate being able to apply your new knowledge and skills?
One of the things I was doing is to make detailed logs of network traffic, using an Intrusion Detection System like snort. I agree that an IDS is not a silver bullet, but helps to identify a lot of attacks, and to prevents many of them. Another one of the tools that I use is the vulnerability scanners such as nessus. It not only indicates what vulnerabilities has my network, but it lets me analyze those attacks by examining network log files.

I will continue learning in the analysis of binary log files. Probably I will improve my knowledge on network traffic analysis and log tools such as etherealand languages such as Perl.

I am very interested in honeynet/honeypot related material, and I will probably install one in a near future for investigation and research purposes, always respecting the legal issues.

3. How can we improve the SotM challenge? What would you like to see added? What would you like to see done differently?
SotM challenges are very interesting and well presented. I wrote below several things that I would like to comment on:

• I think that giving them a background story, like SotM24 or SotM26, improves the attractiveness of the challenge.

• A better option may be to include more questions related to the object to analyze (binary file, floppy image, etc.), and make them more precise. For example, in this challenge, in my opinion the first intermediate question was more difficult to answer than the rest because of its its ambiguity (What's actually an attack? All the traffic entering in a honeypot is considered hostile).

• One more thing that the organizers could do is to allow a download of a md5 hash file of the binary one. That would simplify the verify task.

• The size of the challenges files isn't a problem for me, but I think that interesting things with smaller (and gzipped) files can be done.

Conclusion:

The most important points of this conclusion are discussed under the General Questions section.

One of the main objectives of this challenge was to learn to analyze a complete log file. And to be able to study it from a general layer to a more specific one, noting every detail.

Tools like Ethereal help to analyze binary log files but in the end, they are only tools. It is essential to have an efficient analysis method that allows you to analyze most of the network-traffic dumps. That method shouldn’t be tool or language (eg. Perl) dependent.

A honeypot has some advantages over other security methods. For example, because the honeypot isn’t employed in real production activities, it only receives hostile traffic therefore removing false alarms from the IDS. Another advantage is that it is an ideal tool to identify new and/or undocumented attacks/exploits on the internet.

If the honeypot legal issues are respected, it is an excellent resource, not just for research purposes but also to improve system security in general.

References:

1. Richard Sharpe. What is SMB? v1.2. October 2002. <http://samba.anu.edu.au/cifs/docs/what-is-smb.html>.

2. Sans Intrusion Detection FAQ. Port 137 Scan. May, 2000. <http://www.sans.org/resources/idfaq/port_137.php>.

3. Securiteam.com. Additional Details Released on the IIS Remote Buffer Overflow. June, 2001. <http://www.securiteam.com/exploits/5GP0C2K4KK.html>

4. Famatech. Famatech's Remote Administrator. <http://www.famatech.com/default.html>.

5. Mark Russinovich, Sysinternals.PsExec. Updated April, 2002. <http://www.sysinternals.com/ntw2k/freeware/psexec.shtml>.

6. eEye Digital Security. .ida "Code Red" Worm. <http://www.eeye.com/html/Research/Advisories/AL20010717.html>.

7. SANS Institute. Global Incident Analysis Center. December 25, 1999. <http://www.sans.org/y2k/122599.htm>.

8. Mcafee. W32/SQLSlammer.worm. Updated March, 2003. <http://vil.nai.com/vil/content/v_99992.htm>.

9. Undernet.org. Undernet Scans for Insecure Wingates and Proxies. <http://help.undernet.org/proxyscan/>.

10. Oikarinen, J., Reed D. RFC 1459, Internet Relay Chat Protocol. May 1993. <http://www.ietf.org/rfc/rfc1459.txt>.

11. mIRC Homepage. <http://www.mirc.com/ircintro.html>.

12. IRC BotNET. <http://botnet.sourceforge.net/>.

13. IANA - Internet Assigned Numbers Authority. <http://www.iana.org/assignments/port-numbers>.