Reflected Cross-Site Scripting happens when you provide a malicious javascript code to some input parsing functionality and due to lack of sanitization and filtration the application process your malicious code considering it as a valid input and thus, usually giving a popup of happiness.

However, when it is your lucky day and just for fun and learning you try to increase impact, and all of a sudden the server crashes, reveals the Database Credentials, your mind says only one thing “It’s a holy adventure time”.

Hi fellow hackers and enthusiasts, Today, I will be sharing my recent weird yet lucky experience which occurred accidentally while playing around with reflected XSS. Let’s call the target “redacted.com”.

The application “redacted.com” was having a blog website hosted on Wordpress at domain blog.redacted.com. When it comes to Wordpress, there are relatively fewer attack vectors that you can perform because it’s limiting, and being a third-party service you can not test for each and every functionality. Being lucky enough, I found a reflected XSS in Search Bar in a couple of minutes with this simple payload <img src=”x” onerror=alert(1)>.

That’s it? I just reported it and though to explore other areas of the application but no luck as such. I was getting bored so I planned to check for some of the new “XSS Payloads” discovered from online resources and Portswigger academy and see how they are working. I just ran intruder with all the payloads with maximum threads possible i.e. 999 and went away for a walk.

When I came back and navigated to “blog.redacted.com” to check for XML-RPC and other stuff, I observed that the application is crashed and the error message revealed a “Database connection string containing Login Credentials”.

After fiddling around, trying to login via “wp-admin” endpoint, there was no luck but I reported it anyway. All of sudden, I again started performing recursive directory search and to my luck, I found “/server/phpmyadmin” directory accessible publically. I accessed the endpoint and found the PhpMyAdmin login page and I used the credentials revealed from Error Message and a Successful Login & Access to all databases.

Quickly added comments and updated my Initial Proof-of-Concept Reported. Triaged as P1 the same day and fixed in 3 days. :)

Probable Reason it Might have happened is while searching for and retrieving data from the database, the malicious javascript payload might have broken the MySQL query string logic resulting in a temporary error message until the cache expires.

Takeaways

• If some functionality interacts with Database and you have found any bug on that functionality, just perform little stress testing IF ALLOWED. Some time due to improper handling, the backend logic may break temporary and error messages may reveal you interesting information.
• You never know when is your lucky day, never stop looking for things. You’ll surely succeed.

If you liked the writeup, do clap and follow on Twitter to stay updated about new posts, tips, and tweets :D

Twitter: https://twitter.com/harshbothra_