Cloud lateral movement: Breaking in through a vulnerable container

This blog was originally published by Sysdig here

Written By Stefano Chierici, Sysdig

Lateral movement is a growing concern with cloud security. That is, once a piece of your cloud infrastructure is compromised, how far can an attacker reach?

What often happens in famous attacks to Cloud environments is a vulnerable application that is publicly available can serve as an entry point. From there, attackers can try to move inside the cloud environment, trying to exfiltrate sensitive data or use the account for their own purpose, like crypto mining.

In this article, we’ll introduce a staged, but real-world scenario to showcase how it would be possible for an attacker to get full access to a cloud account.

The scenario for lateral movement

Let’s start this cloud security exercise with a vulnerable Struts2 application, running in a Kubernetes cluster and hosted inside an AWS account.

Once an attacker gets access to the pod, they will assess the environment looking for secrets or credentials to perform lateral movement and escalate the privileges.

Those credentials can potentially be found inside the aws metadata. Once obtained, the attacker will have access to the AWS account, and from there they can start poking around.

Having access to the cloud infrastructure, the attacker will look for misconfigurations that would enable their next actions. For example, solidifying position by persisting their permissions, impairing the cloud defenses, or escalating their privileges. Ultimately the attacker can cause harm looking for data to exfiltrate, or by installing a crypto miner or bot control center.

Now that we understand the overall strategy of our adversary, let’s dig deeper into their actions.

Step 1: Exploiting a public facing web application

One of the Initial access TTP (tactics, techniques and procedures) reported in the Cloud MITRE ATT&CK is via Exploiting Public-Facing Application. It makes sense. After all, anything public is already accessible.

In this scenario, there is an Apache Struts2 application publicly available.

To see if the available instance is affected by well-known vulnerabilities, attackers start doing passive and active gathering information activities. Interacting with the web application, it is possible to retrieve software versions and other additional information regarding the application deployed. From there, the attacker can query vulnerability databases looking for an entry point.

The attacker discovers that the Apache Struts2 version we are using is vulnerable to CVE-2020-17530, which permits remote code execution on the machine. If the attacker manages to exploit this particular vulnerability, they would be able to execute arbitrary code in the machine, including opening a reverse shell within the system.

The attacker sends a crafted HTTP request to the server, and voilà, a shell opens from the victim host to an attacker machine.

The bash command required to open the reverse shell contains special characters, which could cause errors during the execution. To avoid this, it is common to encode the command in base64, decoding it during the execution.

From the hostname, apache-struts-6c8974d494, the attacker can see they landed in a pod or container inside a Kubernetes Cluster.

Step 2: Lateral movement to the cloud

Now that our adversary is in, they have to reckon the terrain. You may think that having landed in a container, the attacker is fairly restricted. And you would be correct, but they still have some options to compromise our cloud security.

The attacker checks if the pod has access to the AWS instance metadata.

It looks like it does. There might be useful information regarding the cloud environment that would help the attacker escalate privileges or perform lateral movement.

Looking at the IAM credentials, the adversary finds the AWS IAM role credentials associated with the Kubernetes node where the pod is running.

The attacker can now import the credentials in their own environment and have direct access to the cloud account via cli.

Step 3: Privilege escalation via policy misconfiguration

At this point, the attacker is able to connect to the AWS account with the stolen credentials.

The first thing they do is start evaluating the roles and policies attached to the impersonated role, trying to find a way to escalate privileges inside the cloud environment.

That devAssumeRole policy looks promising. Let’s see what permissions it grants.

With the AssumeRole, the adversary has the option to act as other users. This is a weird permission to grant to an account like this one. It’s likely a misconfiguration, the kind the attacker was looking for.

Also, with the ReadOnlyAccess privilege, the attacker is able to enumerate the roles available in the AWS account and find which of those they can assume based on the restrictions in place. In this case the attacker can impersonate roles which start with the word “dev.” One of the roles the current users can assume is dev-EC2Full, which permits full control over EC2s.

Assuming this role, the attacker is able to act like a dev user, who has full access over EC2 instances, with the ability to create new instances for their own purpose.

Next steps

Let’s recap what we have discussed so far and the two main flows:

1. A vulnerable public-facing application is running in a Kubernetes production environment. It is used by the attacker as an entry point to the environment.
2. A misconfiguration in dev-related IAM policy attached to a production entity (an EC2 instance running a Kubernetes node), allowing the attacker to assume a more powerful role and escalate the privileges inside the cloud environment.

At this point, the attacker has enough permissions to cause harm to our organization. They could start acting now, or further try to compromise our cloud security and obtain greater access. Don’t miss our “Unified threat detection across AWS cloud and containers” article for a more comprehensive view on the following steps our attacker could take, and see what tools AWS offers to prevent, detect, and mitigate these attacks.

Detecting a lateral movement attack

Fortunately, these kinds of attacks leave a very recognizable track. For example, a reverse shell is something unusual and a runtime security tool can easily raise an alarm. Additionally, security tools can flag misconfigurations. With the right tools, you can strengthen your cloud security.

Detecting public-facing web application exploitation

We saw how the attacker was able to exploit a vulnerability, allowing them to open a reverse shell in the victim pod.

By tapping into the system events, Sysdig knows it happened. One of its many out-of-the-box Falco rules was triggered, and an alert was generated:

But what happens once the alert has been triggered? How can you investigate the event if the container disappears?

In the runtime policy configuration, you can enable system event captures. This will collect all the system events around the time the policy is triggered.

Then, you can perform a forensic analysis with Sysdig Inspect and learn what the attacker has done in the system.

Detecting the lateral movement to the cloud

We saw how the attacker established a connection with the pod and then gathered information about the cloud environment by reading the AWS instance metadata.

Let’s see those commands, using Sysdig Inspect to analyze the capture done by the policy when the Reverse Shell alert was triggered.

First, we can see the bash script used to open the reverse shell.

And later, we can see a curl command to the internal IP that was used to retrieve the IAM secrets that granted access to the AWS account.

Detecting Cloud malicious behaviors and misconfigurations

Security alerts will be generated in case security issues are detected in the account based on runtime rules already in place. Here’s an example of a security alert the attacker might have triggered assuming the role dev-EC2Full.

During the scenario, we saw the adversary was able to escalate the privilege due to a misconfiguration in the environment. What if security teams were able to detect the misconfiguration right after it was applied in the environment?

Using Cloud Connector capabilities, it’s possible to create a custom Falco rule that will generate an alert in case a misconfiguration is applied.

In our case, the misconfiguration was applying a dev-related policy to an instance role that was unrelated to dev. With the custom rule reported here, it’s possible to create detection for this specific scenario.

In the screenshot below, you can see the rule was correctly triggered once the user attached the policy to the wrong role, alerting security teams of the misconfiguration in a matter of minutes.

As with the previous security event, we can see how Sysdig Secure for cloud offers plenty of useful information. Thanks to the additional metadata gathered by the connector, the event contains key information regarding the AWS account, the affected object, and the user executing the actions.

Conclusion

The real-life scenario attack we presented shows how it is possible for an adversary to lateral move inside a cloud environment. Such attacks can start from a public-facing, vulnerable container, and can be detected and mitigated using cloud and container runtime security tools.