News & Commentary

2/16/2017
12:00 PM
Zohar Alon
Zohar Alon
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

The Era Of Data-Jacking Is Here. Are You Ready?

As data in the cloud becomes more valuable, the cost of weak security will soon be higher than many organizations can bear. Here's why.

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.

Related Content:

Zohar Alon is the founder and CEO of Dome9 Security, and a veteran in networking security. He helped shaped the early days of network security while at Check Point Software, where he built Provider-1, Check Point's service provider's management solution, which is still used ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
More Than Half of Users Reuse Passwords
Curtis Franklin Jr., Senior Editor at Dark Reading,  5/24/2018
Is Threat Intelligence Garbage?
Chris McDaniels, Chief Information Security Officer of Mosaic451,  5/23/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Flash Poll
[Strategic Security Report] Navigating the Threat Intelligence Maze
[Strategic Security Report] Navigating the Threat Intelligence Maze
Most enterprises are using threat intel services, but many are still figuring out how to use the data they're collecting. In this Dark Reading survey we give you a look at what they're doing today - and where they hope to go.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-11487
PUBLISHED: 2018-05-26
PHPMyWind 5.5 has XSS via the cid parameter to newsshow.php, or the query string to news.php or about.php.
CVE-2018-11471
PUBLISHED: 2018-05-25
Cockpit 0.5.5 has XSS via a collection, form, or region.
CVE-2018-11472
PUBLISHED: 2018-05-25
Monstra CMS 3.0.4 has Reflected XSS during Login (i.e., the login parameter to admin/index.php).
CVE-2018-11473
PUBLISHED: 2018-05-25
Monstra CMS 3.0.4 has XSS in the registration Form (i.e., the login parameter to users/registration).
CVE-2018-11474
PUBLISHED: 2018-05-25
Monstra CMS 3.0.4 has a Session Management Issue in the Administrations Tab. A password change at admin/index.php?id=users&action=edit&user_id=1 does not invalidate a session that is open in a different browser.