LOGS: GIAC GCIA Version 3.4 Practical Detect Blaine Hein

Hello,

Attached are the three detects required for the SANS GCIA certification
assignment question 2. This includes a reposting of my first two
detects.  Any comments would be greatly appreciated.   

Regards,

Blaine Hein



1       Source of Trace:
1.1     Location of file
This detect was extracted from the file 2002.9.28 downloaded from
http://www.incidents.org/logs/Raw/.
Further supporting information (in the form of 2 more very similar
detects were obtained from the file 2002.9.29 from the same web site.
For the sake of clarity the network layout and description of the detect
are based on the first file.
1.2     Network Layout

All of the captured packets contain two MAC addresses beginning with
[00:00:0C] on the internal side and [00:03:E3] on the external side.
When these two MAC address fragments are referenced to a vendor MAC
address table (http://www.coffer.com/mac_find/) the resulting vendor is
CISCO in both cases. This means that the IDS probe is physically located
between 2 CISCO routers with no other communicating hosts between the
two routers.  The internal network appears to be the address range of
32.245.0.0/16

         +=========+                   +=========+
Internal |         |                   |         | External
=========|  CISCO  |=========+=========|  CISCO  |=========
         |         |         |         |         |
         +=========+         |         +=========+
                        +=========+
                        |         |
                        |   IDS   |
                        |         |
                        +=========+


2       Detect was generated by:

2.1     Raw Detect Information

Snort intrusion detection system version 2.1.2 for Win32 with the
default rule set.  Rule triggered is 

[**] [116:97:1] (snort_decoder): Short UDP packet, length field >
payload length [**]
[Classification: Potentially Bad Traffic] [Priority: 2] 
10/28-04:10:12.336507 0:3:E3:D9:26:C0 -> 0:0:C:4:B2:33 type:0x800
len:0x5C
80.63.124.198:0 -> 32.245.98.91:0 UDP TTL:112 TOS:0x0 ID:314 IpLen:20
DgmLen:78
Len: 129

"Raw" packet extracted from SNORT without ruleset (based on a search for
packets from 80.63.124.198 turned up the following single datagram:

10/28-04:10:12.336507 0:3:E3:D9:26:C0 -> 0:0:C:4:B2:33 type:0x800
len:0x5C
80.63.124.198:0 -> 32.245.98.91:0 UDP TTL:112 TOS:0x0 ID:314 IpLen:20
DgmLen:78
0x0000: 0E 25 00 00 00 89 00 3A 4D 16 01 00 00 10 00 01
.%.....:M.......
0x0010: 00 00 00 00 00 00 20 43 4B 41 41 41 41 41 41 41  ......
CKAAAAAAA
0x0020: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41
AAAAAAAAAAAAAAAA
0x0030: 41 41 41 41 41 41 41 00 00 21                    AAAAAAA..!

As an interesting bit of trivia, note the error in Snort indicating a
source port of 0 instead of 3621.  To eliminate all confusion, here is
the real packet extracted with WinDump:

windump -xXn -r ..\in\2002.9.28 -s 0 net 80.63.0.0/16
04:10:12.336507 IP 80.63.124.198.3621 > 32.245.98.91.0: udp 129
0x0000   4500 004e 013a 0000 7011 e4f8 503f 7cc6        E..N.:..p...P?|.
0x0010   20f5 625b 0e25 0000 0089 003a 4d16 0100        ..b[.%.....:M...
0x0020   0010 0001 0000 0000 0000 2043 4b41 4141        ...........CKAAA
0x0030   4141 4141 4141 4141 4141 4141 4141 4141        AAAAAAAAAAAAAAAA
0x0040   4141 4141 4141 4141 4141 4100 0021             AAAAAAAAAAA..!

2.2     Explanation of Trigger Stimulus

Bytes 2 and 3 of the captured  packet indicate that the total length of
the IP packet and included data are 0x0043 (78 bytes) in length
(highlighted in yellow).  However, Bytes 24 and 25 (Decimal) indicate
that the UDP datagram length is 0x0089 (137 Bytes) in length.  As this
is larger than the entire 78 byte length of the IP datagram, an alert is
triggered.  

While the malformed packet size information is of interest, the
remainder of the packet information is of more interest and is actually
irrelevant to the original detect.  This will be discussed in much more
detail in section 4.

3       Probability the source address was spoofed:

3.1     Type of Detect
UDP attacks directed at port 0 are unlikely to be anything other than an
attempt at a DOS attack.  Based on that assumption, the source address
would highly likely be spoofed.  The only reference to this I have found
to Port 0 DOS attacks is CVE-1999-0675 (detailed in section 4 below)
which refers to a Checkpoint Firewall -1 vulnerability.  As there is no
evidence of a VPN involved in this configuration, and as this
vulnerability is now approaching 5 years old, this is not likely to be
the actual attack implemented here.
However, based on "google" searches for information on the payload
(CKAAAAAA...),  I believe that this is an unsuccessful attempt at a
crafted packet, and that the detection based on the current rule set was
purely coincidental.  As will be shown in the analysis in section 4,
this attack was likely intended as an information gathering exercise
prior to the launching of a real attack.  Based on that assumption, the
IP address(es) would not be spoofed.  More detail to justify the
validity of this assumption is provided in section 4.
3.2     Potential Source of Attack 

inetnum:                80.63.124.0 - 80.63.124.255
netname:                TELEDANMARK-ADSL-USERS
descr:                  TDC NetExpres users
country:                        DK
Source IP address from 2002.9.28 file

IP Address:             211.223.8.0-211.223.8.255
Network Name:           KORNET-INFRA000001
Connect ISP Name:       KORNET
Connect Date:           20031129
Registration Date:      20031209
Source IP address from 2002.9.29
The two source IP addresses in question resolve to the two
geographically distinct areas, though caution must be used as the event
date predates the Korean registration.  There are not sufficient numbers
of events to make a positive determination, but this still looks to me
like the IP addresses are not spoofed due to the apparent information
gathering mission.
4       Description of attack:
The analysis of this attack is somewhat speculative as there were two
distinct oddities to this packet which seem to be unrelated.  There is
the incorrect size of the packet and the apparent insertion of 2 bytes
within the UDP header.  These two irregularities lead to this detect
having similarities to the following detects:  
*       Port 0 DOS / Packet length mismatch
*       System Scan /  SMB Name Wildcard
4.1     DOS
Based on the packet sent, there is a small possibility that this was a
DOS attack against the router.  If the packet size had been correct, the
following alert would have triggered based on the destination port being
0.

alert udp $EXTERNAL_NET any <> $HOME_NET 0 (msg:"BAD-TRAFFIC udp port 0
traffic"; reference:cve,CVE-1999-0675; reference:nessus,10074;
classtype:misc-activity; sid:525; rev:5;)

In its current form, the UDP datagram length rule triggers before the
Port 0 rule is parsed.  As a result the port 0 rule is not triggered.
There is no evidence that the destination host even exists.  Therefore,
it is impossible to confirm or deny the DOS intent of this packet with
this level of detail.  However, this would be a stretch of the
imagination.  The one clear item from the log files; if this was a DOS
attack against the router, it did not succeed.

4.2     System Scan

The fact that a single packet was sent in a one day period, and two
packets of a very similar nature were sent on the second day, makes me
believe that this is an attempt at a slow scan.  It is quite possible
that there is a script tool (with a bug?) which is implementing this
scan.  An interesting exercise would be to send this packet to an
existing system and look for a response to determine if this is really a
bug, or an attempt at subterfuge to throw the IDS analyst off the scent.

If the 2 bytes at offset 22 and 23 were deleted and the remaining
datagram were shifted left accordingly (to correct the "bug"), the
packet would have been destined for port 137.  With this assumption, the
remainder of the packet would have made more sense as the packet length
would then be 0x003a (58 bytes) which would have matched the IP datagram
length of 78 bytes (58 bytes UDP datagram + 20 bytes IP header.)  The
resulting packet (with the last two bytes intact would be the port 137
SMB Name Wildcard attack.  The default rule set shipped with Snort
2.1.12 does not appear to have a rule to detect this attack

4.3     Evidence of Packet Crafting
The following two packets were captured from the 2002.9.29 data file
(the next day.)  The existence of two packets in close proximity allows
us to perform a little more analysis.  

[**] (snort_decoder): Short UDP packet, length field > payload length
[**]
10/29-21:16:27.826507 0:3:E3:D9:26:C0 -> 0:0:C:4:B2:33 type:0x800
len:0x5C
211.223.8.214:0 -> 32.245.161.79:0 UDP TTL:109 TOS:0x0 ID:25767 IpLen:20
DgmLen:78
Len: 129

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
=+

[**] (snort_decoder): Short UDP packet, length field > payload length
[**]
10/29-21:16:33.676507 0:3:E3:D9:26:C0 -> 0:0:C:4:B2:33 type:0x800
len:0x5C
211.223.8.214:0 -> 32.245.161.117:0 UDP TTL:109 TOS:0x0 ID:62887
IpLen:20 DgmLen:78
Len: 129

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
=+

C:\Snort\bin>windump -xXn -r ..\in\2002.9.29 -s 0 net 211.223.0.0/16
21:16:27.826507 IP 211.223.8.214.1026 > 32.245.161.79.0: udp 129
0x0000   4500 004e 64a7 0000 6d11 33e8 d3df 08d6        E..Nd...m.3.....
0x0010   20f5 a14f 0402 0000 0089 003a 0696 0100        ...O.......:....
0x0020   0010 0001 0000 0000 0000 2043 4b41 4141        ...........CKAAA
0x0030   4141 4141 4141 4141 4141 4141 4141 4141        AAAAAAAAAAAAAAAA
0x0040   4141 4141 4141 4141 4141 4100 0021             AAAAAAAAAAA..!
21:16:33.676507 IP 211.223.8.214.1026 > 32.245.161.117.0: udp 129
0x0000   4500 004e f5a7 0000 6d11 a2c1 d3df 08d6        E..N....m.......
0x0010   20f5 a175 0402 0000 0089 003a 0670 0100        ...u.......:.p..
0x0020   0010 0001 0000 0000 0000 2043 4b41 4141        ...........CKAAA
0x0030   4141 4141 4141 4141 4141 4141 4141 4141        AAAAAAAAAAAAAAAA
0x0040   4141 4141 4141 4141 4141 4100 0021             AAAAAAAAAAA..!

The source port is the same for both packets (highlighted in Yellow),
and the "error" in all three packets is identical.  These are crafted
packets.

4.4     Apparent bug in recent versions of Snort 
All three detected packets have source ports of 0 reported by Snort.
However, the packets do not have this source port as can be seen in the
Windump packets.

5       Attack mechanism:
5.1     DOS

        Packet size mismatches are common denominators in several
attacks.  Normally they attempt to cause a crash, or cause the execution
of selected code.  In this case, a poor UDP implementation would be left
with a buffer under run possibly resulting in random data if the buffer
was not properly initialized.  This random data could theoretically
cause a crash.
5.2     SMB Name Wildcard
        This is the normal structure of the Netbios name query.  When
resolving a name with only the IP address available, windows machines
will send these queries as part of normal operations.  The notable
string in the udp datagram "CKAAA..." is generated from a null Netbios
name, "00 00 00..." as a wildcard with a translation function being
performed to complete the mapping.
        However, when these queries arrive from an external network,
they represent a threat to the network based on the information provided
in the response which could include: 
        (Source:
http://www.digitaltrust.it/anachnids/IDS177/research.html)
        1. The NetBIOS name of the server.
        2. The Windows NT workgroup domain name.
        3. Login names of users who are logged into the server.
        4. The name of the administrator account if they are logged into
the server.
        The detected packets are not generated by the standard netbios
name server.  Instead they have been crafted to provide a more directed
approach to scanning a network.
6       Correlations:
The SMB Name Wildcard, the Port 0 DOS, and the packet length mismatches
are not new attacks.  
SMB wildcard attacks have been reported quite extensively from 1999
onwards.  The following links provide a quite good analysis.
http://www.sans.org/resources/idfaq/port_137.php
http://www.digitaltrust.it/arachnids/IDS177/research.html
http://www.giac.org/practical/GCIA/Sebastien_Pratte_GCIA.pdf
http://www.finchhaven.com/pages/incidents/030102_udp_137.html
CAN-1999-0621
The port 0 DOS against the Checkpoint Firewall-1 was documented in 1999.
CVE-1999-0675
The detected packet (including the apparent error has been previously
detected by Andrew Evans on 9 July 2003 
(http://cert.uni-stuttgart.de/archive/intrusions/2003/07/msg00071.html)
and by 
Reto Baumann on 7 Mar 2003.  
(http://cert.uni-stuttgart.de/archive/intrusions/2003/03/msg00090.html)

7       Evidence of active targeting:

This attack does not represent active targeting of particular systems.
Quite the opposite, this attack is the general fishing exercise (looking
for systems, and looking for any response to the probing.)

8       Severity:

severity = (criticality + lethality) (system countermeasures + network
countermeasures)

Criticality     1:  This attack is designed to perform a slow scan of a
network while attempting to mislead the analyst of the real intent.
However, at best, only the existence of a system on the network would be
determined.  Had the packets been crafted correctly, the attack would
have also yielded more information relating to the roles of the detected
systems (e.g. workstations vs. servers.  This correction would result in
the Criticality being raised to 2 in my opinion. 
Lethality   1:  This attack only provides mapping information for
targeting a future directed attack against the network.  There is no
immediate damage to the system, only a reduction in "security by
obscurity."  
System countermeasures 2:  There are no responses to these packets.
However, as there are only 3 captured packets over a 2 day period that
does not provide a warm fussy feeling that the internal hosts are well
protected.  Based on the network configuration discussed below, I am not
inclined to be charitable in the area of system countermeasures.
Network countermeasures 2:  As the network owner has created the RAW log
files for our studies, it is a safe assumption that there actually is an
IDS system located at the same location.  However, in order to limit the
vast number of low tech attacks and noise caused by the lack of good
networking practices out on the Internet, I would expect to see a better
configuration on the CISCO router connecting this network to the
INTERNET.  Based on sound practices for router configurations, I would
not expect to see source broadcast addresses nor LAN protocols entering
from the WAN.  The current configuration allows ports 137 and 139 in
through the external router, along with source broadcast addresses.
This adds an unnecessary burden on the security analyst.
Overall (1 + 1) - (2+2) = - 2.  The most formulated working variation on
this detect is the SMB Name Wildcard which is effectively a pre attack
probe.  While the countermeasures did not score well, this is partially
due to the unknown nature of the scanned network.
9       Defensive recommendation:

The network involved with this detect appears to be quite large.  The
location of the IDS sensor appears to be as close to the outside of the
network as possible.  As such, a second IDS inside the firewall is
needed to determine what makes it into the network.  In this manner the
analyst has a better picture of where rules need to be improved while
still providing insight as to who is knocking on the door.
In addition, there are some basic housekeeping rules which need to be
implemented on the external router.  Even if the router is owned by the
ISP, these recommendations should still be implemented.  First:  LAN
protocols and addresses do not belong on the WAN.  This means that the
standard network O/S protocols such as TCP ports 135, 139, 445 and UDP
ports 137, 138, and 445 should not pass through the external router in
either direction (as source or destination ports.)  Private and Wildcard
IP addresses should also be blocked in both directions through the
external firewall.
These rules should, as much as possible, also be implemented on the
internal router.  In the case where several internal routers converge to
a single external router, this may not always be possible to completely
implement.
10      Multiple choice test question:

21:16:27.826507 IP 211.223.8.214.1026 > 32.245.161.79.0: udp 129
0x0000   4500 004e 64a7 0000 6d11 33e8 d3df 08d6        E..Nd...m.3.....
0x0010   20f5 a14f 0402 0000 0050 0696 0100 0010        ...O.....:......
0x0020   0001 0000 0000 0000 2043 4b41 4141 4141        .........CKAAAAA
0x0030   4141 4141 4141 4141 4141 4141 4141 4141        AAAAAAAAAAAAAAAA
0x0040   4141 4141 4141 4100 0021 0021                  AAAAAAAAA..!..
Q:  What rule will trigger based on the above packet?
A)      [**] [116:97:1] (snort_decoder): Short UDP packet, length field
> payload length [**]
B)      [13]alert udp $EXTERNAL_NET any <> $HOME_NET 0 (msg:"BAD-TRAFFIC
udp port 0 traffic"; reference:cve,CVE-1999-0675;
reference:nessus,10074; classtype:m isc-activity; sid:525; rev:5;)
C)      Both
D)      None
A: A  
The Snort decoder runs before the other rule files. A questions has been
raised regarding processing order of Snort version 1.9.1, but I have not
been able to confirm this behavior)  
11      Source of Trace #2:
Location of trace
This detect was extracted from a tcpdump capture off of my home network
on 22.04.2004 between 08:52:48 (UTC) and 19:53:29 (UTC).
Network Layout
My home network consists of a DSL modem, hub, and 2 computers.  The
first computer is a general purpose system (not logged into the DSL
modem during the capture timeframe.)  The second computer is configured
as an IDS analysis system with Snort, Apache, MySQL, ACID, and
EtherPeek.  As the described configuration was not generating
interesting packets needed to complete my assignment, the personal
firewall was turned off for the duration of the capture.  IP address
assignment is dynamic, so there was no advance indication to the world
that this system with several listening services would be live.

         +=========+                   +=========+
External |         |      Internal     |         | 
=========|DSL Modem|=========+=========| Home PC |
         |         |         |         |         |
         +=========+         |         +=========+
                        +=========+
                        |         |
                        |   IDS & |
                        | Web Svr |
                        +=========+

12      Detect was generated by:
Snort intrusion detection system version 2.1.2 for Win32.  

There are three detects analyzed here as they are actually parts of the
same attack.  I originally selected the first detect shown here as I
could not find a significant amount of analysis already performed.
However, shortly into the analysis, I determined a link with an alert on
an earlier packet.  Later on when I started to gather more technical
evidence, I found another detect was also included in the same data
stream.  As such the three alerts are included together (not in
chronological order.)
First Selected rule triggered is 

[**] [119:4:1] (http_inspect) BARE BYTE UNICODE ENCODING [**]
04/22-08:14:09.456949 0:2:3B:2:67:D2 -> 0:10:A7:5:62:CA type:0x8864
len:0x5DE
211.45.217.3:54291 -> 217.136.26.209:80 TCP TTL:107 TOS:0x0 ID:5528
IpLen:20 DgmLen:1480 DF
***A**** Seq: 0x6EEA5655  Ack: 0xBF8BFB3F  Win: 0xFFFF  TcpLen: 20

The raw packet from WinDump is:

08:14:09.456949 PPPoE  [ses 0x9616] IP 1482: IP 211.45.217.3.54291 >
XXX.XXX.XXX.209.80: . 1441:2881(1440) ack 1 win 65535 (DF)
0x0000   1100 9616 05ca 0021 4500 05c8 1598 4000        .......!E.....@.
0x0010   6b06 540d d32d d903 0000 00d1 d413 0050        k.T..-.........P
0x0020   6eea 5655 bf8b fb3f 5010 ffff 7d98 0000        n.VU...?P...}...
0x0030   b102 b102 b102 b102 b102 b102 b102 b102        ................
.
.
.
0x02f0   b102 b102 b102 b102 b102 b102 b102 b190        ................
0x0300   9090 9090 9090 9090 9090 9090 9090 9090        ................
.
.
.
0x05c0   9090 9090 9090 9090 9090 9090 9090 9090        ................

In a more user friendly format for display (Etherpeek): this packet
looks like:


Packet Info
  Flags:                0x00
  Status:               0x00
  Packet Length:        1506
  Timestamp:            09:14:09.456949000 04/22/2004
Ethernet Header
  Destination:          00:10:A7:05:62:CA  Unex Tech:05:62:CA
  Source:               00:02:3B:02:67:D2  Redback Net:02:67:D2
  Protocol Type:        0x8864  PPPoE Session
PPP over Ethernet
  Version:              1
  Type:                 1
  Code:                 0x00  Session
  Session Id:           38422
  Length:               1482
Point-to-Point Protocol
  PPP                   0x0021  IP, Internet Protocol
IP Header - Internet Protocol Datagram
  Version:              4
  Header Length:        5  (20 bytes)
  Differentiated Services:%00000000
                        0000 00.. Default
                        .... ..x. Reserved
                        .... ...x Reserved

  Total Length:         1480
  Identifier:           5528
  Fragmentation Flags:  %010
                        0.. Reserved
                        .1. Do Not Fragment
                        ..0 Last Fragment

  Fragment Offset:      0  (0 bytes)
  Time To Live:         107
  Protocol:             6  TCP - Transmission Control Protocol
  Header Checksum:      0x540D
  Source IP Address:    211.45.217.3
  Dest. IP Address:     XXX.XXX.XXX.209
TCP - Transport Control Protocol
  Source Port:          54291
  Destination Port:     80  http
  Sequence Number:      1860851285
  Ack Number:           3213622079
  TCP Offset:           5  (20 bytes)
  Reserved:             %000000

  TCP Flags:            %010000  .A....
                        0. .... (No Urgent pointer)
                        .1 .... Ack
                        .. 0... (No Push)
                        .. .0.. (No Reset)
                        .. ..0. (No SYN)
                        .. ...0 (No FIN)

  Window:               65535
  TCP Checksum:         0x7D98
  Urgent Pointer:       0
  No TCP Options
HTTP - Hyper Text Transfer Protocol
  Continuation of existing HTTP
stream<STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><
STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><ST
X><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX>
<STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><S
TX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX
><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><
STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><ST
X><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX>
<STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><S
TX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX
><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><
STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><ST
X><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX>
<STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><S
TX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX
><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><
STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><ST
X><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX>
<STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><S
TX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX
><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><
STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><ST
X><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX>
<STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><S
TX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX><STX
>
FCS - Frame Check Sequence
  FCS:                  0x00000000  Calculated

After a short examination of the related packets the following detect is
also seen to be related to the same attack as it appears immediately
prior to the first detect and within the same http session.

Detect #2 rule triggered is (Packet previous to detect #1):
[**] [119:15:1] (http_inspect) OVERSIZE REQUEST-URI DIRECTORY [**]
04/22-08:14:09.452902 0:2:3B:2:67:D2 -> 0:10:A7:5:62:CA type:0x8864
len:0x5DE
211.45.217.3:54291 -> 217.136.26.209:80 TCP TTL:107 TOS:0x0 ID:5527
IpLen:20 DgmLen:1480 DF
***A**** Seq: 0x6EEA50B5  Ack: 0xBF8BFB3F  Win: 0xFFFF  TcpLen: 20

The Etherpeek decode of this packet is as follows.


Packet Info
  Flags:                0x00
  Status:               0x00
  Packet Length:        1506
  Timestamp:            09:14:09.452902000 04/22/2004
Ethernet Header
  Destination:          00:10:A7:05:62:CA  Unex Tech:05:62:CA
  Source:               00:02:3B:02:67:D2  Redback Net:02:67:D2
  Protocol Type:        0x8864  PPPoE Session
PPP over Ethernet
  Version:              1
  Type:                 1
  Code:                 0x00  Session
  Session Id:           38422
  Length:               1482
Point-to-Point Protocol
  PPP                   0x0021  IP, Internet Protocol
IP Header - Internet Protocol Datagram
  Version:              4
  Header Length:        5  (20 bytes)
  Differentiated Services:%00000000
                        0000 00.. Default
                        .... ..x. Reserved
                        .... ...x Reserved

  Total Length:         1480
  Identifier:           5527
  Fragmentation Flags:  %010
                        0.. Reserved
                        .1. Do Not Fragment
                        ..0 Last Fragment

  Fragment Offset:      0  (0 bytes)
  Time To Live:         107
  Protocol:             6  TCP - Transmission Control Protocol
  Header Checksum:      0x540E
  Source IP Address:    211.45.217.3
  Dest. IP Address:     217.136.26.209
TCP - Transport Control Protocol
  Source Port:          54291
  Destination Port:     80  http
  Sequence Number:      1860849845
  Ack Number:           3213622079
  TCP Offset:           5  (20 bytes)
  Reserved:             %000000

  TCP Flags:            %010000  .A....
                        0. .... (No Urgent pointer)
                        .1 .... Ack
                        .. 0... (No Push)
                        .. .0.. (No Reset)
                        .. ..0. (No SYN)
                        .. ...0 (No FIN)

  Window:               65535
  TCP Checksum:         0xD044
  Urgent Pointer:       0
  No TCP Options
HTTP - Hyper Text Transfer Protocol
  Continuation of existing HTTP stream
  Binary Data:
  SEARCH /........  53 45 41 52 43 48 20 2F 90 02 B1 02 B1 02 B1 02
  ................  B1 02 B1 02 B1 02 B1 02 B1 02 B1 02 B1 02 B1 02
.
.
.
  ................  B1 02 B1 02 B1 02 B1 02 B1 02 B1 02 B1 02 B1 02
FCS - Frame Check Sequence
  FCS:                  0xE64D141C  Calculated
The third detect
[**] [1:648:6] SHELLCODE x86 NOOP [**]
[Classification: Executable code was detected] [Priority: 1] 
04/22-08:14:09.762991 0:2:3B:2:67:D2 -> 0:10:A7:5:62:CA type:0x8864
len:0x5DE
211.45.217.3:54291 -> 217.136.26.209:80 TCP TTL:107 TOS:0x0 ID:5611
IpLen:20 DgmLen:1480 DF
***A**** Seq: 0x6EEA5BF5  Ack: 0xBF8BFB3F  Win: 0xFFFF  TcpLen: 20
[Xref => http://www.whitehats.com/info/IDS181]

In the interest of space I will not include the decode here.  Suffice it
to say that the http data section of the packet included 1440 "no
operation" (NOOP) (0x90) codes.  On average there were 15 of these
packets per attack. The combination of these three detects were found
two further times within the file. 
Explanation of Trigger Stimulus
Detect #1 
Normally, the Http command included within this packet should have begun
with a valid HTTP method such as GET.  Instead, the first data packet is
simply a binary data stream.  The HTTP 1.1 methods are defined in
RFC2616.  The omission of the HTTP method triggers the rule "Bare Byte
Unicode Encoding"

Detect #2
The http data field within this packet starts with the string "SEARCH /"
which conforms to the http method encoding standard.  Therefore, the
rule "Bare Byte Unicode Encoding" does not fire.  While the HTTP method
"search" in this packet is not in the HTTP 1.1 specification, it is
included in the "Web-based Distributed Authoring and Versioning"
(WebDAV) specification. However, the length of the http data field is
larger than the configured maximum for a directory query which is
programmed as a default of 300 in the preprocessor section of the
Snort.conf file.  This triggers the "OVERSIZE REQUEST-URI DIRECTORY."
As this rule triggers before the bulk of the ruleset is applied to the
packet, rule 1500 does not fire. (I am waiting for a Win32 binary for
Snort 2.1.13 to fix this one)

Detect #3
Within the HTTP data field of the packet are a large number of (0x90)
binary instructions which translate to the (NOOP) instruction in x86
assembly language.  A NOOP instruction is simply an instruction which
tells the CPU to wait one command interval and then load and execute the
next command.  Anywhere outside of a wait loop in a program, this is
always a sign of bad things to come.
13      Probability the source address was spoofed:
For this attack to succeed, the attacker must complete a three way
handshake and push data into a vulnerable web server.  In the absence of
predictable sequence numbers this is not possible.  Once the three way
handshake has been successfully completed, and the offending packet(s)
pushed to the web server, the next step is to try to open a telnet
session to the hacked machine on the designated port (e.g.31337) to
determine if the attack resulted in a compromise instead of just a
crash.  The end conclusion is that the source address is unlikely to be
spoofed.
Potential Sources of Attacks
A query to http://ww2.arin.net/whois/ provides the following information
on the three sources for the detected packets.

Search results for: 211.45.217.3

inetnum:      211.45.192.0 - 211.45.255.255
netname:      BORANET-NET-211-45-192
descr:        DACOM Corp.
descr:        Facility-based Telecommunication Service Provider
descr:        providing Internet leased-ine, on-line service, BLL etc.
country:      KR
admin-c:      DB50-AP
<http://www.apnic.net/apnic-bin/whois.pl?searchtext=DB50-AP&form_type=ad
vanced> 
tech-c:       DB50-AP
<http://www.apnic.net/apnic-bin/whois.pl?searchtext=DB50-AP&form_type=ad
vanced> 
mnt-by:       APNIC-HM
<http://www.apnic.net/apnic-bin/whois.pl?searchtext=APNIC-HM&form_type=a
dvanced> 
mnt-lower:    MAINT-KR-DACOM
<http://www.apnic.net/apnic-bin/whois.pl?searchtext=MAINT-KR-DACOM&form_
type=advanced> 
changed:      hm-changed@xxxxxxxxx 20021202
status:       ALLOCATED PORTABLE
source:       APNIC



Search results for: 24.213.249.141
OrgName:    Road Runner-Commercial
OrgID:      RCNY
<http://ws.arin.net/cgi-bin/whois.pl?queryinput=O%20!%20RCNY> 
Address:    13241 Woodland Park Road
City:       Herndon
StateProv:  VA
PostalCode: 20171
Country:    US

ReferralServer: rwhois://ipmt.rr.com:4321

NetRange:   24.213.128.0
<http://ws.arin.net/cgi-bin/whois.pl?queryinput=24.213.128.0>  -
24.213.255.255
<http://ws.arin.net/cgi-bin/whois.pl?queryinput=24.213.255.255> 
CIDR:       24.213.128.0/17
NetName:    RR-COMMERCIAL-NYC-3
<http://ws.arin.net/cgi-bin/whois.pl?queryinput=N%20.%20RR-COMMERCIAL-NY
C-3> 
NetHandle:  NET-24-213-128-0-1
<http://ws.arin.net/cgi-bin/whois.pl?queryinput=N%20!%20NET-24-213-128-0
-1> 
Parent:     NET-24-0-0-0-0
<http://ws.arin.net/cgi-bin/whois.pl?queryinput=N%20NET-24-0-0-0-0> 
NetType:    Direct Allocation
NameServer: NS1.BIZ.RR.COM
NameServer: NS2.BIZ.RR.COM
NameServer: DNS4.RR.COM
Comment:
RegDate:    2003-03-06
Updated:    2003-08-29


Search results for: 217.81.77.151

inetnum:      217.80.0.0 - 217.89.31.255
netname:      DTAG-DIAL14
descr:        Deutsche Telekom AG
country:      DE
admin-c:      DTIP
<http://www.ripe.net/perl/whois?searchtext=DTIP&form_type=simple> 
tech-c:       DTST
<http://www.ripe.net/perl/whois?searchtext=DTST&form_type=simple> 
status:       ASSIGNED PA
remarks:
************************************************************
remarks:      * ABUSE CONTACT: abuse@xxxxxxxxxx IN CASE OF HACK ATTACKS,
*
remarks:      * ILLEGAL ACTIVITY, VIOLATION, SCANS, PROBES, SPAM, ETC.
*
remarks:
************************************************************
mnt-by:       DTAG-NIC
<http://www.ripe.net/perl/whois?searchtext=DTAG-NIC&form_type=simple> 
changed:      ripe.dtip@xxxxxxxxxx 20001026
changed:      ripe.dtip@xxxxxxxxxx 20030211
source:       RIPE
route:        217.80.0.0/12
descr:        Deutsche Telekom AG, Internet service provider
origin:       AS3320
<http://www.ripe.net/perl/whois?searchtext=AS3320&form_type=simple> 
mnt-by:       DTAG-RR
<http://www.ripe.net/perl/whois?searchtext=DTAG-RR&form_type=simple> 
changed:      rv@xxxxxxxxxxx 20001027
source:       RIPE
person:       DTAG Global IP-Addressing
address:      Deutsche Telekom AG
address:      D-90492 Nuernberg
address:      Germany
phone:        +49 180 5334332
fax-no:       +49 180 5334252
e-mail:       ripe.dtip@xxxxxxxxxx
nic-hdl:      DTIP
mnt-by:       DTAG-NIC
<http://www.ripe.net/perl/whois?searchtext=DTAG-NIC&form_type=simple> 
changed:      ripe.dtip@xxxxxxxxxx 20031013
source:       RIPE
person:       Security Team
address:      Deutsche Telekom AG
address:      Germany
phone:        +49 180 5334332
fax-no:       +49 180 5334252
e-mail:       abuse@xxxxxxxxxx
nic-hdl:      DTST
mnt-by:       DTAG-NIC
<http://www.ripe.net/perl/whois?searchtext=DTAG-NIC&form_type=simple> 
changed:      abuse@xxxxxxxxxx 20030210
source:       RIPE
The three source IP addresses resolve to three geographically distinct
areas, specifically Korea, United States, and Germany.
14      Description of attack:
To clarify the attack, the detects will now be reordered into the
originally received order instead of the order upon which the detects
were selected for analysis.
THREE WAY HANDSHAKE (No detect)
One of the requirements for this attack is the establishment of an HTTP
session which of course requires the three way handshake.  These packets
were easily found in the raw packet logs.  No detects are linked to this
activity as this was a connection to an existing HTTP server with Snort
configured with the line 
"var HTTP_SERVERS $HOME_NET" in the snort.conf file.

OVERSIZE REQUEST-URI DIRECTORY
The next packet received by the web server began with the information
"SEARCH /........  " where the information trailing the "/" was a stream
of hex bytes starting with 0x90, 0x02, 0xb1, 0x02, 0xb1,,, After a bit
of a tutorial read on http methods from various sources, I finally found
reference to the search method being part of WebDAV by a google search
on the keywords ("http method" search x02 xb1") The messages thread
refers to WebDAV and Microsoft Security Bulletin MS03-007. 
(Link damaged looking for original again)

A search google search on the words WebDAV and Exploit turned up a good
tutorial on a previous very similar shellcode exploit which is available
at: 
http://home.comcast.net/~merana296463/files/fatelabs-ntdll-analysis.pdf


Since the binary data is not the same, this is not the exact exploit
captured here, but it demonstrates the techniques involved and shows the
resulting logs and results of a successful attack. 
Bare Byte Unicode Encoding
This detect was the original one selected for this analysis.  In reality
it is just part of the stream of data being sent to the web server.  As
Snort is currently stateless, the HTTP analysis is currently only
performed on a per packet basis.  This is explained in the
README.http_inspect file: as extracted below

                This initial version of HttpInspect only handles
stateless processing.  This means that HttpInspect looks for HTTP fields
on a packet by packet basis, and will be fooled if packets are not
reassembled.  This works fine when there is another module handling the
reassembly, but there are limitations in analyzing the protocol.  That's
why future versions will have a stateful processing mode which will hook
into various reassembly modules.

On its own this is an HTTP packet that does not conform to the http
standard in that the data field does not begin with a HTTP method, and
instead begins with Unicode bytes.  The reason that this packet does not
flag as a SHELLCODE x86 NOOP is due to the fact that the NOOP hex values
do not occur until late in the data field.  The current Snort rule #648
only searches for a string of NOOPs until a depth of 128 bytes.  The
NOOPs don't start until well after.    
SHELLCODE x86 NOOP 
This is the meat of the attack which is effectively to pad a large
number of NOOPs into the code space of the program and hope that an
instruction has a jump instruction into this active code space.  We do
not see the active code uploading to the server because (un)fortunately
the Apache web server intervenes prior to the arrival of the interesting
code.  Apache is not vulnerable to the IIS vulnerability and provides
the following error message back to the offending host.  HTTP/1.1
414 Request-URI Too Large<CR><LF>

Note: Unless you turn on word wrapping in WordPad, you may not see the
happy end to that message (the 414 reply) as WordPad seems to have
difficulty with displaying these long lines properly.
Analysis Common to All Detects
All of the detects from a single IP address came from the same http
session, but that does not prove whether they are part of the same event
or whether they are independent events.  My next step was to open the
Apache log file and confirm the outcome of the attack if possible.  I
was quite interested to know whether I could prove to myself that the
attacks were unsuccessful, or whether I would be rebuilding the system
from scratch.  The times in the log files appear different until you
note that the Apache log is UTC +2  and the system log is UTC +1 (CET).
The following log entry shows that the collection of packets have been
reassembled into a single malicious HTTP Search request of over 6 Kbytes
in length.  Over 27 Kbytes of NOOPs and other related binary information
were thrown at the server, but the server generated a response and ended
the session well before they had all been delivered.

This entry was found in the Apache 2.0 access.log
211.45.217.3 - - [22/Apr/2004:08:14:10 +0200] "SEARCH
/\x90\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x0
2\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x0
2\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1.
.
.
\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90
\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90
\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90
\x90\x90\x90\x90HTTP/1.0" 414 366

The end result of this all:  Exploit is the WebDAV Exploit a.k.a.
Windows NTdll.dll Buffer overflow as documented in CAN 2003-0109.
Evidence of Packet Crafting
The rate and types of packets delivered to the web server makes it
probable that some form of script or worm was used to generate and
deliver the packets.  Of interest here is that while the source
application properly initiated the three way handshake, it did not make
use of the push flag, and tended to ignore both the FIN and multiple
Reset flags that were sent back to the attacker by the web server.
Ignoring the reset flag could either be accomplished by the code, or by
filtering at the attacker's firewall (as a hacker defense against active
response mechanisms in an IDS.)
15      Attack mechanism:
This attack is a classic, buffer overflow.  The attack attempts to
exploit a buffer overflow in the WebDAV Search method by pumping a large
number of NOOPs at the web server followed by a block of code which will
nominally create a root shell for the attacker to log into.  As the
attacker has no knowledge of exactly where in the memory space the code
will be downloaded, he effectively needs to have a range of memory
addresses affected which will lead to his code.  A large number of NOOPs
achieves this goal as they will all execute in sequence leading to the
attack code.  The random chance is where the program will branch to, and
whether this will just lead to a bad crash, or to the execution of the
attack code.  There are lots of books written on the subject, but the
document "Analysis of the ntdll.dll WebDAV Exploit, Fate Research Labs
Internet Warfare and Intelligence Team http://www.fatelabs.com, Date:
Tue. March 25, 2003" provides a concise walk through of the events
including logs from successful attacks.  While this is not the exact
attack shown here (the binary code is different in this attack,) the
information is still quite relevant.  Likely this is a variant on the
original script.
16      Correlations:
The WebDAV exploit was first announced in CAN 2003-0109 in Feburary 2003
under the title of "Windows NTdll.dll Buffer overflow".
Other references of user are:
http://www.whitehats.com/info/IDS181
http://www.snort.org/snort-db/sid.html?sid=648
http://home.comcast.net/~merana296463/files/fatelabs-ntdll-analysis.pdf

http://www.securityfocus.com/bid/7116
http://www.microsoft.com/technet/security/bulletin/MS03-007.mspx
http://www.whitehats.com/info/ids181

README.http_inspect from the Snort 2.1.12 documents

The SecurityFocus web site appeared to be a little too helpful as it
provided downloads for 10 different attack scripts to implement this
exploit.  While having the code from these exploits is useful in
decoding new exploits, it is also helps the script kiddies to be
hackers.

There is a short thread on the Snort-Sigs mailing list (2004-04-01
21:05) started by Tyler Hudak with another variant on this attack (where
the initial packet is less than 300 bytes (or the relevant preprocessor
is disabled).  In his case, the "MISC WebDAV search access" rule
triggers.  As the second detect he describes is a x86 ShellCode NOOP, I
suspect that the data again differs from my attack, but that the end
goal is the same.

Finally an excellent in depth analysis is provided by Brandon Young GCIH
at http://www.giac.org/practical/GCIH/Brandon_Young_GCIH.pdf

17      Evidence of active targeting:
In order to be successful previous reconnaissance should be done in
order to find active IIS servers which might be vulnerable.  In this
case, a response on Port 80 was seen to be good enough to launch the
script even though simply opening the default home page would have
hinted to the attacker that he was barking up the wrong tree...  Well
when all you have is a hammer, all your problems look like Microsoft
IIS.
18      Severity
Severity = (criticality + lethality) (system countermeasures + network
countermeasures)
The attacker guessed the right code platform and operating system, but
guessed the wrong web server.  As the web server information was 
 
Criticality     3:  This attack was launched against a Windows XP
workstation configured as a Web server.  As this is one of the main
systems I am currently relying on for Snort analysis to complete this
assignment, this represents a very important asset.  As it is not the
central web server at the office, it does not rate a higher score
Lethality       1:  As the attack was doomed to failure the moment I
chose Apache, this could not be a very lethal attack.
System countermeasures 2:  In order to entice enough packets to perform
analysis, I disabled the personal firewall on the system as a calculated
risk.  However, the system is fully patched for the operating system,
applications and antivirus.  
Network countermeasures 2:  The DSL modem does not have a built in
firewall.  Each system (other than the IDS system with the web server)
has a personal firewall configured to block all incoming connections.
There is an active IDS system on the network which is currently being
reviewed almost daily (looking for the perfect detect for analysis #3)
Severity = (3 + 1) - (2 + 2) = 0
Overall this attack would rates as a 0 mainly due to the fact that the
attacker did not have the knowledge to correctly profile the intended
victim.
19      Defensive recommendation
The temporary disabling of the personal firewall has already been
corrected and is unlikely to be repeated.  Current plans to improve
security include the installation of a dedicated firewall with IDS built
in.  As this network currently has no requirement for published services
to the Internet, the firewall will have all incoming connections
blocked.  The personal firewalls will remain in service, but file
sharing between internal hosts may be allowed after the dedicated
firewall is installed.
20      Multiple choice test question:
alert ip $EXTERNAL_NET any -> $HOME_NET any (msg:"SHELLCODE x86 NOOP";
content: "|90 90 90 90 90 90 90 90 90 90 90 90 90 90|"; depth: 128;
reference:arachnids,181; classtype:shellcode-detect; sid:648; rev:4;) 
Based on the above rule, would the following packet be logged as a
SHELLCODE x86 NOOP exploit?
A)      Yes
B)      No, the IP data field must start with 90 90 90 90 90 90 ... 
C)      Insufficient information is given to determine the answer
D)      No, the detected content is too far from the beginning of the
packet
08:14:09.456949 PPPoE  [ses 0x9616] IP 1482: IP 211.45.217.3.54291 >
XXX.XXX.XXX.209.80: . 1441:2881(1440) ack 1 win 65535 (DF)
0x0000   1100 9616 05ca 0021 4500 05c8 1598 4000        .......!E.....@.
0x0010   6b06 540d d32d d903 0000 00d1 d413 0050        k.T..-.........P
0x0020   6eea 5655 bf8b fb3f 5010 ffff 7d98 0000        n.VU...?P...}...
0x0030   b102 b102 b102 b102 b102 b102 b102 b102        ................
.
.        (deleted section all b102)
.
0x02f0   b102 b102 b102 b102 b102 b102 b102 b190        ................
0x0300   9090 9090 9090 9090 9090 9090 9090 9090        ................
.
.        (deleted section all 9090)
.
0x05c0   9090 9090 9090 9090 9090 9090 9090 9090        ................

Answer: D
The sequence that this rule triggers on does not start until offset
0x2ff which is well after the rule depth of 128 bytes

21      Source of Trace #3:
Location of trace
This detect was extracted from the tcpdump file named 2002.8.22
downloaded from downloaded from http://www.incidents.org/logs/Raw/.  The
timestamps on these packets indicate that they were actually captured on
2003.08.22 between 14:34 and 15:36
Network Layout
Based on the captured packets, the network configuration consists of 2
computers with private IP addresses (192.168.2.101 and 102)   connected
to the INTERNET via a third system (host X) which is performing NAT
translations for host 102.  Insufficient information is available to
determine the IP address of NAT host X, but this host appears to be
programmed as the default gateway for host 102.  Only three MAC
addresses appear on this network.  Packet capture was made inside the
network (remote possibility that it was on host 102 as Windump is
installed on that system, but also possible as a receive only lan
analyzer.)

         +=========+                   +=========+
External |         |      Internal     | Private | 
=========| Host X  |=========+=========|Host 101 |
         |   NAT   |         |         |         |
         +=========+         |         +=========+
                        +=========+
                        | Private |
                        |Host 102 |
                        |         |
                        +=========+

22      Detect was generated by:
Snort intrusion detection system version 2.1.2 for Win32.  
Rule triggered 
[**] [1:2351:1] NETBIOS DCERPC ISystemActivator path overflow attempt
little endian [**]
[Classification: Attempted Administrator Privilege Gain] [Priority: 1] 
08/22-14:34:23.861089 0:D0:59:2B:7A:57 -> 0:50:DA:C5:9D:8B type:0x800
len:0x5EA
192.168.2.101:32777 -> 192.168.2.102:135 TCP TTL:64 TOS:0x0 ID:15427
IpLen:20 DgmLen:1500 DF
***A**** Seq: 0xBBCCB264  Ack: 0x3704D4B  Win: 0x16D0  TcpLen: 32
TCP Options (3) => NOP NOP TS: 167847 11838 
[Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0352]

Explanation of Trigger Stimulus
alert tcp $EXTERNAL_NET any -> $HOME_NET 135 (msg:"NETBIOS DCERPC
ISystemActivator path overflow attempt little endian";
flow:to_server,established; content:"|05|"; distance:0; within:1;
byte_test:1,&,16,3,relative; content:"|5c 00 5c 00|";
byte_test:4,>,256,-8,little,relative; reference:cve,CAN-2003-0352;
classtype:attempted-admin; sid:2351; rev:1;)

This decodes to Write an alert when a TCP packet from an External
network on any port sends a packet to a host on the internal network
port 135 and the following additional conditions are met:
*       Flow:to_server,established;  (the stream is flowing to the
server and a TCP session has been established
*       Content:"|05|;distance:0;within:1;(At byte offset 0 in the TCP
Data the hex data "05" appears.
*       byte_test:1, &,16,3,relative; 3 bytes after the "05" compare the
next byte against 16 (0x10)
*       content:"|5c 00 5c 00|"; search for hex data "5C 00 5C 00" found
at offset "0x56C" within this packet
*       byte_test:4,>,256,-8,little,relative;  8 bytes before the end of
the previous content match compare the next 4 bytes (i.e. the 4 bytes
immediately preceding the last content match to ensure that they are
greater than 256 (when those 4 bytes interpreted as least significant
byte first)
23      Probability the source address was spoofed:
Somewhat less than none.  The attacking host is internal to the network
and on the same segment as the packet logger.  The attack is based on an
established TCP session between attacker and victim with the intent of
establishing a RootShell.
Source of Attack
Internal computer at IP address 192.168.2.101 (MAC Address
00:D0:59:2B:7A:57)
24      Description of attack:
The attacking computer utilized the kaht2.exe exploit code to send a
buffer overflow to the DCOM RPC service on a Windows system.  The
linkage to the kaht2 code is based on a very strong match between the
captured code from the log file, and the shell code extracted from the
kaht2 program.  The kaht2 program was downloaded from
http://www.securityfocus.com/bid/8205/exploit/.
Only 2 bytes of the code differ between the two sets of binary code.
This difference is possibly related to the listening port (53) for the
root shell.  Immediately after the delivery of this payload the
attacking system opened a connection to the exploited system (root
shell) on port 53 where he was able to browse directories, execute
applications that were on the system (Windump), and view raw http
packets (and replies) being transmitted between that workstation and the
Internet.
25      Attack mechanism:
This is a classic buffer overflow overflow as implemented by the
Blaster, MSBlast, LoveSan, scripts and the Nachi, and Welchia worms
(reference to ???)

The destination is port 135 and the DCOM RPC service where the script or
worm overflows a buffer to insert a shell code.  In this case the
shellcode immediately started listening for connections on port 53
providing the attacker with full access on the system.
26      Correlations:
This exploit was first published in July 2003
http://www.microsoft.com/technet/security/Bulletin/MS03-026.mspx
http://www.microsoft.com/technet/security/bulletin/MS03-039.mspx
http://www.securityfocus.com/bid/8205
Snort\rules\netbios.rules
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0352
http://www.cert.org/advisories/CA-2003-16.html
http://www.cert.org/advisories/CA-2003-19.html
The exploit is readily available in either script or worm varieties and
has been categorized under several names and variants. 
27      Evidence of active targeting:
This attack is interesting in that it is an insider attack.  In this
case the attacker is able to monitor the activities of the user of host
102 without significant risk of detection.
28      Severity
Severity = (criticality + lethality) (system countermeasures + network
countermeasures)
 Criticality    2:  Host 102 appears to be a windows 2000 Professional
system (build 2195) with peer web services installed (based on the
directory structure browsed by the attacker which included a inetpub
directory in C:\  The owner of the system may be named Jamie (another
directory in C:\)  The system has at least some administrative tools
(Windump) installed.  However, this configuration does not seem to be a
critical installation based on the network layout.
Lethality       5:  The attack was completely successful with no
apparent error messages being logged by the system (the Port 135 session
was terminated gracefully  without error after the shell code was
delivered.)  The attack makes no changes to the file system nor changes
to the registry making its detection difficult unless the attacker
executes further less subtle attacks.
System countermeasures 1:  While the exploits had only received less
than 2 months of publicity, the publicity available was quite high
profile.  As such, the system should have been patched by late August
when the attack occurred.
Network countermeasures 2:  The network connection is utilizing NAT
which provides a good start towards security.  Specifically, packets
addressed to any ports which are not explicitly mapped through the NAT
box to a particular host on the inside network have no place to go.
Severity = (2 + 5) - (1 + 2) = 4
This is an attack which requires immediate action to ensure that the
system is not used as an attack platform against other systems, and to
protect the privacy of host 102's personal information. Defensive
recommendation.
29      Defensive recommendation:
As this is an insider attack, special attention must be directed at
properly handling the incident.  Management and legal advise must be
sought to ensure that the appropriate civil and / or criminal legal
actions are taken.  Initial steps to preserve and isolate both systems
needs to be taken, as well as isolating the systems from the INTERNET
(as we do not know yet what else is lurking in the two systems.  Once
the legal mire has been sorted, the system needs to be rebuilt (after
preserving and quarantining data) including all of the relevant patches.
A good review on the recovery of compromised systems can be found at 
30      Multiple choice test question:
Based on the following rule from Snort 2.*
alert tcp $EXTERNAL_NET any -> $HOME_NET 135 (msg:"NETBIOS DCERPC
ISystemActivator path overflow attempt little endian";
flow:to_server,established; content:"|05|"; distance:0; within:1;
byte_test:1,&,16,3,relative; content:"|5c 00 5c 00|";
byte_test:4,>,256,-8,little,relative; reference:cve,CAN-2003-0352;
classtype:attempted-admin; sid:2351; rev:1;)

Which of the following stimulus will trigger the above rule (assuming
all other criteria are met)

A)      The string "5c 00 5c 00" within the TCP data of the packet
B)      The Hex data "0x5c005c00" within the UDP data of the packet
C)      The string "attempted-admin" within the TCP data of the packet
D)      The Hex data "0x05" in the first byte of the TCP data of the
packet

Answer D:

Not A (looking for hex not string)
Not B (looking for TCP packets)
Not C (Attempted-Admin is the class type for the alert and does not
appear in the packet)


_______________________________________________
Intrusions mailing list
Intrusions@xxxxxxxxxxxxxx
http://www.dshield.org/mailman/listinfo/intrusions