Hello all,
Below is one of my detects required for the GCIA certification. Your comments,
suggestions and questions are greatly appreciated.
Thanks!
Network Detect 1: Chat MSN Message
Snort Alert:
[**] [1:540:11] CHAT MSN message [**]
[Classification: Potential Corporate Privacy Violation] [Priority: 1]
07/18-08:48:35.294488 46.5.180.250:61149 -> 64.4.12.155:1863
TCP TTL:125 TOS:0x0 ID:38562 IpLen:20 DgmLen:182 DF
***AP*** Seq: 0x94BC4902 Ack: 0x57D2776D Win: 0xF906 TcpLen: 20
1. Source of Trace:
This log was taken from the GIAC Certification Practical logs posted at
http://isc.sans.org/logs/raw/2002.6.18.
Few items of note regarding the log file.
The log files are the result of a Snort instance running in binary
logging mode. This means that only the packets that violate the ruleset will
appear in the log.
All of the IP addresses of the protected network space have been "munged".
Additionally, the checksums have been modified to prevent clever people from
discovering the original IP addresses. You will find that certain keywords
within the packets have been replaced with "X"s. All ICMP, DNS, SMTP and Web
traffic has also been removed.
IP addresses belonging to non-local hosts are the actual IP addresses.
The above items were taken from the readme file located at
http://isc.sans.org/logs/raw/README.
Ruleset and Snort version used to generate the log are unknown.
Network Layout
What makes these logs especially challenging is that the analyst is
given no knowledge of the network from which these logs were created. However,
within the log there is enough information to be gathered to give the analyst a
good, but not exact, picture of the network at hand.
In this case Ethereal version 0.10.5a with WinPcap 3.0 will be used to
help determine the layout.
After loading the log into Ethereal and sorting by time stamp, a quick eyeball
of source and destination IPÂs revealed that all the traffic was inbound or
outbound to network 46.5.0.0/16. By sorting the Ethereal output by source
address it was found that 46.5.180.250 was the only source address in the log
that belonged to that network. At this point http://www.arin.net/ was consulted
to see if the 46.5.0.0/16 network had an owner. Using 46.5.180.250 in the Arin
Whois lookup produced:
OrgName: Internet Assigned Numbers Authority
OrgID: IANA
Address: 4676 Admiralty Way, Suite 330
City: Marina del Rey
StateProv: CA
PostalCode: 90292-6695
Country: US
NetRange: 46.0.0.0 - 46.255.255.255
CIDR: 46.0.0.0/8
NetName: RESERVED-46
Since this network range is reserved by IANA it would appear this would be the
protected network. To verify, other IPÂs from the log that did not belong to
this network address were also run through Arin and other registries. These
IPÂs were found to belong to various public owners.
With the protected network determined, the MAC addresses were examined to get
an idea of how many devices transmit traffic through the sensor which generated
the log. Returning to the only protected IP seen generating outbound traffic,
46.5.180.250, the mac address associated with this IP, 00:00:0c:04:b2:33, was
used as a starting point.
Using eth.src == 00:00:0c:04:b2:33 as an Ethereal display filter, it was found
that the only outbound traffic associated with this MAC address was from
46.5.180.250. While examining the packets displayed with the above filter it
appeared that not only was all outbound traffic coming from the same source mac
address but also all the traffic was destined to various IPÂs but a single mac
address, 00:03:e3:d9:26:c0. With these two MAC addresses identified the
display filter, eth.src != 00:00:0c:04:b2:33 and eth.src != 00:03:e3:d9:26:c0,
was used to see if there were any other MAC addresses sending traffic inbound
or outbound. There were not.
With the sole two MAC addresses found, that ended up in the log anyway, the
next step was to see what kind of devices these were.
Even though Ethereal is nice enough to give us the manufacturers associated
with these MAC addresses, they were manually referenced using the OUI list
found at http://standards.ieee.org/regauth/oui/oui.txt. Using this list and
Ethereal it was determined both MAC addresses belonged to Cisco devices.
00-03-E3 (hex) Cisco Systems, Inc.
0003E3 (base 16) Cisco Systems, Inc.
170 West Tasman Dr.
San Jose CA 95134
UNITED STATES
00-00-0C (hex) CISCO SYSTEMS, INC.
00000C (base 16) CISCO SYSTEMS, INC.
170 WEST TASMAN DRIVE
SAN JOSE CA 95134-1706
With the information found thus far a simple network layout can be produced:
PROTECTED NETWORK ---CISCO DEVICE 1---SNORT---CISCO DEVICE 2---OUTSIDE
46.5.0.0/16 00:00:0c:04:b2:33
00:03:e3:d9:26:c0
The weakness in this diagram is that there is not much known about the
protected network or the nature of the two Cisco devices.
To come up with a better idea of the network, I kept on digging.
Using the MAC OUIÂs an attempt was made to narrow down the possibilities of
what these Cisco devices are.
Poking around http://www.cisco.com an article was found pertaining to a pix
software release. In this document,
http://www.cisco.com/en/US/products/sw/secursw/ps2120/prod_release_note09186a008
01a6d21.html , there was an example Âshow ver run on a pix firewall which
produced the following output(only relevant data shown):
0:ethernet0:address is 0003.e300.1552, irq 10
1:ethernet1:address is 0003.e300.1553, irq 7
The OUIÂs of these two pix interfaces match that of CISCO DEVICE 2
(00:03:e3:d9:26:c0). Though by no means a sure thing, with the above
information and the common practice of sandwiching firewalls with NIDS, it
would make sense that CISCO DEVICE 2 is the inside interface of a PIX Firewall.
The same search was performed for the MAC of CISCO DEVICE 1 but the results
were inconclusive. Though best guess would be that CISCO DEVICE 1 is a router.
With a good feeling about identifying the hardware involved in the network,
attention was turned to gathering more information about the protected
network. A look at the traffic inbound to the protected network, using display
filter ip.dst == 46.5.0.0/16 and sorted by protocol, shows that most of the
inbound traffic is for HTTP, FTP, and DNS. Though some of this traffic is due
to less then honorable packets, there is enough traffic to imply the presence
of these services inside the protected network. The nature of this traffic
suggests that the sensor is placed at an entry/exit for the outer point of a
DMZ.
Looking then at the outbound traffic from the 46.5.0.0/16 network using display
filter ip.src == 46.5.0.0/16, it is seen that ,as mentioned earlier, all
outbound traffic from the protected network is from 46.5.180.250. Looking
through this traffic there were outbound http connections, file sharing
connections, some outbound IM traffic, and few ssh connections. Most of the
traffic was outbound http so I focused on that for a clue. Outbound requests to
port 80 were focused on using a display filter of ip.src == 46.5.180.250 and
tcp.dstport == 80. In these packets there are various GET requests to various
web servers. In the payload of these packets it can be seen that there are
various clients making these requests. Below is an export from ethereal
highlighting these findings. (Export has been edited to show only pertinent
information)
Snip 1
Internet Protocol, Src Addr: 46.5.180.250, Dst Addr: 61.218.76.250
Transmission Control Protocol, Src Port: 63085, Dst Port: http (80), Seq:
512801141, Ack: 1905796758, Len: 425
Request Method: GET
Accept: */*\r\n
Referer: http://www.corega.com.tw/lan.htm\r\n
Accept-Language: en-us,zh-hk;q=0.7,zh-tw;q=0.3\r\n
Accept-Encoding: gzip, deflate\r\n
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR
1.0.3705)\r\n
Host: www.corega.com.tw\r\n
Connection: Keep-Alive\r\n
Snip 2
Internet Protocol, Src Addr: 46.5.180.250, Dst Addr: 209.225.0.6
Transmission Control Protocol, Src Port: 61962, Dst Port: http (80), Seq:
723942382, Ack: 3571025822, Len: 246
Request Method: GET
Accept: */*\r\n
Accept-Language: en-us\r\n
Accept-Encoding: gzip, deflate\r\n
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)\r\n
Host: servedby.advertising.com\r\n
Connection: Keep-Alive\r\n
Looking at these packets shows a GET request made from a Windows 2k machine
running IE 6 and a separate GET request being made from a Windows 98 box
running IE 5.5.
These findings would support that IP 46.5.180.250 is possibly a proxy server
for allowing outbound traffic for internal clients on the protected network.
With this additional information the network seen in the log most likely
resembles the following:
Internal Protected Network (46.5.0.0/?)
|
|
Few Routers Thrown In There
|
|
-------------- Proxy Server (46.5.180.250)
| |
| Few More Routers (due to TTL values seen in outbound packets)
| |
| |
DMZ Router 1 (00:00:0c:04:b2:33)
| |
| Snort---
| |
-------------- Pix Firewall (00:03:e3:d9:26:c0)
|
|
More Stuff (Possibly a NIDS and border router)
|
|
Internet
2. Detect Was Generated By:
The raw log used in this analysis was generated by and unknown version of Snort
using an unknown ruleset and configuration file.
The detects used in my analysis were generated by:
-*> Snort! <*-
Version 2.1.3-ODBC-MySQL-FlexRESP-WIN32 (Build 27)
By Martin Roesch ([email protected] , www.snort.org)
1.7-WIN32 Port By Michael Davis ([email protected] , www.datanerds.net/~mike)
1.8 - 2.1 WIN32 Port By Chris Reid ([email protected])
The version of Snort utilized in my analysis had all rules enabled and the
stream4 preprocessor disabled.
Fist step was to run the log through Snort using the following command:
snort -c c:\snort\etc\snort.conf -l c:\snort\log -k none -r c:\snort\2002.6.18
Options-
-c - was used to specify a config file
-l - was used to let snort know where to log the goods
-k none - was used to ignore the munged checksums
-r was used to read in the log file
There were plenty of events to go around but I wanted to look for something
that I had not seen discussed yet. I decided to go with the following
signature:
[**] [1:540:11] CHAT MSN message [**]
[Classification: Potential Corporate Privacy Violation] [Priority: 1]
07/18-08:48:35.294488 46.5.180.250:61149 -> 64.4.12.155:1863
TCP TTL:125 TOS:0x0 ID:38562 IpLen:20 DgmLen:182 DF
***AP*** Seq: 0x94BC4902 Ack: 0x57D2776D Win: 0xF906 TcpLen: 20
Though perhaps not as scary as some other signatures, this traffic shows a
potentially large vulnerability in the protected network. If the source of
this traffic is not addressed it is very possible that the analyst will be
seeing a lot more of the scary signatures then he or she cares to.
The rule that caught this traffic is:
alert tcp $HOME_NET any <> $EXTERNAL_NET 1863 (msg:"CHAT MSN message";
flow:established; content:"MSG "; depth:4; content:"Content-Type|3A|"; nocase;
content:"text/plain"; distance:1; classtype:policy-violation; sid:540; rev:11;)
For this rule the stimulus was traffic outbound to port 1863, plain text
content, and ÂMSGÂ included in the content. This stimulus fired rule ÂChat MSN
message.Â
3. Probability the source address was spoofed:
The source address in these signatures is not likely to be spoofed. The
signature is firing on a series of instant messages being sent using the MSN
messenger, if the addresses were spoofed there wouldnÂt be much of a
conversation, the attacker would never see the returned messages.
4. Description of Attack:
The MSN traffic detected by Snort is an attack, this traffic is a violation of
policy which may lead to a future attack.
In this case MSN Messenger was downloaded to a client inside the protected
network, installed, configured and activated. Though I cannot say for sure,
the fact that the chat rules were enabled in Snort leads me to believe that the
security personnel responsible for the network are aware of the threat that
Instant Messaging can pose. It is unknown if there is a policy in place for
this type of activity, but there appears to be an interest in monitoring it.
5. Attack Mechanism:
Instant messaging is one of the most popular forms of electronic
communication. ItÂs nature is much like that of email, the client has an
address list, is able to send and receive files, and receive rich content such
as hyperlinks. This kind of activity opens another avenue for a possible
attack to a protected network.
A few of the biggest threats that IMÂing presents to a network are as follows:
Information leaks - IM text is usually sent out in clear text. If there is an
attacker listening they can read the entire conversation. This could be
anything from how someoneÂs dinner was the night before to sensitive company
information.
Opening for a worm - According to an article seen on esecurityplanet at
http://www.esecurityplanet.com/trends/article.php/3373251 , published on June
24th, 2004, attacks focused on IM software are on the rise.
ÂActually, between 2002 and 2003 there was a 400 percent increase in IM
malware, according to Symantec's figures. Since 2002, 25 instant messaging
worms have been released into the wild, with about 20 of them coming out last
year alone. At least five or six have hit the wild so far this year, reports
Chien.Â
Open vulnerabilities - Just like any other piece of software IM software can
open vulnerabilities on the machine it is running on.
An example of a vulnerability that can be introduced to a network through the
use of this software can seen here:
http://securityresponse.symantec.com/avcenter/security/Content/1943.html . This
advisory discusses a buffer overflow condition in the MSN Messaging software
which could allow remote code execution. Though this advisory is from 2002, it
highlights the potential avenues for attack that the unregulated use of this
type of software can open.
A more recent advisory was released in 2004 and can be read at
http://securityresponse.symantec.com/avcenter/security/Content/9828.html . This
advisory discusses a possible information leak in MSN Messaging software.
I believe that attackers are always looking for the path of least resistance.
With much of the security focus and money these days turned to scanning emails
for viruses and getting OSÂs patched products such as IM software may slip
underneath the radar. If this software is being used on a network and not
controlled many levels of security could be bypassed with the only protection
being that which may be deployed on client PCÂs. Attackers are aware of this
and I expect to see a continued rise in attacks focusing on IM software.
6. Correlations:
This is a new detect. I have not been able to find a previous paper discussing
this particular signature.
Because this is signature is alerting on a policy violation there is not a CVE
associated with this alert.
A good article on the threat IM software posses can be read at:
http://www.esecurityplanet.com/trends/article.php/3373251
And some vulnerabilities concerning MSN Messenger can be read at:
http://securityresponse.symantec.com/avcenter/security/Content/1943.html
http://securityresponse.symantec.com/avcenter/security/Content/9828.html
7. Evidence of Active Targeting:
There is no evidence of active targeting. The traffic appears to be normal
conversation between two MSN clients.
8. Severity:
Severity is calculated using the following formula:
severity = (criticality + lethality) - (system countermeasures + network
countermeasures)
Each category is given a value between 1 (lowest) and 5 (highest).
Criticality = 3:
I cannot say for sure what kind of system is running the MSN Messenger
software, most likely this is a Windows Workstation but it could just as well
be a Windows Server. Since I cannot determine what kind of box is running this
software I will take a middle of the road stance and assign a value of 3.
Lethality = 3
This traffic is not that of an attack. However, if this box were to be
attacked by a worm it is possible for the entire network to be taken down.
Since there have only been 5 or 6 worms targeting IM software seen in the wild
last year I will only give this a value of 3. I would expect this value to
rise as attacks against this software increase.
System Countermeasures = 1
There is no way to determine from the log what, if any, antivirus and firewall
software is running on the PC. I will assume the worst case that there are no
countermeasures running on the box and assign a value of 1.
Network Countermeasures = 1
This traffic is being allowed over the protected network so there are no
network countermeasures in place. Snort is only being used to detect this
traffic, which has to count for something so I will give this a value of 1.
Using the above formula this gives a severity rating of 4.
Severity = 4
9. Defensive Recommendations:
The first thing that should be done to combat the use of IM software is to
develop a policy and make sure that each user of the network is aware of this
policy. This policy will vary from company to company, but it is from these
policies that the rest of the defensive actions will be determined.
In most cases I would guess that if the company is concerned enough about IM
software to develop a policy for it, this policy will be a no tolerance
policy. In this case I would make the following recommendations.
 Block known IM ports on company firewalls, especially those between the
protected network and the outside world.
 Restrict user rights on workstations to prevent unauthorized
installation of software.
 Leverage existing IDS devices to detect this traffic by enabling chat
signatures. If there is no IDS device, then one should be purchased.
 Savvy users could use http tunneling software, such as httport, to
bypass firewall rules and avoid chat detection. Analysts should be aware of
this potential violation and look for tunneling traffic during analysis of
daily IDS logs.
 Ensure all company computers are running antivirus software with up to
date definitions.
 Make sure that all current and future employees are aware of this
policy.
10. Multiple Choice Question:
It is decided by your company that the existing Snort NIDS will be used
to detect the use of IM software. Currently, the NIDS are not configured to do
so. What step(s) must be taken to enable the detection of IM traffic?
A) Disable the Stream4 Preproccesor in the snort.conf file.
B) Enable the p2p.rules file in the snort.conf file.
C) Enable the chat.rules file and enable the Stream4 Preproccesor in the
snort.conf file.
D) Enable the chat.rules file in the snort.conf file.
Correct Answer: D
_______________________________________________
Intrusions mailing list
[email protected]
http://www.dshield.org/mailman/listinfo/intrusions
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.