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

[Enno Rey]

Guys,

Marc wrote:

> yes I know from own harsh experiences :)
> but the drop rate is about 50% on average.
> however: on my main server the drop is 100% because my uplink is
> dropping. thankfully I have alternatives.
> 
> and it is something that has to be fixed. dropping fragmented packets is
> a no-no, independent of the IP version.

except for the IP version that kinda deprecates fragmentation, that is IPv6.
you know that I'm a big fan of "drop [all] the crap at your network border"... one of Germany's largest enterprise networks drop all fragments at their borders since 12 months [IPv6]. they don't observe any issues, not even hits on the respective ACLs...

have a great weekend everybody

Enno






> 
> > * Slide #9:
> > 
> > Some router implementations, when they receive a packet meant for a node
> > that has no entry in the Neighbor Cache, they drop the packet, and
> > engage in Neighbor Discovery. If you really engage into sending one
> > probe from a different address at a time, chances are that you might get
> > no response as a result of this.
> 
> this depends on the router/switch, I also have seen this behaviour.
> I have also seen a different behaviour, a router dropping packets if
> they haven't have the local sender in their neighbor list.
> 
> the way to go might be an unsolitated NA broadcast.
> 
> In the situation where I experimented however, I was not in such a LAN
> where either drop type happens.
> 
> My guess would be that this drop is based on NDP exhaustion attack
> prevention implementations.
> 
> > * 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.
> 
> > * Slide #31
> > What does Windows do when multiple FHs are present?
> 
> process them without any issues. 100 atomic fragments? yep, will eat it.
> multilevel fragmentation, yep, can do them too.
> 
> > 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.
> 
> > * 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).
> that would make it easier for firewalls, IDS etc. systems to analyse
> packets. Due to the high complexity of possibilities, thats why it is so
> difficult to get right.
> 
> > * Slide #41
> > You just flood the local netork with lots of PIOS, just lost of RAs, or
> > what?
> 
> yeah that is basically the attack I discovered in 2007 still works today
> (not reliably for the crashes though). floods with random RAs with many
> SLAACs and route entries, but (the -s option) with small lifetimes.
> 
> Greets,
> Marc
> 
> --
> Marc Heuse
> www.mh-sec.de
> 
> PGP: AF3D 1D4C D810 F0BB 977D  3807 C7EE D0A0 6BE9 F573
> _______________________________________________
> Ipv6hackers mailing list
> Ipv6hackers at lists.si6networks.com
> http://lists.si6networks.com/listinfo/ipv6hackers

-- 
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

=======================================================
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
=======================================================