Skip to main content

How I Pwned a company using IDOR & Blind XSS

This post is about exploiting Blind XSS and IDOR to gain access to company's Slack, Facebook Workplace and other services used by the company.

Special Thanks to Inti De Ceukelaire without his disclosure this would not have been possible.

And also thanks to my friend Harsh Jaiswal for giving some ideas.

Most of the people from infosec community must have read the disclosure by Inti De Ceukelaire regarding Ticket Trick, if you have not read I would suggest reading that first. ( https://medium.freecodecamp.org/how-i-hacked-hundreds-of-companies-through-their-helpdesk-b7680ddc2d4c )

After reading the article, first thing came to my mind was exploiting this on a company as it had similar functionality on Support Tickets.

The company's website had a Support Portal. We could create a Ticket by sending an email.

Exploiting Ticket Trick to gain access to company's Slack or Facebook Workplace was not possible as Slack and Facebook included a random token while sending verification or forgot password emails.

But there was a Blind XSS in company's internal domain from where they managed the tickets and an IDOR to View any user's ticket using both the vulnerabilities, I was able to access the company's Slack, Facebook Workplace.


IDOR to View Any Support Ticket:


There was a GET request in the Mobile application which allowed to view support tickets of any user by changing the Ticket ID.

GET /api/param?param=XXXXXXXXXXXXXXXXXXXXX HTTP/1.1
Host: company.com
Connection: close
Accept: application/json, text/javascript
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0
Accept-Language: en-IN,en-US;q=0.8
Cookie: x

The Ticket ID, however, included 12-13 random numbers, so bruteforcing it would have taken a lot of time.

So we still needed to find the Ticket ID.

The IDOR was reported 1 month back was not fixed :P



Blind XSS:


We could create a support ticket by sending an email to support@company.com.

The company then manages the Tickets from an internal domain.

The input fields sent from the email was not sanitized on their internal domain.

I created a ticket by sending an email with XSS payload.
When the ticket was viewed by support staff XSS was triggered on their internal domain.

I had used XSS Hunter to test this Blind XSS, XSS Hunter also captures the DOM of the entire page where the XSS is executed.

The DOM contained all recently created Ticket IDs.

The Blind XSS was also reported a month back and was marked as Not Applicable as the domain where XSS was executed was an internal domain and not mentioned in the scope.



Chaining both the issues:


I sent a password reset link to support@company.com at https://company.slack.com/forgot.
This resulted in the creation of a ticket by no-reply-randomtoken@slack.com.

Immediately after sending the password reset link to Slack, I sent an email to support@company.com with Blind XSS Payload.

After some time the Blind XSS was executed, I received the DOM of the page.

The DOM contained Ticket ID of the email sent from no-reply-randomtoken@slack.com.



Using the IDOR, I was able to View the Ticket which surprisingly contained registration links of 8 Slack Channels of the Company.

Similarly, Company's Facebook Workplace could have been accessed.

This was also marked Not Applicable by the company but was rewarded with the company's minimum bounty amount.

Comments

Post a Comment

Popular posts from this blog

Exploiting a Single Request for Multiple Vulnerabilities

Hello Everyone,

This is my first blog post, it's about multiple security vulnerabilities found from a single request on a private program recently.

The vulnerabilities found are simple Stored and Reflected XSS, SSRF and Command Injection.

But since I have never written any pocs before, so just wanted to write about this one.

So let's call the website as privatesite.com

After login, the first thing I saw was a feature to upload images.

So started testing the uploader functionality, like directly uploading PHP, SWF, SVG, etc., but nothing worked as the uploader looked secured from my end.

Then I noticed there is a feature to crop the image, the post request of this feature looked kind of interesting.

1. SSRF
There was a parameter http_path which had the image URL, so I fired up a socket listening to a port on my server, and in that http_path parameter I put my server's IP and port, and the socket received the connection.

So an external SSRF was confirmed.

2. Stored XSS
On t…