Full Report
Cache poisoning vulnerabilities are typically complicated and hard to come by. This author found a load of them and put them together in a single post. The first issue is a problem with a load balancer. While checking for gathered emails, the author noticed a JavaScript file that contained an email that was not theirs - but had no idea why. After some testing, they noticed this only happened when a particular cookie was removed. It's like the load balancer was caching the file per user but sent back the most recent one if the request didn't have the cookie. This issue was used to salvage a large list of emails from the site. Another load balancer issue was the result of a shallow copy vs. a deep copy. It turned out that once per hour that a caching bug occurred that led to an email leakage. Weird! The final bug started off as hunting for XSSI issues. One of the JavaScript files was constantly changing information in it. This file contained authorization information for each user. What could go wrong with this? The author deleted all of their cookies of the request still went through! But how? The URL had several other parameters, such as the location and other things, but they weren't random. It turned out that the CDN was caching these JS files! By brute forcing the loc parameter, it became possible for an attacker to steal auth information. Pretty neat! A few things to look out from this: Are emails or IDs what you expect them to be? Test out how the caching is being done. Remove parameters, cookies and other things. Is the JavaScript dynamic? Seems to cause lots of problems if it is.
Analysis Summary
# Vulnerability: Multiple Cache Poisoning and Load Balancer Leakage Flaws
## CVE Details
- **CVE ID:** N/A (Discovered via Bug Bounty/Penetration Testing; vulnerabilities were remediated by private vendors)
- **CVSS Score:** Estimated 5.3 to 7.5 (Medium to High)
- **CWE:** CWE-524: Use of Cache-able Resources with Sensitive Information, CWE-444: Inconsistent Interpretation of HTTP Requests, CWE-1329: Shallow Copy
## Affected Systems
- **Products:** Custom web applications utilizing Content Delivery Networks (CDNs) and Load Balancers.
- **Versions:** Platform-specific (not listed).
- **Configurations:**
- Load Balancers configured to cache per-user resources but fail to validate identity when cookies are missing.
- Applications using "Shallow Copy" logic for backend objects containing sensitive customer data.
- CDNs configured to cache dynamic JavaScript files based on non-random URL parameters.
## Vulnerability Description
The article details three distinct scenarios where infrastructure mid-layers (Load Balancers/CDNs) leaked sensitive data:
1. **Cookie-Dependent Cache Logic:** A load balancer was configured to serve cached versions of a JS file. When a user's session cookie was removed, the load balancer defaulted to serving the most recently cached version of that file (belonging to a different user), leaking emails and IDs.
2. **Shallow Copy Memory Leak:** A backend application performed a "shallow copy" of an object. This created a reference to other customer data in memory which was then cached. Once per hour, this cached object would render a page with multiple instances of different customers' data.
3. **Predictable CDN Parameter Caching:** A CDN cached dynamic JavaScript files containing authorization information. These files used a URL parameter (`loc`) that was not sufficiently random. By brute-forcing this parameter, an attacker could request and receive cached JS files belonging to other active users.
## Exploitation
- **Status:** PoC available (Verified during bug bounty and penetration testing).
- **Complexity:** Medium (Requires identifying specific caching headers and parameter behavior).
- **Attack Vector:** Network (Remote).
## Impact
- **Confidentiality:** High (Leakage of PII, including email addresses, user IDs, and authorization tokens).
- **Integrity:** None.
- **Availability:** None.
## Remediation
### Patches
- Fixes were implemented on the vendor side via infrastructure reconfiguration and code updates. No public software patches are applicable as these were architectural flaws.
### Workarounds
- Ensure that any response containing PII or session-specific data includes the header `Cache-Control: no-store, no-cache, must-revalidate`.
- Configure Load Balancers/CDNs to ignore specific dynamic parameters if they are used to serve sensitive content.
## Detection
- **Indicators of Compromise:** Unusual volume of requests to dynamic JavaScript files with varying parameters; multiple IP addresses receiving the same "unique" JS resource.
- **Detection Methods and Tools:**
- Use Intercepting Proxies (e.g., Burp Suite) to search for PII (emails/IDs) in passive scan logs that do not match the tester's account.
- Test requests by stripping cookies or headers to see if the server returns a cached version of another user's data.
- Monitor for "Vary" headers in HTTP responses to ensure proper cache keying.
## References
- hxxps[://]medium[.]com/dataseries/weird-vulnerabilities-happening-on-load-balancers-shallow-copies-and-caches-9194d4f72322
- hxxps[://]cwe[.]mitre[.]org/data/definitions/524[.]html