Misconfigured datastore services abound in the cloud

Are you configuring your cloud perimeter responsibly?

Michael McCoy
Mar 21, 2018 · 5 min read

Cloud hosting provides great flexibility for your developers. They are lured to the cloud by promises of rapid deployments and order-of-magnitude decreases in maintenance costs. But this agility comes with security risks as new services are deployed without adequate safeguards for security and compliance.

Image for post
Image for post

Not only do improperly configured cloud environments pose a significant risk to your business by inadvertently exposing services and data on your cloud perimeter, flaws in these services can provide a safe haven for hackers to build out botnets or perform other malicious attacks. Indeed, a record-setting 1.3Tbps DDOS attack in February 2018 relied on the abundance of improperly secured Memcached servers to execute the attack.

Services exposed on cloud providers

For this post, we look at one of the many corners of the the internet that we track at Qadium: datastore services that appear on well-known cloud hosting providers. In addition to Memcached and its successor, Redis, we also investigate some popular NoSQL databases, namely Cassandra, CouchDB, and MongoDB. These modern datastore services power much of the web we know and love, which explains their popularity in the cloud.

Despite their popularity, these services have one concerning thing in common: they are not security-hardened for the public-facing internet. Indeed, the only safe cloud configuration of these services places them behind restrictive security groups or private VPCs — they should never be directly connected to the public internet.

Image for post
Image for post
Percentage of cloud provider’s IP space exposing datastore services to the public internet.

The figure above shows the percentage of each cloud provider’s total IPv4 space that hosts a publicly accessible datastore service. The absolute numbers are astronomical: In March 2018, Qadium identified more than 75,000 total exposures of these services in the five cloud providers above.

Are default cloud deployments part of the problem?

Every provider we evaluated offers a large number of how-to articles — Hello World instructions — emphasizing how easy it is to deploy X service on their cloud. But when these articles gloss over important security details, it leads to a proliferation of risky perimeter exposures.

Qadium went through each cloud provider to find examples of lax policy related to the development services analyzed, and found that the “Hello World” example configurations for Redis on Azure and MongoDB on Google Cloud Platform create services that are public by default.

Azure & Redis

Azure offers Redis as a managed service, but appears to require a paid “Premium Azure Redis Cache” to block access from the public internet. For many developers on new projects, the lure of “free” gives them the ability to develop prototypes with minimal corporate friction, but in this case, it also means development with minimal security.

Image for post
Image for post

Indeed, a publicly addressable Redis instance appears to ignore Redis’ own security guide which explains that “Redis is designed to be accessed by trusted clients inside trusted environments. This means that usually it is not a good idea to expose the Redis instance directly to the internet…”

Google & MongoDB

Google provides a number of guides to set up MongoDB on its infrastructure. But here, we again see a pattern of insecure-by-default configurations. While Google’s instructions do deploy MongoDB with Node.js warn users that this sets up MongoDB insecurely, our observations suggest that a large number of developers are not taking that warning seriously.

Image for post
Image for post

Once again, this quickstart goes against the best-practice advice from the MongoDB manual, which implores developers to “Ensure that MongoDB runs in a trusted network environment…”.

Amazon, SoftLayer, and Rackspace

We couldn’t find any evidence that the final three providers, Amazon, SoftLayer, and Rackspace offer insecure-default deployments. In fact, we often found the opposite. For example, Amazon’s instructions place Redis in a restrictive security group by default. Why do we still see so many exposures in all cloud providers for these services?

The answer likely lies in lack of awareness of the security risk. Developers connect to services directly during development, which is acceptable when the services are protected within a secure local network. In order to get the same access with cloud services, developers may open up access to the services to the entire internet without setting up appropriate network access controls.

In effect, this treats the global internet as a trusted local network — convenient for development, but the security costs of services like this on your cloud perimeter far outweigh any benefits.

What to do?

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store