Why securing cloud-native applications goes beyond AppSec?

In today’s landscape of microservices, Kubernetes, and cloud environments, attacks can come from multiple vectors, with varying degrees of complexity. Understanding these vectors and how to detect them is crucial for securing your infrastructure and applications. 

This post will explore various attack scenarios including SQL Injection and Cluster Takeover, structured around the 4 Cs of cloud security: Cloud, Cluster (Kubernetes), Container (workload), and Code (application).

To address these challenges, a new approach called Cloud Application Detection & Response (CADR) is emerging. CADR combines cloud management data, container workload data, and application layer data in a unified security solution that allows security teams to detect and respond to modern threats on cloud-hosted applications. By consolidating the capabilities of technologies like Application Detection Response (ADR), Cloud Detection Response (CDR), Endpoint Detection Response (EDR), and Cloud Native Application Protection Platform (CNAPP), CADR provides a comprehensive view of an organization’s cloud runtime security.

tl;dr CADR is the most effective way of telling the story of an attack on a modern technology stack.

Code (Application) Attacks

These attacks can typically be detected and stopped with an effective ADR. They are limited to the scope of the running application and do not involve the cloud or Kubernetes infrastructure. The challenge with this category of attacks is timely detection and appropriate response. For more details you can find examples of these types of attacks below.

Attack: SQL injection

An attacker exploits an application-specific vulnerability in a web application, allowing unauthorized access to the app’s backend database. With this access, the attacker can retrieve or manipulate sensitive data, such as user credentials, personally identifiable information, or proprietary business data.

One notable example occurred in 2019. A SQL injection vulnerability was discovered in the popular online game Fortnite, which has over 350 million users. This flaw could potentially allow attackers to access player accounts, putting sensitive user data at risk

The attacker’s goal here could be data exfiltration (as with the Fortnite example) or manipulating app behavior without gaining deeper system or infrastructure control.

Attack: API abuse

An attacker discovers an exposed API endpoint that lacks proper authentication and rate limiting. By sending a series of automated requests to this endpoint, the attacker extracts sensitive user data or performs unauthorized actions, such as making unauthorized transactions or modifying user information. 

Sadly, 2024 was rife with API abuse attacks. One significant incident involved Trello, where a hacker exploited an unsecured API endpoint to scrape data from 15 million user accounts, including email addresses and personal information. In another case, a vulnerability in Honda’s e-commerce platform allowed unauthorized access to 21,000 customer orders and internal financial data through a flawed password reset API. 

Additionally, PandaBuy faced a serious breach when critical API vulnerabilities exposed the personal data of 1.3 million customers, leading the company to pay a ransom while still contending with extortion attempts. Perhaps the most alarming incident was the Optus API breach, where an API with broken access controls remained undetected for four years, enabling a hacker to access data on 9 million customers, including addresses and ID numbers. 

Container attacks

These attacks are limited to the scope of the containerized environment and do not involve the broader cloud or Kubernetes infrastructure. The challenge with this category of attacks is timely detection and appropriate response. Effective Container Security, often part of a Cloud Workload Protection Platform (CWPP), focuses on monitoring and securing container runtime activities, ensuring that any anomalies or malicious behaviors are quickly identified and mitigated. For more details you can find examples of these types of attacks below.

Attack: container escape

An attacker gains access to a container running a vulnerable web application. They exploit a misconfiguration where the Docker socket (/var/run/docker.sock) is mounted inside the container. Using this socket, the attacker creates a new privileged container with host-level access. By leveraging the chroot command, they change the root directory to the host’s root filesystem, effectively gaining control over the host system. From there, the attacker can move laterally within the network, targeting other containers, services, or sensitive data.

A recent notable incident which utilized a container escape was a cryptocurrency mining campaign, detected by the research team at Aqua security. It utilized a container escape technique leveraging the CGroup release_agent feature. This allowed attackers to break out from the container and potentially compromise the entire host system

Attack: privilege escalation

