Leaking Cloud Databases and Servers Expose Over 1 Billion Records
As The Wall Street Journal recently pointed out, some clients of cloud service providers such as Amazon and Microsoft are accidentally leaving their cloud databases exposed due to misconfigurations of their services. Coupled with recent headline-making breaches, it’s becoming clear that the greatest risks to an organization might come down to a simple permission error or server misconfiguration.
There was a time not long ago when SQL injection was everywhere. From 2011 to 2013, IBM X-Force tracked a number of publicly disclosed data breaches that were often the result of fairly trivial SQL injection exploits, resulting in the loss of millions of email addresses, passwords and other sensitive data.
In the years since, it seems that vendors and businesses are doing a better job of protecting against SQL injection. But in its place, simple permission errors, API oversights and server misconfigurations have become even more pervasive.
In 2017 alone, as of September, IBM X-Force has tracked more than 1.3 billion (yes, billion) exposed records from misconfigured servers — from just 24 incidents. To put that in perspective, these misconfigurations make up 71 percent of the total number of reported leaked records for 2017 so far.
Compared to the impact of SQL injection, X-Force researchers tracked just 97 million records from this attack type at its peak during the three-year period between 2011 and 2013. In short, far fewer incidents are exposing much more data.
Figure 1: Each circle represents a publicly reported data breach or security incident. The size of the circle represents the relative impact of the incident (Source: X-Force Interactive Security Incidents).
Who Owns All This Data?
Cloud services are increasingly easy to set up and can scale to store hundreds of millions of records. They are ideal for archiving large data sets such as marketing lists and customer contacts, and are often used as a back end for mobile apps, which handle large numbers of users and varying types of sensitive data.
In this year alone, cloud server misconfigurations have exposed health records, voter data, customer support PIN codes from a major telecommunications company, credit card information from an e-commerce pet store and personal details of millions of wrestling fans, to name a few.
One disturbing recent incident involved an open file server from a toy company that makes teddy bears that can play back audio recorded by parents for their children. All of these audio files were sitting open on the web for anyone to access. Another misconfigured file server from a U.S. sheriff’s office contained audio recordings of crime reports and confidential informants, along with other highly sensitive information.
These unsecured cloud databases shined a light on other concerning privacy issues. It is not surprising to most people that their social media postings and profiles can provide a lot of publicly accessible data points. Given the ease of scraping these sites using application program interfaces (APIs) and other methods, marketers and research groups have begun storing personality profiles derived from social media data without users’ approval or awareness.
These profiles can contain in-depth data on people’s opinions, preferences and views. As a result, this is prized data for marketers, voter demographics and other applications requiring precise targeting. While there is nothing outwardly illegal about collecting publicly accessible data, it does bring into question the ethics of storing this information en masse, particularly on an improperly secured cloud database. Given that most people are unaware they are being tracked in this way, there is little to no recourse to opt out.
A Tale of Two Spammers
Marketing and research groups are not the only ones amassing archives of public data. Considering the huge amount of leaked records over the last five-plus years, there are billions of email addresses and password combinations available for purchase on the Dark Web.
Just two of the incidents tracked by IBM X-Force were responsible for over 1 billion exposed records so far this year. Interestingly, in both cases, the incidents involved spam groups.
In the first case, the operational intricacies of a quasi-legitimate affiliate marketing organization were exposed by an improperly secured rsync backup, which provided public access to their spam tactics and more than 393 million unique email addresses used for campaigns. In August, a security researcher discovered a misconfigured command-and-control (C&C) server used by a spambot, which contained over 711 million email addresses, passwords and Simple Mail Transfer Protocol (SMTP) credentials.
Figure 2: Each circle represents a publicly reported data breach or security incident. The size of the circle represents the relative impact of the incident (Source: X-Force Interactive Security Incidents).
Why Are These Misconfigurations on the Rise?
SQL injection attacks were so prevalent in years past because it is fairly easy to scan public-facing servers to find vulnerable targets. Similarly, tools such as the Shodan search engine make it much easier to search for publicly accessible cloud databases and services.
In the last few years, a handful of dedicated security researchers have uncovered hundreds of millions of exposed data records that were publicly accessible without any form of login or authentication.
While cloud vendors all publish guidelines on how to secure a production system, there are still thousands of open instances for a variety of reasons:
- The ease of using a cloud database provides simple setup for a single purpose, such as a marketing database. Those creating these databases do not always consider the potential implications of amassing thousands of data records on a public server if it’s ever breached.
- Many incidents have been related to old test servers filled with real customer data, which were used by developers and never properly secured.
- App developers use these data back-end services for scalability and ease of use, but they may not be well-versed in setting proper permissions or access, since these systems tend to fail-open, giving the impression that they are functional and secure.
Another troubling trend is drop locking, in which attackers scan for misconfigured open systems such as MongoDB databases and then drop database tables or lock out legitimate users to extort a ransom payment. From December 2016 into the first part of the year, researchers at the GDI Foundation tracked more than 45,000 open MongoDB databases in which tables were either dropped or encrypted for ransom.
The original attack involved copying the database in full, removing or replacing the tables, and notifying the database owner to pay the attacker by leaving a text file on the server where the data once resided. However, at one point, due to the ease of exploitation, there were multiple groups vying to extract a ransom on these same open systems. At times, these competing groups overwrote each other’s ransom demand messages, making it even more difficult for victims to retrieve their stolen data.
In August 2017, GDI noted a revival of these attacks, resulting in another wave of 26,000 locked databases, with one attacker alone hijacking 22,449 instances.
Figure 3: (Source: Shodan search engine)
How to Mitigate the Risk of Leaky Cloud Databases
Analyzing the threat and risk will always lead to a better understanding of the potential impact and help to define necessary controls. The first step should be to conduct a proper risk assessment on the cloud deployment you or your organization uses.
Apply data confidentiality controls such as data encryption. If used effectively, this can minimize the impact in a case of leaked data. Fortunately, more cloud vendors are helping with control options, gating data behind stricter permission settings so that it is more secure out of the box, even at the potential expense of accessibility.
For enterprise customers contracting the services of a cloud provider, embed your security policies into the contract to ensure cooperation from your vendor. Always review vendor best practices before going into production, conduct a pilot with test data or, better yet, consider periodically engaging a professional penetration testing service to map vulnerabilities and inadvertent access issues.
Stay up to date with the latest security incidents IBM has been tracking on the X-Force Interactive Security Incidents website. You can also use reliable threat intelligence sources to stay apprised of any new threats that may apply to your organization and help you re-assess risk.