Security firm admits to exposure of 5 billion records, after attempting to censor researchers

 

In March 2020, Bob Diachenko reported discovering an unprotected, publicly accessible  Elasticsearch instance which exposed two collections of records: first set with over 5 billion records, and another with over 15 million, still updating live when found. 

In what Diachenko had then-described as an irony, the leaking data was actually part of a  “data breach database” maintained by a security firm. It comprised previously exposed dumps with users’ personal information, such as emails and hashed passwords. 

Image: Security Discovery

To be clear, the exposed records do not appear to expose anything which wasn’t already exposed in previous data breaches. Monitoring services like HaveIBeenPwned keep track of email addresses and hashed passwords in a similar fashion to let users check for “pwned” credentials. Given the DNS records and information contained in SSL certificates, it didn’t take much for Diachenko or any security researcher to trace the origins of the leak back to Keepnet Labs, a UK-based security firm.

The same month, security expert and blogger Graham Cluley had published this report and his findings. However, in an update added June 3rd, 2020 in the post, Cluley had redacted the name of the company citing legal threats from the company as a reason. 

Despite Cluley offering to coordinate with the company and giving them an opportunity to provide their version of the story and a public statement, he was still pushed by their legal counsel to “[not publish] an article naming them in relation to the security breach, and [demanding that he] removed their name from the article.” 

Cluley mentions in his latest post that it is “best policy” for companies to open up and apologise about incidents like these, as that builds trust with customers and the information security industry.

“But Keepnet Labs didn’t do that,” he added. “Instead, it contacted media outlets requesting that their name be removed from the news reports. 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.”

This week, Keepnet Labs has stepped up and finally issued a public statement admitting to the exposure and providing more information. The reason for the leak seems to be a necessary scheduled maintenance performed by an outsourced IT contractor.  

“In March 2020, [our outsourced IT service provider company] was performing scheduled maintenance and was migrating the ElasticSearch database,” stated Keepnet Labs, citing “significant performance issues and increasing customer numbers” as the reason behind the maintenance.

The statement continues, “During this operation, regrettably, the engineer responsible later reported that he had to disable the firewall for approximately 10 minutes to speed up the process. During this window, the Internet indexing service, BinaryEdge indexed this data. A security researcher (Mr. Bob Diachenko), found this indexed data and could access the ElasticSearch database via an unprotected port. He could query the data and see high-level information regarding the dataset. Please see screenshot, this is how he could discover how many records were stored in that database.”

 

Image: Keepnet Labs

 

The public release provides more context and explanations by Keepnet Labs, in addition to some lessons learned from the incident. Keepnet Labs also debunked some of the previously reported news stories and apologised for the incident, in the same post.

“Keepnet Labs accepts full accountability for this incident and after completing a detailed investigation, has implemented a number of changes to our business and technology to ensure this will not happen again. We have also taken proactive steps to reduce the data we process. We accept that for the period the firewall was disabled by the service provider, those individuals were at increased risk on the basis that there was another duplicate copy of the data online for those with the technical skills to access it. For this, on behalf of Keepnet Labs and the service provider, we are very sorry.”

It is understandable as to why a security firm would take steps to contain information about such a data breach, as Keepnet Labs did. After all, a company in the business of protecting its clients against cyber attacks does not want to be implicated in one. But since the cat had been already out of the bag, admitting to the incident, offering a public statement sooner and taking immediate steps to notify their customers that they are investigating the matter, would have likely instilled a greater confidence in the firm, than opening up about a March occurrence in June – that too, after making a series of legal threats to deter “causing damage to our brand and reputation.”

No software is without flaws, and sooner or later even the most secure system in the world may get hit by a data breach. It isn’t only about preventing cyber attacks but how an organization chooses to respond when met with a time of crisis. In Keepnet’s case, that is the most important takeaway for businesses.