An attacker gains initial access to a container running a vulnerable application. They exploit a misconfiguration or vulnerability to escalate their privileges within the container. For example, the attacker might find that the container is running with excessive privileges or that there are misconfigured permissions. By leveraging these weaknesses, the attacker can gain root access within the container. From there, they can attempt to break out of the container and gain control over the host system, potentially compromising other containers and services running on the same host.

A recent notable example of privilege escalation involved the ransomware group Akira and their attack on Usina Alta Mogiana (UAM), a multinational agriculture company. This sophisticated attack demonstrates the severe consequences of privilege escalation in modern cybersecurity landscapes. What makes this attack particularly notable is its speed and sophistication. The entire process, from initial breach to ransomware deployment, took place within just six hours

Cluster (Kubernetes) attacks

If we assume that ADR encompasses the application layer, Kubernetes-specific attacks can be categorized as operating system-level threats. These attacks target the Kubernetes API and its associated components. However, Kubernetes is often treated as a cloud service, monitored and secured like other cloud resources, effectively positioning it within the scope of CDR. Despite this, Kubernetes introduces unique security challenges that demand specialized attention.

Attack: sensitive data exfiltration

An attacker managed to gain access to a service account token that was leaked from the cluster. They can now use this service account token to read secrets from the cluster without spawning a new process or deploying any pods in it.

Attack: misconfigured RBAC

An attacker gains initial access by exploiting unauthenticated requests from anonymous users with privileges, and then creates a new ‘ClusterRole’ with near admin-level privileges and a ServiceAccount ‘kube-controller’ in the ‘kube-system’ namespace to gain persistence on the cluster.

This attack type, dubbed “RBAC Buster”, was discovered by Aqua security in 2023. It was recorded and analyzed as a result of a threat actor breaching one of their Kubernetes honeypots and was observed to have been actively used to compromise 60 misconfigured Kubernetes clusters. The repercussions of the RBAC Buster attacks on Kubernetes clusters can be significant and include unauthorized access to data, exposure of secrets, resource hijacking, and potentially even reputation damage.

Cloud attacks 

These attacks can typically be detected and stopped with a good CDR, since they are limited to the scope of the cloud. The challenge with this category of attacks is timely detection and appropriate response.

Attack: Cloud asset enumeration for public S3 buckets

An attacker conducts cloud asset enumeration to identify publicly accessible Amazon S3 buckets in a cloud environment. The attacker uses cloud API access or misconfigured credentials to list and inspect S3 buckets and their access policies. Key steps in this attack include:

1. Enumerating Buckets:
   Using tools like AWS CLI, SDKs, or third-party scripts, the attacker lists buckets within an account. This often exploits overly permissive IAM policies or compromised credentials.
2. Checking Permissions:
   The attacker checks bucket policies and ACLs to identify buckets with public or overly broad access (e.g., s3:GetObject allowed for Principal: “*”).
3. Accessing Sensitive Data:
   If a bucket is publicly accessible, the attacker downloads its contents, potentially exposing sensitive data like PII, credentials, or proprietary information.
4. Exploiting Misconfigurations:
   Beyond downloading data, attackers may also upload malicious content to writable buckets, enabling further attacks such as phishing or malware distribution.

A recent example of an enumeration attack occurred in May 2023, involving Visa’s payment ecosystem. Visa reported that enumeration attacks, specifically banking identification number (BIN) generation attacks, resulted in approximately $1.1 billion in losses for US merchants

Attack: post exploitation – cloud ransomware

Poor bucket configurations or compromised account credentials can be the entryway for an attacker to conduct a ransomware attack on an S3 bucket. 

They begin by creating a KMS (Key Management Service) key in their own AWS account or a compromised account and configuring it for public access, allowing any AWS user to encrypt objects using this key. However, decryption requires the attacker’s key, making the data inaccessible to the legitimate owner.

A recent example of post-exploitation occurred in the RedJuliett APT campaign between November 2023 and April 2024. After gaining initial access to government, academic, and technology organizations in Taiwan and other countries through SQL injection and directory traversal exploits, the threat actors employed several post-exploitation techniques:

