RE: [Intrusions] LOGS: GIAC GCIA Version 3.4 Practical Detect- David Chance (2nd Attempt)

What really made me curious was the bit about the linux ports that chris
compton had mentioned; the bit about pop3/ssl and ldap/ssl. Either your
paragraph is incredibly confusing, or I am too dense to understand it. Could
you clarify and repost? 

As the paragraph stands, it sounds like you assert that pop3/ssl and
ldap/ssl are ports unlikely to be found on a linux system, which seems
rather absurd.

Cheers,

Chris Meidinger

> -----Original Message-----
> From: intrusions-bounces@xxxxxxxxxxxxxx 
> [mailto:intrusions-bounces@xxxxxxxxxxxxxx] On Behalf Of 
> skycopp-mail8531@xxxxxxxxxxxxxx
> Sent: Sunday, May 09, 2004 4:40 PM
> To: intrusions@xxxxxxxxxxxxxx
> Subject: Re: [Intrusions] LOGS: GIAC GCIA Version 3.4 
> Practical Detect- David Chance (2nd Attempt)
> 
> 
> Chris those are very good comments, Thank you. Here are my responses:
> 
> #1 What about crafted/manipulated TTLs? (Referring to the 
> packets from the attacker) It is entirely possible for the 
> TTLs to have been crafted in some fashion. However I examined 
> more traffic from the attacker
> (10.10.10.112) to other destinations and discovered a DNS 
> request. The TTLs in this request were exactly the same (64) 
> as the ones in the packets that I have examined in this 
> detect. Therefore I can reasonably conclude that the TTLs are 
> accurate. Below I have included the example.
> 15:06:19.689411 0:1:2:79:91:ed 0:50:56:40:0:64 79: IP (tos 
> 0x0, ttl 64, id 13294, len 65) 10.10.10.112.32769 > 
> 10.10.10.2.53: [udp sum ok] udp
> 37 (DF)
> 15:06:19.691236 0:50:56:40:0:64 0:1:2:79:91:ed 137: IP (tos 
> 0x0, ttl 64, id 0, len 123) 10.10.10.2.53 > 
> 10.10.10.112.32769: udp 95 (DF)
> 
> #2 What about a sample of the “plainly obvious” scanning (to 
> prove your assertion)\.
> This is a very good point, I will include evidence into the 
> final draft.
> 
> #3 My gut tells me this (scan) is an excellent opportunity to 
> spoof – especially being so “noisy” and so close, and 
> especially since there are no three way handshakes. Were 
> there any SYN/ACK responses? If so, why would the attacker 
> not respond?
> A very good point. First, even though there were no three-way 
> handshakes doesn’t mean that the source of the scan was 
> spoofed. As I mentioned earlier under the first point above, 
> the source was detected performing a DNS query and then 
> receiving the response from a DNS server. Second, there were 
> no SYN/ACK packets but there were 4 RST/ACK packets from 
> ports 20, 21, 25, and 443. RST/ACK packets are used to 
> immediately terminate a connection. Third, if an attacker is 
> performing a half scan, he will not respond to SYN/ACK 
> responses in order for the connection to not be logged. 
> http://xforce.iss.net/xforce/xfdb/405
> 
> #4 What about details on doing some of these things (Defense 
> recommendations)? How do I change the default community 
> strings? What kind of rules could be implemented for the filters?
> These are very good points and I will put a little more 
> detail into this section.
> 
> -----Original Message-----
> From: Chris Compton <chris@xxxxxxxxxxxxxxxxx>
> To: Intrusions@xxxxxxxxxxxxxx
> Sent: Thu, 6 May 2004 09:03:58 -0600 (MDT)
> Subject: Re: [Intrusions] LOGS: GIAC GCIA Version 3.4 
> Practical Detect- David Chance (2nd Attempt)
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Comments below...
> 
> Chris Compton, GSEC, GCIA
> Chief Security Consultant
> Intrusion Labs
> Mayfield, Kentucky
> (270) 247-2301
> http://www.intrusionlabs.com
> 
> A Division of Specialized IT, LLC
> 
> Unauthorized interception of this communication could be a 
> violation of Federal and State Law. This communication and 
> any files transmitted with it are confidential and may 
> contain protected information. This communication is solely 
> for the use of the person or entity to which it was intended.
> If you are not the intended recipient, any use, distribution, 
> printing or acting in reliance on the contents of this 
> message is strictly prohibited. If you have received this 
> message in error, please notify the sender and destroy any 
> and all copies.
> 
> 
> skycopp-mail8531@xxxxxxxxxxxxxx wrote:
> | Hi, this is my second time to post this for review.
> | Comments are greatly appreciated.
> | ***********************************
> |
> |
> | [**] SNMP AgentX/tcp request [**]
> | 11/18-14:06:01.297406 10.10.10.112:49043 -> 192.168.17.129:705 TCP 
> | TTL:64 TOS:0x0 ID:23696 IpLen:20 DgmLen:60 DF
> | ******S* Seq: 0x304C702F Ack: 0x0 Win: 0x16D0 TcpLen: 40 
> TCP Options 
> | (5) => MSS: 1460 SackOK TS: 273599 0 NOP WS: 0 
> | =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
> | [**] SNMP AgentX/tcp request [**]
> | 11/18-14:06:01.617286 10.10.10.112:49056 -> 192.168.17.129:705 TCP 
> | TTL:64 TOS:0x0 ID:58508 IpLen:20 DgmLen:60 DF
> | ******S* Seq: 0x30F0C853 Ack: 0x0 Win: 0x16D0 TcpLen: 40 
> TCP Options 
> | (5) => MSS: 1460 SackOK TS: 273631 0 NOP WS: 0 
> | =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
> |
> | Source of Detect:
> |
> | This detect was taken from the 2003.12.15.tgz file at 
> | http://www.incidents.org/logs/raw/. Within that file 
> contained a log 
> | called 2003.12.15.5. This detect was generated by running the
> following
> | command:
> |
> | Snort –r 2003.12.15.5 –c snort.conf
> |
> | Snort Name of executable (version 2.0.2) -r <tcpdump file> Read the 
> | tcpdump formatted file.
> | 2003.12.15.5 Name of file
> | -c <config-file> Use the rules located in the default configuration 
> | file.
> |
> | The next thing I wanted to do was reduce the tcpdump file into a
> smaller
> | file so that I can focus more specifically on the traffic 
> between the
> 2
> | IP addresses. I filtered out the excess traffic by using (ip.addr eq
> | 10.10.10.112 and ip.addr eq 192.168.17.129) in ethereal (Version 
> | 0.10.0). I then used Windump to create a .txt file of the traffic
> with
> | the following command:
> |
> | Windump –nr detect > detect.txt
> |
> | Windump Name of executable (Version 3.6.2) -n Don’t convert 
> | addresses to names -r <tcpdump file> Read packets from file
> |
> |> <log> Redirect the information into a text file
> |
> |
> | --- snippet---
> | 14:06:01.297314 IP 10.10.10.112.49041 > 192.168.17.129.2035: S
> | 817317959:817317959(0) win 5840 <mss 1460,sackOK,timestamp
> |
> | 273599 0,nop,wscale 0> (DF)
> | 14:06:01.297362 IP 10.10.10.112.49042 > 192.168.17.129.782: S
> | 805420019:805420019(0) win 5840 <mss 1460,sackOK,timestamp
> |
> | 273599 0,nop,wscale 0> (DF)
> | 14:06:01.297406 IP 10.10.10.112.49043 > 192.168.17.129.705: S
> | 810315823:810315823(0) win 5840 <mss 1460,sackOK,timestamp
> |
> | 273599 0,nop,wscale 0> (DF)
> | 14:06:01.616713 IP 10.10.10.112.49044 > 192.168.17.129.1391: S
> | 813305201:813305201(0) win 5840 <mss 1460,sackOK,timestamp
> |
> | 273631 0,nop,wscale 0> (DF)
> | 14:06:01.616767 IP 10.10.10.112.49045 > 192.168.17.129.542: S
> | 818792105:818792105(0) win 5840 <mss 1460,sackOK,timestamp
> |
> | 273631 0,nop,wscale 0> (DF)
> | 14:06:01.616813 IP 10.10.10.112.49046 > 192.168.17.129.363: S
> | 815682827:815682827(0) win 5840 <mss 1460,sackOK,timestamp
> |
> | 273631 0,nop,wscale 0> (DF)
> | --- snippet---
> |
> | The format of the log is as follows:
> |
> | |Date/time| SourceIP: Port > DestinationIP: Port| SYN #| 
> Window Size 
> | |TCP Options|
> |
> | It appears that the layout of the network is as such:
> |
> | 10.10.10.12
> | 3COM
> | 00:01:02:79:91:ed
> | Linux 2.4/2.6
> | |
> | |
> | ----SNIFFER
> | |
> | |
> | ----FIREWALL
> | |
> | |
> | 172.20.201.0/24
> | 192.168.17.0/24
> | 00:50:56:40:00:6D
> | VMWARE
> |
> |
> | I used a vender/Ethernet MAC address lookup located at 
> | http://www.coffer.com/mac_find/ to discover the type of systems. I
> also
> | used p0f v 2.0.3 and ran the following command to detect the
> operating
> | system:
> |
> | p0f –s detect3
> | The “-s” option says to read packets from TCPDump snapshot named
> “detect3”.
> |
> | ---snippet---
> | 10.10.10.112:48552 - Linux 2.4/2.6 (up: 0 hrs) -> 
> 192.168.17.129:822 
> | (distance 0, link: ethernet/modem)
> |
> | I ran it again with the –R (RST/RST-ACK mode) and discovered that
> | 192.168.17.129 was a recent Linux 2.4 version.
> | It is apparent to me that this scan was created in a lab 
> environment.
> | The TTLs from the source was 64 and the destination was 
> only two hops 
> | away. However I will still analyze this detect as if 10.10.10.12 was
> an
> | attacker and 192.168.17.129 was the victim.
> 
> What about crafted/manipulated TTLs?
> 
> |
> | Detect Generated By
> |
> | The traffic triggered on the following rule:
> |
> | alert tcp $EXTERNAL_NET any -> $HOME_NET 705 (msg:"SNMP AgentX/tcp 
> | request"; reference:cve,CAN-2002-0012; reference:cve,CAN-2002-0013; 
> | sid:1421; rev:2;
> classtype:attempted-recon;)
> |
> | In layman’s terms, the rule says to trigger an alert when an
> outside IP
> | address using any source port sends traffic directed to our network
> on
> | destination port 705. The rule also gives a reference to
> CAN-2002-0012
> | and CAN-2002-0013 and is in its second revision. It is also
> classified
> | as a recon rule.
> |
> | It is plainly obvious that 10.10.10.112 was port scanning 
> | 192.168.17.129, however I will focus on examining the alert and the 
> | packet that triggered it. It was this packet that triggered the
> alert:
> |
> 
> What about a sample of the "plainly obvious" scanning? (To prove your
> assertion)
> 
> | 14:06:01.297406 IP 10.10.10.112.49043 > 192.168.17.129.705: S
> | 810315823:810315823(0) win 5840 <mss 1460,sackOK,timestamp 273599 
> | 0,nop,wscale 0> (DF)
> |
> | The outside address 10.10.10.112 using port 49043 sent a TCP packet
> with
> | the SYN flag to the victim machine 192.168.17.129 to port 
> 705. The SYN 
> | flag is the first step in establishing a connection between two 
> | systems using the TCP three-way handshake method.
> |
> | Probability the Source Address Was Spoofed
> |
> | Unlikely. All IP addresses in the raw packets located at
> Incidents.org
> | have been obfuscated; therefore we have to assume that the 
> IP address 
> | was a legitimate routable address according to IANA.
> |
> | In the dump, I gathered all traffic coming from 10.10.10.112 to see
> if
> | there were any completed 3 way handshakes, which would have been
> proof
> | that the address is not spoofed. There were no 3 way 
> handshakes, but 
> | that is not proof alone that the IP address is spoofed. This is the 
> | part where experience and gut intuition comes into play.
> |
> | Looking at the traffic, it is easy to see that the source IP had 
> | conducted a port scan aimed at one particular destination 
> IP address, 
> | 192.168.17.129. There were 3430 SYN packets sent to the victim with 
> | destination ports ranging from 1 to 61440.
> | In order for this port scan to be considered successful, there must
> be a
> | legitimate source to receive back the information.
> | What use is it to port scan a victim if the information has no place
> to
> | return to?
> 
> My gut tells me this is an excellent opportunity to spoof -- 
> especially being so "noisy" and so close, and especially 
> since there are no three way handshakes. Were there any 
> SYN/ACK responses? If so, why would the attacker not respond?
> 
> Without having any packets, it's hard to say, but I think 
> there needs to be more digging, and some evidence that proves 
> your assertions -- i.e., Packets.
> 
> |
> | Description of Attack
> |
> | Port scanning is a popular reconnaissance technique used by hackers
> to
> | see what holes are available in a system. Similar to door knocking,
> the
> | attacker “rings the doorbell” of the system to see if anyone
> opens the
> | door. If someone opens the door by means of a SYN-ACK, the attacker 
> | knows that he can connect at this port. If he gets a no 
> answer or RST 
> | he now knows that the port is not available for a connection or a
> packet
> | filtering device is intervening. Note, continuing with the door 
> | knocking analogy, a RST packet would be considered as a harsh “Go
> Away”
> | voice from the other side of the door.
> |
> | This packet is a SYN scan that is attempting to see if port 
> 705 will 
> | respond. However, the target system did not respond except for 4 
> | RST-ACK packets when ports 20, 21, 25, and 443 were 
> scanned. This is 
> | indicative that a packet filtering device is not intervening for
> these
> | ports, but is silently dropping packets for the others.
> |
> | Attack Mechanism
> |
> | Port 705 is commonly used by AgentX, which provides an “extensible
> SNMP
> | agent” framework. As networks grow, there is a need for 
> dynamically 
> | extending management objects in order to maintain and monitor the 
> | network. Add to this mix that there is a lack of
> standards
> | in this area that has made it more difficult to create SNMP 
> | applications. Many vendors were forced to create several subagent 
> | environments that would support different platforms.
> |
> | The AgentX protocol was independently created to provide a standard
> of
> | communication between subagents and master agents.
> | This allowed the various agents to interoperate at the protocol
> level.
> | A master agent listens on port 161, and then forwards the 
> requests to 
> | subagents. RFCs 2741 and 2742 discuss the use of AgentX further.
> |
> | 
> http://www.iss.net/security_center/advice/Exploits/Ports/705/d
> efault.htm
> |
> | There are several vulnerabilities associated with port 705. 
> VU107186 
> | describes that there are multiple vulnerabilities in SNMPv1 trap 
> | handling which can give a malicious user unauthorized privileged
> access,
> | create Denial of Service conditions, format string vulnerabilities,
> and
> | cause a general buffer overflow. 
> http://www.kb.cert.org/vuls/id/107186
> |
> | VU854306 describes that there are also multiple vulnerabilities in
> the
> | request handling of the SNMPv1. Like VU107186 this 
> vulnerability note 
> | states that it is possible for a malicious user to create Denial of 
> | Service conditions, format string vulnerabilities or cause 
> a general 
> | buffer overflow. http://www.kb.cert.org/vuls/id/854306
> |
> | A quick search using Google revealed that there are a plethora of
> hacker
> | tools available that can easily exploit these vulnerabilities. This 
> | makes these vulnerabilities more serious because any script kiddie
> can
> | easily download the tools and exploit a network.
> |
> | Solarwinds has developed two tools in particular: SNMP Dictionary
> Attack
> | Tool and the SNMP Brute Force Attack Tool.
> | http://support.solarwinds.net/Help/Sections/Security.htm
> |
> | There is also a tool called SNMPBrute, which is an SNMP community
> name
> | brute force tool available at
> | http://www.securiteam.com/tools/5EP0N154UC.html.
> |
> | SNMP Watcher is a tool that can query network components for
> information
> | about their configuration and activity and can retrieve the
> information
> | in raw format at the data level. 
> http://www.dartmouth.edu/pages/softdev
> |
> | As to this was only a scan, there is no other information 
> that would 
> | indicate the attacker would attempt other SNMP attacks.
> |
> | Correlations
> | CAN2002-0012
> | (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0012) :
> | Vulnerabilities in a large number of SNMP implementations allow
> remote
> | attackers to cause a denial of service or gain privileges 
> via SNMPv1 
> | trap handling, as demonstrated by the PROTOS c06-SNMPv1 test suite.
> |
> | CAN2002-0012
> | (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0013) :
> | Vulnerabilities in the SNMPv1 request handling of a large number of
> SNMP
> | implementations allow remote attackers to cause a denial of service
> or
> | gain privileges via (1) GetRequest, (2) GetNextRequest, and (3) 
> | SetRequest messages, as demonstrated by the PROTOS c06-SNMPv1 test
> suite.
> |
> | SaiPrasad Kesavamatham has a beautiful write-up on this alert.
> | http://www.giac.org/practical/GCIA/SaiPrasad_Kesavamatham_GCIA.pdf
> |
> | Evidence of Active Targeting
> |
> | It is easy to see that the source, 10.10.10.112 was specifically 
> | targeting 192.168.17.129 by performing port scanning. The attacker
> did
> | not probe any other systems. I get the feeling that this is an
> initial
> | sweep of the ports because the attacker scans ports that are
> generally
> | only found on windows machines. The p0f tool suggests that 
> the target 
> | machine is Linux. For example, the attacker scanned port 
> 636 which is 
> | Secure LDAP over SSL/TLS and also port 563 which is Pop3 
> over SSL. If 
> | the attacker had done his homework, he probably wouldn’t have
> wasted his
> | time. I don’t think that he advance knowledge of the operating
> system.
> |
> 
> I'm not sure I am reading this correctly -- are you saying 
> that these ports are NOT used on Linux??? Even asserting that 
> it is uncommon, would be treading on thin ice. Maybe I misread....
> 
> |
> | Severity
> |
> | Severity = (Criticality + Lethality) – (System Countermeasures +
> Network
> | Countermeasures)
> |
> | Criticality: How critical is the system (DNS server vs. 
> workstation) 
> | to the network or organization? This score depends upon the role in
> the
> | network / organization that the system plays. As mentioned earlier, 
> | this detect seems to have been created in a lab 
> environment. However, 
> | since this system appears to be directly behind some sort of
> firewall, I
> | will assume that this is an important server that may be hosting 
> | services such as FTP, SMTP or HTTPS since those are the only ports
> that
> | aren’t filtered. Compromising this host would be a huge 
> problem for
> the
> | security of the network. Therefore I feel that it is necessary to
> score
> | this as 5.
> |
> | Lethality: How severe the damage would be if the attack succeeded?
> | Port scanning is considered by some to not be lethal. In my 
> opinion, 
> | getting information on the host and finding out what ports are open
> is
> | only half the battle. However, I still believe that port scanning is
> at
> | the low end of the spectrum. I will score lethality as a 1.
> |
> | System Countermeasures: How strong are the defensive mechanisms on
> the
> | system? These vulnerabilities are rather old that I can reasonably 
> | assume that the system admin has most likely patched against these 
> | vulnerabilities using vendor supplied patches. However I 
> cannot score 
> | this as a 5 because I don’t want to make such a huge assumption
> without
> | knowing more details of the targeted system, such as if 
> SNMP has been 
> | disabled. I will score system countermeasures at 4.
> |
> |
> | Network Countermeasures: How strong are the defensive mechanisms on
> the
> | network? I believe that the firewall has been locked down 
> tightly due 
> | to the fact that the probes to port 705 were dropped and not
> responded
> | to. The only responding packets were immediate resets to 4 other
> probed
> | ports. I also noticed that probes to ports 199 (SNMP UNIX
> Multiplexer),
> | 391 (SNMP Relay Port), and 1993 (Cisco SNMP TCP port) were also 
> | discarded. I will score network countermeasures a 5.
> |
> | SEVERITY = (5 + 1) – (4 + 5) = - 3
> |
> | Defense Recommendations
> |
> | There are several recommendations on protecting a network against
> SNMP
> | vulnerabilities:
> |
> | A. Apply filtering to SNMP traffic.
> | B. Isolate SNMP into a separate management VLAN.
> | C. As with any other service, disable SNMP if not necessary.
> | D. Filter SNMP traffic from non-authorized hosts.
> | E. Change default community strings.
> | F. Also for further assurance, SANS has created SNMPTool that can 
> | immediately detect where the SNMP service is running from any system
> and
> | device within a network. Send an email to snmptool@xxxxxxxx to
> request
> | the tool.
> | G. Download and run assessment tests with the tools listed in the 
> | Attack Mechanism section against your network.
> 
> What about details on doing some of these things? How do I 
> change the default community strings? What kinds of rules 
> could be implemented for the filters?
> 
> |
> | Question
> |
> | Every analyst should have a robust suite of tools when analyzing
> network
> | traffic. One of the must have tools is ‘p0f’. P0f 
> version 2 is a 
> | versatile passive Operating System fingerprinting tool used for 
> | information gathering on servers and hosts. What does the ‘–R’
> command
> | line switch do? For example:
> |
> | p0f –s detect3 -R
> |
> | A. Resolve host names.
> | B. Run signature collision check.
> | C. Go into RST/ RST+ACK mode.
> | D. Read fingerprints from file.
> |
> | Answer: C
> |
> | The ‘-R’ command line switch will fingerprint several different
> types of
> | traffic, most importantly the “connection refused” and
> “timeout”
> | messages. http://lcamtuf.coredump.cx/p0f/README
> |
> |
> |
> | _______________________________________________
> | Intrusions mailing list
> | Intrusions@xxxxxxxxxxxxxx
> | http://www.dshield.org/mailman/listinfo/intrusions
> |
> |
> |
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.1 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFAmjCakMfeavTy3P0RAnVmAJ4sfUiImM0eBBN3ZNKHUGPWpNmn2ACgl0Oq
> MPHJTiaIaHEohSZk/Hzb9uU=
> =fnTD
> -----END PGP SIGNATURE-----
> 
> 
> _______________________________________________
> Intrusions mailing list
> Intrusions@xxxxxxxxxxxxxx
> http://www.dshield.org/mailman/listinfo/intrusions
> _______________________________________________
> Intrusions mailing list
> Intrusions@xxxxxxxxxxxxxx
> http://www.dshield.org/mailman/listinfo/intrusions
> 
_______________________________________________
Intrusions mailing list
Intrusions@xxxxxxxxxxxxxx
http://www.dshield.org/mailman/listinfo/intrusions