Challenge Analysis
By: Michael Capp
The Challenge
In early March 2003, the Azusa Pacific University Honeynet
Project deployed an unpatched Windows 2000 honeypot having a null (blank)
administrative password. During its
first week of operation, the honeypot was repeatedly compromised by attackers
and worms exploiting several distinct vulnerabilities. Subsequent to a successful attack, the
honeypot was joined to a large botnet.
The challenge is based on logs from five days of honeypot operation,
collected using Snort. The logs have
been edited to remove irrelevant traffic and combined into a single file. Also, IP addresses and certain other information
have been obfuscated so that the identity of the honeynet is not readily apparent. Your mission is to analyze the log file in
order to answer the questions below.
Binary
Verification:
|
Original |
:MD5 (sotm27.gz) =
b4bfc10fa8346d89058a2e9507cfd9b9 |
|
Download (Win) |
:MD5 (sotm27.gz) =
b4bfc10fa8346d89058a2e9507cfd9b9 (See Figure 1.0) |
|
Download (Linux) |
:MD5 (sotm27.gz) =
b4bfc10fa8346d89058a2e9507cfd9b9 (See Figure 1.1) |
Figure 1.0:
Figure 1.1:
mcapp@eeyore mcapp $
md5sum sotm27.gz
b4bfc10fa8346d89058a2e9507cfd9b9 sotm27.gz
mcapp@eeyore mcapp $
TABLE OF CONTENTS
2. What
message is sent by an IRC client when it asks to join an IRC network?
4. What
are botnets commonly used for?
5. What
TCP ports does IRC generally use?
6. What
is a binary log file and how is one created?
7. What
IRC servers did the honeypot, which has the IP address of 172.16.134.191,
communicate with?
1. What
IP source addresses were used in attacking the honeypot?
2. What
vulnerabilities did attackers attempt to exploit?
3. Which
attacks were successful?
1. What
did you learn about analysis as a result of studying this scan?
2. How
do you anticipate being able to apply your new knowledge and skills?
Questions
1.
What
is IRC?
Internet
Relay Chat (“IRC”) is a client/server-based chat system first started in August
1988 by Jarkko Ouikarinen. In order to use IRC, a client is required that
sends and receives messages from an IRC server; this can be as simple as a
standard telnet client. The IRC server
is responsible for ensuring messages are broadcast to those participating in
the joined discussion(s). Following are
several terms that are common with IRC usage:
|
Term |
Definition |
|
Channel |
‘Rooms’ or categorized chat areas where people gather to
chat. |
|
DCC |
Direct link between clients commonly used to transfer
files back and forth on IRC. |
|
IRCops |
Net or Server operators.
They share responsibility to ensure servers are functioning properly
and users “behave”. |
|
Lags & Splits |
Splits happen when one or more servers are overloaded and
users get bumped off. Lags occur when
there are significant delays in transmitting messages between networks. |
|
Nick |
Nickname, handle, or pseudonym used instead of real names. |
|
Ops & Operators |
Users with administrative authority over a channel or
multiple channels that can perform various moderator-type commands. |
2.
What
message is sent by an IRC client when it asks to join an IRC network?
In relation to the packet captures, the first sessions originated with packet
35748 where the IRC server attempts to identify the honeypot via the IDENTification protocol (RFC1413).
Response Line: NOTICE AUTH :
*** Looking up your hostname…
Response Line: NOTICE AUTH : *** Checking
Ident
Response Line: NOTICE AUTH :
*** No Ident response.
The
purpose of IDENT is to attempt verification of the source of the
connection. When a connection is made,
an ident capable service queries the client on port 113 to determine the user
that opened the TCP socket. If the
client is running a properly configured IDENT daemon, an appropriate response
would be returned to the server’s request.
Following
the IDENT request, in packet 35753, a request is sent from the attacker or bot
to the IRC server providing the nickname or pseudonym that the attacker or bot
wanted to initially use:
Request Line:
NICK eohisou
Request Line:
USER eohisou localhost localhost
: eohisou
See Appendix A
for the complete logs retrieved from the attacker’s IRC session.
3.
What
is a botnet?
In
order to understand the purpose of a botnet, it is important to understand the
basic functionality of a bot, or roBOT. A bot is a computer program that works in
conjunction with IRC and performs various functions. Several bots serve a legitimate purpose; to
perform such tasks as: keeping channels open if no users are present, protect
against net-split attacks, enforce bans/channel security, etc.
Botnets are a
collective group of individual bots that typically are the result of a Trojan
or strategically placed bot on an individual or company computer.
4.
What
are botnets commonly used for?
In
practice, botnets can act as Trojans, luring the typical home user to run a
script, visit a website, or run an infected program that can potentially add
their computing power to this collective.
Collectively, botnets can be used to perform large distributed denial of
service attacks, channel attacks, net splits, or any number of programmatic
functions that the bot was designed to perform.
5.
What
TCP ports does IRC generally use?
RFC1459
does not specifically state reserved ports for use with the IRC Protocol,
however, TCP ports 6665-6669 are reserved for IRC usage and it most IRC servers
operate on port 6667.
6. What
is a binary log file and how is one created?
A
binary log file is a file that is created that is unreadable as a standard text
file and usually requires specific utilities to interpret or read the data in
the file. One substantial benefit is
that binary log files are typically smaller than normal text files. Many programs contain the ability to create
binary log files and in several circumstances; this is configurable via the
configuration file. As an example: Snort contains the ability to write to the tcpdump format by modifying the snort.conf
file and including the line:
Output log_tcpdump : snort.log
Additionally,
by default, Linux logs information about users that have logged into the system
to a binary log file. It is kept up to
date by utilities such as login and in.uccpd. The data is viewable with tools such as last,
lastb, who, and finger.
7. What
IRC servers did the honeypot, which has the IP address of 172.16.134.191,
communicate with?
After
specifying a filter in Ethereal to limit the Protocol traffic to IRC and the
source IP to 172.16.134.191, it was determined that the honeypot communicated
with the following three (3) IRC servers:
63.241.174.144
217.199.175.10
209.196.144.172 (irc5.aol.com)
8. During
the observation period, how many distinct hosts accessed the botnet associated
with the server having IP address 209.196.44.172?
In order
to determine the number of distinct hosts that form this botnet, the beginning
IRC session was started and “Follow TCP Stream” was used within Ethereal. The IRC stream was then saved into a text
file and parsed to remove all excess information. The following command on Linux was used to
determine that 3,457 hosts were existent within this channel at that given
moment:
mcapp@eeyore mcapp
$ wc
–w challenge.txt
3457
challenge.txt
mcapp@eeyore mcapp $
Similarly, parsing the file to reveal names in the channel
on Microsoft Word reveals the same results:
9. Assuming
that each botnet host has a 56 kbps network link, what is the aggregate
bandwidth of the botnet?
Based upon the above assumption, the
aggregate bandwidth of this botnet would meet or exceed, depending on actual
available bandwidth per host:
193, 592 kbps,
193,592,000 bps,
~194 Mbps –or-
the
equivalent of approximately 126 T1’s, 4 T3/DS3’s, or 1 OC3 and 24 T1’s.
1. What
IP source addresses were used in attacking the honeypot?
Please follow
this link for a chart
containing the source addresses and their associated attacks.
2. What
vulnerabilities did attackers attempt to exploit?
The following are
specific vulnerabilities that were targeted and their possible related
references:
|
Vulnerability |
Reference |
|
Microsoft
Windows 2000 vulnerable to Denial of Service (“DoS”)
via malformed packets sent to port 445/tcp. |
http://www.kb.cert.org/vuls/id/693099 |
|
Hack’a’Tack Trojan |
http://www.iss.net/security_center/advice/Intrusions/2001534/default.htm |
|
Windows
Shares |
http://www.cert.org/advisories/CA-2003-08.html |
As you can see from the charter below,
the most common attacks were related to Microsoft operating system flaws and
vulnerabilities, a few of which were successfully exploited as you will see
detailed in Question 3.
3. Which
attacks were successful?
As
noted by the RED in the chart, there were
several successful attacks on this specific honeypot. This link provides a detailed analysis of
each attack listed
Attack 1 (Detailed Event Analysis)
03/03/2003
21:55:34 - Initial packets from
195.36.247.77 indicate someone specifically interested in NetBIOS/SMB ports 139
and 445 as well as any vulnerabilities that may exist on port 135
(DCE/RPC/EPMAP).
|
274 |
236844.901586 |
Attacker |
Server |
TCP |
4768 > epmap [SYN]
Seq=148910790 Ack=0 Win=16384
Len=0 |
|
275 |
236844.906655 |
Server |
Attacker |
TCP |
epmap >4768 [SYN, ACK]
Seq=2453546201 Ack=148910790 Win=17040
Len=0 |
|
280 |
236846.003387 |
Attacker |
Server |
TCP |
4792 > microsoft-ds [SYN]
Seq=149838612 Ack=0 Win=16384
Len=0 |
|
281 |
236846.003395 |
Attacker |
Server |
TCP |
4792 > netbios-ssn [SYN]
Seq=149921138 Ack=0 Win=16384
Len=0 |
Attacker Observations:
Domain Name: NULL
User name: NULL
Host name: LIO-UEA8YNL9UE1
Native OS: Windows 2002 2600 (Windows XP)
Native LAN Manager: Windows 2002 5.1
The
attacker connects to the \SAMR path in order
to enumerate the domain and user information.
|
315 |
236860.101949 |
Attacker |
Server |
SAMR |
OpenDomain request, S-1-5-32 |
|
316 |
236860.104895 |
Server |
Attacker |
SAMR |
OpenDomain reply |
|
317 |
236861.346261 |
Attacker |
Server |
SAMR |
EnumDomains request |
|
318 |
236861.348643 |
Server |
Attacker |
SAMR |
EnumDomains reply |
|
321 |
236863.396376 |
Attacker |
Server |
SAMR |
OpenDomain request,
S-1-5-21-1229272821-706699826-1060284298 |
|
322 |