Attacks/Breaches
2/2/2012
01:35 PM
Connect Directly
RSS
E-Mail
50%
50%

VeriSign 2010 Hack: DNS Data Theft A Possibility

SEC data breach disclosure report triggers admission from VeriSign that attackers might have accessed sensitive domain name system data. What could they do with it?

10 Companies Driving Mobile Security
10 Companies Driving Mobile Security
(click image for larger view and for slideshow)
Several successful hacks of VeriSign's network, in 2010, might have compromised critical information relating to the Internet's domain name system (DNS).

According to information released by VeriSign in October 2011, "we have investigated and do not believe these attacks breached the servers that support our domain name system network." But the company didn't rule out that information relating to the DNS network wasn't stolen in the attacks, which occurred before some assets of the company were acquired by Symantec in 2010.

VeriSign helps manage the DNS--which enables IP addresses to be mapped to textual website names--as well as the ".com" top-level domain. But the company also provides user authentication services, offers website security services, conducts cybercrime research, and signs code, to authenticate updates from such software vendors as Microsoft and Adobe, as well as for Java.

[ Worst attacks last year? See 6 Worst Data Breaches Of 2011. ]

Thursday, however, Symantec said that the attackers definitely hadn't accessed certain critical systems. "The Trust Services (SSL), User Authentication (VIP), and other production systems acquired by Symantec were not compromised by the corporate network security breach mentioned in the VeriSign Inc. quarterly filing," spokeswoman Nicole Kenyon said via email. "Symantec takes the security and proper functionality of its solutions very seriously."

The VeriSign hacks were first reported Thursday by Reuters. Why the delay in the breaches coming to light? Although the attacks occurred in 2010, the company's security team apparently didn't report the incidents to the management team until September 2011. VeriSign then disclosed them to the Securities and Exchange Commission on Oct. 28, 2011, in the company's Form 10-Q Quarterly Report.

Recently released SEC guidelines now make such disclosures mandatory. Reuters said that in its review of 2,000 filings since that rule went into effect that mention breach risks, the VeriSign disclosure appears to be the worst.

"I think the SEC guidance is making material disclosures happen now, and will continue to happen in the future. So we'll find out about more and more of these types of incidents," said Anup Ghosh, CEO of browser security vendor Invincea, by phone.

Hack attacks are the leading cause of data breaches, and the attack against VeriSign's network likewise resulted in data being stolen. According to VeriSign's SEC filing, "information stored on the compromised corporate systems was exfiltrated." Although the company's security team noticed the intrusion shortly after it occurred and quickly "implemented remedial measures designed to mitigate the attacks and to detect and thwart similar additional attacks," VeriSign's lack of specificity over what might have been stolen suggests that it simply doesn't know.

According to security experts, data breaches are now so widespread that being breached is a question of when, not if. "The fact that VeriSign was targeted? Not surprising at all. The fact that they were breached? Not surprising at all," said Ghosh. "I don't think VeriSign is at fault. This is the state of the security that we have at present. These guys are targets."

Some risks from a successful hack of VeriSign, however, are that attackers might be able to knock the DNS offline--thus taking down large parts of Internet--or redirect people to fake websites to infect their PCs with malware or steal financial information. "In this case, it looks like that wasn't the objective," said Ghosh. "It wouldn't surprise me if whoever breached their network was after corporate documents, like pending deals or sales. That would be of interest to China, for example."

The hack of VeriSign echoes 2011 attacks against certificate registrars Comodo and DigiNotar, both of which appeared to be executed by--or on behalf of--one or more nation states. Those attacks exposed fundamental weaknesses in the trust model underpinning the current use of SSL digital certificates for authenticating websites. Notably, by exploiting a certificate authority, an attacker can create fake digital certificates to spoof any website, as the hacker behind the Comodo attack apparently did with Google, Skype, and Mozilla websites. The result is a system based on trust, but which can't be trusted.

Interestingly, before news of the VeriSign breach surfaced, the VeriSign brand name was already slated to be partially phased out, for the assets that Symantec had acquired.. Beginning in April 2012, Symantec said that all VeriSign SSL seals would be rebranded as "Norton Secured Seals." After the change, Symantec said that the seals would be used by more than 100,000 websites in 165 countries.

The VeriSign hack makes this the second time in a month that a security-related company has been in the news, owing to its having suffered a past hack that was later discovered to have resulted in the exposure of sensitive data. The other company was Symantec, which recently rushed out a patch for pcAnywhere, its remote-access software, after hacktivist group Lords of Dharmaraja bragged about possessing the source code for some Symantec products.

Symantec initially dismissed that claim. But the company then discovered that in a 2006 security incident, attackers had apparently not just breached Symantec's servers, but stolen the source code in question, thus putting current users at risk of attack, should the attackers discover zero-day vulnerabilities in the code that they could exploit.

Heightened concern that users could inadvertently expose or leak--or purposely steal--an organization's sensitive data has spurred debate over the proper technology and training to protect the crown jewels. An Insider Threat Reality Check, a special retrospective of recent news coverage, takes a look at how organizations are handling the threat--and what users are really up to. (Free registration required.)

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-4734
Published: 2014-07-21
Cross-site scripting (XSS) vulnerability in e107_admin/db.php in e107 2.0 alpha2 and earlier allows remote attackers to inject arbitrary web script or HTML via the type parameter.

CVE-2014-4960
Published: 2014-07-21
Multiple SQL injection vulnerabilities in models\gallery.php in Youtube Gallery (com_youtubegallery) component 4.x through 4.1.7, and possibly 3.x, for Joomla! allow remote attackers to execute arbitrary SQL commands via the (1) listid or (2) themeid parameter to index.php.

CVE-2014-5016
Published: 2014-07-21
Multiple cross-site scripting (XSS) vulnerabilities in LimeSurvey 2.05+ Build 140618 allow remote attackers to inject arbitrary web script or HTML via (1) the pid attribute to the getAttribute_json function to application/controllers/admin/participantsaction.php in CPDB, (2) the sa parameter to appl...

CVE-2014-5017
Published: 2014-07-21
SQL injection vulnerability in CPDB in application/controllers/admin/participantsaction.php in LimeSurvey 2.05+ Build 140618 allows remote attackers to execute arbitrary SQL commands via the sidx parameter in a JSON request to admin/participants/sa/getParticipants_json, related to a search parameter...

CVE-2014-5018
Published: 2014-07-21
Incomplete blacklist vulnerability in the autoEscape function in common_helper.php in LimeSurvey 2.05+ Build 140618 allows remote attackers to conduct cross-site scripting (XSS) attacks via the GBK charset in the loadname parameter to index.php, related to the survey resume.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Where do information security startups come from? More important, how can I tell a good one from a flash in the pan? Learn how to separate ITSec wheat from chaff in this episode.