Exploitation and Prevention of common AWS Vulnerabilities

Published: at 12:00 AM

AWS has become the clear market leader on the cloud platform providing comprehensive services, easy to use with the IaaS, PaaS, and SaaS models. As mentioned, it is one of the most popular cloud platforms. There will be security threats on the AWS platform too. Sometimes, developers mistakenly leak the credentials via hardcoded on their codebase, which might impact the organization. Here, we will discuss the common vulnerabilities on the AWS platform. Some are them are listed below:

One thing to be noted is Reconnaissance and OSINT, the key for cloud services and applications for pentesting. When attacking apps and servers, collect the info and resources as many as you can. Post exploitation has no limits with the cloud.

S3 Bucket

Amazon Web Services (AWS) provides a service called Simple Storage Service (S3) which exposes a storage container interface. The storage container is called a “bucket” and the files inside the bucket are called “objects”. S3 provides an unlimited storage for each bucket and owners can use them to serve files. Files can be served either privately (via signed URLs) or publicly via an appropriately configured ACL (Access Control List) or ACP (Access Control Policy).

S3 directory traversal

S3 Bucket permissions are secure by default, meaning that upon creation, only the bucket and object owners have access to the resources on the S3 server as explained in the S3 FAQ. Well, there are lots of issue and misconfigured mistakely done by Developers let’s figure it out much more in briefly.

Attacker’s view

For the enumeration of buckets, make sure you do well enough to know the bucket name. I recommend perform the combination of domains , subdomains, even with top level domains too. To determine the existence of bucket, you can navigate to pre-defined S3 URLs (Default format https://bucketname.s3.amazonaws.com) and check the response code.

The DNS-entry of the domain might reveal the bucket-name directly if the host points directly to S3.

You can also use aws cli to check out the content in the bucket.

aws s3 ls s3://bucketname --region $region

Defender’s view

Subdomain takeover on s3

S3 each bucket points to a specific domain or subdomain. When s3 buckets is no longer in use, developer/user might delete them from their Amazon account, but forgets to remove the DNS entry pointing to that subdomain it may escalate to a subdomain takeover because amazon allow non existing bucket names to be claimed again on any other account.

Consider, S3 bucket is created and its URL is https://momobhai.s3.amazonaws.com which bound to a subdomain momobhai.com belonging to org to obfuscate the AWS S3 URL. Later when this bucket is deleted from AWS S3, but the CNAMEs record from the DNS plaform(Route53, cloudflare) is not removed, an attacker may create an AWS S3 bucket with the same name and the malicious contents of this bucket will be served on the victim’s domain(eg: storage.example.net), Hence s3 subdomain takeover takes place.

Attacker’s view

dig cname <enter the subdomain>

<Error>
<Code>NoSuchBucket</Code>
<Message>The specified bucket does not exist</Message>
<BucketName>momobhai.cloud</BucketName>
<RequestId>ASJKADUSDSADASDSA</RequestId>
<HostId>sdausdhausdakslcnxuc=</HostId>
</Error>

You can use single command for checking out the s3 subdomain takeover.

http -b GET http://{SOURCE DOMAIN NAME} | grep -E -q '<Code>NoSuchBucket</Code>|<li>Code: NoSuchBucket</li>' && echo "Subdomain takeover may be possible" || echo "Subdomain takeover is not possible"

If it’s considered as vulnerable

Defender’s view

Insecure S3 upload policy & Directory traversal

Attacker’s view

aws s3 ls s3://bucketname
aws s3 rm s3://bucketname/objectname --no-sign-request # try to remove the file exposed to public
aws s3 cp filename s3://bucketname/ --no-sign-request # try to upload a file to the bucket
aws s3 mv filename s3://bucketname/ --no-sign-request # try to move a file to the bucket, incase if you are able to move a file, you can delete the file via move too

Defender’s view

Lambda

Serverless is a cloud computing execution model that automatically scales resources according to demand. It simplifies the process of building and deploying applications. Most common flaws we have seen so far is injection flaws. It occurs when untrusted input is being passed directly to interpreter and eventually gets executed. This might lead to OS command injection, file system access, privilege escalation, and other attacks or function runtime code injection including on Nodejs,python,java,golang.

Here is the free Lambda vulnerable lab.

Defender’s view

SSRF

If an attacker can make arbitrary HTTP/HTTPS requests from the server and get the respponses then it’s considered as SSRF(Server Side Request Forgery) vulnerability. It access EC2 metaservice with certain user role, might include private keys too.An attacker could then impersonate the role attached to the machine using the temporary credentials and do additional discovery or damage. It’s perform via GET based approach where a response for a user URL is being fetched via HTTP GET request through endpoints of EC2 instance.There is no authentication at the Instance Metadata endpoint. This allows for a simple GET request with no additional/custom headers to retrieve information.

curl url=http://ec2instanceip/latest/meta-data

To determine if the EC2 instance has an IAM role associated with it, look for it. A 404 response indicates there is no IAM role associated. You may also get a 200 response that is empty, this indicates that there was an IAM Role however it has since been revoked.

curl url=http://ec2instanceip/latest/meta-data/iam/iam
curl url=http://ec2instanceip/latest/meta-data/iam/security-credentials

Make sure you have aws cli and check whether those credentials active or not. Export those necessaries credentials to your environment.

aws sts get-caller-identity

Based on the credentials, attackers can leverage and use the services what they wish for for the target organization.

Defender’s view

aws ec2 run-instances --image-id  \
 \
--metadata-options "HttpEndpoint=enabled,HttpTokens=required"

For existence instance

aws ec2 modify-instance-metadata-options \ --instance-id \ --http-tokens required \ --http-endpoint enabled

IAM Issues & Security Groups

Identity and Access Management(IAM) allows users to assign AWS permission to people. This allows them to control what they can do with AWS resources whereas Security groups are a network feature like a firewall that controls what inbound(incoming) or outbound(outgoing) traffic can be sent to a specific services(instance).

If no security group is assigned to an instance in, then the instance automatically gets assigned to the default security group of the VPC which allows public access to all the associated resources. What if this cases rises on RDS so that attacker can have public access to RDS with credentials. Any security group having an IP address as 0.0.0.0/0 means that it allows unrestricted or public access.

I highly recommended Pacu to exploit configuration flaws in IAM issue and whole AWS infrastructure.

Note: IAM exploitation requries credentials in most cases.

Defender’s view

Others

Snapshots exposed to the public

Snapshots are an effective way to replicate data and applications. There is a chance that a snapshot may be exposed to the public ensure that develoepr might try to give access permission to certain users. Rather than defining fine grained permissions, it is easier and faster to share broadly and hence it got exposed to public.

Attacker’s view

Defender’s view

Conclusion

You have successfully reached till the end and learned much more about AWS security practises. Intently, you have learned something new. If you have anythings on this, please feel free to reach out to me at Twitter.

Last one, Hey, never miss any updates about blog posts, you can subscribe to my SRE/DevOps newsletter.