Cloudflare R2 Bucket Detection (Cooked Meat)

original:Hacking a Misconfigured Cloudflare R2 Bucket: A Complete Guide (intigriti.com)

There are several ways to find or identify a Cloudflare R2 bucket. We will introduce 2 methods in this article.

If you frequently test web applications, you may use a proxy interception tool to help intercept HTTP requests. You can search for referrals in HTTP responses because R2 buckets are sometimes used to serve static content such as images and javascript files.

You can use the following regular expression pattern to search for buckets in responses:\.r2\.cloudflarestorage\.com\/?

Or search the response for a typical private R2 bucket:

<?xml version="1.0" encoding="UTF-8"?>
<Error>
  <Code>InvalidArgument</Code>
  <Message>Authorization</Message>
</Error>

For public buckets, you can look for the following responses:Object not found

Dorking:

Search private CF R2 bucket:
site:.r2.cloudflarestorage.com "company"

Search the public CF R2 bucket (R2.dev enabled):
site:.r2.dev "company"

Once all R2 buckets related to the target are listed, we can move into the attack phase.

Attack - Exploiting R2.dev Access Enabled

By default, Cloudflare R2 buckets are never publicly accessible and explicit user permission is always required to enable public access. However, developers can choose to expose their buckets by assigning a custom domain or enabling R2.dev.

Assigning a custom domain is the default and recommended way to make a bucket public.

R2.dev is a simple feature that enables developers to expose their data buckets. This feature is for testing purposes only (especially during active product development). But sometimes, developers forget to turn it off, potentially exposing data objects to unauthenticated visitors.

This means that if the developer has not assigned any custom domain to the bucket, we can still request private data objects via R2.dev! Data objects (or files) often contain sensitive information (such as invoices and receipts) and should not be accessible to anyone.

For example, an attacker can easily find sensitive files that have been indexed in the past through Google dorking.

As an unauthorized user, you can quickly check whether the R2 bucket has R2.dev enabled by observing the response. If the index page returns "Error 404.Object not found", R2.dev is enabled. If "Error 401. You do not have permission to view this bucket" is returned, it means R2.dev is disabled.

Attack - Exploiting Missing Authorization Checks on Sensitive Files

Since Cloudflare does not provide access control lists or bucket policies (or similar features to control access), it is the developer's responsibility to use middleware to perform basic authorization checks. Especially for sensitive files containing PII data, to verify ownership of each individual file or data object.

At the same time, if this type of middleware is missing and the file bucket is public, then R2 cannot verify access permissions to any requested files. Any bad actor could view sensitive files without authorization.

Without taking any steps to limit file types, file sizes, or file names, bad actors can upload unwanted files (such as SVG files that could introduce stored XSS vulnerabilities), upload large chunks of data and increase cloud bills, or even overwrite files by providing existing file names!

attack-exploitMisconfigured CORS policy

Overly lax CORS policies can allow bad actors to access data buckets from unauthorized sources.