Nextcloud 35.0.0 — das Secret für föderierte Freigaben ist ein nicht eingeschränktes App-Passwort für den gesamten Dateibaum des Teilenden
abraxaslabs.tech · github.com/abraxas · @abraxas_null · [email protected] · nextcloud-federated-ocm-token
Nextcloud Server 35.0.0 - Nextcloud GmbH
Ein föderiertes Share-Secret wird als unscoped PERMANENT_TOKEN-App-Passwort für den Sharer erzeugt. Die Empfänger-API gibt es als refresh_token zurück. Wird es als Bearer auf dem WebDAV des Senders wiederverwendet, meldet es sich als der Sharer an und liest Dateien, die niemals geteilt wurden.
Ein böswilliger Akteur, mit dem du eine einzige Datei föderiert teilst, kann sich als du auf deinem Nextcloud anmelden, 2FA umgehen und alle deine Dateien lesen oder überschreiben, nicht nur die eine, die du geteilt hast.
| ID | noch keine CVE |
| CWE | CWE-269, CWE-287 |
| CVSS | Kritisch: 8.1 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N (föderierter Empfänger). Public-Link-Convert ist schlimmer (kein Empfänger-Konto auf einem Peer). |
| Produkt | Nextcloud Server |
| Betroffen | 35.0.0 (da02f41) offizielles nextcloud:35.0.0-apache |
| Auth | föderierter Empfänger (oder Public-Link-Konverter) |
| Lizenz | GNU Affero GPL v3.0 |
| Lab | nur 127.0.0.1 |
Du teilst eine Datei oder einen Ordner mit bob auf einem anderen Nextcloud. Nextcloud erzeugt ein 32-stelliges Secret, speichert es als dein App-Passwort und übergibt dieses Secret an Bob als refresh_token.
Bob (oder jeder, der deinen öffentlichen Link in ein föderiertes Share umwandelt) kann dann:
Sie erhalten keine PHP-Shell auf dem Host. Sie benötigen nicht dein Passwort. Akzeptiere das Share nicht und rufe nicht zuerst OCM access-token auf: Dieser Austausch sperrt den Dateisystem-Scope. Das Lab beweist das Pre-Exchange-Secret.
Ein Share soll ein Share sein. Eine Datei. Ein Ordner. Ich habe FederatedShareProvider::createFederatedShare auf Tag v35.0.0 gelesen. Es erzeugt ein 32-stelliges Secret als IToken::PERMANENT_TOKEN für den Sharer ohne Scope. PublicKeyToken::getScopeAsArray setzt standardmäßig SCOPE_FILESYSTEM => true. Das ist ein App-Passwort. Session::tryTokenLogin akzeptiert ein permanentes Bearer.
Die OCM-Exchange-Arbeit (PR #57234 / #57166) sperrt den Dateisystem-Scope bereits nach dem ersten Austausch. Ein inoffizieller Writeup nutzte diesen Post-Exchange-Hop. Ich habe es zuerst damit versucht. In diesem Tree ist das ausgetauschte Token TEMPORARY, benannt OCM Access Token, und /remote.php/dav lehnt es ab (allowOcmAccessToken false). DAV sagte nein.
Also habe ich nicht ausgetauscht. ocm_discovery_enabled blieb false, damit der Empfänger es nicht für mich austauscht. Zwei offizielle nextcloud:35.0.0-apache-Boxen, overwrite.cli.url als Docker-DNS (http://sender / http://recipient). Lass das auf 127.0.0.1 und S2S spricht mit sich selbst.
Alice teilt eine Datei mit bob@http://recipient. Bob liest ausstehende Shares. refresh_token Länge 32. access_token Länge 0. Unauthentifizierter Bearer-GET auf Alices private Witness-Datei, die nie im Share war, lieferte 200, X-User-Id: alice.
cd lab
./run.sh
Ziel nur http://127.0.0.1:18340 (Sender) und :18341 (Empfänger).
SUCCESS NEXTCLOUD-OCM-PERMANENT-TOKEN who=federated-recipient uid=alice NEXTCLOUD-OCM-PERMANENT-TOKEN-WITNESS
Erzeuge das föderierte Secret mit Dateisystem-Scope false ab dem ersten Insert. Akzeptiere dieses Secret nicht als Bearer/Basic auf /remote.php/dav. Der erste Austausch sperrt bereits den FS-Scope; create hätte niemals ein App-Passwort herausgeben dürfen.
GNU Affero GPL v3.0. Siehe LICENSE. Nur Loopback-Lab. Keine Gewährleistung.