How I hacked multiple Indian universities (AGAIN).

If you haven’t already read part 1 make sure to check that out here: https://medium.com/thedeephub/how-i-got-rce-on-an-indian-university-without-admin-credentials-tale-of-directory-listing-sql-1f77e2933011

After reporting the vulnerabilities from my first analysis the university took less than 2 days to fix it and asked me to do a quick re-test which I agreed to. However, this time around I found even more vulnerabilities, and I wanted to write about it, because I found RCE again, but the way I found it shocked even me, and I think this is valuable for bug bounty hunters.

Remember that pesky admin panel with BAC (Broken Access Control)? Remember how I thought it was an EAR, but it wasn’t? Turns out I was wrong! I decided to take a second look at it and go to /admin/logged and intercept and view the request in burp suite, which looked something like this:

All I had to do was scroll down, I’m not sure how I missed this, but the admin panel content is clearly shown when scrolling down such as “crete new page” and other privileged roles.

Therefore, I installed the Noscript extension which comes bundled with the TOR Browser (colloquially known for accessing the “dark web”) and popped right into the admin panel.

The reason this works is because the JS is redirecting me away from the admin panel, so all I had to do is disable JS to see the contents of the admin panel and start working my way through it.

I know could finally test if there was stored XSS that could get executed on the admin panel, whereas before I could not because I had no admin panel access. To do this I simply filled out an application to the university and threw in a simple payload:

What this payload does is it breaks out of the current tag it’s in with the “> and then opens a new image tag and uses the onerror attribute to execute JS when the image fails to load, which it will. Moreover, I didn’t close the image tag, but that’s okay because a lot of browsers (including chrome) will repair broken HTML for you, so it’ll close the image tag for me. This is awesome because not only does this bypass simple regex checks looking for <anything here> but also keeps our payload a little smaller.

Now, the last vulnerability we had a simple file upload, access PHP shell, and that’s it. However, this time the file upload feature was completely patched. I thought for a second and then realized that some developers sometimes have old copies of their server code in the same directory. For example, admin.php will be the production one, and then you’ll have a adminold.php or admin2.php. However, as we mentioned before we can’t fuzz because of a robust WAF. Theoritically we could just create a large time delay on the fuzzing sofwtare (FFUF), tie some proxies with it, and wait a few hours to see what we have. However, I decided to do some manual fuzzing before going ahead with that approach and tried the following:

And apply2.php popped up! The same old vulnerability was detected in there too. Easily, I uploaded a PHP shell and just hopped right back on their servers.

Hmmm, now I remember last time there was a lot of restrictions on the server with the account I had privileges on the server with. This time I tried looking around more, and to my surprise there were poor misconfigurations everywhere. I ran linpeas.sh (with permission) and sifted through the output.

Turns out CPanel, has a webserver which you can enable and receive emails at myidentifier@DOMAIN.com. I had access to the folders that stored the emails and could read, modify, and delete their contents. I looked through the unread emails and found some banking-related emails!

Moreover, I was able to dump their CPanel webserver hashes, the way I found these was by reading LINPEAS output and sifting through the home directories.

I could simply reset their CPanel password, grab the code from their email (which I have access to via RCE), log in, and have full root access to the server.

https://www.linkedin.com/in/muhammadalisecured/