Keepnet Labs case study: how NOT to handle a data breach

We just released news on this one but here’s a summary of what happened: In March 2020, Bob Diachenko, cyber threat intelligence director of Security Discovery reported coming across a leaky Elasticsearch instance. The instance had been indexed by the BinaryEdge search engine and exposing upwards of 5 billion records. Diachenko could trivially trace the maintainer of the instance back to Keepnet Labs, a British security firm.

What was actually being leaked was nothing but a data dump of email addresses and hashed passwords from previously exposed leaks, making the discovery “enormous” but by no means “critical.” Still the data exposure posed risk to users previously impacted by other breaches, as Diachenko noted:

“Even though most of the data seems to be collected from previously known sources, such large and structured collection of data would pose a clear risk to people whose data was exposed. An identity thief or phishing actor couldn’t ask for a better payload. Fraudsters might target affected people with scams and phishing campaigns, using their personal information to craft targeted messages.”

Learning of this Diachenko, “immediately sent a security alert to the company which seemed to be responsible for the exposure but never received a reply. Database, however, [had] been taken offline within an hour after notification sent.”

Silencing researchers and news reporters

In March, renowned security expert Graham Cluley published details about this “data leak” on his blog, however was forced to censor the name of the company after he was threatened with legal action, should he not comply with the request. Failure to reach a mutual agreement with Keepnet Labs, Cluley complied with the request deleting mentions of company’s name from his posts and disabling any comments so as to prevent anyone else from naming the company.

Only this week, Keepnet labs has admitted to the data leak in their detailed publicly released statement.

What happened in March, is being admitted to and disseminated to the public in June, by the security firm.

Cluley stated on his latest blog post following the company’s disclosure:

“I gave Keepnet Labs multiple opportunities to tell me what was incorrect in my article, or to offer me a public statement that I could include in the article. I told them I was keen to present the facts accurately.”

“But Keepnet Labs didn’t do that. Instead, it contacted media outlets requesting that their name be removed from the news reports,” stated the expert. “It even contacted people who had simply been quoted in the news reports (individuals who didn’t even name Keepnet Labs in the quote they offered journalists) and threatened them with legal action unless they somehow withdrew their comment.”

Contrast this with an alternative scenario: had Keepnet Labs acknowledged the data incident when it had happened, advised all its clients and the general public of the findings and the immediate steps they were taking, as well as “refuted” the perceived seriousness of the data leak, the company would have fostered a greater trust and confidence the community had in Keepnet Labs. Being open about things like these shows a sense of ownership and transparency.

Cause of the leak

The cause of the leak as explained by the company in their statement is rather simple. An outsourced IT contractor was tasked with migration of the Elasticsearch database during a “scheduled maintenance.” What necessitated this maintenance was “significant performance issues as a result of increasing customer numbers.”

During that window, the engineer tasked with the migration briefly disabled firewall controls for about 10 minutes, to expedite the process. This is when the engine BinaryEdge stumbled upon this “open” instance and indexed this data.

Diachenko later discovered this indexed data, and was able to see through a JSON response of a network request that there were some 5088635374 records in one of the exposed sets:

Takeaway for businesses

I can understand as to why any security firm would find it very difficult to publicly announce that they themselves had been involved in a data incident, something they pledge to protect their clients against! However, in the world of computers, no single system or component is guaranteed to be immune against attacks and vulnerabilities. Protecting your infrastructure is only half the battle won. How the senior management responds to crises, should they occur, tells the other half of the story.

Handling a data incident: an inadvertent leak or a breach should be handled with enough consideration towards your clients, the public and your company’s reputation. Security through obscurity has never worked, as history teaches us.

In Keepnet Labs’ case, they seem to have relied on controlling the news around the incident which had already been out, in an attempt to stop the spread of misinformation that “could be misleading, causing damage to our brand and reputation.”

However, censoring researchers, bloggers and media outlets through legal threats, and sitting on the findings this long probably caused more damage than would’ve been necessary – after all, the leak in itself didn’t expose anything that hadn’t already been previously leaked.

Keepnet Labs’ detailed findings, reasons, lessons learned and an apology have been published in the same statement.

© 2020. Ax Sharma. All Rights Reserved.

About the author

Ax Sharma

Ax Sharma is an Indian-origin British security researcher, journalist and TV subject matter expert with a focus on malware analysis and cybercrime investigations. His areas of interest include open source software security, threat intel analysis, and reverse engineering. Frequently featured by leading media outlets like the BBC, Channel 5, Fortune, WIRED, The Register, among others, Ax is an active community member of the OWASP Foundation and the British Association of Journalists (BAJ).

See author's posts