Re: 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/default.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