Crazy stored XSS on a router!

Here it is, yet another client side vulnerability but this time much more intense and much better honestly. For privacy reasons I won’t mention the name nor anything that could indicate what type of router this is since I had reported this issue but it isn’t fixed yet. However I wanted to write about this and how crazy sometimes XSS can be. So without further a do, lets just jump into it.

So this router has a web interface where you can tweak some things like SSID (or name of the network), password, how many devices can be connected etc.. My web interface is available at http://192.168.1.1 so once I logged myself in with default credentials and opened the developer tools on chrome I realized that there is a JS variable called ssid which stores the current ssid of the network. It’s always good to see what could be attacker controlled so I decided that I would research what I can do with this.

I tried to escape the variable by giving my network the following name My network’ but I failed.

As you can see, the ssid or the name was stored in a secure way and there wasn’t pretty much anything that I could do… WRONG! See, the JS code which was creating ssid variable and all these other ones is actually embedded in a script tag, it isn’t a file that is imported to the page, it is EMBEDDED in a script tag directly. So I had an idea to give my network a following name </script><script>alert(1);//

Since the code was embedded inside of the script tag and it would take whatever I set as my ssid of the network into ssid JS variable, my payload would simply close the existing script tag, open a new one and then call alert(1); and then comment the rest of the code to avoid syntax error.

So that is what I did. I changed the name of my network to </script><script>alert(1); //

After I connected to the network and visited the http://192.168.1.1 I was greeted with this:

The alert(1) was called and I had successfully found a stored XSS vulnerability on my router! If you are interested, here is how the variable looks like now:

So that was it. This vulnerability is indeed crazy and made me feel realy smart for a few days lol. Never have I thought this would be something I’d found but again, research, research and research. As I have said in my last write up, trying out something and failing is still research. Research doesn’t always result in bug reports for even experienced hackers, but being creative, knowledgeable and consistent will help you with finding bugs like this. I hope you learned something here and I hope this will help you with hacking later on. As always, keep your composure and let write ups like these motivate you to continue with your hacking journey!

If you have any questions:

Instagram: deadoverflow

Twitter: deadoverflow_