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

[Fernando Gont]

Hi, Marc,

On 10/17/2015 03:25 AM, Marc Heuse wrote:
> 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.

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


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

Nope. e.g. FreeBSD as a router will drop them, and they have been
subject to NCE. Besides, this happene when sending from 40 different
sources rather from thousahnds --- i.e. NCE prevention wasn't kicking in
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.



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

When it comes to "multilevel ragmentation", does that mean that the
"second" FH will appear as a result of packet reassembly or what? --
i.e. "nested" fragmentation

(i.e., the packet is reassembled, and turns out that the reassembled
packet is a fragment...)

That case would be legal. OTOH, multiple FHs back to back are non-ensical



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


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


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

Yes. But, I said, both of them are different problems.

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont at si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492