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

[Marc Heuse]

Hi Fernando,

On 17.10.2015 00:17, Fernando Gont wrote:
>> I released that for the my presentation at GSEC Singapore, "Hiding in
>> Complexity". Slides are here:
>> http://gsec.hitb.org/materials/sg2015/D3%20-%20Marc%20Heuse%20-%20Hiding%20in%20Complexity.pdf
> 
> Nice preso! Somme comments/question/feedback on the slideware:
> 
> * Slide #1:
> 
> Side comment: for remote scans pentests, the issue is that at time,
> employing EHs gets your traffic dropped.

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.

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