The past few months have seen a deluge of attacks on database deployments in production environments. Victor Gevers, an ethical hacker and founder of GDI Foundation, broke news about attacks on MongoDB instances in December, and this was covered again in the Kaspersky Labs blog. We then heard about attackers going after CouchDB and Hadoop databases in the wild.
Attackers all targeted instances that they thought would have valuable data — for example, databases owned by healthcare providers and telcos. Soon, tens of thousands of database instances were reported to be held for ransom, and the world of IT security had its next mega-crisis. This trend of going after corporate data in production environments for fame and profit, known as data-jacking, has only just begun.
Here's what we know so far about these attacks:
This round of attacks was opportunistic and relatively unsophisticated. Attackers were going after low-hanging fruit and quick wins rather than specifically picking targets they wanted to compromise. For example, in the case of MongoDB, the attackers used a Shodan query to find unprotected MongoDB servers online. In other cases, the attackers used readily available toolkits to get access to vulnerable instances.
The rise of untraceable cryptocurrency is making it easier for data-jackers to get away with ransom. The attackers invariably asked for ransom in Bitcoins. In many instances, the attackers did not make backups of the data before deleting it. In other words, they didn’t intend to return the data to the victims even after the ransom was paid.
The attacks can almost always be traced back to user error and permissive security policies that expose vital internal resources to the public. For example, in the case of MongoDB, the default database installation does not require authentication to access the database — a recipe for disaster for companies using third-party software such as open source databases without putting adequate security measures in place. In the software-defined world of the public cloud, exposed weaknesses are bound to get exploited very quickly. As Gartner predicted, 95% of cloud security failures will be the customer's fault.
Here are three ways to prepare your company to deal with data-jacking in a cloud environment:
1. Design cloud security in layers, starting with policies that minimize the attack surface by eliminating unnecessary asset exposure. Gartner, in its report titled How to Make Cloud IaaS Workloads More Secure Than Your Own Data Center (registration required), describes the hierarchy of security measures in a cloud workload protection platform from foundational technologies such as configuration and vulnerability management, network segmentation and traffic visibility, to less critical technologies such as antivirus (AV) and vulnerability shielding. Understand the value of what you are trying to protect and decide how much security you are going to invest in.
2. Before using third-party software such as an open source database in your applications, educate yourself about best practices and known vulnerabilities, do's, don'ts and gotchas. In the public cloud, one strike is all it takes to bring a business to its knees.
3. Be proactive about compliance and security maintenance. Compliance doesn't just refer to adhering to industry standards such as PCI DSS and SOC 2, but also to best practices such as the CIS AWS Foundations Benchmark. Don't make tracking, fixing, and monitoring a once-a-year exercise.
In many ways, data-jacking today is reminiscent of Telnet-based (pre-SSH) hacking in the '90s, when open ports and weak admin passwords were invitations to get hacked. But as data in the cloud becomes more valuable, the cost of weak security may soon be higher than many organizations can bear.