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
Cartoon
Current Issue
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-3352
Published: 2014-08-30
Cisco Intelligent Automation for Cloud (aka Cisco Cloud Portal) 2008.3_SP9 and earlier does not properly consider whether a session is a problematic NULL session, which allows remote attackers to obtain sensitive information via crafted packets, related to an "iFrame vulnerability," aka Bug ID CSCuh...

CVE-2014-3908
Published: 2014-08-30
The Amazon.com Kindle application before 4.5.0 for Android does not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.

CVE-2010-5110
Published: 2014-08-29
DCTStream.cc in Poppler before 0.13.3 allows remote attackers to cause a denial of service (crash) via a crafted PDF file.

CVE-2012-1503
Published: 2014-08-29
Cross-site scripting (XSS) vulnerability in Six Apart (formerly Six Apart KK) Movable Type (MT) Pro 5.13 allows remote attackers to inject arbitrary web script or HTML via the comment section.

CVE-2013-5467
Published: 2014-08-29
Monitoring Agent for UNIX Logs 6.2.0 through FP03, 6.2.1 through FP04, 6.2.2 through FP09, and 6.2.3 through FP04 and Monitoring Server (ms) and Shared Libraries (ax) 6.2.0 through FP03, 6.2.1 through FP04, 6.2.2 through FP08, 6.2.3 through FP01, and 6.3.0 through FP01 in IBM Tivoli Monitoring (ITM)...

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.