ChatGPT Account Takeover - Wildcard Web Cache Deception
Last year Nagli discovered a web cache deception vulnerability in ChatGPT. The impact of this was critical, as it lead to the leak of user’s auth tokens and subsequently, an account takeover. OpenAI notified users of ChatGPT of this vulnerability, and quickly patched the bug… Or did they?
In this writeup, I will explain how I was able to abuse a path traversal URL parser confusion to achieve what I like to call a “wildcard” cache deception vulnerability, in order to steal user’s auth tokens and take over their accounts. I will make the assumption that readers know the basics of the web cache deception vulnerability, as I will not go into too much depth explaining it. If you are not already familiar with this awesome vulnerability yet, or would like a refresher, I highly reccomend to check out Nagli’s writeup first and come back to this one. Additionally, this bug uses a similar concept to the web cache poisoning vulnerability I found in Glassdoor last year, which allows us to cache “un-cacheable” files and endpoints. While it is not exactly the same technique, it demonstrates how much potential there is for URL parser confusions, specifically with path traversals, to open new doors for all sorts of cache vulnerabilities.
While playing around with ChatGPT’s newly implemented “share” feature, which allows users to publicly share their chats with others, I noticed something weird. None of my shared chat links would update as I continued talking with ChatGPT. After dealing with bugs like this for a while, the first thing that came to mind was a caching issue. I figured that the shared chat was cached, and therfore wouldn’t update until the cache entry died. To test this out, I opened the network tab in my dev tools to check the response headers, and as I predicted, I saw the Cf-Cache-Status: HIT header. This was pretty interesting to me, as this was not a static file. I checked out the URL, and saw that the path did not have a static extension as expected:
