CVE-2024-37010

Exploit für CVE-2024-37010: Zugriff auf externen Speicher anderer Benutzer & Lateral Movement:

https://www.cert.ssi.gouv.fr/avis/CERTFR-2024-AVI-0753/

https://owncloud.com/security-advisories/insecure-direct-object-reference-in-external-storage

Einleitung

Owncloud verwandelt einen Server in eine Cloud zum Speichern von Dateien, ähnlich wie Google Drive. Das ermöglicht es Unternehmen beispielsweise, eine Cloud für Mitarbeiter bereitzustellen, ohne dass diese von einem Dritten verwaltet wird.

Wenn Administratoren es entsprechend konfiguriert haben, können Benutzer auch externen Speicher wie andere Clouds, FTP oder Google Drive verbinden, um Dateien auf einer einzigen Cloud zu zentralisieren und den Benutzern so das Leben zu erleichtern.

Sobald wir unseren externen Speicher erstellt haben, können wir dieses Formular aktualisieren, um beispielsweise das Feld „Ordnername“ zu ändern. Wenn das Formular aktualisiert wird, wird eine Anfrage mit dem gesamten Formular im JSON-Format gesendet. In diesem Formular ist das Feld „ID“ als Ganzzahl die Kennung unseres externen Speichers, die vom Server bei der Erstellung des Speichers generiert wurde.

2. Idor Idor

Stellen wir uns vor, dass ein anderer Benutzer in Owncloud, beispielsweise der Administrator, ebenfalls einen externen Speicher mit der ID „18“ hat.

Führen wir nun die Formularaktualisierungsanfrage als Benutzer „normal_user“ ohne besondere Rechte erneut aus, ändern jedoch die ID auf 18, den externen Speicher des Administrators.

1. Geben Sie die Admin-Speicher-ID ein.
2. Legen Sie einen beliebigen Speichernamen „storage_pwned“ fest.
3. Um sicherzugehen, geben wir auch einen beliebigen Host an, in diesem Fall einen Burp Collaborator. Wichtiger Hinweis: Das Ändern des Hosts ist nicht zwingend erforderlich. Das Ändern des Hosts bedeutet, dass die Speicherkonfiguration unterbrochen wird und der Owncloud-Server keine Dateien mehr vom ursprünglichen Speicher abrufen kann.

Sobald die Anfrage gesendet wurde, erhält der Server einen 404-Fehler (4) und teilt uns mit, dass er keinen Speicher mit der von uns angegebenen ID gefunden hat (5).

Wenn wir uns jedoch mit dem Admin-Konto verbinden, sehen wir Folgendes:

Der Speicher des Administrators wurde aktualisiert.

• Der Speichername wurde in „storage_pwned“ geändert.
• Der Host wurde durch die Adresse des Collaborators ersetzt.
• Und am wichtigsten: Der Benutzer „normal_user“ wurde zu den Benutzern hinzugefügt, die auf den Speicher zugreifen dürfen.

Wenn wir uns wieder als „normal_user“ anmelden, sehen wir, dass wir jetzt Zugriff auf „storage_pwned“, den Speicher des Administrators, haben.

Benutzer A hat es geschafft, den Speicher von Benutzer B zu aktualisieren und wieder Zugriffsrechte darauf zu erlangen. Wir erinnern daran, dass Benutzer A den Host während der Aktualisierungsanfrage NICHT ändern darf, um die Konfiguration von Benutzer B nicht zu unterbrechen und dann auf die Dateien des Letzteren zugreifen zu können.

Hier ist der Code, der zum Aktualisieren des externen Speichers verwendet wird.

Zunächst einmal sehen wir, dass keine Überprüfung der Rechte des Benutzers stattfindet, der die Anfrage gerade gestellt hat. Der Code prüft nicht, ob der Speicher dem anfragenden Benutzer gehört. Dies erklärt, warum „normal_user“ den Speicher des Administrators aktualisieren konnte.

