Threat Intelligence Blog

Pick a Strategy for Dealing with BIND Vulnerabilities

– by Chris Hauser

Own your DNS before someone else does

It’s well known that DNS servers and protocols were first designed decades ago without security in mind.  With the increasing “internet of things”, DNS operations are more important than ever.  Meanwhile, the consequences of DNS protocol attacks can be financially crippling, can compromise an organization’s mission, and even a country’s national security. Attacks are increasing in frequency and sophistication, often targeting a country’s financial systems, electrical grid, or classified information management systems.

The most common DNS server is BIND, an application that powers over 83% of the DNS servers in operation today. You can better grasp this big BIND majority when you consider that nearly all the non-Windows-based DNS servers, including commercial DNS servers that the IPAM (IP address management) vendors include, are based on BIND.

The BIND vulnerabilities problem

The Internet Systems Consortium (ISC) manages BIND and its evolution as an open-source, but supported application. ISC does a great job of managing patches, but consider the amount of time remaining vulnerable if you were in either one of these scenarios:

Scenario A: Running BIND on my own UNIX / LINUX servers

  • …time to identify a new vulnerability
  • …time for ISC to issue a patch
  • …time needed for me to deploy that patch

That’s a lot of time to be vulnerable to DNS interruption.

Scenario B: Running BIND that I got from my IPAM vendor

  • …time to identify a new vulnerability
  • …time for ISC to issue a patch
  • …time for my IPAM vendor to implement the patch
  • …time for my IPAM vendor to deliver me a software update
  • …time for me to qualify the software update, which crosses my IPAM and my DNS
  • …time for me to deploy my IPAM+DNS software update

That’s even more time to be vulnerable to DNS interruption!

DNS BIND attacks

I took a look at the various patches to BIND vulnerabilities back through 2012. My researched showed that strict DNS protocol enforcement could guard BIND servers from roughly a third of past two years of Common Vulnerabilities and Exposures (CVE).

Two examples of CVE’s based on protocol

  1. Special Query Crashes BIND (CVE-2013-4854) – in this case, the BIND server can crash when a query is deliberately malformed to contain an incorrect IP address-type (RDATA) for a site on a network.
  1. Special Query Crashes BIND (2013-3919) – for this exploit an attacker can create a denial-of-service (DoS) attack by sending a BIND (recursive server) a request for an address for a site that is especially malformed and often created by the attacker.

Why have strict protocol enforcement for DNS?

The idea of strict protocol enforcement is better known with web application firewalls. I think people understand that web servers can’t both be efficient and self-protecting. It’s the same with DNS servers. CloudShield DNS Defender is a protocol-specific firewall designed to specifically protect against many kinds of DNS protocol attacks. CloudShield DNS Defender uses CloudShield Deep Packet Processing (DPP) capabilities to examine full DNS protocol messages. Among other protections, DNS Defender has a protocol filter that ensures enforcement with RFC’s.

Returning to our earlier examples: With DPP, DNS message fields can be read at full speed and queries with invalid RDATA will be discarded instead of being sent to the BIND server – protecting against CVE-2013-4854. Similarly, malformed traffic can be discerned and blocked with DPP – protecting against CVE-2013-3919.

Strategy choices for dealing with BIND vulnerabilities

I provided just two examples, but my point is that there will be an endless stream of BIND vulnerabilities. Either way you implement BIND – on your own UNIX servers or on your vendors’ IPAM appliances – you could benefit from a protection tool, like DNS Defender, which can protect your BIND servers from both known and new vulnerabilities. This can prevent you from having anxiety during the long duration from discovery of a BIND vulnerability to the time a patch is deployed.

Or you can be anxious.

My next blog post will examine other vulnerabilities discussed in BIND CVE’s with additional analysis.

Get more information

Here is a list of links for you to explore to find out more about what I’ve shared in this post:

 

Additional Posts

Webinar Recap: Making the Business Case for Threat Intelligence

Eric Olson, VP of Product Strategy, and James Carnall, VP of our Cyber Intelligence Division, ...

Watch that Pin: Trojans Are Now Using Pinterest

  New Trojans targeting banks in South Korea have been using Pinterest as a Command and ...