[Intrusions] LOGS: GIAC GCIA Version 3.4 Practical Detect VilaipornTaweelappontong
Breault.SM at forces.gc.ca
Breault.SM at forces.gc.ca
Sun Jul 11 22:24:12 GMT 2004
Hi hope this helps,
>cut from your detect
3. Probability the source address was spoofed
HTTP session requires a complete 3-way handshake.
This packet, however, did not complete the handshake
so it is unlikely that the source ip would be spoofed.
Does this mean that an IP who does not complete the handshake is therefore
not spoofed????
Stephen Breault
Master Seaman
Shift 4 Supervisor
DND Computer Incident Response Team (DND CIRT)
Canadian Forces Network Operations Centre
Téléphone / Phone: (613) 945-7746 CSN: 849-7746
Télécopieur / Fax: (613) 945-6407
Courrier électronique / E-Mail: <mailto:Breault.SM at forces.gc.ca>
DWAN: <mailto: Breault MS SH at ADM(IM)
CFS Leitrim at Ottawa-HullCFNOC@Ottawa-Hull>
Building/Edifice: CFS Leitrim
DIN: <http://img.mil.ca/cfiog-ipc/ops/cirt/>
***** Computer security incident? Call 613-945-7777 or toll free
1-877-DND-CIRT ******
***** Incident Informatiques? Apellez 613-945-7777 ou sans frais
1-877-DND-CIRT ******
-----Original Message-----
From: Vilaiporn Taweelappontong
[mailto:vilaiporn_taweelappontong at yahoo.com]
Sent: Sunday, July 11, 2004 2:31 AM
To: intrusions at lists.sans.org
Subject: [Intrusions] LOGS: GIAC GCIA Version 3.4 Practical Detect
VilaipornTaweelappontong
Dear all
This is a second attempt to post the assignment. I
would really appreciate if someone could give me
comments on my analysis.
Thank you very much in advance and regards,
Vilaiporn
1. Source of trace
Source of trace was file 2003.12.15.6 downloaded from
www.incidents.org/log.
-Statistics (from Ethereal)
File length: 3000044
Format: libpcap
Start time: 2:07:16.936242
End time: 2:08:17.518422
Elapsed time between first and last packet: 60.582
seconds
Packet count: 36672
Snapshot length: 96
I used the Statistics function of ethereal to
summarize a list of IP addresses and MAC addresses in
the file. And I looked up a vendor Ethernet MAC
address from the web site
http://www.coffer.com/mac_find/. Below is an
architecture base on my understanding:
10.10.10.165 (00:03:47:8c:89:c2 Intel machine ) --->
3COM (00:01:02:79:91:ed) ---> Sniffer ----> Firewall
---> 192.168.17.68 (00:50:56:40:00:6D VMWARE)
Observation:
File date and timestamp reported are different. The
file name indicate that the data should be 2003/12/15
but the date specified in all packets actually
indicated packets generated on 2003/11/19. I
understand that some technique was used to obfuscate
the information, such as modify ip address, as
checksum of all packets are correct. Or no obfuscation
has been done.
2. Detect was generated by
The file is stored in tcpdump binary format. The
detect presented in this assignment was generated by
Snort version 2.1.1, which I ran the analysis with my
Windows 2000 Server machine. I ran snort in the NIDS
mode with standard snort ruleset downloaded on 2 May
2004. All rules files were enabled. Command that was
used:
C:\snort\bin\snort -r 2003.12.5.6 -c
c:\snort\etc\snort.conf -l ex1 -X -d -A full
-r 2003.12.5.6 read source file 2003.12.5.6
-c c:\snort\etc\snort.conf run against the
configuration file snort.conf
-l ex1 log the output file (alert file and log file)
in ex1 folder
-X dump the raw packet data starting at the link layer
(in this case, this is the Ethernet header)
-d dump the application layer (dump the packet
payloads with the packet headers)
-A full display text alert with full packet headers
The selected alert result is as follow:
[**] (http_inspect) BARE BYTE UNICODE ENCODING [**]
11/19-02:08:04.823979 10.10.10.165:1085 ->
192.168.17.68:80
TCP TTL:128 TOS:0x0 ID:42592 IpLen:20 DgmLen:41 DF
***A**** Seq: 0xE4F18713 Ack: 0x16A6B6DB Win: 0x4470
TcpLen: 20
The snort rule that trigger the 'Bare Byte Unicode
Encoding' was the http_inspect in the preprocessor
configure. [1] Preprocessors take the decoded packets
from the Snort packet decoder and can examine or
manipulate them before they are handed to the
detection engine.
preprocessor stream4_reassemble
preprocessor http_inspect: global \
iis_unicode_map unicode.map 1252
preprocessor http_inspect_server: server default \
profile all ports { 80 8080 8180 } \
oversize_dir_length 500
Note that profile all includes the 'bare byte
decoding' enabled. The following configuration were
displayed when you run snort (without quiet option
enabled). You can see that the bare byte option was
set to YES.
HttpInspect Config:
GLOBAL CONFIG
Max Pipeline Requests: 0
Inspection Type: STATELESS
Detect Proxy Usage: NO
IIS Unicode Map Filename:
c:\snort\etc\unicode.map
IIS Unicode Map Codepage: 1252
DEFAULT SERVER CONFIG:
Ports: 80 8080 8180
Flow Depth: 300
Max Chunk Length: 500000
Inspect Pipeline Requests: YES
URI Discovery Strict Mode: NO
Allow Proxy Usage: NO
Disable Alerting: YES
Oversize Dir Length: 500
Only inspect URI: NO
Ascii: YES alert: NO
Double Decoding: YES alert: YES
%U Encoding: YES alert: YES
Bare Byte: YES alert: YES
Base36: OFF
UTF 8: OFF
IIS Unicode: YES alert: YES
Multiple Slash: YES alert: NO
IIS Backslash: YES alert: NO
Directory: YES alert: NO
Apache WhiteSpace: YES alert: YES
IIS Delimiter: YES alert: YES
IIS Unicode Map: GLOBAL IIS UNICODE MAP CONFIG
Non-RFC Compliant Characters: NONE
To look into the packet in details, I used windump to
generate packet in hex format:
C:\windump>windump -r 2003.12.15.6 -x -vv -n "dst host
192.168.17.68 and port 80"
02:08:04.823979 IP (tos 0x0, ttl 128, id 42592, len
41) 10.10.10.165.1085 > 192.
168.17.68.80: . [tcp sum ok] 3841034003:3841034004(1)
ack 380024539 win 17520 (DF)
4500 0029 a660 4000 8006 6dd3
0a0a 0aa5
c0a8 1144 043d 0050 e4f1 8713
16a6 b6db
5010 4470 b6b3 0000 9000 0000
0000
It's obvious that host 192.168.17.68 is a web server
and it's IIS. The data field displayed in hex above is
'90' (NOP bytes usually used by shellcode) which seems
like someone is trying a buffer overflow on the web
server.
Let's also look at other packets associated with host
192.168.17.68 for a better analysis.
C:\Snort\log\old>snort -r 2003.12.15.6 -v -q "host
192.168.17.68"
11/19-02:07:48.841453 10.10.10.165:1691 ->
192.168.17.68:1080
TCP TTL:128 TOS:0x0 ID:41554 IpLen:20 DgmLen:48 DF
******S* Seq: 0x293AB444 Ack: 0x0 Win: 0x4000
TcpLen: 28
TCP Options (4) => MSS: 1460 NOP NOP SackOK
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
11/19-02:07:51.828714 10.10.10.165:1691 ->
192.168.17.68:1080
TCP TTL:128 TOS:0x0 ID:41720 IpLen:20 DgmLen:48 DF
******S* Seq: 0x293AB444 Ack: 0x0 Win: 0x4000
TcpLen: 28
TCP Options (4) => MSS: 1460 NOP NOP SackOK
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
11/19-02:07:57.968183 10.10.10.165:1691 ->
192.168.17.68:1080
TCP TTL:128 TOS:0x0 ID:42089 IpLen:20 DgmLen:48 DF
******S* Seq: 0x293AB444 Ack: 0x0 Win: 0x4000
TcpLen: 28
TCP Options (4) => MSS: 1460 NOP NOP SackOK
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
11/19-02:07:59.094302 10.10.10.165:1703 ->
192.168.17.68:1080
TCP TTL:128 TOS:0x0 ID:42248 IpLen:20 DgmLen:48 DF
******S* Seq: 0x296B9F43 Ack: 0x0 Win: 0x4000
TcpLen: 28
TCP Options (4) => MSS: 1460 NOP NOP SackOK
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
11/19-02:08:02.163499 10.10.10.165:1703 ->
192.168.17.68:1080
TCP TTL:128 TOS:0x0 ID:42416 IpLen:20 DgmLen:48 DF
******S* Seq: 0x296B9F43 Ack: 0x0 Win: 0x4000
TcpLen: 28
TCP Options (4) => MSS: 1460 NOP NOP SackOK
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
11/19-02:08:04.823979 10.10.10.165:1085 ->
192.168.17.68:80
TCP TTL:128 TOS:0x0 ID:42592 IpLen:20 DgmLen:41 DF
***A**** Seq: 0xE4F18713 Ack: 0x16A6B6DB Win: 0x4470
TcpLen: 20
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
11/19-02:08:08.302980 10.10.10.165:1703 ->
192.168.17.68:1080
TCP TTL:128 TOS:0x0 ID:42605 IpLen:20 DgmLen:48 DF
******S* Seq: 0x296B9F43 Ack: 0x0 Win: 0x4000
TcpLen: 28
TCP Options (4) => MSS: 1460 NOP NOP SackOK
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
11/19-02:08:09.095015 10.10.10.165:1711 ->
192.168.17.68:1080
TCP TTL:128 TOS:0x0 ID:42615 IpLen:20 DgmLen:48 DF
******S* Seq: 0x2999ACB6 Ack: 0x0 Win: 0x4000
TcpLen: 28
TCP Options (4) => MSS: 1460 NOP NOP SackOK
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
11/19-02:08:12.089067 10.10.10.165:1711 ->
192.168.17.68:1080
TCP TTL:128 TOS:0x0 ID:42647 IpLen:20 DgmLen:48 DF
******S* Seq: 0x2999ACB6 Ack: 0x0 Win: 0x4000
TcpLen: 28
TCP Options (4) => MSS: 1460 NOP NOP SackOK
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Run time for packet processing was 0.750000 seconds
The above information still not enough to analyse the
intruder's attempt so I have merged all log files into
one with the following command.
C:> mergecap -w merge 2003.12.15.1 2003.12.15.2
2003.12.15.3 2003.12.15.4 2003.12.15.5 2003.12.15.6
2003.12.15.7 2003.12.15.8 2003.12.15.9 2003.12.15.10
2003.12.15.11 2003.12.15.12 2003.12.15.13
2003.12.15.14
Then I ran snort again with the same set of rules.
Some of the results that I got were shown below:
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
11/19-02:05:05.114599 10.10.10.165:2695 ->
192.168.17.68:1
TCP TTL:128 TOS:0x0 ID:21572 IpLen:20 DgmLen:48 DF
******S* Seq: 0x8158842 Ack: 0x0 Win: 0x4000
TcpLen: 28
TCP Options (4) => MSS: 1460 NOP NOP SackOK
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
11/19-02:05:05.115021 10.10.10.165:2696 ->
192.168.17.68:2
TCP TTL:128 TOS:0x0 ID:21573 IpLen:20 DgmLen:48 DF
******S* Seq: 0x816111F Ack: 0x0 Win: 0x4000
TcpLen: 28
TCP Options (4) => MSS: 1460 NOP NOP SackOK
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
11/19-02:05:05.116627 10.10.10.165:2697 ->
192.168.17.68:3
TCP TTL:128 TOS:0x0 ID:21574 IpLen:20 DgmLen:48 DF
******S* Seq: 0x816B61C Ack: 0x0 Win: 0x4000
TcpLen: 28
TCP Options (4) => MSS: 1460 NOP NOP SackOK
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
11/19-02:05:05.117195 10.10.10.165:2698 ->
192.168.17.68:4
TCP TTL:128 TOS:0x0 ID:21575 IpLen:20 DgmLen:48 DF
******S* Seq: 0x817B1FC Ack: 0x0 Win: 0x4000
TcpLen: 28
TCP Options (4) => MSS: 1460 NOP NOP SackOK
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
11/19-02:05:05.117646 10.10.10.165:2699 ->
192.168.17.68:5
TCP TTL:128 TOS:0x0 ID:21576 IpLen:20 DgmLen:48 DF
******S* Seq: 0x81865D4 Ack: 0x0 Win: 0x4000
TcpLen: 28
TCP Options (4) => MSS: 1460 NOP NOP SackOK
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
The above are just sample packets. We can tell from
the generated packets that the attacker did TCP port
scan and UDP port scan to identified the open ports of
host 192.168.17.68. Once port 80 is found running, the
attack knew that this is a web server. So the attacker
was trying to scan the server with, probably, web
server scanning tools.
3. Probability the source address was spoofed
HTTP session requires a complete 3-way handshake.
This packet, however, did not complete the handshake
so it is unlikely that the source ip would be spoofed.
4. Description of attack
[1] Bare byte encoding is an IIS trick that uses
non-ASCII chars as valid values in decoding UTF-8
values. This is NOT in the HTTP standard, as all
non-ASCII values have to be encoded with a %. Bare
byte encoding allows the user to emulate an IIS server
and interpret non-standard encodings correctly.
There are no legitimate clients that encoded UTF-8
this way, since it is non-standard.
For more descriptions on the terms being used,
Unicode is a single unified character set. Unicode
provides a unique number for every character, no
matter what the platform, no matter what the program,
no matter what the language. [5]
UTF-8 is a method to encode character to Unicode. (one
of the three common encoding method) UTF-8 encodes
each Unicode character as a variable number of 1 to 4
octets. Using Unicode/UTF-8, you can write in emails
and source code things such as Mathematics and
Sciences or different languages.
ASCII - ASCII code is the numerical representation of
a character. Because computer can only understand
numbers. All non-ASCII characters usually screwed up
when output it to the browser, such as some special
character or language. UTF-8 supports ASCII characters
but not very good in non-ASCII character.
A http connection to the web server will usually start
with a request method such as GET or POST. All packets
(except for the highlighted one) has started a 3 way
handshake by initiating SYN to the web server. Somehow
the highlighted packet sent the packet with ACK flag
set to the web server without the request method. This
does not follow the RFC2616 and trigger snort rule to
alert. The result from Ethereal actually display this
packet at 'Continuation' which means there is no
request in the packet.
5. Attack mechanism
As I analyzed the combined log, I found that host
10.10.10.165 tried various attacks against host
192.168.17.68 including TCP scan, UDP scan, socks scan
and probably Unicode attack. Usually I would try to
obtain the correlation evidence from the secondary
resource such as web server to confirm the attack.
However, the secondary resource is not available in
this case and we only have the snort log up to less
than 2 hours. With such limitation I would assume that
the attack using Unicode, somehow, was used as part of
the scanning process and one of the scanning policy
happen to use the non-ASCII character that trigger the
snort rule to alert.
To confirm my understanding, I set up a web server at
home and wrote some e-commerce pages. Then I ran snort
with the same rule set and used N-Stealth, a HTTP
Security Scanner, to scan the e-commerce application
that I created. N-Stealth used various combinations of
possible web application attack and generated a lot of
alerts including bare byte Unicode encoding' alerts.
6. Correlations
Bare byte Unicode encoding is considered under the
Unicode attack category. The Unicode attack was
previously raised by Bruce Schneier at
http://www.schneier.com/crypto-gram-0007.html
7. Evidence of active targeting
The attacker was trying to scan for vulnerable host.
Host 192.168.17.68 is not the key target at first.
8. Severity
Severity = (criticality + lethality) (system
countermeasures + network countermeasures)
Criticality 4: This attack targets the IIS
Server which is a widely used web server worldwide.
Lethality 2: This attack could be part of the
scanning and DoS. If successful, it could bring down
the server. For this case, this server is not the
target at first. The attacker performed host scanning
to look for vulnerable host. The attacker may have
succeeded compromise the server. From the log, there's
no sign of system down.
System countermeasures 2: The problem of IIS way of
encoding the non-ASCII character cannot be resolved
solely by patching. So I give 2.
Network countermeasures 2: Firewalls and routers
cannot prevent the Unicode attack that well. So I give
2 for this as well. Unless a specific web application
firewall is being used, then I will give a higher
rating.
Severity = (4 + 2) - (2 + 2) = 2
9. Defensive recommendation
-Apply necessary patches to prevent known
vulnerabilities at the web server or operating system.
-Apply a secure programming concept when developing
the web application. Necessary input validation must
be in place to filter out characters that will not be
needed. For most of the case, non-ASCII character
won't be needed for any field.
-Have network measures in place such as properly
configured router, firewalls and IDS.
10. Multiple choice questions
Which web server could be vulnerable to 'bare byte
Unicode encoding' attack?
A. IIS
B. Netscape
C. Apache
D. Any web server
Answer: A
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail
_______________________________________________
Intrusions mailing list
Intrusions at lists.sans.org
http://www.dshield.org/mailman/listinfo/intrusions
More information about the Intrusions
mailing list