Zweitens sehen wir, dass der Code bei jeder Aktualisierung den Benutzer, der die Anfrage gerade gestellt hat, zu den Benutzern hinzufügt, die für die Verbindung mit dem Speicher autorisiert sind, was erklärt, warum „normal_user“ nach der Aktualisierung auf magische Weise Zugriff auf den Speicher des Administrators erhielt.

Zusammenfassung

In diesem Beispiel haben wir gesehen, wie es einem Benutzer möglich war, vollständigen Zugriff auf den externen Speicher eines anderen Benutzers zu erlangen und so Zugriff auf dessen persönliche Dateien zu erhalten. Dies macht sie bereits zu einer ziemlich kritischen Schwachstelle.

3. Noch weiter...

Wie Sie sehen, ist dieser IDOR (Insecure Direct Object Reference) bereits eine schwerwiegende Schwachstelle. Versuchen wir jedoch, sie weiter auszunutzen, um die potenziellen Auswirkungen zu erhöhen.

Dazu wollen wir den Authentifizierungsprozess verstehen, den der Owncloud-Server für externen Speicher durchführt, um Dateien abzurufen. Bei grundlegenden Authentifizierungssystemen, die ein einfaches Login/Passwort-Paar verwenden, wird der Cloud-Server einfach

Stellen wir uns nun vor, dass ein Angreifer diese Konfiguration aktualisiert, indem er den Host auf eine von ihm kontrollierte Adresse ändert. Das bedeutet, dass der Owncloud-Server nun Anmeldeinformationen an diese neue, vom Angreifer kontrollierte Adresse sendet.

Genau das können wir dank unserer Schwachstelle tun.

Wenn wir die Aktualisierungsanfrage wiederholen und die Speicher-ID eines anderen Benutzers angeben, müssen wir lediglich den Host ändern, indem wir beispielsweise unseren Burp Collaborator angeben.

Auf diese Weise versucht der Owncloud-Server, wenn der Benutzer erneut eine Verbindung herstellt, sich bei unserem Collaborator zu authentifizieren, indem er ihm die Anmeldeinformationen des Benutzers sendet.

Auf magische Weise empfängt der Collaborator die Authentifizierungsanfrage vom Owncloud-Server mit den Base64-kodierten Anmeldeinformationen.

Wir haben soeben die Klartext-Anmeldeinformationen des externen Speichers des Administrators abgerufen.

Ein kleiner Extra ...

Für die Authentifizierung an einem externen Speicher können Sie Ihre eigenen Owncloud-Anmeldeinformationen verwenden, um sich anzumelden, wenn Sie beispielsweise dasselbe Passwort verwenden. Wenn Sie eine Aktualisierung des externen Speichers anfordern, können Sie im Feld „authMechanism“ den Wert „password::sessioncredentials“ angeben.

Der Owncloud-Server speichert dann unsere Anmeldeinformationen beim nächsten Verbindungsaufbau im Klartext und überträgt sie zur Authentifizierung an unser externes Speichergerät.

Sie sehen also, worauf das hinausläuft ...

Das bedeutet, dass ein Angreifer diesen Mechanismus auch für den externen Speicher eines anderen Benutzers aktivieren und so die Klartext-Anmeldeinformationen der Owncloud-Sitzung des Opfers an einen von ihm kontrollierten Host übertragen kann, wie wir es gerade getan haben.

4. Risikozusammenfassung

CVE-2024-37010 ermöglicht es einem Angreifer mit einem Konto auf einem Owncloud-Server daher:

• Lese-/Schreibzugriff auf Dateien in externen Speichern anderer Benutzer zu erhalten.
• Klartext-Identifikatoren für verbundene externe Speichergeräte zu erhalten.
  • Weiterleitung zu externen Speichern.
• Unverschlüsselte Owncloud-Konto-Anmeldeinformationen für Benutzer mit externem Speicher zu erhalten.
  • Account-Übernahme & Privesc.

Chronologie

• 03/11/2024 - Sicherheitslücke entdeckt
• 12/03/2024 - Bericht an Owncloud gesendet
• 09/09/2024 - Öffentliche Bekanntgabe & CVE von Owncloud