[ipv6hackers] IPv6 security presentation at Hack.lu 2011

[Douglas Otis]

On 9/25/11 1:03 AM, Fernando Gont wrote:

Hi Fernando,
> 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.
Some consideration must be given in how to detect hosts when DHCPv6 is 
not used.  A rouge RA could easily implement Prefix Information and 
RDNSS options where monitoring DHCPv6 would then not detect which hosts 
were involved.  The DUID offered by DHCPv6 will not relate to specific 
hosts or their assigned assigned addresses.  Remote-ID Option 37 
described in RFC4649 might be used to replace DHCPv4 Option 82 to aid 
the port/IP address mapping, but then what when DHCPv6 is not used?
>> 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?
NAT mapping rarely offers security.  SSL CBC has proven easily 
exploitable once a MitM situation is established.  NAT use places 
reliance on the LAN to avoid address spoofing and related MitM 
scenarios, much like that found with XSS.   End to End security does not 
require use of IPsec, although IPsec would be one such anti-MitM 
alternative.
>>>> 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".
Thoughtful deployment is still a better choice.  IPv6 is here now and 
the simpler approach is native support on the LAN.
>> 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.
Disabling IPv6 at the host will break services that do not assure 
functionality in this downgraded mode.  Not deploying IPv6 on the LAN 
also invites less secure fallback transitional schemes.  When a host is 
compromised, is it still safe to assume IPv6 is disabled?  Is there 
spoofing protection with ISATAP?
>>> -- 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.
When will these issues be resolved to meet your satisfaction?  FreeBSD 
vendors have already released patches for the issue where perhaps due to 
the BSD license, fixes are driven by affected vendors.  All the more 
reason for the market to insist repairs are made or find alternatives.  
Going back to IPv4 is not an alternative at this time.
>>> 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.
As in removing it from the Internet, from the router, from the switch?  
Providing reasonable security for remote systems is easier using of 
end-to-end security methods.  IPv4 refers to translated IP address space 
full of questionable middle boxes.  While indeed IPv6 is not perfect, 
IPv6 provides future growth.
>>>> 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.
Your strongest statements are to disable IPv6 (at the host), as if 
practical, possible, or offering better security.  Securely using IPv6 
is the new cost of doing business, period.
>> 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.
Should everyone stop using SSL because of the CBC issue?  Many of these 
issues will require improved monitoring over what we have today.  Those 
that start now will be ready when IPv6 really takes off, as it is about 
to do.
> 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".
More systems will remain vulnerable longer as malefactors take advantage 
of "IPv6 broken" networks as they leak data over unseen transitional  
protocols. :^(
>>> 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.
Exactly.  This was tongue in cheek.  I even said it would not prevent 
any exploits.
>>> 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?
There are many exploits that will always remain possible.  Whether by 
spoofing ARP broadcasts, spanning tree protocols, VLANs, etc.  Progress 
is made by achieving an environment able to offer end-to-end security.   
While not everything needs to operate in this way, it is vitally 
important more networks make progress in this direction where data is 
secured by direct communication.  More work needs to be done on DNSSEC, 
SeND, DANE, etc.  SeND can work within mixed environments and not be 
supported by all hosts.  Security can step over less secure hosts for 
now and be limited to Cisco and Juniper routers and switches where 
security is important.
> And no, I'm not arguing that you shouldn't monitor v6 just because
> you've disabled it.
Additional monitoring will be fairly unlikely when they think no one is 
using IPv6.
>> 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.
That is what they said about SSL.  :^)  One might hope DANE and dynamic 
DNSSEC becomes available, where support for SeND then becomes eas to 
deploy.
>> 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.
There is no universal defense against ARP or ND spoofing.  And it is 
common for interfaces to utilize many IP addresses.  Using static MAC 
tables might help, but often that is not practical.  While neither ARP 
nor ND traffic can be completely enforced, that was the goal behind 
SeND.  Do we need to wait for the value of security and cost of the 
hardware to become comparable?  It is foolish to think either ND or ARP 
are secure.
>> 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
Dropping packets that combine SYN and RST flags seems logical as well, 
but even that is not a complete solution.
>> 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.
When done with IPv6, the states are simpler.  Far fewer keep-alives and 
no dynamic reassignment of the destination address.  When a subsequent 
middle box is not present, there are fewer opportunities where traffic 
can injected within the LAN.  There are two types of LAN.  Those that 
have been compromised, and those that compromise has not yet been 
discovered.
>> 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...
Any duration in regard to IPv6 can have much longer periods without any 
risk of running out of port resources.
>> 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.
Do we agree NATs offer poor security?  To a user, they'll suffer the 
same attack.  For the attacker, one would hope the LSN has improved 
monitoring over what is found in CPE, which is as good a none.
>>> 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"?
The ability to establish a paradigm of end-to-end 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??
It is deployable when security holds enough value for the organization.
>>> 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 thing as a "free lunch".
Or a practical solution that depends on massive IP address lists.  IMHO, 
this needs to move to crypto validation and interim tables ASAP, a la DANE.
>>>> 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 please provide some
> pointers?
http://tools.ietf.org/agenda/81/repute.html

Their charter refers to protocols that can not fairly support negative 
reputation assessments.  I am working on a paper to describe details of 
the concerns.

-Doug