Uncovering Web Cache Deception: A Missed Vulnerability in the Most Unexpected Places

In our constantly changing online landscape, security vulnerabilities can lurk where you least expect them. In this article, we delve into the tactics of attackers who exploit caching mechanisms to gain access to sensitive Personally Identifiable Information (PII) on seemingly harmless URLs.

VULNERABILITY DESCRIPTION

This vulnerability involves a Web Cache Deception attack targeting the https://redacted.com/anynonexisting URL endpoint. By manipulating the caching mechanisms, unauthorized users can gain access to sensitive Personally Identifiable Information (PII), such as First Name, Last Name, Phone Number, Email Address, User Id, and Encrypted IP Address.

During the assessment of the target application, it was observed that the server had implemented restrictions to prevent Web Cache Deception attacks on API/Web endpoints that had session tokens or data in the response.

Unfortunately, the same precautions were not implemented on the /404 page or any /nonexistingurl. We discovered that the response for any endpoint that doesn't exist contained PII information without any cache controls in place.

RISK BREAKDOWN Risk: HIGH Difficulty to Exploit: Easy

STEPS TO REPRODUCE

Step 1: Assume yourself as a victim already logged into the website and navigate to https://www.redacted.com/favicon.ico?agilehunt=13337.

Step 2: Observe that the response for the request has "cache-control" set to public, and the response for the request has been cached as "HIT" after visiting it twice:

Step 3: Upon verifying the response with the current authenticated user for this request or visiting any directory that doesn't exist, you will find PII information in the response:

Step 4: Now that we know any directory that doesn't exist throws a 404 Oops page, but the response contains the above PII information, and the cache configuration is misconfigured.

To verify this exploit, continuously send the request from Step 1 so that the response for that specific URL, which is cached on the server, can be tested using a tool like Burp Suite Intruder. Set the payload as null with 500 numbers.

Step 5: While running the request above concurrently - Send a fresh request to https://www.redacted.com/favicon.ico?agilehunt=13337 via Private Session browser or using Burp Repeater ( Intruder Recommended for faster reproduction) without any cookies or authorization token observe that the request has no authentication token or cookies, but the response contains the cached PII Data without any authentication.

IMPACT Exploiting this vulnerability presents severe risks. Attackers can access and potentially misuse PII data, leading to privacy violations, identity theft, and other malicious activities. The obscured UserID value leakage exacerbates the situation and fails the purpose of Obfuscation, enabling attackers to chain this vulnerability (if found ) with others, such as IDOR attacks, to gain unauthorized access to sensitive resources, manipulate data, and potentially cause significant harm.

RECOMMENDATION

Review and Update Cache Controls: Ensure that cache controls are properly configured on all web endpoints, including the /404 page. Implement cache policies that prevent sensitive PII data from being stored in the cache and served to unauthorized users.

Implement Authentication Checks: Implement authentication checks for all requests that could potentially access PII data. Only authenticated and authorized users should have access to sensitive information. Enhance Error Handling: Customize error handling for the /404 page and any other non-existent URL endpoints. Avoid displaying sensitive data in error responses. Instead, provide generic error messages.

CONCLUSION

While the target application had implemented safeguards to prevent Web Cache Deception attacks on endpoints containing session tokens or data, these protections were not extended to the /404 page or any /nonexistingurl. Consequently, any request to a non-existent endpoint yielded PII information in the response without proper cache controls in place.

Our step-by-step analysis demonstrated the ease with which this exploit can be executed.

For more information check out these references:

• Cache Poisoning and Cache Deception
• Web Cache Deception Attack