[Intrusions] LOGS: GIAC GCIA Version 3.4 Practical Detect Vilaiporn Taweelappontong
Dana Webber
dana at dunrobin.dyn.dhs.org
Sun Jul 11 13:50:34 GMT 2004
Corelations?
> It is obvious that host 192.168.17.68 is a web server and it's IIS.
This is not obvious to me.
On Saturday 10 July 2004 22:30, Vilaiporn Taweelappontong wrote:
> 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
--
Dana Webber
dana at dunrobin.dyn.dhs.org
http://dunrobin.dyn.dhs.org
Getting a computer system to work is like banging your head against a brick
wall until the wall falls down.
More information about the Intrusions
mailing list