Hi, I’m Anderson a.k.a (and0x00). Today, I will share the experience of searching for and finding a vulnerability in Microsoft. I intend to provide some insights in this writeup for those who also wish to get into a Hall of Fame or perhaps even earn some good dollars. This article will also be available on my website and personal archive at https://and0x00.com, follow me!
For some time now, I have been following the global Bug Bounty scene and started to wish to enter the Hall of Fame of large organizations just like the security writers I’ve been reading. Without a doubt, this is an excellent way to showcase your ability to identify and exploit threats, as well as prove to yourself. So, with some courage, I decided to take some time to look into Microsoft’s domains.
Do not be mistaken, searching for vulnerabilities in organizations that understand security risks is a laborious process. It requires determination, persistence, and yes, a bit of luck. It’s important to be sharp and know what to do when the opportunity arises. Being familiar with as many vulnerabilities as possible, as well as understanding unique and out-of-the-box scenarios in which they might occur, significantly increases your chances of success.
Test the most common scenarios, but also think and simulate challenging scenarios that, if they occur, the vulnerability could be exploited in much the same way. Understand your tools, know exactly what they are doing, and understand the limits of your tests so you can perform complementary tests. Remember, sometimes a simple cookie or header makes the difference for a successful exploit.
With that said, let’s get to the point!
After a long time of mapping and frustrated testing, I ended up at xxxxx.microsoft.com. The site was nothing special; it was a standard page from the main microsoft.com domain with a header, a login button, and many pages. Reviewing the source code of the page, the amount of JavaScript content, both written and being loaded, was notable.
I analyzed the pages of the site for a while, checking if any text present in the URL was being reflected in the source code of the page and yes, many occurrences. I tested each one of them, and a snippet similar to this was being loaded without the proper sanitization of the myURL variable that reflected the URL.
card = $('.user-profile-card', this);
if (!card.hasClass('loading')) {
card.addClass('loading');
myURL = 'https://xxxxx.microsoft.com/?test'-alert(document.domain)-'payload=1;
myData = {
'userId': userIdValue,
'currentPageURL': myURL
};
...That was exactly what I was looking for! After some adjustments to the payload, I had a valid RXSS!
Timeline of the report:
May 10, 2023: Reported the vulnerability.
May 17, 2023: Vulnerability confirmed.
May 31, 2023: Added to the Hall of Fame.
Thank you for reading my article! Have a great day and see you next time!
