December 7, 2016

Microsoft Haven’t Fixed Year Old IPv6 DoS Vulnerability in Windows

CVE-2010-4669 describes a vulnerability in the Neighbor Discovery (ND) protocol implementation in the IPv6 stack in Microsoft Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, and Windows 7. Using a simple tool like flood_router6 from the thc-ipv6 package a remote attacker can cause a denial of service (CPU consumption and system hang) by sending multiple Router Advertisement (RA) messages with different source addresses.

The problem is that updating the routing tables and configuring IPv6 addresses requires lots of CPU resources (ie. 100%). If a network is flooded with random router announcements, Windows (and other operating systems like FreeBSD) struggle to update their routing tables. The denial of service remains in affect until the flooding is terminated.

With the inevitable move over to IPv6 this issue which has been known for nearly a year is becoming more and more critical. The problem seems to be that Microsoft and other IPv6 vendors aren’t offering much in the way of solutions.

Juniper Networks, the high performance switch manufacturer, have gone on record to say that they are not fixing this issue until the IETF workgroup has a proposal on a standard way to fix it. We assume Microsoft are following the same thinking.

More information on the vulnerability is available here and here. Below is a video showing the attack in progress:

Note: The Live Hacking Ethical Hacking and Penetration DVD contains the flood_router6 tool.

New Protection From Internet Routing Hijacking and Incorrect Addressing

The beginning of January saw the start of a new era for Internet routing. Well, it almost did. Four of the five Regional Internet Registries (RIRs) have deployed the Resource Public Key Infrastructure (RPKI), a robust security framework for verifying the association between resource holders and their Internet resources.

RIPE Network Coordination CentreThe RIRs, like the RIPE Network Coordination Centre (which is responsible for the European part of the Internet), provide Internet resource allocations, registration services and co-ordination activities. RPKI allows ISPs and network operators to verify the accuracy of routes on the Internet and to prevent fraudulent or erroneous misdirection of Internet traffic. A famous example of erroneous routing happened in 2008 when the YouTube web site was unavailable in several different parts of the world because Pakistan Telecom incorrectly co-opted YouTube’s IP address range as its own.

The only RIR not to implement RPKI yet is the American Registry for Internet Numbers (ARIN). According to their website their deployment has been delayed until “very early in the second quarter of 2011”.

Once AIRN is up and running the use of Resource Certificates will mean that worldwide each resource holder will own a certificate which lists the Internet resources (IPv4 addresses, IPv6 addresses, and Autonomous System Numbers) that are owned by the certificate holder (e.g. an ISP). The certificate are of course encrypted and by using the public keys associated with the certificate owner the list of Internet resources can be easily verified.

Internet Infrastructure Supports DNSSEC Now

DNSSEC is now up and running in all of the internet root servers. Rod Beckstrom, president and CEO of ICANN, the governing body for Internet domains, at Black Hat 2010 conference made this announcement. Nine top-level Internet domains have also now been signed with DNSSEC, including in .uk, .org, and others.

“We expect another dozen or so to take this step over the coming weeks,” Beckstrom said. He says others should be DNSSEC-signed in the next 12 months.

What is DNSSEC?

The Domain Name System Security Extensions (DNSSEC) is a suite of Internet Engineering Task Force (IETF) specifications for securing certain kinds of information provided by the Domain Name System (DNS) as used on Internet Protocol (IP) networks. It is a set of extensions to DNS which provide to DNS clients (resolvers) origin authentication of DNS data, authenticated denial of existence, and data integrity, but not availability or confidentiality.

DNSSEC was designed to protect Internet resolvers (clients) from forged DNS data, such as that created by DNS cache poisoning. All answers in DNSSEC are digitally signed. By checking the digital signature, a DNS resolver is able to check if the information is identical (correct and complete) to the information on the authoritative DNS server. While protecting IP addresses is the immediate concern for many users, DNSSEC can protect other information such as general-purpose cryptographic certificates stored in CERT records in the DNS. RFC 4398 describes how to distribute these certificates, including those for email, making it possible to use DNSSEC as a worldwide public key infrastructure for email.

DNSSEC records:

  • RRSIG
  • DNSKEY
  • DS
  • NSEC

How it works?

DNSSEC works by digitally signing these records for DNS lookup using public-key cryptography. The correct DNSKEY record is authenticated via a chain of trust, starting with a set of verified public keys for the DNS root zone which is the trusted third party.

Please visit http://en.wikipedia.org/wiki/DNSSec for more information. This page has been used as a reference for this article.

[ad code=2 align=center]