Comparitech researchers regularly scan the internet for exposed databases. When we discover such exposures, our goal is to disclose incidents to responsible parties so that they can take the necessary action to secure the leaked data. Ultimately, we want to minimize the impact to end-users whose information has been leaked.
After tracking response times to alerts, we discovered that more than half of companies don’t send a response to data exposure notifications. According to Comparitech researchers, in 502 data incidents studied, only 210 organizations sent a response to our alerts. Most of those took a day to respond, but others waited up to 17 days before responding.
The exposures studied resulted from unsecured databases, left open to public access. Vulnerable databases can enable unauthorized parties to access data, leading to data breaches that jeopardize the privacy and security of those whose information is stored within.
Details held in some of the databases we’ve discovered include account login credentials (usernames and passwords), personal information such as name, date of birth, address, phone number, and Social Security Number (SSN), medical information, banking data, and more.
The state of data breach disclosure study
As soon as a leak is discovered, we take steps to identify the owner of the database and alert them to the exposure. Where possible, we also investigate the content of leaked databases and determine what details were exposed and to whom the information pertains. Ideally, the database owners react quickly to our alerts by closing public access to the information and notifying any parties concerned.
In some cases, the response time is very swift. We often receive an acknowledgment thanking us for a disclosure and assurance that the database is secured (which we then verify). However, in many cases, we receive a delayed response or none at all.
To study the state of data breach disclosures, we tracked response times to alerts over the past 12 months. 23 percent (115) of organizations acknowledged our alerts within 24 hours. 12 percent (58) took two days to respond and two percent (10) sent an acknowledgment within three days. A further five percent (27) took between four and 17 days to respond to the disclosure. 58 percent (292) did not acknowledge our alert at all.
In cases where no acknowledgment was received, we did continue to follow up. We found that all databases were eventually secured or destroyed by a bot attack (more on that below). Reasons for a lack of acknowledgment are not clear, but in some cases, companies may try to avoid admission of a breach so as to “silence” the incident. In other cases, in particular some of those where we observed bot attacks, it appears our alerts have been ignored.
The vast majority of the exposed databases we discovered were Elasticsearch (182) and MongoDB (229) databases. These are the two most popular database types used for managing NoSQL data, so it’s no surprise that they feature heavily in our dataset. While these options offer solid security features, misconfigurations can leave them unintentionally exposed. Other fairly common application types discovered in our research included Kafka (13), Jenkins (11), Zeppelin (13), and Zookeeper (12).
Why swift action in response to data leaks is important
So does a day or two really matter? Yes.
According to our research, reaction time is crucial. In an earlier study, we set up a honeypot consisting of an exposed Elasticsearch database simulation. The leaked data was accessed by attackers within eight hours.
We left it exposed for around 10 days, and it was attacked 175 times during that period, an average of 18 times per day. In short, a speedy response time can drastically reduce the risk of exposure of sensitive data.
Bear in mind that the response time does not indicate how long the data has been exposed, as it could have been openly accessible before our researchers discovered it. Results in our honeypot experiment indicated that attackers are actively seeking these exposures.
One way attackers find exposed databases is to monitor Internet-of-Things (IoT) search engines such as Shodan and Binary Edge. Indeed, we found that the day on which the largest number of attacks occurred was the same day our honeypot was indexed on Shodan. However, in that study, data was accessed dozens of times before the database showed up on either of these search engines. This implies that attackers are being proactive and using their own scanning tools to find vulnerable databases, not just relying on IoT search engines.
Once malicious actors have their hands on exposed data, they can use it for a variety of nefarious purposes. Some will use the information directly in cybercrimes such as phishing schemes, fraud, identity theft, extortion, and more. Others will post information for sale on underground marketplaces such as those found on the darknet. For example, credit card details can fetch $5–35 per set on the dark web, and “fullz” data (which includes name, date of birth, address, phone number, SSN, and more) can net a criminal $14–60 per set.
Aside from data theft, databases are subject to other types of attacks. For example, in our honeypot experiment, our database was attacked by a malicious bot that deleted the database contents and requested a ransom payment. Other attacks observed by the team involved cryptojacking, credential theft, and configuration changes. Another honeypot experiment run by Comparitech researchers further illustrates the types of malicious requests sent to unsecured servers.
Laws regarding public disclosure of data breaches
It may be alarming to see that hundreds of data breaches have been discovered by our researchers alone within the past 12 months. And you might be wondering how many of these leaks your own data has been involved in. That brings us to public disclosure of breaches. In many cases, we create a public report detailing a leak we’ve discovered, in order to help alert those impacted. But what is the responsibility of the affected organization when it comes to disclosure?
Here, we take a look at some of the laws in place designed to hold companies responsible for publicly disclosing breaches and alerting end-users. Note that this does not constitute legal advice and we encourage you to seek additional information from official sources.
US
In the US, each state has its own laws regarding data breach disclosure. In general, most follow the lead of California which was the first state to enact such a law. Under this and similar laws, companies are usually required to disclose a data breach to affected parties in writing, immediately after the breach has been discovered.
Breaches must also be reported to the state Attorney General, but criteria for reporting varies. Usually, breaches of a certain size (for example, those affecting more than 500 or 1,000 individuals) must be reported. Depending on the state, breaches only have to be reported if there is a likelihood that an unauthorized person has accessed the information and the breach is likely to cause substantial harm.
EU
Under the General Data Protection Regulation (GDPR), in general, data breaches involving personal information must be reported to the relevant authority within 72 hours of discovery. As outlined by the UK’s Information Commissioner’s Office (ICO): “If the breach is likely to result in a high risk of adversely affecting individuals’ rights and freedoms, you must also inform those individuals without undue delay.”
Canada
Under the Personal Information Protection and Electronic Documents Act (PIPEDA), breaches must be reported to the Privacy Commissioner of Canada if an assessment by the affected organization indicates that the breach causes a real risk of significant harm (RROSH) to an individual. Individuals impacted by the breach must be directly notified (except in certain cases where indirect notification is allowed) as soon as possible after the breach has been discovered.
Australia
Companies in Australia are subject to the Notifiable Data Breaches scheme. Organizations and agencies have “30 days to assess whether a data breach is likely to result in serious harm.” In the case of a serious data breach, the affected organization must report it to the Australian Information Commissioner and alert impacted individuals via email, phone call, or text message.