Remediating issues in the cloud presents a multifaceted challenge due to the dynamic and intricate nature of these environments. The scalability of cloud infrastructure, comprising various interconnected services and resources, amplifies the difficulty in identifying and addressing issues at scale without interrupting the working production environment.
Monitoring and addressing cloud misconfigurations and vulnerabilities is essential for keeping the cloud environment secure. Following the shared responsibility model, customers bear the responsibility for handling alerts and addressing identified issues. A notable observation from some of our customers indicates that a significant portion, approximately 70–80 percent, of security analysts’ time is dedicated to tasks such as triaging findings, strategizing remediation plans, and executing the actual remediation or automation activities.
Wiz x Tamnoon – Visibility and Remediation
Wiz is a cloud agnostic, agentless solution that scans your entire cloud infrastructure and gives you full visibility into your resources and cloud risks. Wiz scans the cloud and workloads for deep analysis across vulnerabilities, misconfigurations, data security, malware, and secrets, and provides the attack paths in a single pane of glass across clouds.
Tamnoon.io offers a solution that combines human expertise and AI with the goal of helping teams quickly and safely remediate cloud risks. With Tamnoon.io, SecOps and DevOps teams fix more risks in less time, while limiting the negative impact of configuration changes to their environments.
The Tamnoon team gained a lot of experience starting, or restarting, cloud monitoring and remediation programs for our customers. We found that making a new or revamped program successful requires some “quick wins” the team can then build on. In general, quick wins are activities with good return on investment, that require low investment. In the world of security remediation, a quick win is a successful remediation of a high-severity finding (a finding with a significant and clearly understood risk), where the remediation can be carried out without great effort, and with a very low chance of breaking anything. Having quick wins like this under the team’s belt bolsters confidence and organizational clout, and increases the team’s ability to tackle harder tasks later on.
We believe this focus on quick wins should be shared by every team just beginning their journey with Wiz. In the example scenario below, we address a type of finding with critical implications (extremely easy to exploit, often with potentially costly damages), but also with an easy path to remediation; with little chance of adverse impacts on any application or business process.
Examining Cloud Configuration Rules
In Wiz there are two types of security findings: “Findings” and “Issues.” Typically, one only finds critical findings among Issues. But critical issues, by and large, are a combination of multiple findings. For instance: some virtual machine is (i) publicly exposed, and (ii) running a software component with a high-severity vulnerability. Such issues can be truly critical, but their triaging and remediation (upgrading a software library) can be difficult.
Wiz also generates findings against Cloud Configuration Rules. These findings are in general “atomic,” and often easy to remediate. Sometimes these detected configurations may even be intentional, and remediation may break some business process or application – investigation and testing is required before remediation is executed.
However, there are a few Cloud Configuration Rules which show misconfigurations that should – practically – never be tolerated, rarely carry false positives, and present remediations extremely unlikely to break anything. This is a good place to start! The most obvious such rule is “S3 Bucket ACL should not allow global ‘WRITE_ACP’ permission.”
The high-severity risk of S3 buckets with publicly writable ACLs
By pulling this finding from Wiz, we are able to see details about the underlying affected S3 bucket, the configuration of the resource, and remediation guidance for resolving.
AWS S3 is perhaps the most widely used cloud service. It’s one of the first services AWS offered, and because of its relatively long history in the space, S3 has a somewhat complex security model. That model allows Admins to choose between a “bucket policy” and a “bucket ACL” to set access controls for S3 buckets and the objects inside them. Today, bucket ACLs are not the preferred mode of managing access on S3 buckets, but they are still widely used.
S3 ACLs use the concept of a “grant” that associates a user or user-groups with a permission. Two of the built-in groups one can assign in grants are:
- http://acs.amazonaws.com/groups/global/AllUsers which comprises everyone.
- http://acs.amazon.com/groups/global/AuthenticatedUsers which comprises all AWS authenticated users – meaning many, many millions of users.
There are 5 permissions that can be specified by ACLs:
- (1) “READ” and (2) “WRITE” provide permissions to get and to place objects, respectively, in the bucket.
- (3) “READ_ACP” and (4) “WRITE_ACP” are more exotic permissions: they specify who can read and modify the ACL itself.
- (5) “FULL_CONTROL” covers all of the previous four permissions.
The bottom line here is that it is possible to create an S3 ACL that allows all users, or all AWS authenticated users, to change it. Below is an example of an ACL with grants that permit such access:
"Grants": [
{
"Grantee": {
"Type": "Group",
"URI": "http://acs.amazon.com/groups/global/AuthenticatedUsers"
},
"Permission": "WRITE_ACP"
}
]
Now, actually allowing this to happen, in practice, never makes sense. We have not encountered applications that dynamically add or remove grants from bucket ACLs, let alone without assuming some specific role in the bucket’s account. Doing so will allow malicious users to easily:
- Allow themselves into the bucket and then exfiltrate, modify and/or poison the files therein, and then remove themselves from the ACL.
- Create a service disruption/DoS by removing other grantees’ permissions to access the bucket, which may break applications, services and processes.
We hasten to add that ACLs should not grant READ_ACP access to global groups. At minimum, this would disclose the user IDs and sometimes names of organizational users with sensitive permissions. This information can be leveraged to perform targeted attacks (phishing, or other) aimed at stealing their credentials. Wiz detects this less critical misconfiguration as well.
Attackers know about this type of misconfiguration, and often wield automated tools designed to discover and exploit it.
Tamnoon recently identified this exact risk in a large entertainment company; key stakeholders were alarmed at the risk but pleasantly surprised with the ease of the remediation process. After noting the risk as critical per Wiz, Tamnoon not only provided the customers with an automated remediation solution, but also analyzed their cloudtrail to see if any of the instances of misconfigurations were exploited. Luckily, in this instance, no exploits were identified.
Remediating “low-hanging fruit” misconfigurations
The least-disruptive remediation of misconfigured S3 buckets involves a 3 step process:
- Get the current ACL of each bucket
- Remove from the ACL the global permission to READ_ACP and WRITE_ACP
- Apply the modified ACL to the bucket
In most cases, there is a simpler way to reset the bucket ACL:
aws s3api put-bucket-acl --bucket <bucketname> --acl private (or public-read, or public-read-write, or authenticated-read)
More information on this solution here.
Detecting Exploits
Having a global “WRITE_ACP” should be considered a critical, highly exploitable vulnerability and should be investigated for possible exploitation.
In this case, any changes to these buckets’ ACLs should be individually investigated. Changes to S3 ACLs are recorded in cloudtrail. The API call to look for in cloudtrail is PutBucketAcl.
Any and all such calls for the vulnerable buckets should be considered highly suspect and the activity of any user that was granted access via such API call should be further tracked. This can be done using the AWS CLI by running the following command in each account and region where the misconfiguration was identified.
aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=PutBucketAcl --region example-region
Summary
Getting early wins in triaging alerts and mitigating risks is crucial for the success of new or revamped cloud monitoring programs. When starting out, remediation teams need to focus on findings whose remediation would provide a great return on low investment, and pave the way for addressing more complex issues at greater cost.
When using Wiz, one way of locking down these early wins is to focus on findings generated by Cloud Configuration Rules – detecting high risk misconfigurations with a very low chance of intentionality. These rules and their findings are your proving ground for an effective cloud monitoring program.
Further Reading from Tamnoon
