In this article, I reveal a misrouting vulnerability that I uncovered while diving into Google Cloud Load Balancers connected to storage buckets—something that exposed thousands of websites to potential attacks. By crafting unconventional HTTP requests, I stumbled upon a flaw that reveals sensitive bucket names and opens the door for attackers to exploit load balancers in unexpected ways. Ever wonder how much damage can be done through a misconfigured cloud setup? Think data leakage, resource exhaustion, and sneaky redirections. Curious about how I pulled it off and the risks you might be overlooking? Read on to find out.
One of the things that I came to understand by doing security research’s is that detaching from the consequences often yields to good results. Some of these gems could manifest itself in the most unexpected times or places.
Misrouting vulnerabilities and SSRFs
I was conducting a research for fun and profit on reverse proxy misrouting vulnerabilities(https://www.acunetix.com/vulnerabilities/web/reverse-proxy-misrouting/). In order to do that, I first used bbscope to collect a list of domains from my bug bounty programs on Hackerone and Bugcrowd.
I then proceeded to perform recon and subdomain enumeration on those domains. I split the work across multiple Digital Ocean droplets using Axiom and Subfinder for speed and efficiency. I gathered a list of +1Million assets within the scope.
For fuzzing, I used Nuclei and focused on creating edge case templates/attack vectors that could have been missed by automated scanners or other researchers.
Initial Discovery
When it comes to fuzzing, I have learned that the best finds come from talking gibberish to web servers and looking for hints in their response. And that’s exactly what I did. The case that caught my attention was a pattern that was repeated on over 5000 websites.
When sending an HTTP request with a path that starts with character different than “/” the server discloses some bucket name in the response
HTTP Request:
GET @fuzz/ HTTP/1.1
Host: www.acme.com
Connection: close
Response:
<?xml version='1.0' encoding='UTF-8'?><Error><Code>InvalidBucketName</Code><Message>The specified bucket is not valid.</Message><Details>Invalid bucket name: 'acme-backend-bucket-for-protection@fuzz'</Details></Error>
This After verifying those targets IP ranges, I concluded that those were Google Cloud Load Load Balancers designed to forward traffic to an predefined Google Cloud Bucket.
Google Cloud Load Balancers and Storage Buckets
Google Cloud Storage buckets are cloud-based containers used to store and organize data in Google Cloud Platform (GCP). They function similarly to folders in a file system, but with added features for scalability, durability, and security.
Google Cloud About Cloud Storage buckets | Google Cloud
Google Cloud Load Balancers can be configured to serve content directly from Google Cloud Storage (GCS) buckets. This setup is commonly used for static website hosting or content delivery. Here's how it typically works:
- The load balancer acts as the frontend, receiving incoming HTTP/HTTPS requests.
- Instead of routing these requests to backend instances or services, the load balancer is configured to fetch content from a specified GCS bucket.
- This configuration allows for efficient serving of static content without the need for dedicated web servers.
In this setup, the load balancer essentially becomes a proxy between the user and the GCS bucket, handling the request routing and content delivery. This architecture can provide benefits such as improved performance, reduced server costs, and simplified management for static content hosting.
Experimenting
To get a better understanding of how this architecture works, I followed google’s tutorial to create an experimental lab with a load balancer and a storage bucket. I also spent some time playing with google cloud storage’s public endpoint storageapis.google.com to figure out what was happening behind the scene.
The following schema simplifies this
Redirecting the request
To see if I it was possible to redirect the request, I tried creating a bucket with the same name as one of my targets with a suffix “-private” appended to the name.
I then uploaded an index.html which contained the string POC. I tried to trick the target load balancer to redirect the request to my private bucket by requesting -private/index.html. The following screenshot is a proof of concept.
My first thought was that this could have been a common misconfiguration. But then when I tried replicating the same steps on my personal load balancer, it turned out that by default, all load balancers were vulnerable. I tried working around it with custom URL map rules, but there was no escape from this edge case.
The following schema should explain what is going on behind the scenes in case of any confusion:
Security Implications:
- Disclosure of the bucket name: While the bucket name could be considered public information, clients do not expect load balancers to disclose the name of the bucket with error messages. This could allow attackers to conduct further attacks directly on the bucket without having to pass through the load balancer or any firewalls that might be put in place.
- Ability to communicate custom responses to load balancers : Threat actors could set their buckets to return custom headers starting with “x-goog-meta-key” in the response returned by their bucket through a command like the following:
gsutil setmeta -h "x-goog-meta-redirect-url:https://www.google.com" gs://vellum-sc-backend-bucket-for-protection-pwn/index.htmlThose same headers will be reflected in the response of the misrouted request. If the load balancer has custom rules for dealing with such headers(redirection, cache..), attackers could tamper with their values through the issue discussed in this report.
- Risk of leakage of information through the logs: The requests sent by load balancers to the buckets could be found in the threat actor's access logs: https://cloud.google.com/storage/docs/access-logs. If the load balancer is configured to send sensitive data especially in the url of the request(such as private keys or url signatures), the attacker would be able to access this information by enabling and inspecting their exploit bucket access logs.
- Resource exhaustion: The load balancer data transfer usage is billed per GiB: https://cloud.google.com/vpc/network-pricing#lb. Attackers could host large files on their own buckets and abuse their target’s load balancer to fetch them. This could lead to important extra charges for the client or complete denial of service in some cases.
Timeline:
- Issue reported - November 09, 2023
- Issue Triaged as a P2 severity issue - November 09, 2023
- Issue rewarded - December 12, 2023
- Issue Fixed - September 27, 2024
To conclude
In a world of cloud, reverse proxies will always be a security concern. This area still has untapped potential from a security perspective, despite being sometimes overlooked by pentesters and researchers.
Thanks for reading !
Find me on:
https://www.linkedin.com/in/medmahmoudi/
Get in touch ?