The Fallout from MongoDB Breaches

In early January 2017, multiple media sources reported extensive attacks on misconfigured MongoDB databases exposed to the Internet. The initial estimates placed over 46,000 publicly exposed databases at risk, mostly hosted on Amazon AWS. Since then, the noise of these attacks has subsided, but this week we are learning about two very different styles of breaches as a result of misconfigured MongoDB databases. Early attacks included data exposure and even for ransom after the database was remotely wiped. These new announcements suggest the results can be even more sinister.

Spiral Toys was the First

The first attack is against children’s plush toys manufactured by Spiral Toys. These Bluetooth enabled stuffed animals are the latest devices to enter the IoT craze and suffer from a variety of Bluetooth security flaws, and unfortunately an insecure public MongoDB instance. Last week it was disclosed that 800,000 users accounts, children’s voice mail clips, passwords, and personally identifiable information was leaked due to poor security practices. The company allegedly has been slow to respond, including filing reports under California’s Data Breach laws. One can only conclude they do not care, do not have the expertise to respond, or do not believe it is a problem. Whatever the reason, an insecure MongoDB used to support their product resulted in a substantial and frightening data breach against a children’s toy. This is not the first toys to have been targeted. Remember V-Tech in November 2015?

Emory Health

The second attack is characteristic of the breaches we see weekly in the news. However, it is the biggest breach to date in 2017. 80,000 individuals were exposed due to a misconfigured MongoDB exposed on the Internet at Emory Healthcare. Last week, Emory Health reported to the Department of Health and Human Services details of the breach but the initial instance occurred at the end of 2016. In addition, as convoluted as it may sound, an extortion attempt was targeted at Emory but no data was wiped. Emory refused to pay the ransom and they were able to secure the database before any other threats emerged. This is very important since the data compromised included names, birthdates, contact information, and most importantly, internal medical records, appointments, and medical study information. If the latter was wiped or encrypted what would be the results to patient health? Could there have been a loss of life due to the unavailability of medical records? These are questions we cannot answer but emphasize the sinister nature of these threats and how an unsecure database could cause extreme havoc.

Steps to Mitigate the Threats

The threat against an insecure database is well known. Unfortunately, older versions of the MongoDB had insecure default configurations that could lead to a data leak, harvest a breach, or even put your organization on the front page of a periodical. When there are tens of thousands of these instances known to be at risk on the Internet, organizations must be vigilant in verifying that their instance is not one of them. If you are unsure of your own risks, conduct a cloud based vulnerability assessment or web application scan that can determine if you have a publicly exposed MongoDB at risk. Next, secure privileged accounts for MongoDB databases. Basic password configuration problems are what caused the initial problems we are now reading about daily. Be sure to contact us for a strategy session on securing your databases and critical data from data breach risks.