Tools Resources

Killing Cloud Security Misconceptions #4: There is No Private in Your Public Cloud

Or Azarzar

Monday, Aug 2nd, 2021

Last time in our Killing Cloud Misconceptions regular series, we talked about how the principle of least privilege doesn’t work for cloud environments. This time we’re turning to the idea of keeping your assets secure using private networks. This myth is a pervasive one - but that just means it’s worth debunking even more!

Many people that use the public cloud rely on segmenting assets in private networks inside their cloud environments to keep their assets secure. As networking-wise their assets are then private, it’s easy to see where this particular misconception comes from. While it’s true that if there is no public IP, or if the private network isn’t exposed to the internet then these assets can’t be accessed externally, that doesn’t mean there is no access at all and that their data is safe from manipulation, extraction, or risk.

Your Internal Servers Aren’t as Private as You Think They Are

The truth is that every single asset in AWS, or on any public cloud is accessible through a cloud service provider’s API. It doesn’t matter whether they are private or public networks, they can all be accessible, and allow attackers to shut down services or make changes to your environment, if the right permissions are granted. All that needs to happen is a single user credential or public access key exposure – something as simple as a compromised developer workstation that has sufficient permissions, and the attacker will be able to access any private asset in the cloud.

Let’s look at three real-world examples of how an attack on “private” networks can occur, and how the misconception of data safeguarding in the cloud occurs.

1. Information Stolen from a Public GitHub Repository

First, let’s take the example of a developer who generates an access key for his AWS account. The user’s access key includes the permissions to deploy and modify existing ec2 instances, as well as their network access rules. Within the environment, the company keeps private workloads that run the customer database. Inside this database there is sensitive financial information, from credit card details to credentials such as usernames and passwords.

Our developer is only human, and as part of his code, he forgets his access key ID and the secret access key in a public GitHub repository. As many attackers have automation working around the clock to constantly scan public GitHub repositories, it’s only seconds or minutes later that the access key ID and secret access key are in the hands of a bad actor. Quickly, they open the existing server to the public internet, which means the customer database (and all the sensitive information held within) is now accessible through a publicly exposed server.

2. A Malicious Open-Source Library

Example two coming up, this time regarding your admin workstations - likely to have some of the highest permissions and therefore a regular target. In this scenario, a malicious bot is looking to steal secret credentials to cloud environments from admin workstations, and it accomplishes this using an open-source library from inside an asset discovery tool. This tool works to continuously map often-neglected assets in your cloud environment such as old backups for databases, snapshots for old servers, and more.

When the bot uncovers these assets, it will automatically attempt to share those assets with its own cloud account. If successful, this data can then be extracted and scraped to be sold on the Dark Web. As of last year, 15 billion stolen login details, stemming from 100,000 breaches, are circulating on the Dark Web. If you think it can’t happen to you - you’re wrong.

3. Cross-account Access Breach

Our last example for today involves cross-account access. Imagine your platform engineering manager uses cross-account access as a legitimate part of his job, in this case to integrate a solution to a data analytics platform. The account is used for private data only, and none of the assets are publicly exposed to the web. Secure? Maybe not.

In this case, the data analytics solution itself is breached as a result of an application vulnerability in the SaaS platform. This may have come from human error on the vendor’s part – but there is nothing that your business, or your platform engineer could have done to stop it happening. The attacker abuses the cross-account access to its customer, extracts all of the data, and then encrypts it – holding your business to a heavy ransom to release the data, and throwing your organization into a media spotlight nightmare.

It’s Not Called “Public” Cloud for Nothing!

Using private networks and then patting yourself on the back that your public cloud environment is secure does not sound like a cloud security strategy. It’s important to recognize that on the public cloud – nothing is ever really private when a sophisticated attacker (or plain old human error) gets involved! There are a number of routes to data leaks, ransomware attacks, or public access for your private data.

To shore up these attack paths, at panoptica we provide customers with a full view of a real-world risk assessment, based on our innovative graph-based approach that looks at your environment the same way the attackers do. We don’t ignore private networks - because we can guarantee that the attackers won’t either.

Looking for risk-specific prioritization for your public cloud? Try a 14-day trial of Panoptica – risk free.

Get Started

Solutions

Tools

Resources