Locking Down The Cloud: Why DNS Security Must Be Improved

Flaws in DNS are giving rise to exploits that could make moving computing functionality into the cloud a risky proposition. Say you're using a software-as-a-service CRM offering. When a salesperson types your SaaS provider's URL, how do you know his browser is linked to the vendor's server, and not a rogue?

Consider the hijacking of Comcast's Internet portal, Comcast.net. In May, attackers gained access to Comcast's Network Solutions administrative accounts and redirected customers to a defaced page. It took several hours for the company to regain control of its domain. Had the attackers been more subtle, they could have inflicted serious financial harm on Comcast by intercepting customer data, rather than simply causing embarrassment.

Security of DNS, which for 20 years has underpinned the Internet's name resolution system, was thrust into the spotlight this year with the discovery by IOActive researcher Dan Kaminsky of a flaw that could have made hijacking a domain name a trivial exploit that took only minutes to execute. How real was the risk? It resulted in the largest simultaneous security software patch in Internet history in July, with 16 vendors with whom Kaminsky shared the flaw--including the major makers of DNS servers, such as Cisco, Microsoft, and Sun Microsystems--releasing their respective patches on the same day.

If we can't rely on DNS, it's a stretch to let business units access mission-critical applications over the Internet, or trust that sensitive data sent to SaaS providers hasn't been intercepted. This sentiment isn't lost on our readers: In our most recent cloud computing survey, security was by far the most oft-cited concern.

The best answer to date for alleviating the security risks posed to DNS is DNS Security Extensions, or DNSSec, a group of protocols that ensures the authenticity and integrity of DNS name resolution. DNSSec isn't perfect, but it could stop many of the attacks that have bedeviled DNS servers and that rely on redirecting users to sites of the attacker's choosing.

For now, companies depend solely on SSL when moving sensitive data into the cloud. SSL relies on digital certificates to authenticate servers and provide encryption. If the digital certificates are valid, SSL authentication will protect against spoofing. But if an attacker poisons DNS and redirects everyone looking for, say, citi.com to his server, he can then disable SSL for the login, and users will get no error message. Another caveat: SSL failures, such as expired or untrusted certificates and domain name mismatches, are too often treated as inconveniences--developers and users tend to ignore SSL certificate alert warnings.

DNSSec's role is to stop the attack before it gets to the point where the attacker can trick the user.

DIG DEEPER

THREAT LANDSCAPE

DNS is just one of the attack vectors that IT needs to monitor. Download our 2008 InformationWeek Security Survey, free for a limited time.

>> See all our Analytics <<

Ideally, DNSSec would ensure that users are connected to the proper site, while SSL would be used to authenticate the server. There is some movement in this direction. The U.S. Office of Management and Budget has set December 2009 as the deadline to have DNSSec deployed for all .gov sites, and the .org domain is gearing up for a phased rollout beginning in January.

But that's where adoption ends, for now. VeriSign has yet to commit to signing the two most populated top-level domains, .com and .net, which it controls, citing the sheer scale of the undertaking. Microsoft hasn't set a date for providing DNSSec software on clients or its own DNS server, and few service providers have deployed DNSSec-aware DNS servers.

CLOUDY, CHANCE OF STOLEN DATA
The trust that "I'm talking to the server I intend to talk to" is fundamental to the client-server model and becomes even more critical as organizations begin to move to SaaS and cloud computing, where IP addresses change while domain names stay constant.

From the perspective of a chief security officer considering letting employees send data to a SaaS provider, there's no way to ensure that a DNS response is accurate and coming from an authoritative source. That blind spot works to attackers' advantage in that, before they can eavesdrop on applications or manipulate conversations, they have to get unsuspecting users to connect to their servers. DNS spoofing--the ability to forge responses to DNS requests--lets attackers redirect users to servers they control by replacing a server's actual IP address in a DNS name lookup with an IP address the attacker controls.

