ApostropheCMS: Nicht authentifizierte Ressourcenerschöpfung über pre-auth aposBigUpload-Verarbeitung in @apostrophecms/import-export

Zusammenfassung

Eine potenzielle Denial-of-Service-Schwachstelle durch nicht authentifizierte Anfragen besteht im Upload-Pfad für gestückelte Importe (Chunked Uploads), der von @apostrophecms/import-export genutzt wird.

Die betroffenen Import-API-Routen rufen:

self.apos.http.bigUploadMiddleware()

auf, bevor die eigentliche Import-Behandlungsroutine ihre Authentifizierungsprüfung vornimmt.

Da an bigUploadMiddleware() kein authorize-Callback übergeben wird, können nicht authentifizierte Anfragen die Operationen aposBigUpload start, chunk und end erreichen, bevor die nachgelagerte req.user-Prüfung den Import ablehnt.

Infolgedessen kann ein nicht authentifizierter entfernter Angreifer serverseitigen Upload-Status erzeugen, Chunk-Daten in den Upload-Speicher schreiben, die Verarbeitung temporärer Dateien anstoßen und vom Angreifer gesteuerte Bereinigungsoperationen auslösen, noch bevor die Authentifizierung erzwungen wird.

Betroffene Komponente

Paket:

@apostrophecms/import-export

Bestätigte betroffene Version:

3.6.2

Potenziell frühere betroffene Versionen:

Das Problem kann frühere 3.x-Versionen betreffen, in denen die aktuelle auf Big-Upload basierende Import-Implementierung vorhanden ist. Die genaue Einführungsversion wurde noch nicht vollständig verifiziert; es wird empfohlen, dass die Maintainer den betroffenen Versionsbereich bestätigen.

Schwachstellentyp

Primär:

CWE-400 — Unkontrollierter Ressourcenverbrauch

Verwandt:

CWE-306 — Fehlende Authentifizierung für kritische Funktion

CWE-770 — Ressourcenzuweisung ohne Limits oder Throttling

Technische Details

Die Route für den Seitenimport registriert die folgende Middleware-Kette:

packages/import-export/modules/@apostrophecms/import-export-page/index.js

importExportImport: [
  self.apos.http.bigUploadMiddleware(),
  async (req) => {
    return self.apos.modules['@apostrophecms/import-export']
      .import(req, self.__meta.name);
  }
]

Es wird kein authorize-Callback an bigUploadMiddleware() übergeben.

Die Implementierung von bigUploadMiddleware() unterstützt explizit einen authorize-Callback und führt diese Autorisierung vor der Verarbeitung des aposBigUpload-Protokolls durch, sofern bereitgestellt.

Ohne diesen Callback werden Anfragen, die Folgendes enthalten:

aposBigUpload[type]=start

aposBigUpload[type]=chunk

oder

aposBigUpload[type]=end

sofort verarbeitet.

Die eigentliche Authentifizierungsprüfung erfolgt erst später in:

packages/import-export/lib/methods/import.js

