[ipv6hackers] thc-ipv6 v3.0, IPv6 complexity and evasions

[Marc Heuse]

Hi Fernando,

On 20.10.2015 02:37, Fernando Gont wrote:
> I'd argue that for most of the traffic that you employ for evasion, the
> right thing to do is to dropped. (Yep, I agree that dropping fragments
> is not nice).

yes and no.
In IDS evasion you have three basic types:
1. sending duplicate packets with different content and a hop limit - 1
2. fragmentation wizardry
3. extension header stacking (this one is IPv6 only)
- and a mix of these.

a stateful inspection firewall *should* always filter all packets. in
reality it depends on the vendor if they do or don't.

#1 would pass a static filter, and no router would drop these kinds of
packets.
#2 some of the examples I use for bypass are legit packets - basically
the IDS is doing the basic things wrong. no firewall can do something
there. but otherwise: yes, a firewall should drop when multi
fragmentation layers or overlapping/resending fragments is present.
#3 again, some firewalls filter, some dont. with the snort example, you
just put 9 destination EH there with their minimum size and then your
payload. No firewall I know filters this unless you configure it to, and
it is an RFC legal packet, but Snort will not see the attack itself but
just yell "uhhhh too many headers here".

>>> * Slide #13
>>> What do you mean by "splitting connections"?
>>
>> you send from 2001::1 to the server, the server sends the reply packets
>> to 2001:2. Pretty simple, but fucks up the flow analysis.
>> The tool does just this basic implementation for TCP as a POC. you could
>> do that for all protocols, to/from random addresses from the client (and
>> server), fragment packets, etc.
> 
> Are you using MTCP or what? Because the remote TCP will obviously repond
> to the Source Address in the SYN packet.

on both sides of the connection you run a little user space tool hooked
to ip6tables NF_QUEUES that sets the address. on the client side on the
destination of incoming packets, on the server side on the destination
of outgoing packets.
and recalc the checksum afterwards.

>>> You say "Resending fragments with different data:
>>> last received is used". But you previously said that Windows doesn't
>>> allow overlaping fragments, so... what would "Resending fragments with
>>> different data" actually mean?
>>
>> exactly that. it is the exact same fragment part that is sent first with
>> fake data then with real data, and the last packet (so here the real
>> data) is processed.
>> it seems that windows interprets them as a resend and surprisingly takes
>> the newer data, as - how I implemented this test case - they do not overlap.
> 
> But... then they are not dropping overlapping fragment but they *do*
> allow overlapping fragments.

in their book it seems not to be a case of overlapping, but a resend.
write them an email and complain :)


>>> * Slide #39
>>>
>>> You say that draft-ietf-6man-oversized-header-chain-09 (now RFC7112!) is
>>> incomplete. What, specifically, are you thinking of? (prohibition of
>>> overlapping fragments is in a different RFC).
>>
>> the draft (or now RFC) is great.
>> incomplete in so far, as in my opinion there has to be a MUST on the
>> order of EHs, and how often each EH is allowed to be present (all just
>> one except for DST EH two).
> 
> Well, those are two different issues.

of course but still this is what is needed if we dont want to scrap EHs
altogether.

sorry that I also focus on solving things. I know this is unusual for me
as I usually solely concentrate on breaking stuff :p

Greets,
Marc

-- 
Marc Heuse
www.mh-sec.de

PGP: AF3D 1D4C D810 F0BB 977D  3807 C7EE D0A0 6BE9 F573