In this post, as with all of my posts, I want to be brief, because its your time I am spending right now and that's precious.
In short, in this post I will explain some of AWS Cloud Security Misconfigurations I often see in the pentests I carry out.
Open S3 Buckets
An S3 Bucket is a cloud storage where the AWS can help you store objects, which are essentially files. The web applications are using the S3 buckets for various reasons including hosting a website through the s3 (static content, using a dynamic API found in another host), host the private files of the user (instead of hosting them in the webserver) or even hosting static files of a website such as images, css or JavaScript files.
Firstly, the buckets have different configuration options in AWS. For buckets that its indented to be used only for private files, you should configure them to disallow any public access for the whole bucket. That means only authorized requests are allowed to access any object within the bucket.
Secondly, you can specify which objects can be public and which can't. Often, people are based in Security through security motto, and hide files in the S3 with the assumption that nobody knows the filename or it is difficult to be assumed.
This is connected with the next issue, which is a overly permissive S3 buckets. By default a bucket doesn't disallow from anyone (outside your organization) to list the bucket files. That means, the files of your bucket can be listed. Therefore, if the files are in public view, anyone can download them. Control who can do what in your bucket by setting up the ACLs and put some resource policies.
Uploading to an S3 Bucket
You should only upload to an S3 bucket only through your webserver. You would wonder why. The reason is because while the AWS may pass on a session token which can be passed to the client-side for uploading directly to the S3 bucket. At a first glance, it may seem fair and safe. However, you must verify that the uploading folder is the right one (as the bucket name is also sent through the client). Not only that, but by default any object uploaded (by ANY user) it overrides any previous file being in the bucket. That means by knowing the other user's filenames can be fatal, as a user may overwrite the files of another user. Due to difficulty in development of such functions I personally recommend to avoid such techniques, and sending the file firstly to the webserver and then forwarding the file to the S3 through the webserver. Make sure the file isn't in the root directory (or any other directory accessible by the user directly as a webshell can be uploaded).
Accessible Metadata
AWS offers an API to its various services which a programmer can perform API requests and retrieve various information. Such information could be a session token.
One may wonder, how one could call such metadata services?
The services can be called internally, when enabled for a particular service, by using the following endpoints:
http://169.254.169.254/latest/meta-data/iam/security-credentials/dummy
http://169.254.169.254/latest/user-data
http://169.254.169.254/latest/user-data/iam/security-credentials/[ROLE]
More endpoints exist, which can be used for any kind of things. Endpoints which are very useful for an attacker.
So how an external user, may call such metadata services belonging to AWS? To perform such queries one may have access either through a EC2 instance, or through a lambda function. This can be done by exploiting another vulnerability, such as SSRF or RCE.
Due to high number of attacks taking advantage the metadata service, AWS now gives the option of a second version of the service which requires two requests to perform a request. Therefore, an SSRF (which is a single request from a user to an internal node) cannot be used to exploit this misconfiguration. The metadata service is also known as IMDS (Instance Metadata Service). Make sure that your instances, use IMDSv2! If you don't need IMDS, then disable it for the particular instances.
Misconfigured Security Groups
One of the most common mistakes the cloud engineers do, is to have a security group (especially the default one) to be open to the internet by permitting the internet users to access all inbound ports. There are sensitive services which should never be allowed to reach the internet, such as MySQL servers, RDP servers and more. If there is a need to offer a service to a remote host, you can do this through whitelisting the IP address or through CIDR.
I hope the above most-common mistakes are enough for now. Follow me to have a look at the second part which is the most interesting, covering policies and IAM privileged escalation.
Top comments (0)