PUT Based CSRF via Client Side Path Traversal + Cookie Bomb on Acronis Cloud

## Summary Hi team, I found a way to perform **PUT Based CSRF attacks** to unintended paths by using a Client Side Path Traversal in the **Integrations** Component due to lack of sanitation of the GET parameter called **tenantUuid** in the javascript. The vulnerable endpoints are the following, each URL correspond to a different integration: - https://mc-beta-cloud.acronis.com/integration/att/ui/index.html?groupId=690986&tenantUuid=some-uuid - https://mc-beta-cloud.acronis.com/integration/cw/ui/index.html?groupId=undefined&tenantUuid=some-uuid&lang=en&readOnly=false Clarify that despite they are different integrations with different endpoints, both threat the GET parameter in the same way. ## Description Using the normal flow of the application when going to any of the previous URL's it will return a form in the HTML. Once the user had entered the values in the inputs and click in the **Save** button, the javascript will perform the following concatenation to perform the XHR PUT request with the inputs entered in the body: **`https://mc-beta-cloud.acronis.com/api/integration/att/2/partners/{TENANTUUID-GET-PARAMETER}/credentials?version=0`** In the next image you can see it: {F2150914} Since any sanitation of the appended parameter is being done in the javascript, we can craft a custom link containing **path-traversal** in the **tenantUuid** parameter and perform the PUT request to other endpoint. Consider this scenario: An admin go to this link -> **`https://mc-beta-cloud.acronis.com/integration/att/ui/index.html?groupId=690986&tenantUuid=a/a/a/../../../../../../../../api/settings/v1/TENANT/namespaces/com.acronis.partners.company/settings/partner.profile.company/values?`** Enter the **username** and **password** fields requested, and click the **Save** button. Once clicked, a XHR PUT Request will be sent to **`https://mc-beta-cloud.acronis.com/api/settings/v1/TENANT/namespaces/com.acronis.partners.company/settings/partner.profile.company/values?/credentials`**, which is not the intended one. To perform the PUT CSRF Attack in this specific endpoint as I will explain, you need to chain it with other attack to see the HTML Form. However, there are some limitations to have in mind: - We don't have control over the body of the PUT XHR Request. - **The path of the injected PUT request needs to have a different status code from 200 when performing a request with the GET Method**. This is due to when rendering the HTML a previous GET XHR will be made to the endpoint specified in the **tenantUuid** parameter and if the status code is 200 it will not render the form since will thread as if we have already filled it previously. Despite the limitations I managed to create an scenario which can lead to reset the information of your company account field by chaining it with a **cookie bomb** attack to get rid of the restriction of the HTTP Status codes limitation. ## Attack Flow 1. User visits any domain in the scope ***.acronis.com** which URL contains the XSS Payload. This XSS will plant a **cookie bomb** pointing to the CSRF path we want to attack and those cookies will expire in 10 sec, time needed to load the Acronis Cloud page. 2. Once the cookie bomb is planted, a **redirect** to the Acronis Cloud Website with the **Client Side Path Traversal** payload will be made. While the Acronis Cloud website is loading, the GET XHR Request (which is the same endpoint as the PUT which will be sent later by the user) will return a **400 HTTP Code** due to the large number of cookies sent, so the form will be shown. 3. Finally, since we can see the form, the user just need to enter his username and password and click in the Save button, once done it will perform a PUT Request pointing to the endpoint specified in the GET parameter **tenantUuid**. Since the cookies are already expired they will not be sent in this injected PUT XHR Request and will return a **204 HTTP Code**, leading to perform the PUT CSRF attack. In my PoC I used the PUT Based CSRF to reset the **company name ** field of your company information with the endpoint **/api/settings/v1/TENANT/namespaces/com.acronis.partners.company/settings/partner.profile.company/values** as I will show in the video. ## Steps To Reproduce 1- Host this HTML as an example of a subdomain in ***.acronis.com** containing an XSS. ```html <html> <head> <meta charset="utf-8"> <title>Acronis Cloud - PUT Based CSRF</title> <style> body{ background: #00204d; font-family: monospace; font-size: 15px; } .poc{ background: white; width: 500px; padding: 20px 40px; border-radius: 10px; color: #404040; margin: auto; } button{ margin: 10px; background: #3a67a6; color: white; border: none; border-radius: 20px; height: 50px; width: 250px; padding: 8px; font-size: 14px; } </style> </head> <body> <div class=poc> <h1>Acronis Cloud PoC</h1> <hr> <button id='go' onclick="start();">Click to start!</button> </div> <script> function start() { var base_domain = ".acronis.com"; var path = "/api/settings/v1/TENANT/namespaces/com.acronis.partners.company/settings/partner.profile.company/values"; var pollution = Array(4000).join('a'); var date = new Date(); date.setTime(date.getTime() + (10 * 1000)); /* Plant a Cookie Bomb for the Endpoint we want to perform the PUT CSRF Attack. */ for (var i = 1 ; i < 99 ; i++) { document.cookie = 'bomb' + i + '=' + pollution + ';Domain=' + base_domain + ';expires=' + date + ';path=' + path; } var redirect = "https://mc-beta-cloud.acronis.com/integration/att/ui/index.html?groupId=690986&tenantUuid=a/a/a/../../../../../../../../api/settings/v1/TENANT/namespaces/com.acronis.partners.company/settings/partner.profile.company/values?"; window.location = redirect; } </script> </body> </html> ``` 2- Visit the website and check it. In the next video you can see it too: {F2150577} As my previous report in #1777079, I simulated an XSS in the scope ***.acronis.com**, but in this case I edited my **/etc/hosts** file, you can do that in this way or entering the cookie bomb payload in the console while visiting any subdomain (But be careful that the cookies are only valid for 10 seconds in my code). Also, since the integrations component seems a new functionality and as I see in the UI you have planned to add more integrations, if any of those sends in the body of the injected PUT Request some parameter with the same name of other parameters used in other endpoints which may be used to edit information, it may lead to PUT CSRF Attacks in other scenarios/endpoints with more impact. I will keep you updated if I found more endpoints which can be chained with this report too. Finally, I will like to let you know that you can access the mentioned integrations endpoints without being logged in, I do not know if that's the intended behavior or not, but, just in case I let you know it. Let me know if I explained well myself about how to perform this attack. ## Recommendations Integrations uses the same javascript which handles the GET parameters in the same way. You can cast the GET Parameters used in the javascript to just allow **[A-Za-z0-9/]** characters, rejecting in that way performing a path-traversal in the client-side requests. Or directly return an error and don't process the requests. ## Impact Perform PUT Based CSRF attacks to unintended paths on behalf of the victim. In my PoC I chained it with a cookie bomb, but endpoints using the GET Method returning a different status code than 200 may be carried out without needing to chain it with this.