Recommended Free Tools
“Data Leak Week” was a cluster of cloud-storage exposures reported by Dark Reading on December 10, 2019—not one breach or a current tally of victims. The incidents included an ElasticSearch database holding more than 2.7 billion email addresses and an Amazon S3 bucket containing nearly 800,000 applications for copies of US birth certificates. Both exposures stemmed from data stores reachable online without effective access controls. The reporting did not establish that criminals downloaded or misused all of the records.
What happened during Data Leak Week?
Dark Reading used “Data Leak Week” to describe several separate exposures discovered around the same time. The common issue was not a newly discovered flaw in one product: databases and cloud storage had been left accessible from the public internet without effective authentication or access controls.
The figures below are findings reported in 2019, not current counts of exposed or compromised people.
| Exposure | What was reported | Important qualification |
|---|---|---|
| ElasticSearch database | More than 2.7 billion email addresses; about 1 billion records included plaintext passwords | Bob Diachenko could not verify every address was valid and active; the database operator was not identified. |
| AWS S3 bucket | Nearly 800,000 applications for copies of US birth certificates | Fidus Information Security reported complete world-readable access. The applications included personal information. |
| Exposed files trend | Digital Shadows cited a 50% year-over-year increase in exposed files caused by misconfigured online storage | The comparison was with 2018 and was cited in the 2019 report. |
Dark Reading’s December 10, 2019 report covered the incidents and their potential consequences.
#1 Best Overall
How were billions of email addresses exposed?
Security researcher Bob Diachenko found an ElasticSearch database on a US-based colocation server. It had no password protection and had been available for at least a week. After Diachenko reported it, the server was taken down on December 9, 2019.
The database contained more than 2.7 billion email addresses, mainly associated with Chinese internet providers including Tencent, Sina, Sohu, and NetEase, alongside some Yahoo, Gmail, and Russian-domain addresses. Around 1 billion records included passwords stored in plaintext. The records were associated with a prior 2017 breach; the reporting did not identify the database operator or establish that every address remained active.
Rank #2
Were the passwords in plaintext, and what did that mean?
Yes. The report said about 1 billion of the records included plaintext passwords: passwords stored in readable form rather than protected by a one-way password-hashing process. Anyone able to read those records could potentially see those credentials. The count describes records in the exposed database, not proof that one billion people had current, working passwords exposed or that attackers used them.
- Account takeover: A readable password may put an account at risk, particularly if its owner reused that password elsewhere.
- Targeted phishing: Email addresses and other identifiers can help an attacker craft convincing messages.
- Credential reuse risk: People who suspect a password may have been exposed should change it anywhere it was reused and enable multifactor authentication where available.
What was in the birth-certificate application bucket?
Fidus Information Security found nearly 800,000 applications for copies of US birth certificates in an AWS S3 bucket belonging to a document-ordering service. The applications dated back to late 2017 and included names, birthdates, addresses, email addresses, phone numbers, and other personal information.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →The bucket allowed complete world-readable access. As Fidus director Andrew Mabbitt explained, “The bucket was configured for complete world readable access — allowing anybody with the URL to obtain a full list of all files.” A separate collection of about 94,000 death-certificate applications was mentioned in the report, but it was not accessible in the reporting reviewed.
At the time of publication, Fidus said the birth-record data still appeared exposed and that repeated attempts to contact the service had received no response. That was the status reported then, not a statement about the bucket’s present-day configuration.
Why did the exposures matter?
Email addresses paired with plaintext credentials can support account takeover and phishing. Birth-certificate application data can help someone attempt identity theft or fraud. An attacker could also combine email addresses and personal identifiers to target bank or other valuable accounts.
Exposure is not the same as confirmed theft. The 2019 report did not prove that every record was downloaded, that all email addresses were valid, or that criminals exploited the data. John Bambenek of ThreatStop described the underlying risk: “The problem is that it’s still far too easy to make mistakes that expose all your data to the Internet.”
How can organizations reduce the risk of another cloud data leak?
The practical lesson is to treat cloud storage and databases as systems that require deliberate access controls, continuous oversight, and a clear understanding of what sensitive information they hold. Anurag Kahol, CTO of Bitglass, recommended maintaining visibility into customer data, applying real-time access control, encrypting data at rest, and detecting misconfigured cloud-security settings.
- Know where sensitive data lives. Maintain an inventory of customer and personal data across S3 buckets, ElasticSearch, and other online stores.
- Restrict access deliberately. Require authentication and grant only the permissions users and services need. Public access should be intentional, narrowly scoped, and reviewed.
- Detect configuration changes. Monitor for storage or database settings that make data publicly reachable, and alert the people responsible for remediation.
- Encrypt data at rest. Encryption adds protection if storage is accessed improperly, though it does not replace access controls or safe key management.
- Prepare a response process. Identify who can revoke public access, assess what data was exposed, preserve relevant evidence, and notify affected parties when required.
For AWS S3, the essential security objective is to prevent unintended public access and verify permissions at both the bucket and object levels. For ElasticSearch and similar databases, keep interfaces off the public internet unless there is a justified need, and require strong authentication and authorization. Monitoring matters because a secure initial setup can be undermined by a later configuration change.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
