Vulnerabilities / Threats

10/25/2017
07:00 PM
Connect Directly
Twitter
LinkedIn
RSS
E-Mail
50%
50%

Kaspersky Lab Collected, Then Deleted NSA File from a Home Computer

Concerns over handling classified US data one of the reasons why Kaspersky Lab CEO ordered file deletion, company says.

Moscow-based Kaspersky Lab, under scrutiny for allegedly helping Russian agents steal classified US government data, today conceded its software had collected a file containing source code for a classified NSA hacking tool from a home computer in September 2014.

But the company then deleted the file on the instructions of CEO Eugene Kaspersky and did not share it with anyone else, the security vendor said in a report Wednesday outlining the initial findings of an internal investigation.

According to the security vendor, the file was automatically uploaded to its AV network for analysis from the home computer of an NSA contractor who was running Kaspersky's software. The 7zip archive file contained what appeared to be new, unknown, and debug variants of a hacking tool used by the Equation Group, a hacking team of the NSA.

The home computer on which the NSA file was hosted had a pirated - and malware-infected - version of Microsoft Office running on it, and Kaspersky Lab's AV software apparently detected the NSA file as potentially malicious as well, automatically submitting it to the vendor for analysis. Such automatic submissions are common to all AV tools when they encounter new or previously unknown malware. In this case, Kaspersky's analysis showed the archive to contain malware and source code for Equation APT malware.

"The reason we deleted the files is because first of all, we don't need the source code to improve our protection technologies and secondly, because of concerns regarding the handling of classified materials," a Kaspersky Lab spokesperson said. This concern was later turned into a rule that requires Kaspersky analysts to delete any potentially classified materials that the company's software accidentally collects, she added.

It's too soon to say whether Kaspersky Lab's latest explanation will tamp down or inflame concerns raised by recent reports that Russian agents have used the company's software to steal US secrets.

The Wall Street Journal and other media outlets have quoted unnamed sources as informing them about Russia-sponsored actors using Kaspersky Lab's antivirus technology to search for and steal classified US data from computers running Kaspersky's software. The reports have alleged that the company tweaked its AV software so Russian agents can search systems belonging to Kaspersky's customers using keywords such as "classified" and "top secret."

The US government earlier this year banned federal agencies from using the vendor's software after Israeli cyber spies informed it about discovering classified material on Kaspersky's network. The Israeli agents had previously broken into Kaspersky's network and were apparently spying on the security vendor's activities when they discovered the material.

On Wednesday, Senator Jeanne Shaheen (D-NH), called on the Trump Administration to declassify any information it might have on Kaspersky Lab even as the House prepared to begin hearings on the issue. Meanwhile, in September Best Buy confirmed it would no longer carry Kaspersky's products citing concerns the company's alleged connections to the Russian government.

Kaspersky Lab has vigorously denied the claims and has suggested it is the victim of the current geopolitical climate. Earlier this week, the company announced that it would allow review of its source code by independent third parties. The security vendor's internal investigation, too, is part of an effort to tell its side of the story.

But some experts say Kaspersky Lab's explanation for how it happened to find the NSA material and what it did after, while plausible, raises more questions.

From the security vendor's report, the NSA file was running on a machine with a virus created by key generator (keygen) for the pirated software, says Simon Gibson, security architect at Gigamon and former Bloomberg CISO. "This keygen software triggered a scan and subsequently the debug or test versions of new Equation Group software being developed were found and uploaded to Kaspersky for analysis," he notes. While that is plausible, it suggests a level of sloppiness on the NSA contractor's part that is surprising, Gibson says.

"People are lazy and make mistakes like downloading a Windows keygen rather than submitting the paperwork to get a paid-for license from their employer," he says. But "most hackers know how hacking works and have a natural sense of self-preservation which makes this level of sloppiness hard to believe."

Wesley McGrew, director of cyber operations at Horne Cyber Solutions, says his concern is with Kaspersky Lab's claim that it deleted the NSA file.

"It's difficult to imagine a scenario where an antivirus company, with an interest in analyzing new malicious software samples and developing signatures for detection, would pass up the opportunity to analyze a collection of source code and debug samples for a malware family," he says.

Kaspersky Lab has analyzed and published research on other Equation Group malware samples, and has claimed to be neutral in the pursuit of nation-state malware samples, he says. "At the time the decision was made to delete, they had already collected the data and associated it with a group they're interested in. Why would their take on it being nation-state intelligence-affiliated push them to delete?"

But John Pescatore, a former NSA analyst and director of emerging security threats at the SANS Institute, says there's little Kaspersky Lab can do at this point beyond what it already has to prove it is not complicit with the Russian government.

"They have provided their source code for inspection," he says. "There's not much further they can go."

Related Content:

 

Join Dark Reading LIVE for two days of practical cyber defense discussions. Learn from the industry’s most knowledgeable IT security experts. Check out the INsecurity agenda here.

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
What We Talk About When We Talk About Risk
Jack Jones, Chairman, FAIR Institute,  7/11/2018
Ticketmaster Breach Part of Massive Payment Card Hacking Campaign
Jai Vijayan, Freelance writer,  7/10/2018
7 Ways to Keep DNS Safe
Curtis Franklin Jr., Senior Editor at Dark Reading,  7/10/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Locked device, Ha! I knew there was another way in.
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-15137
PUBLISHED: 2018-07-16
The OpenShift image import whitelist failed to enforce restrictions correctly when running commands such as "oc tag", for example. This could allow a user with access to OpenShift to run images from registries that should not be allowed.
CVE-2017-17541
PUBLISHED: 2018-07-16
A Cross-site Scripting (XSS) vulnerability in Fortinet FortiManager 6.0.0, 5.6.4 and below versions, FortiAnalyzer 6.0.0, 5.6.4 and below versions allows inject Javascript code and HTML tags through the CN value of CA and CRL certificates via the import CA and CRL certificates feature.
CVE-2018-1046
PUBLISHED: 2018-07-16
pdns before version 4.1.2 is vulnerable to a buffer overflow in dnsreplay. In the dnsreplay tool provided with PowerDNS Authoritative, replaying a specially crafted PCAP file can trigger a stack-based buffer overflow, leading to a crash and potentially arbitrary code execution. This buffer overflow ...
CVE-2018-10840
PUBLISHED: 2018-07-16
Linux kernel is vulnerable to a heap-based buffer overflow in the fs/ext4/xattr.c:ext4_xattr_set_entry() function. An attacker could exploit this by operating on a mounted crafted ext4 image.
CVE-2018-10857
PUBLISHED: 2018-07-16
git-annex is vulnerable to a private data exposure and exfiltration attack. It could expose the content of files located outside the git-annex repository, or content from a private web server on localhost or the LAN.