[ipv6hackers] IPv6 security presentation at Hack.lu 2011

[Fernando Gont]

Hi, Doug,

On 09/22/2011 08:55 PM, Douglas Otis wrote:
>> 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.

NOt sure what you mean. In my presentation,  DHCPv6 and SLAAC are mostly
described as *alternative* autoconf mechanisms. If I were to desdcribe
RDNSS, I'd also have to describe PI option, etc... and the slides don't
get into that level of detail.


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

Can you point out where this "increased security" comes from?


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

Sloppy wording: I should have said "deploy IPv6" rather than "enable IPv6".


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

"Disable proto 41" sounds good for referring to packets being filtered
at a firewall. However, other (not mutually exclusive) options are
avialable, such as disabling v6 suppport at the OS.


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

Agreed. This is is noted in several slides. e.g., the first few ones,
and the "IPv6 security implications on IPv4 networks".


> Enabling IPv6 on the LAN permits better monitoring and
> suppresses more problematic fallback strategies.

It also enables pontential vulnerabilities. See the latest (?)
remotely-explotaible vulnerability in OpenBSD dated 2008 or so.


>> 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. :^(

If you disable IPv6 in the sense of removing support for it, that attack
is not possible.


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

Nobody said that. Please look at the slides. On the contrary, I'd argue
that *something* should be done about it.


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

I wouldn't necessarily suggest "enabling IPv6". If we blindly advise
organizations to enable IPv6, and they get hacked as a result of that
(see the OpenBSD vulnerability above), then we'd have done a
(security-wise) very poor consulting work.

First of all comes an assessment of what the organization would gain
from enabling IPv6 (along with considering possible alternatives).
Then comes the security analysis.
Then the questions "are the benefits worth the risk"?

In many cases, the answer may be "yes". IN other it may be "no". There's
no "one size fits all".


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

That is increased complexity itself.


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

How could you perform an ND-based attack if IPv6 is disabled at the
kernel level?

And no, I'm not arguing that you shouldn't monitor v6 just because
you've disabled it.



> Please overcome misconceptions regarding NATs and IPv6.  Whether IPv6 or
> IPv4 is used, a LAN is vulnerable without SeND.  

A network is always vulnerable. What changes is what it is vulnerable
to. And I personally don't belive in this sort of "silver bullet"...
particularly when a solution is hard to deploy, and it's associated
complexity is well above 0.

Such complexity, by itself, is prone to introduce vulnerabilities in the
corresponding implementations.


> Middle Boxes such as
> NATs remove many protections otherwise possible.  The LAN is vulnerable
> whether through ARP spoofing, 

ARP traffic is *way* easier to monitor and police than ND traffic is.


> spanning tree or NAT table corruption,
> etc.  With RFC793 simultaneous-open handshakes, a Sneak Ack Attack can
> reverse the logical direction of connection setups. 

TCP simultaneous opens are not supported by all OSes. If that was the
case, we'd probably not need syn cookies or syn caches. Pleasee see the
corresponding discussion about "SYN flood attacks" in:
http://www.gont.com.ar/papers/tn-03-09-security-assessment-TCP.pdf


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

Nobody argued that. But it's true that when deploying a NAT you get a
"only allow return traffic" stateful firewall as a side effect.


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

huh? You'll have keep-alives in v6 if you do stateful firewalling...


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

A hacked CPE router only affects that customer. A hacked LSN affects all
customers that depend on that system. -- that's the difference.



>> 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. :^(

Can you explicitly point out what you mean by "improved security"?



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

Do you argue that this is "deployable" in a tyipical organizational or
home network??


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

There's no such a tihng as a "free lunch".



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

I wasn't aware about this ongoing work. Could you plkease provide some
pointers?

Thanks!

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