A bit of an odd title, eh? Either way, this article will be about a very peculiar bug that I discovered somewhat recently, where it was possible to overwrite user’s/victim’s profile images. But, there’s also a twist to it.

Initial recon:

When a website has any kind of upload function, there are a few things to immediately take a look at, it’s not even hacking really, it’s using the upload function of the website as it is intended.

The first thing that I tend to look for is whether I can select any file to upload (if I can, I just make a note of that while still uploading the expected type of file which is usually of image type)

Upon uploading the expected file type, usually an image of some kind, the next thing to look for is where is that image being stored and the naming convention. If the image is stored on aws then I note that and get XXE payloads ready, if it’s the same domain, then I note that, but if it’s some third party host then I leave it be (this doesn’t take into consideration whether the pulled name inside img src can be xss payload)

In this case, the upload location was the domain, which meant it was time to try various tricks in order to see if I can get any other file type uploaded, or whether I can trick in any way for the uploaded file to be executed as anything other than a regular image. That failed. But, the naming convention and the upload request parameters and their values suggested idor potential.

How does it work?

In this case, it was soon obvious that each user would get their own folder assigned to them, and their folder is where all their uploaded images would get stored to. In addition, all the uploaded images get renamed to userid_randomnumber_(small-medium-or-large).png

Upon further inspection, the randomnumber turned out to be not that random, but a unix epoch timestamp. For example: 1598044883 is same as Friday, August 21, 2020 9:21:23 PM GM

#computer-security #cybersecurity #bug-bounty #website-security #infosec #security