Risk
9/25/2008
11:15 AM
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail
50%
50%

Locking Down The Cloud: Why DNS Security Must Be Improved

What's in a domain name? Everything, when your data is at stake.

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.

InformationWeek Reports

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.
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.

Previous
1 of 3
Next
Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-3341
Published: 2014-08-19
The SNMP module in Cisco NX-OS 7.0(3)N1(1) and earlier on Nexus 5000 and 6000 devices provides different error messages for invalid requests depending on whether the VLAN ID exists, which allows remote attackers to enumerate VLANs via a series of requests, aka Bug ID CSCup85616.

CVE-2014-3464
Published: 2014-08-19
The EJB invocation handler implementation in Red Hat JBossWS, as used in JBoss Enterprise Application Platform (EAP) 6.2.0 and 6.3.0, does not properly enforce the method level restrictions for outbound messages, which allows remote authenticated users to access otherwise restricted JAX-WS handlers ...

CVE-2014-3472
Published: 2014-08-19
The isCallerInRole function in SimpleSecurityManager in JBoss Application Server (AS) 7, as used in Red Hat JBoss Enterprise Application Platform (JBEAP) 6.3.0, does not properly check caller roles, which allows remote authenticated users to bypass access restrictions via unspecified vectors.

CVE-2014-3490
Published: 2014-08-19
RESTEasy 2.3.1 before 2.3.8.SP2 and 3.x before 3.0.9, as used in Red Hat JBoss Enterprise Application Platform (EAP) 6.3.0, does not disable external entities when the resteasy.document.expand.entity.references parameter is set to false, which allows remote attackers to read arbitrary files and have...

CVE-2014-3504
Published: 2014-08-19
The (1) serf_ssl_cert_issuer, (2) serf_ssl_cert_subject, and (3) serf_ssl_cert_certificate functions in Serf 0.2.0 through 1.3.x before 1.3.7 does not properly handle a NUL byte in a domain name in the subject's Common Name (CN) field of an X.509 certificate, which allows man-in-the-middle attackers...

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Dark Reading continuing coverage of the Black Hat 2014 conference brings interviews and commentary to Dark Reading listeners.