Recent events involving AWS S3 data compromises have once again highlighted the ongoing and complex struggle organizations face when attempting to achieve a secure state of operations in the cloud. Of particular interest is the reinforcement of the need for defense in depth with active monitoring. While officially published documents have left out the detail of the initial server compromise, the community has postulated that a SSRF (Server Side Request Forgery) was initially used to steal valid IAM Credentials for a role from the victim’s AWS account.
SSRF requires that an attacker take advantage of a flaw in the exposed web interface of a server in order to trick the server into executing commands on behalf of the attacker. If this method of attack is successfully used, the IAM role credentials can be obtained through the call to an “internal” address. In the case of SSRF, the internal resource with the credentials is accessed by another internal resource (the server), which is executing the attacker’s command.
The most common point made in news reports about AWS S3 data compromises is that the S3 bucket was misconfigured and left exposed to the internet without requiring authentication. When an S3 bucket is configured to require authentication, and even restrict access to specific IAM roles, most organizations would consider the bucket to be secure. When paired with an SSRF attack (or other successful attack method) that obtains credentials to S3, those S3 buckets are now accessible to the attacker within the scope of the permissions granted to the compromised IAM Role.
Solutions to Consider
S3 buckets are always publicly facing, so only the validity of credentials typically stands between an attacker and the target data. Enter IAM policy condition statements. The example below would restrict access, even for valid credentials, unless the request comes from a source IP address in the list. This is one additional layer of defense that organizations should consider utilizing for access that is expected to originate from a specific network location (internal or external).
“Condition” : {
“IpAddress” : {
“aws:SourceIp” : [“192.168.0.0/24”, “10.10.11.0/24”]
}
}
Other leading practices include the enablement of CloudTrail logs to have visibility into the actions taking place. These logs are instrumental in assisting both internal incident responders and external investigators in piecing together the events that occurred.
CloudWatch events can be considered to monitor for and alert on (or even act through lambda functions) suspicious activity such as making AWS API calls from external IP addresses or sync’ing S3 buckets to external locations.
For an industry leading benchmark to guide the baseline security implementation, consider the AWS CIS Foundations Benchmark.
For additional insight into what is occurring in your AWS environment, and visibility into potential security risks, consider the following AWS services:
- AWS Security Hub (report on and enable all of the below in a single dashboard)
- AWS Guard Duty (identify suspicious activity)
- AWS Macie (identify suspicious movement or storage of sensitive data)
- AWS Inspector and AWS Config (identify risky system or service configurations)