1. They used T1071.001 (Application Layer Protocol: Web Protocols) to establish command and control (C2) by creating SoftEther VPN bridges.
2. The group deployed open-source web shells for persistent access to compromised systems.
3. They leveraged T1068 (Exploitation for Privilege Escalation) in Linux environments, exploiting an elevation of privilege vulnerability to maintain control over the compromised systems.

Attack: exfiltration from RDS

An attacker who gains access to an RDS (Relational Database Service) instance may attempt to exfiltrate sensitive data stored within the database. This could include personal identifiable information (PII), financial records, or other confidential data. Exfiltration often involves running queries to extract large volumes of data, exporting database snapshots, or directly transferring data to an external location. 

In some cases, attackers may escalate privileges to gain read access to more sensitive data. Since RDS instances can have their own roles, an attacker who compromises these roles may gain access to other cloud resources, leading to a broader compromise of the entire cloud environment. This can facilitate further exfiltration or manipulation of sensitive information across interconnected services.

In May 2024, the Mitiga Research Team found hundreds of databases being exposed monthly through Amazon RDS snapshots, leading to extensive leakage of Personally Identifiable Information (PII).

Warning! Attacks are rarely in a single dimension

The examples above were a best effort to depict attacks contained in a single layer of the 4Cs – Code, Container, Cluster, and Cloud. These attacks can be avoided, detected and responded to in the confines of one silo (e.g. cloud security, DevSecOps, AppSec, etc). The bad news is that this is rarely the case.

Having said that, most attacks will start in one layer to gain initial access and then break through the boundaries of the specific layer and permeate to the other layers. This introduces problems ranging from multiple alerts – since every security tool you use will alert on the specific problem it detected – through triage and analysis, to respond to the attack.

Below are a few examples of attack paths that highlight the need for a holistic view and a holistic security approach, when it comes to cloud security.

Code to Container and Cluster attacks

These types of attacks are more complex because they move between the application and its underlying Kubernetes infrastructure. The complexity of these attacks presents challenges that go beyond simple detection and response. To effectively identify them, security teams must recognize the attacks both on the application and infrastructure levels. They need to establish connections between these seemingly separate incidents, and combine related attacks into a single, security event. This approach requires a deeper understanding of the relationship between application-level and infrastructure-level security, along with advanced correlation techniques to effectively identify and respond to these threats.

Attack: RCE to Cluster Takeover

An attacker exploits a vulnerability in the application, such as remote code execution or an exposed sensitive file, to gain access to the container where the application is running. Once inside, the attacker accesses the Kubernetes API server from within the container. They then find that the application’s service account has been granted excessive privileges.

By using the compromised container’s service account token, the attacker can query the Kubernetes API server and potentially perform actions within the cluster, such as:

• Listing other pods in the namespace or cluster to gather information about the environment.
• Accessing secrets or sensitive configurations mounted in other pods.
• Creating or modifying deployments to deploy a malicious pod, gaining more control or persistence within the cluster.
• Escaping to the host.

A recent example of Remote Code Execution (RCE) leading to potential cluster takeover is the Kubernetes vulnerability CVE-2023-5528, discovered in late 2023 and publicly disclosed in March 2024. To exploit this vulnerability, an attacker only needs to modify a parameter and apply three YAML files to gain RCE over the Windows endpoints. This ease of exploitation makes it particularly dangerous, as it could allow for a complete takeover of all Windows nodes in a Kubernetes cluster

Code to Container to Cluster to Cloud attacks

Similar to the section above, these types of attacks are more complex because they move between the application and its underlying Cloud and Kubernetes infrastructure. It gets more complex, because it needs to account for Cloud security in addition to Kubernetes and application security. Similar to the section above these attacks presents challenges that go beyond simple detection and response. To effectively identify them, security teams must recognize attacks both on the application and infrastructure levels. They need to establish connections between these seemingly separate incidents, and combine related attacks into a single, security event. This approach requires a deeper understanding of the relationship between application-level and infrastructure-level security, along with advanced correlation techniques to effectively identify and respond to these threats.

Attack: Exploiting LFI to compromise Kubernetes and AWS IAM

