.png)
July 31, 2022
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?
Join us for a chat and walk away with a sinister looking (but comfortable) Kraken shirt! We’ll have fun surprises and entertainment throughout the show – you won’t want to miss.
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. We’ll also cover how to detect and mitigate this kind of attack by using Sysdig Cloud Connector.
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.
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.
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.
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.
Let’s recap what we have discussed so far and the two main flows:
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.
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.
The Sysdig Secure DevOps Platform provides the visibility you need to confidently run containers, Kubernetes, and cloud. Built on an open-source stack with SaaS delivery, it is radically simple to run and scale.
With Sysdig Secure for cloud, let’s see how you are able to detect this attack in each of its steps.
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:
Thanks to the metadata collected by the Sysdig Agent deployed in the Kubernetes cluster, the alert contains a lot of useful information. Beyond the IPs involved, the alert also includes the cluster name, namespace, and deployment of the pod.
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.
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.
Thanks to Sysdig Secure for cloud, security protection extends to the whole cloud environment. 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.
- rule: "Attach a dev-AssumeRole Policy to a non-dev Role" desc: "dev-AssumeRole Policy must be attached to only dev Roles so that only dev users can assume extra roles" condition: jevt.value[/eventName]="AttachRolePolicy" and (not jevt.value[/errorCode] exists) and (not jevt.value[/requestParameters/roleName] contains "dev") and jevt.value[/requestParameters/policyArn]="arn:aws:iam::720870426021:policy/dev-AssumeRole" output: The dev-AssumeRole has been attached to a Role (%jevt.value[/requestParameters/roleName]) which is not related to the dev. requesting IP=%jevt.value[/sourceIPAddress], AWS region=%jevt.value[/awsRegion], requesting user=%jevt.value[/userIdentity/arn]" priority: "WARNING" tags: - "cloud" - "aws" source: "aws_cloudtrail"
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.
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 the features in Sysdig Secure.
By leveraging the new Sysdig Secure for cloud, security teams can put together security events related to containers and cloud assets, centralizing threat detection and strengthening cloud security. This can all be done with a single tool, out-of-the-box policies, and no need for further custom integrations.
Our tools make the investigation of security events easier. When it’s vital for security teams, they have all the relevant information in the same place, in a centralized timeline, and with a correlation between events.
With Sysdig Secure for cloud, you can continuously flag cloud misconfigurations before the bad guys get in, and detect suspicious activity like unusual logins from leaked credentials. This all happens in a single console, making it easier to validate your cloud security posture. And it only takes a few minutes to get started!
Start securing your cloud for free with our Sysdig Free Tier!
The Sysdig Secure DevOps Platform provides the visibility you need to confidently run containers, Kubernetes, and cloud. It’s built on an open-source stack with SaaS delivery, and is radically simple to run and scale.
Request a free trial today!
Join our session on Thursday, August 11 from 10:00am-11:30am.
