Hello bug bounty hunters . This is Daoud Youssef a part time bug bounty hunter and Co-founder of flawminers.com . Today I would like to show you a vulnerability I have discovered recently and it has small tips and tricks could be useful to anyone found the same vulnerability so let’s begin .
I have been invited to a private program so I can’t name it so let’s call it redacted.com and all subdomains are in scope of this program so first I go with the recon flow and use my private framework to enumerate subdomains which use many tools to collect subdomains actively and passive then I pass the collected subdomain to httprobe tool to check live subdomains . Usually my methodology first to go after subdomains with 403 or 404 response code or subdomains with empty main page because these subdomains are always neglected by the other bug bounty hunters and finding a vulnerability on it is more easy and means more chance to not get a duplicated report .
Also in my methodology i love to fuzz endpoints with non expected methods and headers and payload to check the behavior of the web application in non standard and expected circumstances
So after i have collected subdomains i pass them to aquatone tool and open the HTML generated file in the browser and i noticed a subdomain with interesting name which is webhook.redacted.com with only one number in the whole page which is 0 as shown below
Sometimes when you found subdomains with specific names may you think directly of some type of vulnerability like if you found grafana.redacted.com you will directly know that you are dealing with grafana and go direct to test its version for known exploits and this (webhook) name may attract you to search for SSRF vulnerability as the name suggest it deals with URLs also as i said before i love hunting on subdomain with empty pages so I decided to go with it
First I changed the request method to POST instead of GET and nothing changed in the response
Then I added dummy post data a=4 and also nothing changed
Then I thought to add the post data as json data and i suddenly found this error
My eyes sparkled with this error as I though that I am going to find a SQLi vulnerability so I tried hard with all payloads , cheat sheet , write-ups and also tools like ZAP ,burp pro, sqlmap , ghauri but no luck with exploiting it but during my test I noticed that any data I inject in the json data it reflect in the source code non-encoded so I think if I can’t get SQLi let’s test for POST based json XSS
So I tried this payload <script>alert(1)</script> but as shown in the below screenshot it escaped the slash on the closing tag so the payload didn’t work
So I think to use HTML tag that have only open tag without needing of closing tag to avoid the escape of closing tag so I used <img src=x onerror=alert(1)> and bingo the payload reflected non encoded and trigger the alert when I show response in the browser . but here is a very important notice that this could not be happened unless the response header content-type is set to text/html
But as we all know no bug bounty program will accept showing this only on burp so we need to made HTML poc and exploit the vulnerability with it so looking at the payload used we need to send json data within form as you can see that the request sent with header
content-type: Application/x-www-form-urlencoded
so we need to send the curly braces ({}) and the double quotation (“”) and the colon (:) in the form field so I have an idea why we can’t send these sympols in the name of the variable or the value of it as shown below
In this POC you need to notice a couple of things
1- We injected the whole payload in the name of the parameter with empty value
2- We should use enctype=text/plain so the browser doesn’t url-encode these special character
3- I have added an auto submit code (document.TheForm.submit()) so the form submitted automatically after victim open the html page to avoid that the victim need to do two action (open the page and submit the form ) because the more action needed from the victim means the less severity of the report so in this case the victim only needs to visit the malicious website which contain invisibly the malicious payload
But unfortunately the browser add extra equal sign (=) to the end of the payload because it should do this between the name of the parameter and the value of it and as the value is empty the equal sign added in the end of the payload which stop it from work as shown below because it breaks the json payload and the payload is no more a valid json so the response go back to be like as if it is a regular post based
I tried also to make the whole payload in the value of the parameter and with empty name parameter but the browser add equal sign in the begin of the payload which also make the payload a non valid json . here I was very disappointed because the whole vulnerability will fail because of equal sign (=) added by the browser which invalidate the JSON syntax.
But suddenly i have an idea . The payload already have equal sign (=) in the middle of it (<img src=x onerror=alert(document.domain))
Why we don’t omit the equal sign from the payload and divide it to two pieces the first is the part before the equal sign and put it in the parameter name and the second part after the equal sign and put it in the value of the parameter and let the browser put the equal sign so it complete the payload for us as shown below
And bingooooo it worked like a charm
Takeaways :-
1- Fuzz everything even it shows blank page .
2- Never give-up and try to be creative .
3- Always begin with empty main page subdomains
I hope even only one bug hunter get benefit from this write-up . I have tried to explain every small details for beginners . if you like this write up follow me on twitter Daoudyoussef