XSS like a Pro

Hello Friends,

I'm gonna share my interesting finding here.


Recently, 
About two months ago, I received a private invitation on Bugcrowd and the next day I started to look for bugs on that website because there was only one target (testing site) in scope and they provided me some credentials.

I can't disclose the site name, so let's assume https://redacted.com

First of all, I logged-in to that site (redacted.com) with the provided credentials and inspected the site around 15 minutes and tried to understand it.

After that, I started to look for bugs and found multiple bugs mostly stored XSS. At that day, I had found a total 11 vulnerabilities. I reported them and received a bounty on each report. So, I'm not disclosing the bounties. Also, I'm not sharing my all findings but some.

So, 
At the beginning, I tried to change my default password and successfully changed my password to '1' which was the first bug that there is no password policy. After that, I checked some session management & rate limiting issues and found nothing. Then I just copied my profile pic url & opened it in Incognito mode or in private window, the site prompts the basic authentication to login, which allowed me to bruteforce the users login and it was my second finding.

After playing some times with the application, I realized that there are great chances of XSS.

So, I found my first simple stored XSS by uploading html file because there is a feature which allow users to upload html file and sharing it with others (team members).

Then, I found my second stored XSS in report feature, which allows me to create a report with html resulted in stored xss.

I earned $450 for my submission on @Bugcrowd #ItTakesACrowd #BugBounty pic.twitter.com/JoLkSLeNPj

— Anas Mahmood 🇵🇰 (@AnasIsHere) October 6, 2019

Then, I found my third Reflected XSS in a parameter (href).

Wait...

It was not easy, I spent time on each vulnerability, because the application allow HTML at certain endpoints but there were strong filters in place.

In Reflected XSS case,

There was an 'href' parameter in a URL, so I just changed the href parameter  value to http://evil.com and it's shows a link in response and it's reflected inside anchor tag in href attribute [<a href="reflection">Link</a>]
So, I changed the value to javascript:prompt(0) & jaVascript://evil.com & other protocols but it was not allowed, only url with 'http' was allowed then I tried to break the href param with double quotes like this http://evil.com/"> but it was also not possible to break the href attribute so first I was thinking that there is no XSS then I again carefully inspected the Source code and DOM by Ctrl+U and Ctrl+Shft+I and saw that the keyword was also reflecting inside javascript so without wasting a single minute, I entered the payload ['-confirm(3)-'] in href param value like this [href=http://evil.com'-confirm(3)-'] and Boom, XSS fired in the browser.

I spent approx 2-3 hours on finding the above vulnerabilities.

After that, I took a little break and thought to stop hunting and take some rest.

After a few minutes, I changed my mind  "Don't stop & Keep going", so I again turned on my laptop and started to look for XSS at multiple places and found six more XSS. Now I'm sharing three most exclusive findings.

Stored XSS in Web Link

There was a feature which allow users to add URL, and other users can view the URL(like website url in the profile page), so I entered javascript:prompt(4) in the url field & the site showed some error "URL must start with http or https" so it was not allowed to start the URL with any other protocol. So I entered http://evil.com in the url field and click on Submit then intercepted the request with Burp & changed the url from http://evil.com to javascript:prompt(3) and it was successful.

Then, I saw that that the payload becomes xxxxxxxxx:prompt(3) means [javascript] replaced to [xxxxxxxxx] and at that time, I was like that

So, I again repeated the steps and changed the url to jaVasCript:prompt(4) and nothing happened with the uppercase so after trying some payloads with encoding I figured out the payload ie [jaVascript&colon;confirm(3)]. 

The steps were:

Entered the valid url http://evil.com in URL field and clicked on Submit.

Intercepted the request with Burp and changed http://evil.com to jaVascript&colon;confirm(3).

Forwarded the request and turned off the intercept.

Clicked on the link, XSS Successfully executed.

After they fix the issue, I found the bypass.

Bypass:
I had repeated the previous steps and changed the url to [http://evil.com/"><script>alert(3)] and saw the url in response which is [http://evil.com/&quot;&gt;alert(3)] means it's stripping the [<script>] tag so the final payload becomes [jaVascript<script>:confirm(3)] and it was successful and bypassed the previous patch.

Stored XSS in Messages

The application had different roles for users, high to low privilege.

For example: 
Instructor(high privilege/admin)
Student(low privilge)
& 
More.

There was a message feature which allow students to message instructors & instructors to message students with HTML so I sent a message with multiple payloads like 
[<a href="javascript:alert(1)">Click Me</a> OR <a href="http://evil.com" onevent=XSS >Click Me</a> etc.] 
from student(low) to instructor(high) but nothing happened because the javascript ,<script> tag along with the event handler got filtered. I tried almost everything from encoding to bunch of payloads but nothing worked and I was thinking that it's not vulnerable anymore.

After that, I repeated the same steps and sent the message with the payload like [<a href="javascript:alert(1)">Click Me</a>]  from instructor to student account and it was successful. So, instructor can perform XSS attack on students by sending a message and the report was rated as P3.

Stored XSS in User Email

It's my special finding which was rated as P2. I found an stored XSS in users email through which student(low) can perform Cross Site Scripting attack on Instructor(High).

Instructor (high) can view all team members including student(low)

by Name and Email and can edit the role and remove the members in settings.

At that time I thought, previously I found an XSS with the payload in the name field and it's got triggered in admin account.

So, I changed the student account name to something evil with the payload but nothing happened due to proper input sanitization so the name field was not vulnerable anymore.

Then, I was thinking it's not vulnerable because there is only way to XSS by changing Name.

I asked myself, what about email?

If we change the email to something evil maybe it's possible to XSS with the email.

So, whenever I enter some special characters in the email field, the site says that it's not allowed.

So, I just entered hacker@mail.com and clicked on Save and intercepted the request with burp & changed it to [hacker@mail.com"> ontest="test"] and it was changed successfully.

I quickly checked the student email from instructor account and saw that hacker@mail.com" ontest="test" in email and [<a href="mailto:hacker@mail.com" ontest="test">hacker@mail.com" ontest="test"</a>] in source code.

So, I quickly repeated the steps and changed the email to hacker@mail.com" onmouseover="prompt(3)" and checked the response from instructor account, onmouseover=prompt(3) replaced to xxxxxxxx=prompt(3).

I repeated the steps multiple times and tried a number of payloads with different encoding but nothing worked and I was like that

After that, I took a deep breath and drunk some water then I traced my steps by following previous step and I got an idea that the application strips an angle bracket, so the final payload becomes [hacker@mail.com" <onmouseover>="confirm(1)"] and when I moved the mouse cursor on student email from instructor account to check the code, XSS fired.

Takeaways


Always, check the reflection everywhere in Source code and in DOM and note the total number of reflections and where it's reflecting in response.

Don't worry if u get some errors like 'not allowed', just enter the allowed characters and submit the request then intercept the request with burp and modify it.

Also check with different privileges of account because sometimes the application doesn't sanitize user input on higher privilege.

Inspect carefully that what is reflecting and what characters are stripping and note the response and craft the payload accordingly.

Thanks for reading.


I hope you like this sharing.

Have a nice day.

Happy Hacking!