How Almost Sacrificing a University Group Project led to a Microsoft Bug Bounty

By: Alex Bryant, Aditya Dindi, and Eric Esquivel

Eric and Aditya got together to work on their group project for their business class at university. Their team for the project included other people, and the way which a lot of university and high school students communicate is through a platform called GroupMe. GroupMe is a mobile and web group messaging app owned by Microsoft, with millions of registered users.

While looking around GroupMe, they got curious and 25 minutes later, wallah, an alert box appeared on their screens proving a Stored Cross-Site Scripting (XSS) vulnerability. Afterwards a close friend, Alex, joined and together they proceeded to escalate the vulnerability and successfully performed Cross-Site Request Forgery (CSRF) and postponed the group project.

Cross-Site Scripting (XSS) is a type of attack where malicious JavaScript is injected in web applications and it is executed on user’s browsers. There are 3 types of XSS attacks: Reflected, DOM, and Stored.

Reflected XSS is a vulnerability where the injected JavaScript reaches the back-end server and gets returned to the user without being filtered or sanitized.

Stored XSS occurs when user input is stored on the target server and then a victim retrieves the stored data where the malicious JavaScript is executed in their browser.

DOM XSS or Document Object Model XSS occurs when the injected JavaScript is used to change the page source through the DOM.

Cross-Site Request Forgery (CSRF) is an attack where an attacker is able to perform and execute requests on behalf of the authenticated victim.

When a message is sent in GroupMe, the recipient receives a “message request”. This is a preview message where the recipient can either accept or deny a message. When a message is accepted, it becomes a full chat where the users can send messages back and forth.

This is extremely important to know because when HTML and JavaScript was sent through as a message request, it was improperly being sanitized. As long as the user never accepts or denies the message request, an attacker is able to continuously send unsanitized HTML and JavaScript to the victim.

Figure 1: Sending the malicious JavaScript payload to the Victim-Account userFigure 2: Receiving the malicious JavaScript payload message from the Attacker-Account userFigure 3: Malicious JavaScript is executed on the Victim-Account’s Browser

Before knowing the specifics, Eric was able to pop an alert box on Aditya’s browser, but after Aditya accepted the message request to reply with his own payload, they were not able to perform XSS anymore as the full chat messages are properly sanitized. Alex quickly identified that the reason it worked the first time around was because it was a message request, and not a full chat where the sanitization was different. From here, we created additional accounts and made sure to not accept the messages so we could keep testing.

We quickly created 2 simple XSS payloads:

Redirect victims to different webpage like the signout page, for example.Remove the accept box from the user’s screen as soon as they read the message request so that they couldn’t mitigate the threat.

However this wasn’t enough. We wanted to take this vulnerability further.

After looking around GroupMe some more, we found that when users enable/disable 2-Factor Authentication (2FA), or change their email, they automatically send their stored X-Access-Token through the web request and are not required to enter their password for verification.

We took advantage of this lack of verification and utilized a XSS payload to grab a user’s token value and performed CSRF by sending a POST request to the GroupMe web servers to change the account’s email address and disable 2FA. After that, we performed a password reset where an email will be sent to the email address we changed it to and completely take over the account.

We created a “master” XSS payload where we were able to perform all of the following in one single message leading to an instant account takeover:

Remove the accept message boxChange the user account’s email address to one of our choosingDisable 2 factor authenticationSign the user out of their account

Stored Cross-Site Scripting

Input filtering: Making sure that any user input is filtered for only expected or valid inputUtilizing Response Headers: Using appropriate response headers can help prevent Cross-Site Scripting by making sure HTTP / JavaScript is not executed when they are in the HTTP responsesContent Security Policy: CSP works by limiting the resources that a page can load

Cross-site Request Forgery

CSRF Tokens: A CSRF token is a value that is generated by the back-end server is shared and checked with the client when the client is performing an action

After finding and exploiting the unsanitised message requests, we were able to perform XSS to CSRF and send requests on behalf of the user as soon as they read our message, leading to immediate account takeover. Overall, there were some hiccups along the way during the review period, but we had a great experience finding and reporting this bug, and it has motivated us to stay curious and find more vulnerabilities like this one. (By the way, we got a 100 on our group project!)

This bug was found by the three independent security researchers listed below:

- Alex Bryant | AlonTheSlay

https://www.linkedin.com/in/awb-alontheslay/

- Aditya Dindi | Pyrus

https://www.linkedin.com/in/adityadindi/

- Eric Esquivel | Agent007

https://www.linkedin.com/in/ericesquivel1/

Microsoft’s Online Acknowledgement Page:
https://msrc.microsoft.com/update-guide/acknowledgement/online

Figure 4: Our public acknowledgements