Apr 24, 2021
How I found Cross-Site-Scripting (Reflected) on more than 300 systems!
Hey everyone, welcome to my second write-up.
If you didn’t read my first, you can find it https://mrsinister1501.medium.com/my-bug-bounty-hunting-journey-methodology-and-tips-xd-790d8deb6247
This write-up is going to be about an Interesting bug, which I found a month ago. Hope you learn something from this write-up and have fun :)
#Let’s start!
As soon as I got invited to a HUGE private program on HackerOne, I decided that this is the one, and planned to stick with it for quite a while.
I started my automation and meanwhile did some Shodan Dorking on the company to find some interesting targets to start with.
I used this Shodan Query:
org:target http.html:"Login" port:443 -http.title:"Error,Forbidden,403"
Then after going through the results, the last result was of a Service which I knew provides “Admin Panels” for companies. So this definitely looked interesting.
I visited the domain and it loaded a login page/admin panel that looked like this:
I tested for some vulnerabilities, but nothing worked. When I was just about to move on from this endpoint, I checked the result of https://github.com/ffuf/ffuf, and I got nothing. I got a bit frustrated and entered /pleasework . Then I got a bit happier when I saw this:
I saw that “/pleasework” got reflected on the 404 Error page.
I thought of the exact thing anyone else would think of….
XSS!
I tested with <s>strikethrough?</s> and HTML Injection successfully worked.
Then I tried the basic XSS Payload(<script>alert(1)</script>)
But a WAF was in place…
Then I started to build a payload that bypasses the WAF and executes XSS.
After a lot of hit and trial, I concluded that any payload with these tags blocks the request.
<a>
<script>
<body>
<audio>
<image>
<img>
<style>
<iframe>
“javascript”
<animate>
Also, a lot of event handlers were being blocked if sent in the request. Eg- onerror. I was losing hopes of getting XSS on this endpoint.
But I remembered that <div> Tags can also be used for getting XSS.
I used a payload with <div> tag, and it didn’t get blocked. But it didn’t execute the XSS either due to some other characters in the payload getting blocked.
So now I had to build a payload with <div> tag.
Portswigger’s XSS cheat sheet and
XSS: Beating HTML Sanitizing Filters — PortSwigger came in very handy.
I tried different event handlers, to get them to work with the <div> tag.
After messing around with the WAF and getting blocked, I finally came up with a payload that actually worked!
<div onpointerover=”alert(‘XSS POC by mrsinister15’)”>Please put your mouse on me to see the magic ;)</div>
Yeah, the XSS worked. But with this payload, it would require some unlikely user interaction. The XSS would fire if a user hovers their mouse on the text-
“Please put your mouse on me to see the magic ;)”. Which is pretty cool, but we can do better.
Then after some more time, I came up with a better payload idea.
If I replaced the <div> with <html> then it would require much less user interaction because then if the victim hovers their mouse anywhere on the page, the XSS would fire.
I reported this issue to my private Bug Bounty target and slept because it was nearly 4 am for (I started at 12 am).
In the morning I tested some more and came up with 2 more payloads, these both didn’t require any user interaction!
These payloads were:
<svg id=x tabindex=1 onload=alert(1)></svg>With this payload, XSS would fire when the page loaded!
The alternative and the best payload was:
<svg/onload=alert(1)>I added these two payloads to my report, and my report got triaged but with this message:
The team accepted my report as Admin Panel Disclosure and not as
Reflected XSS. Apparently, the XSS that I found was in a third-party service and not in their system. After reading this I realized that all websites using the “third-party service” would be vulnerable to XSS with the payloads mentioned above in this write-up. I quickly went to Shodan to search for the service and its version. I got more than 300 results and I tested the payload on a few of them, and all of those websites were vulnerable to XSS at the same endpoint, with the same payload!
I contacted the service to tell them about this “exploit”, and I’m waiting for them to fix this. Then on 23rd April 2021, I got paid out by the private program for reporting the disclosed Admin Panel to them. Apparently, it was an admin panel to their Internal network which they “couldn’t afford to expose”.
#Some Tips and tricks for finding XSS for yourself! :
- When testing for XSS, always start by using a rare word. Eg- pleasework123. (It would be easier to find the reflection of it in the source code :)
- You can automate finding reflections with some open-source tools.
Eg- https://github.com/mikey96/reflection-public - But remember that no tool can just find you an XSS and throw it in your lap, it can help you find reflections but then you gotta do it manually.
- When testing for XSS, if
<>are not being filtered, then there must be a WAF in place. Sometimes, a company uses both for extra protection. Most of the time you can bypass the WAF by using different tags and different event handlers that are not getting blocked. - You can hardly find anything if you’re just copy-pasting the payloads.
- If you see that something is being reflected, then add some special characters into the input field along with “a rare word” and see the response in the source code. Eg- If “pleasework123” is being reflected, try “pleasework123 ‘ “ ><” and see if in the response any of them is being filtered or not. If it’s not being filtered, then there is a positive chance that you will somehow manage to get XSS by bypassing the WAF(if any).
- If
<>are being filtered then you can not keep your hopes too high.
You could try to escape from the tags in which your input is going with a quote or double-quote, you could also try Double URL encoding your input if the target is URL encoding your input, sometimes if you double URL encode your payloads, the target might decode them and the payload might work! - In case your target is HTML encoding your input(<,>) and in the source code “<” is getting reflected as
<and “>” is getting reflected as>
Then you can try to make a payload out of these reflections. Eg- Try to use the HTML encoded result of “<” and “>” to form a payload like this-”<script>alert(1)</script>” If you’re lucky then this would get decoded and the XSS might work! - XSS is a really common vulnerability, but that doesn’t mean that it’s too easy. It’s fun actually, but it comes with experience.
- Always test every input field and view the source code for reflections.
You should also test for Blind XSS by putting your (XSSHunter)payloads in every input field, especially if they ask for your contact info or if they ask you to fill a form. XSSHunter is in the trend for finding Blind XSS so do give it a shot.
If you have any questions, please feel free to hit
me up on my [Twitter](https://twitter.com/KabirSuda)