An attacker discovers a Local File Inclusion (LFI) vulnerability in a Kubernetes workload and uses it to access the pod’s service account token located at /var/run/secrets/kubernetes.io/serviceaccount/token. This service account token allows the attacker to authenticate with the Kubernetes API.

Attack Steps:

1. LFI exploitation:
   The attacker leverages the LFI vulnerability to read the service account token from the pod’s file system.
2. Cluster access:
   Using the extracted token, the attacker connects to the Kubernetes cluster. If the service account has elevated privileges (e.g., cluster-admin or permissions to manage workloads), the attacker can execute malicious actions within the cluster.
3. Node targeting:
   The attacker identifies nodes with attached AWS IAM roles (e.g., through metadata or cluster configuration inspection) and schedules a malicious pod with a node selector to ensure it lands on a targeted node.
4. AWS privilege escalation:
   Inside the pod, the attacker exploits the IAM role associated with the node to access AWS resources. Using the permissions of the IAM role, they initiate a CreateUser API call to create a new AWS IAM admin user for persistent access.
5. Establishing persistence:
   The attacker sets up long-term AWS access by assigning full administrative policies to the new user, creating access keys, and potentially disabling alerts or logs.

Impact:

• Cluster compromise: The attacker gains control over the Kubernetes cluster.
• Cloud takeover: The attacker gains persistent, unauthorized access to the AWS account with administrative privileges.
• Data breach: Access to sensitive resources, including S3 buckets, databases, and other cloud services.

A notable, if not very recent example of such an attack took place in 2013 and targeted the Whatsapp media server. Back then, the Whatsapp media server was vulnerable to Traversal Local File Inclusion. The flaw allowed hackers to gather usernames and other sensitive files.

Attack: SSRF to Gain IAM Privileges

The attacker discovers a Server-Side Request Forgery (SSRF) vulnerability in an application running within a Kubernetes pod. This vulnerability allows the attacker to make arbitrary HTTP requests from the application’s context.

The application pod has an overly permissive IAM role, granting it permissions to create users and perform other IAM actions on the cloud account (for your reading ease we will go with AWS in this example). Exploiting the SSRF vulnerability, the attacker crafts a request from within the Kubernetes workload to the AWS IAM API, using the pod’s IAM role to:

• Create a new IAM user with elevated permissions.
• Generate an access key and secret key for the new IAM user, allowing the attacker long-term access to the AWS environment.

A notable example of using SSRF to gain IAM privileges is the Capital One data breach that occurred in 2019. 

1. The attacker exploited a misconfigured web application firewall (WAF) to send malicious requests to the AWS metadata service.
2. By querying the metadata service, the attacker obtained temporary IAM credentials associated with the WAF’s role.
3. The WAF’s IAM role had excessive permissions, allowing the attacker to access and exfiltrate data from cloud storage systems.
4. Using the stolen credentials, the attacker was able to access and steal personal information of over 100 million Capital One customers.

Final thoughts

Most incidents will be detected in one place (Code, Container, Cluster, Cloud) with other sources used for enrichment. However, we must recognize that we are in a new era in which the attackers are getting more sophisticated and they don’t care about our organizational silos or the limitations of our tools and dashboards. It actually helps them, because it slows down detection and resolution times. 

This new era of cyberattacks requires us to be vigilant throughout the depth of our stack from application to infrastructure and back again. Different attackers have different goals and tactics. Some exploit application vulnerabilities to gain access to infrastructure and then move laterally in it. Others may leverage weakness in infrastructure to gain access to the application and hold it or its data for ransom. Still, others stick to traditional methods, focusing on a single layer of the stack. The unpredictability of these attacks means that organizations must be prepared to respond quickly and effectively to any scenario. This requires minimizing false positives and duplicate alerts to reduce alert fatigue and ensure efficient incident response.

By understanding these diverse attack vectors and leveraging ARMO CADR, you can significantly enhance your ability to detect and respond to complex attacks in the microservices era. Don’t wait—book a demo today to see how ARMO CADR can prepare you for novel security challenges.