[ipv6hackers] IPv6 security presentation at Hack.lu 2011

[Douglas Otis]

On 9/21/11 11:48 PM, Fernando Gont wrote:
Hi Fernando,
> Hi, Douglas,
>
> Thanks so much for your feedback! Please find my comments inline..
>
> On 09/21/2011 04:05 PM, Douglas Otis wrote:
>> The Brief overview on auto-configuration should mention RDNSS/DNSSL RA
>> options.
> Any particular reason for describing those? -- i.e., since it is a
> one-hour presentation, it's mostly a high-level overview, that only gets
> into some detail when needing to prove that something is more of a myth
> than a "fact".
Yes.  DHCP is NOT required by IPv6 to support DNS.  This impacts 
security that depends upon DHCP snooping and should be mentioned.

Many expect a transition to IPv6 will not occur soon.  However support 
issues related with 6to4 caused a rethink by ISPs.  The less painful 
option is Dual-Stack Lite where ISPs deploy native IPv6 with centrally 
controlled LSN where customers might share IPv4 addresses.  This 
increases a desire for IPv6 connectivity for improved security and freedom.
>> ---
>> In Key areas in which further work is needed:
>>
>> The statement 'Pushing people to "Enable IPv6" point-and-click style is
>> simply insane' is deceptive.
> While I might s/insane/incorrect/ (or the like), I do believe that
> enabling a technology that one doesn't understand is a really bad idea.
Even the assumption IPv6 is not enabled is a flawed concept.  In 
addition it would be appropriate to assume there WILL be an IPv6 
firewall when IPv6 is enabled.  Alternatively, it would be wrong to 
assume any effective IPv6 firewall exists otherwise.  Perhaps you could 
replace "disable IPv6" with "disable Protocol 41" instead. :^)
> -- If whoever enabled v6 needed "5-step recipe to enable v6" or the
> like, then they probably should have been trained before enabling v6.
Again, the message should be that IPv6 _already_ exits within their 
networks.  Enabling IPv6 on the LAN permits better monitoring and 
suppresses more problematic fallback strategies. The message should be 
there is a need to monitoring this traffic NOW!  Not enabling IPv6 on 
the LAN only offers a false sense of security.
> IMO, this applies to *any* technology, not just v6, and is mostly
> orthogonal to how good or how bad are the security properties of that
> technology.
>
> If you don't know "good enough" how your network works, attackers will
> probably do better.
Exactly.  Any compromised system within a LAN can easily set up IPv6 
connectivity, specifically because a lax approach was taken where not 
enabling IPv6 was seen as offering improved security. :^(
>> It is wrong to suggest _not_ enabling IPv6
>> in a network offers improved protections.
> Well, I'd not say that it "provides improved protection", but rather
> than "does not increase risk".
Disagree.  This view increases risks by offering the false concept that 
relative inaction is better.  By suggesting a NEED to enable IPv6 within 
the LAN raises attention to the fact that IPv6 is already present and 
the related risks MUST be mitigated or at least monitored.  These risks 
do not go away because IPv6 is not enabled.  Instead these risks become 
more difficult to monitor and the lack of monitoring gives malefactors a 
field day.  As it is now, everyday is a field day. :^(
> IPv6 (as any technology that you'd enable in addition to what you're
> already using), will add more pieces to the puzzle, increase complexity,
> and increase the number of potential vulnerabilities that could be
> exploited.
Complexity could be reduced by RAs announcing routes and RDNSS where any 
AAAA records in DNS are filtered and any other IPv6 traffic is 
black-holed.  Even that effort will not stop malefactors from using 
their own covert name services and IPv6 networks within a LAN where IT 
"thought" IPv6 was disabled.
>> The statement 'Training is needed for engineers, technicians, security
>> personnel, etc., before the IPv6 network is running.' is also
>> deceptive.  Unless extraordinary measures are taken which are also
>> likely to disable desired functionality, it would be wrong to suggest
>> IPv6 is not enabled in some fashion.  IPv6 must be considered analogous
>> to that of a gun where security demands that it always be considered
>> loaded.
> If I don't know how to handle a gun, I'd probably wouldn't have one in
> the first place. But if I *was* handled one, then I'd probably leave it
> as quite as possible, rather than start loading bullets and playing with
> the trigger, as if I knew what I was doing....
Internet connectivity IS a loaded gun.  Inaction after "disabling IPv6" 
is like leaving the safety off in the presence of children.  Disabling 
IPv6 on the LAN offers NO protection nor does it make maintaining 
security easier.  The natural reaction of the OS or application is to 
then seek alternatives.
>> Those who feel protected by an IPv4 NAT should also consider trade-offs
>> needed to sustain peak loads.  Often shortcuts that minimize overhead
>> also allow exploits.
> NATs do have some side-effect protections (albeit not bullet-proof,
> since technologies such as Teredo can be leveraged to break that
> assumption that "incoming connections are not allowed"). That said, I
> fully agree that NATs introduce a "single point of failure" in the network.
Please overcome misconceptions regarding NATs and IPv6.  Whether IPv6 or 
IPv4 is used, a LAN is vulnerable without SeND.  Middle Boxes such as 
NATs remove many protections otherwise possible.  The LAN is vulnerable 
whether through ARP spoofing, spanning tree or NAT table corruption, 
etc.  With RFC793 simultaneous-open handshakes, a Sneak Ack Attack can 
reverse the logical direction of connection setups.  Even symmetric NAT 
restrictions on undefined endpoints can be defeated by an unprivileged 
compromised system through the use of broadcast MACs or techniques that 
take advantage of exceptions that permit diagnostics.

See:
http://www.cs.columbia.edu/~smb/talks/arp-attack.pdf
http://nmap.org/misc/split-handshake.pdf
http://samy.pl/pwnat/

Often applications don't notice when an SSL certificate fails to match 
against a domain.  Even with SSL, Middle Boxes offer easy MitM 
exploits.  It is absurd to describe NATs as offering improved 
protection.  Practices that depend on NAT "security" invite prone 
systems that do more harm.  IMHO, it is easier to firewall IPv6 than 
deal with IPv4 related nonsense such as keep-alives, dynamic 
translations, port mapping, etc.
> Whether the pros outweigh (security-wise) the cons (or not) depends,
> among other factors, where in the network the NAT box is. -- e.g.,
> glearly a CGN has many more negative implications that a NAT at a home
> router.
There are many compromised CPE routers.  An ISP's LSN are not likely to 
be any worse.
>> We have seen several high profile companies and
>> agencies where IPv6 offers covert channels for breached data by some of
>> the newer bot-nets.  In several cases, the IT staff were unaware of
>> there being any IPv6 connectivity.  In this light, these two comments
>> are poorly considered to say the least.
> The bottom-line is that you should make sure that your "assumptions" are
> correct. -- e.g., if you're argument for not applying specific v6
> technologies is that "my network is v4-only", you better make sure
> that's the case.
Assuring an assumption of "IPv4 Only" requires a sizable effort that 
will prevent improved security from then being employed. :^(
>> Any NAT device within a network provides an easily exploited opportunity
>> for undetected MITM attacks.  Only End-to-End security offers protection
>> from exploits related with ARP or ND+MLD where End-to-End security is
>> likely only possible with IPv6.  This does not need to be IPsec.
> I cannot see why you argue that end-to-end security is only possible
> with IPv6.
It is possible to deploy SeND at Switches and routers without support of 
the hosts.  In this fashion, a far greater portion of the path can be 
controlled where common LAN exploits can be avoided or detected.
>> In the further work needed section, perhaps a statement that RA resource
>> management flaws MUST still be corrected within affected hosts, such as
>> ignoring multiple headers or fragmentation to allow other OOB validation
>> methods whenever SEND is not available.
> Yes. Actually, I wrote to I-Ds to make an RA-Guard and ND-monitoring
> mitigations:
>
> *<http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-01.txt>
> *<http://tools.ietf.org/id/draft-gont-6man-nd-extension-headers-01.txt>
>
> However, so far they are still "individual submissions", and that's why
> I didn't mention this as a possible solution that could be applied to
> solve these problems right now. But I agree that I should have
> notes/insisted that this should be pursued.
>> One might also add in further work section, the currently announced IPv6
>> size in conjunction with its exponential growth means use of source IP
>> addresses or prefixes alone are much less effective in attack mitigation
>> strategies.
> When it comes to "filtering" as a mitigation for DoS, my take is that an
> IPv6 /64 corresponds to what we currently do with a single IPv4 address.
> Put another way, where in IPv4 you might be filtering a single IPv4
> address or a small prefix, in IPv6 you'd be filtering at least a /64.
>
> It would be worth adding, I agree.
The table size needed for such a strategy will likely increase in by a 
factor of about 340,000 over what is used for IPv4 when only IPv6 
prefixes are captured.  Of course, this short-cut will disable entire 
networks whenever someone forgets their password and tries too many 
times.  Not a practical defense strategy in many cases.  IP address 
related security must be replaced by certificates that can establish 
white-listed address space for short durations.  Perhaps wide spread 
deployment of DANE with dynamic DNS updates is where this needs to 
evolve.  Without something like this, keeping up with a geometrically 
increasing attack surface seems doubtful.
>> Just this prefix space is already more than 56,000 times
>> that of the entire IPv6 address space.  Certificate based access should
>> be employed whenever possible might also be good advice.
> Ip address-based authentication is already well-broken with IPv4. (e.g.,
> I had mentioned that already when working on a sec assessment of v4
> <http://www.gont.com.ar/papers/InternetProtocol.pdf>). So I'm not sure
> anything changes in this respect when it comes to v6.
Some now hope in a new repute WG to base reputation on IP address 
authorizations and message signatures that exclude who sent the message 
and its intended recipient!  This is another reason for mentioning 
Dual-Stack Lite to raise security considerations that are related to 
both the evolving IPv6 AND IPv4 address space.

And thank you for your valuable efforts.

-Doug