The good news is, DNS hijacking of a popular Web site is difficult to pull off for any length of time. If a high-volume site, such as a large cloud computing provider, were hijacked, users would likely smell something fishy, and because of the sheer number of redirections to the false front, the legitimate site owner would be alerted. Similarly, an attack on a caching DNS server that serves a large number of users wouldn't stay secret for long. The side effects in either case will manifest as slow and broken connections on the user end, while the targeted SaaS or cloud vendor's site would see a precipitous enough decline in traffic that an investigation would ensue. Moreover, most attackers lack the sophistication to make a convincing forgery of a major site, just as phishers can't quite avoid mangling the English language.

Still, imagine the damage that could be done in even an hour of employees shipping customer data to a forged site during a busy period for your business. And highly targeted attacks may be less visible and therefore less detectable. A disgruntled employee could redirect traffic through a proxy server within a company's borders. That's far easier than redirecting the entire Internet--especially if the attacker has physical access to the network.

The DNS Security Extensions comprise a suite of standards that extend DNS to include features to sign and validate records using public key cryptography. Similar in concept to SSL, trust anchors at the root of the DNS, or at top-level domains like .com, .gov, and .org, sign the records in their zones. In turn, subdomains, such as example.com, example.gov, or example.org, sign the DNS records in their domains. Signatures indicate that records are authentic, from the authoritative zone. A DNSSec-aware computer or caching name server can verify that records are signed starting at the top-level domain and working down to the domain name you're interested in. If all the records check out, you have a verified DNS name.

In theory, DNSSec is fairly simple. In reality, the details are very, very messy. In practical terms, rollout of DNSSec will require new processes at every level of DNS and affecting every facet of domain management. For example, a policy framework governing how domain name owners will be verified and approved by registrars must be defined and enforced before DNSSec-protected domains are issued. After all, there's no value in signing domain names if you can't vouch for the authenticity of the owner. The process would need to be similar to how certificate authorities verify domain owners before issuing the Web server certificates used in SSL. Then, you need to do key management--always a fun process. In other words, a thorough vetting process is complex, labor intensive, and expensive.

YEAH, THERE'S AN APPLIANCE FOR THAT
Setting up DNS for DNSSec is complicated, but one vendor has stepped in to help. In June, Secure64 debuted Secure64 DNS Signer. DNS Signer is a hardware appliance, running Secure64's OS, aimed at managing all DNSSec key management and signing functions. The appliance runs on Hewlett-Packard hardware and uses the Trusted Computing Group's Trusted Platform Module to protect zone keys. Installation is relatively simple, requiring few changes to an existing DNS infrastructure. The claimed benefit is in a reduction in key and zone management tasks.

Still, complex changes may be required to a network to allow the DNSSec to function. For example, intervening network devices, such as firewalls that inspect DNS traffic, need to allow the DNSSec records to pass unhindered, yet DNSSec records are larger than 512 bytes and don't conform with DNS-size packets. This is primarily an issue with DNS proxy servers, which not only enforce how address port pairs pass packets, but may also attempt to verify that the claimed protocol, DNS, is conformant.

Caching DNS servers and DNS stub resolvers--the software on computers responsible for resolving names to IP addresses--also must be configured to support and verify DNSSec records, while at the same time accepting and caching unsigned DNS responses. To date, Microsoft hasn't given any indication about when, or if, it will support DNSSec in its host operating systems. Microsoft's DNS Server can cache DNSSec records, but not verify them. Without DNSSec-aware caching servers and stub resolvers, DNSSec is useless.

Finally, DNSSec won't be applied to every domain anytime soon, if ever, just as SSL isn't used by every Web site, only those that need authentication and encryption. The result is that there must be a way to tell applications that use DNS whether the requested domain name has been validated. That brings in a new wrinkle--how do you handle DNSSec-protected name resolution when there's a failure, such as an expired or untrusted response? With SSL, Web browsers give people the option to ignore the error. Given a choice, most generally make the wrong move and continue an SSL session even through it's invalid and therefore untrustworthy. Application developers face a Catch-22: Refuse to give the user the choice to continue potentially dangerous behavior and risk them finding a different Web browser that lets them do what they want, or let them make a dangerous decision.

