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

[Enno Rey]

Hi,

On Tue, Oct 20, 2015 at 08:54:22AM +0200, Marc Heuse wrote:
> 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).
> 
> 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

actually most commercial firewalls will drop this _by default_.
I can confirm for Check Point (see also https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk39374) and Cisco ASA, both tested ~ 12 months ago with latest code, at the time.
See also https://www.ernw.de/download/AAtlasis-RISC-project-presentation-%20results.pdf.

The main point/difference here being that a firewall usually operates in "allow sth, drop the rest" mode whereas an IDPS (or, for that matter, an "Infrastructure ACL" or most FHS features like RA Guard) operate in "(recognize) and drop sth bad, allow the rest" mode. The latter is very hard (if not impossible) to achieve properly once EHs and/or fragmentation come into play.

best

Enno








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