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.
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
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.
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.
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:
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:
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.
Salaam Bhai. Really amazing hack !Motivates me much
ReplyDeleteGreat Find!
ReplyDeleteAwesome
ReplyDelete