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

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.

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:

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?

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.


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.

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