[Intrusions] LOGS: GIAC GCIA Version 3.5 Practical Detect By RobPerdue
Smith, Donald
Donald.Smith at qwest.com
Sat Aug 14 16:49:59 GMT 2004
Donald.Smith at qwest.com GCIA
I reserve the right to be wrong but don't exercise it too often.
> -----Original Message-----
> From: intrusions-bounces at lists.sans.org
> [mailto:intrusions-bounces at lists.sans.org] On Behalf Of rsp7 at njit.edu
> Sent: Friday, August 13, 2004 9:57 AM
> To: intrusions at lists.sans.org
> Subject: [Intrusions] LOGS: GIAC GCIA Version 3.5 Practical
> Detect By RobPerdue
>
>
> 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
Did you get more packets? Can you dump the data level?
Does the ttl/windowsize etc tell you anything about the os?
Look at P0f for clues.
>
> 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_rel
> ease_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.
Good! This is the best analysis of MACs I have seen so far.
If you think about how macs are most likely issued within a company like
cisco
It is reasonable to assume they are issued in Sequential BLOCKs. Of
course we don't know how big a block or the boundries of such a block.
>
> 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 (roesch at sourcefire.com , www.snort.org)
> 1.7-WIN32 Port By Michael Davis (mike at datanerds.net ,
> www.datanerds.net/~mike)
> 1.8 - 2.1 WIN32 Port By Chris Reid
> (chris.reid at codecraftconsultants.com)
>
> 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
MSN messenger is fairly standard base software for microsoft systems.
Therefore I don't think you can assume it was downloaded and then
installed...
> 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.
Perhaps a list under host defenses of know ENCRYPTED im clients?
>
> 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."
Maybe a list of im "worms". Most were not pure im but some worms/virii
did use im for getting end users to download and run a trojan or virus.
You may also want to check out buddylinks not a worm not a virus but not
something you would want on your system either;-)
>
> 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.
How about CVEs for msn messager?
>
> 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.
I only see one packet and that doesn't have any "traffic" or data.
More might be helpful.
>
> 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
> Intrusions at lists.sans.org
> http://www.dshield.org/mailman/listinfo/intrusions
>
More information about the Intrusions
mailing list