Wappalyzer SSRF Write up
Wappalyzer is used a lot by the infosec commmunity to find what websites are implementing in their websites. Awhile back I noticed @Random_Robbie and @Spam404Online on twitter reported XSS vulnerabilities in Wappalyzer ‘s website that were fixed, which spurred me to see if I can find a high severity issue in their website due.This will be quite a short write up,mainly discussing recon and particular stuff that any bug hunter should draw attention to.
We first check their website’s robot.txt for any sensitive files or end points, which is everyone should do, one of end points was named console which looked interesting. When I visited it, it said “waiting for input followed” and “ stop” in a black box, this looked familiar since on their main page they have a feature called “Analyze a website in real-time” which shows the same dark screen and same message as before.
How this end points functions is that you submit a url and it’ll crawl that website, showing the directories. One of the vulnerabilities that was uncovered was being that if the website had several directories then it would put the input into a script block. This end point didn’t strip input which allowed me to find a trivial xss involving </script><svg/onload=confirm()>, which meant you could submit website/xss-payload/ and it’d fire. I checked if the end point made a request to any other pages when you submitted url and it made a request to the console end point as I mentioned before.
The end point looked like this, wappalyzer.com/console?url= and as most people would of guessed when greeted with this type of parameter is to try to pass the local host address to the end point. First I tried 127.0.0.1, then http://127.0.0.1, both resulted in errors but remembering the site was https, I tried https://127.0.0.1 which resulted in it crawling the directories of the website. Nothing severe yet since it just showed know directories and nothing sensitive, I moved forward to attempting to check ports and protocols of the website. Additionally I tried to check for any form of XSPA vulnerabilities but that resulted in nothing. I checked the common ports and protocols which resulted in the following results,
Which returned a Connection reset by peer error. This an indication that there was an SSH service listening which didn’t like the request.
Connection from [88.99.*.*] port 12346 [tcp/*] accepted (family 2, sport 34480)
Confirming that we can get ftp connections going from the website which could lead to a DOS attack .
I used https://hackerone.com/reports/115748 as reference for different protocols to test out during my testing of this website and we could draw several conclusions from this. We could send spam requests from wappalyzer’s server due to gopher protocols, we could create DOS due to FTP (of course I didn’t opt to test this), crafted udp connection, etc. These vulnerabilities where patched quickly. It’s good practice to check any url= parameters or any parameter that uses urls in it for ssrf.