[ipv6hackers] IPv6 Security research

Owen DeLong owend at he.net
Wed Mar 28 21:52:52 CEST 2012

Sent from my iPad

On Mar 28, 2012, at 1:48 AM, Marc Heuse <mh at mh-sec.de> wrote:

> Hi Owen!
> Am 28.03.2012 05:14, schrieb Owen DeLong:
>> This requires you to have access to or compromise at least
>> one machine on the target network first. I'd be more
>> concerned about remote scanning attacks than local ones.
> penetration test assignments are often performed locally (internal
> audits, infrastructure reviews before going live, etc. (and playing
> scanning games at conferences too).
> So this is something penetration testers (like me) have to solve.
> But I totally agree, remote scanning techniques is the harder and more
> interesting part. I'd like to see more on this topic, further research
> from what I have published. And my published techniques get a bit
> obsolete, I heard that several DHCPv6 implementations now moved to
> random allocation.
>> If you're local, why not just enumerate the solicited
>> node addresses (there are only 16.7M of them, after all)
>> with ND packets and look for the answers. That should grab
>> 100% success and works regardless of RA or any other
>> mitigation tool.
> in the hope of learning something new here:
> what does this help? of course you could scan for ff02::1:ffXX:YY:ZZ
> (which is like scanning a IPv4 A class network) but I do not see how
> this helps. It is still a multicast address, so you can simply use
> ff02::1 as well. You can't TCP portscan a multicast address, NDP to a
> multicast address gets (of course) no result, and the same ping-reply
> restrictions apply to the solicitated node multicast address as for the
> all nodes multicast address. So I'm clueless how this would work.

My point is that NDP does get a response where others may not. NDP will always get an answer unless I'm missing something.

Given your comments above, however, I'm not sure what the definition of help is.

My point was that even if you close the other "hole", you can't close the NDP hole for local networks, so, there really isn't a solution to the problem of being able to trivially scan a local network.

Further, the hole described seemed, given the relative ease of the NDP "exploit", a ridiculously large amount of work for zero additional data.


More information about the Ipv6hackers mailing list