async import(req, moduleName) {
  if (!req.user) {
    throw self.apos.error('forbidden');
  }

Dies bedeutet, dass die Authentifizierung erst stattfindet, nachdem die Middleware für Chunked-Uploads bereits serverseitige Arbeiten ausgeführt hat.

Angriffsablauf

1. Start

Ein nicht authentifizierter Angreifer sendet eine aposBigUpload[type]=start-Anfrage.

Der Server generiert eine Upload-ID und speichert die vom Angreifer bereitgestellten Upload-Metadaten, einschließlich des deklarierten chunks-Zählers.

2. Chunk

Der Angreifer kann Chunk-Daten hochladen.

bigUploadChunk() kopiert vom Angreifer kontrollierte Daten nach:

/big-uploads/<id>-<n>-<chunk>

3. Ende

Der Angreifer sendet eine aposBigUpload[type]=end-Anfrage.

bigUploadEnd() beginnt mit der Verarbeitung des Uploads und erstellt temporäre Dateien, bevor der nachgelagerte Import-Handler aufgerufen wird.

Erst nach Abschluss dieser Verarbeitung erreicht die Ausführung die spätere Authentifizierungsprüfung in import().

4. Bereinigungsverstärkung (Cleanup Amplification)

Der vom Angreifer kontrollierte Wert chunks wird auch von bigUploadCleanupOne() verwendet:

for (const { chunks } of Object.values(bigUpload.files)) {
  for (let i = 0; (i < chunks); i++) {
    await ufs.remove(...);
  }
}

Bei der Upload-Initialisierung scheint keine niedrige Obergrenze für die deklarierte Anzahl an Chunks erzwungen zu werden.

Dadurch kann ein nicht authentifizierter Angreifer die Anzahl der Dateisystem-Bereinigungsoperationen erhöhen, die für einen Upload durchgeführt werden.

Proof of Concept

Die folgende Reproduktion wurde ausschließlich in einer isolierten Testumgebung durchgeführt.

Upload ohne Authentifizierung starten

curl -s -X POST \
  'http://localhost:3000/api/v1/@apostrophecms/page/importExportImport?aposBigUpload[type]=start' \
  -H 'Content-Type: application/json' \
  --data '{"files":{"file":{"name":"evil.tar.gz","size":4,"type":"application/gzip","chunks":1}}}'

Der Server gibt eine Upload-ID zurück, obwohl die Anfrage keine authentifizierte Sitzung besitzt.

Einen Chunk hochladen

printf 'PWN!' >/tmp/chunk.bin

curl -s -X POST \
  'http://localhost:3000/api/v1/@apostrophecms/page/importExportImport?aposBigUpload[type]=chunk&aposBigUpload[id]=<ID>&aposBigUpload[n]=0&aposBigUpload[chunk]=0' \
  -F 'chunk=@/tmp/chunk.bin;type=application/octet-stream'

Die Anfrage ist erfolgreich und führt dazu, dass serverseitiger Upload-Speicher belegt wird.

Den Upload abschließen

curl -i -X POST \
  'http://localhost:3000/api/v1/@apostrophecms/page/importExportImport?aposBigUpload[type]=end&aposBigUpload[id]=<ID>'

Beobachtetes Verhalten:

• start liefert HTTP 200 und eine Upload-ID ohne Authentifizierung zurück.
• chunk liefert HTTP 200 zurück und führt zur serverseitigen Speicherung des Chunks.
• end erreicht schließlich die nachgelagerte Authentifizierungsprüfung und wird abgewiesen.
• Die serverseitige Big-Upload-Verarbeitung fand jedoch bereits vor dieser Zurückweisung statt.

In der isolierten Testumgebung:

• chunks=1 führte zu einem Bereinigungsversuch.
• chunks=50 führte zu 50 Bereinigungsversuchen.

Dies zeigt, dass die vom Angreifer kontrollierte Chunk-Anzahl den Umfang der serverseitigen Bereinigungsarbeiten direkt beeinflusst.

Sicherheitsauswirkungen

Die Schwachstelle ermöglicht es einem nicht authentifizierten Remote-Angreifer, serverseitige Speicher- und Dateisystemoperationen zu veranlassen, die nur für autorisierte Import-Benutzer zugänglich sein sollten.

Mögliche Folgen sind:

• Verbrauch von Upload- und temporärem Speicherplatz.
• Erzeugung von serverseitigem Upload-Status durch nicht authentifizierte Benutzer.
• Wiederholte Dateisystem-I/O.
• Bereinigungsverstärkung basierend auf angreifergesteuerten Chunk-Zahlen.
• Potenzielle Dienstbeeinträchtigung oder Denial-of-Service bei wiederholtem oder ausreichend verstärktem Angriff.

Ursache

Die Authentifizierung wird erst im nachgelagerten Import-Handler erzwungen und nicht vor der Chunked-Upload-Middleware.

Die Middleware selbst unterstützt bereits einen authorize-Callback, der speziell dafür vorgesehen ist, die unautorisierte Nutzung der Big-Upload-Funktionalität zu verhindern.

Empfohlene Behebung

Authentifizierung vor der Verarbeitung jeder aposBigUpload-Operation vorschreiben.

Beispielsweise:

• Einen geeigneten authorize-Callback an bigUploadMiddleware() auf allen Import-Routen übergeben.
• Nicht authentifizierte Benutzer vor start, chunk oder end abweisen.
• Angemessene Obergrenzen für deklarierte Chunk-Zahlen durchsetzen.
• Deklarierte Größen gegen die tatsächlich hochgeladenen Daten validieren.
• Speicher- und Ratenbegrenzungen pro Benutzer sowie global einführen.
• Sicherstellen, dass temporäre Dateien entfernt werden, wenn die nachgelagerte Verarbeitung fehlschlägt.
• Regressionstests hinzufügen, die bestätigen, dass anonyme Anfragen für start, chunk und end abgewiesen werden, bevor Upload-Status oder Dateien angelegt werden.

Relevanter geprüfter Commit:

d3ff8c9bb001be1acf7fdc3f035190250ac64b45

Danksagung an Forscher

Kai Zhi

GitHub:

https://github.com/kaizhi888