Load Balancer Response with HTTP Status 206 to GET of .env

[TimJohns]

Folks,

I recently noticed an intriguing log entry indicating a Load Balancer responded with an approximate ~3KB of data and an HTTP status 206 in response to a single GET request of '.env'. Pardon the potential mis-label, setting up Cloud Armor is where I am looking next, but this question is probably more general.

This particular load balancer is a global HTTPS LB configured to serve public static content from a backend bucket. I am very curious about the 3KB returned, and how the requestor coaxed a 206 out of the load balancer. So far I have been unable to replicate this behavior, and any case would like to determine how to configure the load balancer to include the request headers and payload that the requestor sent, in the event I see this behavior again. 

If anyone has any guidance on configuring a global HTTPS load balancer to log request content and headers, ideally ONLY for GET requests of /.env, please let meknow.

Additionally, if anyone has any insight into the nature of this particular request, please feel free to reach out here or privately.

Thanks!

-Tim

[imtaher · Accepted solution]

It's possible that the requestor sent a partial content request with a "Range" header that requested a specific range of bytes in the file, and the load balancer responded with only that range of bytes (approximately 3KB). The HTTP status 206 indicates a successful partial content response.

To log request content and headers for a global HTTPS load balancer, you can enable access logging for the backend bucket that the load balancer is serving content from. Access logs can capture information about incoming requests to the bucket, including the request headers and payload.

To configure access logging for a Google Cloud Storage bucket, follow these steps:

1. Open the Cloud Storage console and select the bucket that you want to enable access logging for.
2. Click on the "Edit bucket details" button.
3. Scroll down to the "Logging" section and click on the "Configure" button.
4. Enable logging and choose the destination bucket and object prefix for the access logs.
5. Select the log format that you want to use, such as "JSON" or "CSV".
6. Click on the "Save" button to save your changes.

Once access logging is enabled for the bucket, you should start seeing logs for incoming requests to the bucket, including GET requests for the .env file. You can use the logs to investigate the nature of the requests and the responses that the load balancer is sending.

It's worth noting that exposing sensitive environment variables through a publicly accessible endpoint like this can pose a security risk, so it's important to review your application's security posture and ensure that any sensitive information is properly protected.

To ask questions by protecting your information you can go on Kiask.

[TimJohns]

Thanks - 

By including the Range header, I can reproduce the 206, and the content returned is indeed the contents of the 404 page I have configured for the bucket, so mystery mostly solved.

The Cloud Storage console doesn't seem to have an option to Edit Bucket Details, but the concept makes great sense to me, and I was also theoretically able to enable access logging using the command line instructions here:

https://cloud.google.com/storage/docs/access-logs#delivery

e.g. :

gcloud storage buckets create gs://example-logs-bucket
gcloud storage buckets add-iam-policy-binding gs://example-logs-bucket --member=group:cloud-storage-analytics@google.com --role=roles/storage.legacyBucketWriter
gcloud storage buckets update gs://staticsite-bucket --log-bucket=gs://example-logs-bucket

Still waiting for access log data (per the Docs, should be sent over at 15 past the hour), but 

As far as .env containing sensitive data, that's what originally piqued my curiousity about the 206. This is almost certainly a threat actor scanning for secrets in .env files - but I don't HAVE a .env file in that bucket, and my initial attempts to GET all returned 404 (as expected). With the Range header included, I do get the 206, but that strikes me as a bit semantically weird -- I would have expected 404 regardless of the presence or absence of Range.

For completeness, this returns a 206 and the full contents of my configured 404 page:

curl 'https://example.com/.env' --header 'Range: bytes=0-' -i

And this returns a 404 and the full contents of my configured 404 page:

curl 'https://example.com/.env' -i

 Thanks again.

-Tim