ROAD TO DEPLOYMENT
The Public Interest Registry, which manages the .org domain, announced in May 2008 plans to sign .org beginning in early 2009 and proceed with a phased deployment of DNSSec to a limited number of domains and registrars. The reason for the slow rollout is that DNSSec is uncharted territory; only a few other top-level domains--namely Mexico, Puerto Rico, and Sweden--have started using the protocol. Policy and technical issues that must be sorted out range from required software to generate and manage keys to deciding how to vet domain owners. The U.S. federal government's DNSSec initiative also is a phased rollout.

VeriSign, which runs the root servers and controls the .com and .net top-level domains, is taking a more measured approach. The company was involved in the development of DNSSec standards documents and runs test beds, so it's invested in securing DNS. However, VeriSign also has the responsibility of making sure the root servers and the top-level domains it manages are stable and available, and the sheer scale of the undertaking is daunting. Ken Silva, VeriSign's CTO, says .com contains more than 77 million active domains, and .com servers receive about 600,000 queries per second. Because DNSSec records are larger than DNS records, storage and network capacity would need to be increased to meet the new load. And capacity scaling at top-level domain servers is only one issue. All caching name servers also would have to be scaled up for storage and network capacity, as well as adding cryptographic functions to validate DNSSec records that they retrieve and forward.

Domain owners would need to manage keys and ensure DNSSec records are signed properly. An expired DNSSec key should be treated as a failure and not trusted, which will result in hosts not being able to access services. If a domain generates revenue, a failure in DNSSec could get expensive fast. These issues aren't insurmountable, but VeriSign is being cautious in approaching DNSSec, and rightly so.

UNTIL THEN, WHAT'S LEFT?
To positively identify a service, you need some way to authenticate it. SSL/Transport Layer Security is a well-understood and widely deployed protocol for providing authentication and encryption functions. The SSL protocol hasn't shown any weaknesses, even though certain implementations of SSL/TLS libraries have.

Whether SSL/TLS is an effective way to secure data moving outside your borders depends on a few factors. First, it must be applied correctly in Web applications, such as SaaS and cloud computing. A number of developers we spoke with say that, in many cases, applications that use Web services, SOAP, and REST and employ SSL/TLS don't check the authenticity or validity of the digital certificate. The reason, typically, is that the cost of downtime because of an SSL/TLS failure from an invalid or untrusted self-signed certificate is unacceptably high. Other security functions, like network firewalls, which limit who can access a Web service, and XML firewalls, which inspect Web services traffic for problems, are deemed sufficient.

We disagree. To safely use SSL/TLS as a secure protocol, certificate validity must be verified and where there are failures, the connection should be aborted until trust can be re-established. This need not be onerous. Organizations don't need to purchase digital certificates from a public certificate authority to have the certificate trusted. For now, given an application where the client population is small, running your own certificate authority and issuing certificates may be sufficient.

We say "for now" because as more IT processes rely on Web services, that position will become untenable. The brief history of Internet security shows us that attackers, from lowly miscreants to organized criminals, follow the technologies that will let them commit mayhem. We're still years away from widespread DNSSec adoption, while SSL/TLS is available now. But don't assume that cloud and SaaS providers are using SSL/TLS properly. Ask for confirmation that any application that handles sensitive data uses certificates appropriately and will safely authenticate services.

As for DNSSec, CIOs need to turn up the heat. Start pressuring operating system vendors to install DNSSec-aware software to authenticate DNSSec responses. Insist that application vendors support DNSSec so a Web browser, for example, can differentiate between a signed and unsigned DNS response. Demand that service providers support DNSSec in their name servers. Follow the various test cases and, as DNSSec moves along, consider creating your own DNSSec DNS server and signing your own zone. DNS insecurity is a problem for everyone who uses the Internet, and we all must be part of the solution.

Continue to the sidebar:
Time To Send Out For Security Help?