I’m gonna share my story of a Remote Code Execution vulnerability that I found by happenstance. Since, I’m not supposed to disclose any information about the target, we will call it “redacted.com”.
I was fed up with the last target that I was testing since it had an extremely limited scope so I decided to move on to a new target. I found my target i.e. “redacted.com” and started to test it. It was an e-commerce website. I started to look for XSS in the search bar but unfortunately, I didn’t find one. I created an account on the same to get a better scope. After I logged in, I noticed that the web application allows the user to link their social handles. I quickly jumped into it and was able to trigger an alert! I made another account to see if the alert will trigger if someone else tries to view the attacker’s profile and the alert triggered there as well. I quickly reported the bug and came back to my account to test the application further.
Now comes the interesting part xD.
While I was closing the alert that popped up, I unknowingly clicked somewhere on the webpage and it landed me to a new page where the user can raise a ticket regarding their issues. I noticed that a user can attach some files while raising a ticket. I tried uploading a PHP shell but it didn’t allow me to do that.
After messing with it for a few minutes, I concluded on the fact that the web application allows some specific extensions only that are “.jpg”, “.png” and “.pdf” only. To save my time and to get a better idea about how the security mechanism is working, I fired up my Burpsuite and uploaded a valid “.jpg” file and intercepted the response. To my surprise, the file was uploaded in a directory of “redacted.com”.
With rising hopes, I renamed the PHP web shell and changed its extension to “.jpg”. But to shatter my hopes, I wasn’t able to upload it. It made me a bit upset but I didn’t stop there.
I started to figure out how the security mechanism is working. I wrote my points on a piece of paper and concluded on the following points:-
- The file extension is being validated at the client’s end only.
- The file content is being validated at the server’s end.
So, I tried adding “GIF98” in the web shell’s code to escape the server-side validation and “.jpg” to bypass the client-side validation of the file name. But this time too, I wasn’t able to get RCE. The file got uploaded but altering the “.jpg” extension gave me an error. I didn’t know, why.
After banging my head twice, I thought that there might be a server-side validation of the file extension which isn’t functioning properly. To give it a last try, I uploaded the same web shell with the “.jpg” extension and “GIF98” in the web shell’s code. I sent the request to the repeater and changed the file name from “webshell.jpg” to “webshell.php%00.jpg” to truncate the “.jpg” extension at the server’s end. AND YES! It got uploaded as a PHP file.
My reaction was like:-
I quickly went to see if the web shell got executed. AND YES AGAIN! I GOT RCE.
- June 01: Reported to the HackerOne Team.
- June 01: HackerOne Team marked it as Triaged.
- June 02: Temporary fix pushed, got $800
- June 08: Final fix pushed, got $4000.
That was how I made $4800 accidentally. The story of my “Accidental RCE”