Untangling the complex web of corporate cloud security threats

In the third quarter of 2019 the cloud market reached an important tipping point. With public cloud spending soaring by 24% from the previous quarter, over half of all IT vendor revenues from infrastructure came from cloud rather than on-premises, according to IDC. The message was clear: cloud computing has become the new normal in IT. 

But as the market matures, so the use of cloud technologies becomes more complex: multi- and hybrid cloud set-ups are now increasingly common. IT security leaders are struggling to manage this complexity and uphold their part of the shared responsibility model with limited in-house skills. They’re also faced by an increasingly cloud-savvy cybercrime underground, ready and able to exploit any gaps in protection and user error.

The bottom line is that organisations can’t afford to do security in the cloud as they treated security in legacy environments; as an afterthought. It must be proactive, agile and built-in from the start.

A shared responsibility

Organisations migrate data and services to the cloud for a few well understood reasons: to drive efficiency, reduce costs, improve business agility and enhance the customer experience. Yet there are misconceptions: cloud infrastructure might accelerate time-to-market eventually, but it can take years to fully migrate apps and servers to the cloud. Similarly, IaaS providers might have better security capabilities and resources than you can afford in-house, but they won’t do everything. The likes of AWS, Azure and Google Cloud Platform (GCP) might secure the platform infrastructure, but customers are responsible for protecting the data residing there.

This is a common misconception, and one that’s driving one of the greatest threats to corporate cloud security today: misconfiguration. Every single day, Trend Micro identifies 230 million configuration errors that can leave organisations unwittingly exposed to cryptojacking, digital skimming, data exfiltration, ransomware and more. In AWS at least, default settings are secure. But they are often changed by under pressure IT teams looking to streamline internal workflows and processes. 

A people problem

AWS S3 buckets are one of the most common flashpoints for malicious activity and user error. If IT admins make them publicly writable then trouble could soon follow if hackers decide to use widely available scanning tools to prove deployments. That’s what happened at the LA Times when IT staff accidentally misconfigured access control lists (ACLs); allowing write access to the entire bucket in which was hosted a subsite for the newspaper. A cyber-criminal discovered the error and uploaded a Monero cryptocurrency miner to the JavaScript code in the bucket.  

In fact, Trend Micro analysed traffic over a three-month period and identified a large number of compromised global sites that were hosting at least part of their website on Amazon S3 buckets. Some were attacked by hackers with malicious JavaScript designed to harvest user information and card details when they paid for goods on the sites. Such Magecart campaigns are said to have infected tens of thousands of e-commerce sites around the world, including a British Airways breach which may cost the airline £183 million in GDPR fines.

Even when organisations are not hosting websites in their S3 buckets, there are still risks. If they’re publicly writable, the AWS repositories could be abused by cyber-criminals to host command-and-control (C&C) servers; store child exploitation material; or be used as an entry point to steal sensitive corporate information. 

Containers under fire

Containers represent another front in the war against cybercrime. These lightweight, isolated environments are increasingly favoured by DevOps teams as an easier way to rapidly test and deploy new applications and integrate hybrid clouds. Docker is one of the most popular tools out there to create and deploy containers. Yet here, too, user error is exposing organisations to greater cyber risks. 

Trend Micro has discovered numerous Docker servers exposed to the public internet without any protections in place. Often the Docker images were found to already be running cryptocurrency miners. There are several ways a hacker can achieve this: perhaps by installing it from an image that contains the code, hosted on a repository like docker.io, or by using a popular base image like Alpine Linux or Ubuntu and installing the mining software at boot time. Exposed container infrastructure could also invite hackers to install other malware to steal data or hold your IT infrastructure hostage. Remember: any container on an exposed Docker system can be introspected and its data exfiltrated, while they can also allow attackers to move laterally to different parts of the network.

Exposed by error

We also found common security weaknesses with AWS Lambdas, lightweight processes that run for only a limited time, as part of serverless architectures. Some developers think that because the Lambda function names are not directly known to the attacker, they are already more secure and therefore require little in the way of authentication. In reality, they can be relatively easily found by inspecting proxy server logs, examining the source code of web pages that use Lambdas with an API gateway on the back end, or by listening to network traffic with a sniffer. They could, in so doing, expose sensitive internal data or provide attackers with access to other cloud resources.

Another common sight in cloud infrastructure is container orchestration platform Kubernetes. Unfortunately, in just one month in 2019 we found over 32,000 Kubernetes servers that were left wide open. This is not recommended as it allows hackers to probe the infrastructure for remotely exploitable vulnerabilities which could allow them access. 

From the start

Most of the mistakes we’ve highlighted above are preventable. They don’t even cover the challenges associated with cloud credentials, which are often leaked via Pastebin and similar sites, and are bought and sold on a thriving black market. The bad news is that the trend for human error in cloud security will only increase as organisations embrace DevOps, containers and IaaS to drive digital transformation-fuelled growth.

To avoid unintentionally exposing corporate data and systems to the internet, and therefore also to the black hats, IT leaders must first understand their cloud infrastructure. Consider cloud deployment scripts like AWS CloudFormation to see how it all fits together, what controls are in place by default and where there may be gaps. Then it’s a case of following best practices such as least privilege access policies, and applying a Cloud Security Posture Management (CSPM) tool to monitor closely and continuously for misconfigurations. 

Finally, integrate security into your DevOps culture. This is easier said than done, especially if the function has a reputation for being a block on innovation. But with newer, API-led security services now available, developer teams don’t have to sacrifice speed and agility for better protection. The benefits of the cloud are undeniable, but they can swiftly be undermined if multi-layered security is not put in place from the start.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.