RE: LOGS: GIAC GCIA Version 3.5 Practical Detect By RobPerdue

[email protected] GCIA 
I reserve the right to be wrong but don't exercise it too often.


> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of [email protected]
> Sent: Friday, August 13, 2004 9:57 AM
> To: [email protected]
> 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 ([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 

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
> [email protected]
> http://www.dshield.org/mailman/listinfo/intrusions
> 
_______________________________________________
Intrusions mailing list
[email protected]
http://www.dshield.org/mailman/listinfo/intrusions