During a bug Hunting, I tested a university Like web application that allowed users to enroll in courses, earn certificates, and share badges.

My initial testing on the user profile section, which included checks for CSRF, IDOR, and Layer 7 DoS vulnerabilities, did not yield any results. I then decided to focus on the profile picture upload feature.

Initial Analysis:

I uploaded a profile picture and intercepted the request using Burp Suite. The server responded with a 200 OK status and provided a new URL for the image, which followed this pattern: /wp-content/uploads/{unix_timestamp}.png .

When I opened this image URL in a browser, I noticed an important response header: Cache-Control: max-age=14400

This meant the server cached every response from this URL for 4 hours. Crucially, this caching policy also applied to 404 Not Found error responses.

The Vulnerability:

Two key points defined the vulnerability: 1. Every uploaded profile picture was named using the current Unix timestamp. 2. Every server response (including a 404 error) for these image URLs was cached for 4 hours.

This led to a simple exploit idea:

Since Unix timestamps are predictable and easy to guess, I could request a URL for a future timestamp (e.g., /wp-content/uploads/81171724049436.png). The server would check for this non-existent file and cache the resulting 404 error for 4 hours.

Later, when that exact future timestamp arrived, if any user uploaded a profile picture, the server would save it using that same timestamp. However, anyone trying to view the image would receive the cached 404 page for the next 4 hours, effectively making their profile picture invisible.

The Exploit:

To exploit this, I created a Python script that continuously sent lightweight HEAD requests to the /wp-content/uploads/{Future_timestamps}.png directory, targeting a series of increasing future timestamps.

By running this script, I poisoned the cache for numerous upcoming timestamps. This meant that any user who uploaded a profile picture while my script was running would find their image unavailable on their profile for the next 4 hours due to the pre-cached 404 response their profile Pic URL. That it!!!!!

This was an interesting case of cache poisoning that disrupted a core application feature.

I hope you found this explanation clear and learned something new from it.

Thanks, @exploit5overs