DNS Flaws Need Patching
Thanks to this month's DNS vulnerabilities, a lot of patching will be taking the time of DNS administrators. In fact, it might even seem like 2002 all over again.
What if they announced a domain-name system (DNS) vulnerability and it didn't affect anyone? The last time pervasive DNS flaws came to light was in 2002, when a wide range of products or technologies were affected from an equally wide variety of vendors.
It's the same this time around: according to experts, the two DNS flaws that came to light month affect products from nearly 80 vendors.
For frantic customers, that means one thing: a whole lot of patching will be going on. In 2002, researchers disclosed flaws in the Berkeley Internet Name Domain (BIND) and Berkeley Software Distribution (BSD) DNS resolver libraries, two foundational, freely available and ubiquitous DNS components.
On Tuesday, July 8, researchers identified two new DNS resolver-related vulnerabilities. The good news is that most vendors produced patches shortly after the announcement was made.
In contrast to the BIND and BSD vulnerabilities -- the impact of which was believed to be huge simply because of the trickle-down prevalence of the former Berkeley technologies in so many n-generation DNS implementations -- the latest batch of DNS flaws is much better understood. The U.S. Computer Emergency Readiness Team (US-CERT), for example, concludes that it affects DNS Server offerings from at least 79 different vendors (see http://www.kb.cert.org/vuls/id/800113).
What are overworked, underpaid, and (increasingly) under-staffed DNS administrators to do? Roll up their sleeves and start patching, according to Gartner Inc., and be thankful -- Gartner analysts Greg Young, Paul Proctor, and Mark Fabbi conclude -- that no one has yet figured out how to exploit the new DNS flaws.
"No exploits for these DNS vulnerabilities had been documented … [and] Microsoft and many of the other affected vendors have given them their second-highest severity ranking, because remote code execution [a requirement for highest severity] is not relevant," they point out. "Nonetheless, this vulnerability could allow transparent rerouting of traffic or routing of traffic sent to internal addresses outside the enterprise perimeter, potentially exposing sensitive information and increasing the risk of further exploits and external 'ownership' of internal networks. Moreover, because exploiting this vulnerability does not result in changes to configuration tables in the application, exploits would be difficult to detect."
Why, therefore, do the new DNS issues explicitly affect so many more platforms than 2002's foundational flaws? The Gartner team points out the proactive tip to the most recent DNS patches: they implement changes (based on recommendations from security researchers) in DNS interaction that are designed to make it more difficult for attackers to exploit DNS resolver implementations. What that means, the analysts notes, is that just about all extant DNS Server implementations need to be "fixed."
"The patching process includes a change in DNS interaction designed to make it more difficult to 'guess' a transaction ID, which is the reason it spans so many implementations," Young, Proctor, and Fabbi indicate.
"The patch also changes the usual DNS 'handshake' and the DNS query protocol involving port/socket usage via port randomization," they continue. This could result in additional headaches for DNS admins, according to Gartner: "Firewalls, routers or DNS proxies may require configuration changes in cases where DNS traffic is expected to use a specific port or socket. If the enterprise firewall limits DNS connections to a single port [e.g., the DNS-standard port 53], this restriction must be removed."
Elsewhere, Young, Proctor, and Fabbi conclude, DNS administrators should take several additional steps. If they're limiting DNS socket ranges, for example, they'll need to review their DNS patch release notes to determine whether they'll need to change their client-side DNS implementations, too.
That's not all. "Request a signature update from your intrusion detection system or intrusion prevention system vendor that includes detection of possible exploits using this vulnerability," the Gartner trio recommends. "Follow the established best practice of filtering IP addresses at the perimeter to prevent spoofing, such as internal IP addresses coming from external domains."