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-0761
Published: 2014-08-27
The DNP3 driver in CG Automation ePAQ-9410 Substation Gateway allows remote attackers to cause a denial of service (infinite loop or process crash) via a crafted TCP packet.

CVE-2014-0762
Published: 2014-08-27
The DNP3 driver in CG Automation ePAQ-9410 Substation Gateway allows physically proximate attackers to cause a denial of service (infinite loop or process crash) via crafted input over a serial line.

CVE-2014-2380
Published: 2014-08-27
Schneider Electric Wonderware Information Server (WIS) Portal 4.0 SP1 through 5.5 uses weak encryption, which allows remote attackers to obtain sensitive information by reading a credential file.

CVE-2014-2381
Published: 2014-08-27
Schneider Electric Wonderware Information Server (WIS) Portal 4.0 SP1 through 5.5 uses weak encryption, which allows local users to obtain sensitive information by reading a credential file.

CVE-2014-3344
Published: 2014-08-27
Multiple cross-site scripting (XSS) vulnerabilities in the web framework in Cisco Transport Gateway for Smart Call Home (aka TG-SCH or Transport Gateway Installation Software) 4.0 allow remote attackers to inject arbitrary web script or HTML via unspecified parameters, aka Bug IDs CSCuq31129, CSCuq3...

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
This episode of Dark Reading Radio looks at infosec security from the big enterprise POV with interviews featuring Ron Plesco, Cyber Investigations, Intelligence & Analytics at KPMG; and Chris Inglis & Chris Bell of Securonix.