Download Untangling the Web of Cloud Security Threats
The adoption of the cloud has been steadily on the rise, not only among smaller companies that are looking for more cost-effective alternatives to physical infrastructure but also in large enterprises that want to take advantage of its flexibility. However, one of the challenges organizations face, especially those who are just moving to the cloud, is a lack of familiarity with how the cloud is operated and how it is different from a purely on-premises system. Cloud setups typically involve not just a single implementation; instead, they combine different services from different cloud providers, often in conjunction with physical data centers.
This challenge extends to security — there are risks in inadequately securing cloud deployments and being unfamiliar with configuration specifics of cloud services. Many factors can lead to exposure of workloads and applications to attacks, including misconfigurations, improper use of technology, inexperience in operating and securing cloud systems, or even mere oversight on the part of developers or cloud engineers. The components of cloud systems are interconnected in many ways, making potential attack vectors difficult to map. For IT security personnel who are only starting to get a grip on cloud platforms and services, security presents a daunting endeavor.
[What you need to know about cloud security]
In our paper entitled “Untangling the Web of Cloud Security Threats,” we provide examples of threats and risks organizations could face when migrating to the cloud or using cloud services. No matter the cloud service or platform, the common theme we found is that misconfiguration continues to be one of the major pitfalls of cloud security, affecting both companies who subscribe to cloud services and users of software that are hosted on the cloud.
World-Writable Amazon S3 Buckets
Amazon Web Services (AWS) has emerged as a major player in the cloud industry thanks to its various offerings. Among the products in the AWS stable, the Amazon Simple Storage Service (Amazon S3) is perhaps the most popular; its infrastructure is being used by companies such as Netflix, Reddit, and Pinterest.
One of the consistent trends we saw in studying Amazon S3 buckets is that many organizations leave them world-writable — a misconfiguration that allows unauthorized users to write to the bucket. A well-reported example involved the L.A. Times, which previously had a network access control list (ACL) configured to allow public write access to the bucket that hosted its homicide website. This allowed an attacker to add a cryptocurrency miner to the JavaScript code.
Telemetry gathered from Akamai data for the Trend MicroTM Smart Protection NetworkTM infrastructure also showed that attacks on a number of websites with world-writable buckets occurred during most of 2019 — with some attacks involving the injection of malicious code and, eventually, exfiltration of data from website forms. Another issue we encountered were files classified as malicious that were being hosted on Amazon S3 buckets. Many of them use the old path-style addressing scheme. What this means is that the bucket is using a generic Amazon S3 hostname in contrast to the virtual-hosted scheme where the bucket’s name is included in the hostname.
This poses a problem for security filters since blocking the hostname of a malicious website that uses the path-style scheme will invariably block other non-malicious sites as well.
A second major service available in the cloud is computation, which is focused these days on container technology. Like the general cloud segment, containers have also seen a high rate of adoption these past few years. Software like Docker, Kubernetes, and AWS Lambda have helped push container technology forward, offering lightweight and efficient cloud deployments to organizations looking to streamline their development operations. However, lapses or mistakes in configuration are common, putting systems at risk of attacks that take advantage of these misconfigurations.
Docker
Docker users have been plagued by the proliferation of malicious containers delivering cryptocurrency miners, often as a result of Docker containers that are exposed to the internet. These miners can cause significant performance hits to the machine they have infected, and can even cause monetary loss due to extreme CPU utilization in cloud deployments based on auto-scaling instances.
There are a number of techniques for an attacker to inject a miner into an exposed Docker server. The simplest way is for the cryptocurrency miner to be installed directly from an image containing the code. Another common method is to use widely used base images like Ubuntu to install the mining software during the boot sequence.
AWS Lambda
AWS Lambdas are serverless event-driven processes that provide lightweight and cost-effective solutions for applications without set utilization patterns. A common misconception is that Lambdas are protected by virtue of an attacker not being able to directly retrieve function names. This misconception can often lead to functions being implemented without proper authentication.
However, attackers can find Lambdas through a number of methods — for example, using a sniffer to listen to network traffic or by examining the source code of sites that use Lambda and run an API gateway. Without a secure Lambda authentication in place, sensitive information is at risk of being exposed.
In addition, due to how developers code them, many Python-based Lambda functions print a stack trace when given incorrect arguments, which can lead to an attacker gaining knowledge of the nuts and bolts of the Lambda implementation.
Kubernetes
Kubernetes is an open-source container orchestration platform used to manage container workloads. Using Shodan, we found 32,000 instances of Kubernetes servers exposed to the internet in January 2019. Similar to other instances of misconfiguration, a Kubernetes service, or any of its components, that is publicly accessible to the internet can be exploited for malicious purposes.
Kubeletes
Kubernetes uses the API of its Kubeletes subcomponent to manage the containers in each node. In older Kubernetes iterations before version 1.10, Kubelet exposed the data port 10255 and the control port 10250. Both of these ports can be exploited. While the abuse of the control port is more apparent — for example, it can be used to install cryptocurrency miners — port 10255 can contain potentially sensitive information.
etcd
Etcd is a distributed and replicated key-value store that acts as the main datastore for Kubernetes. It is responsible for storing the configurations of Kubernetes installations as well as providing the storage backend for service discovery. Apart from Kubernetes, other applications, like CoreDNS and Rook, use etcd. Given its use as a datastore, a publicly exposed etcd can potentially leak sensitive data — including credentials used for servers and applications. We found over 2,400 exposed etcd servers using Shodan, representing a mix of both Kubernetes and other software.
Improper Credential Management
Credential usage — though often overlooked — is one of the most important aspects of cloud computing. Since organizations cannot physically secure a cloud system like they can a data center, the need for strong credential security becomes even more magnified. One challenge when it comes to securing credentials is that many processes often need to access data and other resources that require authentication. This means that users need to secure both data and the credentials from exposure.
A common mistake made by programmers is that they inadvertently leak credential information on public repositories like GitHub. Sensitive data like API keys are sometimes found in code snippets posted online, which can then be used by an attacker to potentially take over the account the credentials are used for. Compromised accounts can be used for a number of malicious purposes such as the theft of customer data, which can then be sold in the underground.
Another issue we found is that many inexperienced programmers often follow misleading cloud tutorials, many of which encourage the hardcoding of credentials inside the code itself. This becomes an issue if and when the code is published to a repository, where it is accessible to anyone.
As the adoption of cloud services grows, organizations need to be fully informed about the threats they face and be properly prepared to secure their cloud systems. The benefits of the cloud cannot be realized without a robust security implementation in place. The threats we analyzed in our research do not cover all of the potential threats and risks in the cloud, but we included some of the most significant ones. This is especially important for IT and security personnel who need to understand both the structure of the cloud as well as the strategies needed to secure it.
Read our complete report, “Untangling the Web of Cloud Security Threats,” which gives an in-depth look at the threats we discussed here and provides recommendations on how to defend against these.
Like it? Add this infographic to your site:
1. Click on the box below. 2. Press Ctrl+A to select all. 3. Press Ctrl+C to copy. 4. Paste the code into your page (Ctrl+V).
Image will appear the same size as you see above.
Recent Posts
- Ransomware Spotlight: Ransomhub
- Unleashing Chaos: Real World Threats Hidden in the DevOps Minefield
- From Vulnerable to Resilient: Cutting Ransomware Risk with Proactive Attack Surface Management
- AI Assistants in the Future: Security Concerns and Risk Management
- Silent Sabotage: Weaponizing AI Models in Exposed Containers