Gitblit Embedded SSH Auth Bypass (CVE-2024-28080)

Summary

CVE-2024-28080 ist ein authentication bypass im embedded SSH‑Service von Gitblit, verursacht durch falsche Handhabung des Sitzungszustands bei der Integration mit Apache MINA SSHD. Wenn ein Benutzerkonto mindestens einen SSH public key registriert hat, kann ein Angreifer, der den Benutzernamen und einen der public keys dieses Benutzers kennt, sich ohne privaten Schlüssel und ohne Passwort authentifizieren.

Affected: Gitblit < 1.10.0 (beobachtet in 1.9.3)
Fixed: 1.10.0
Requirements to exploit:
Git over SSH auf der Instanz aktiviert
Das Opferkonto hat mindestens einen SSH public key in Gitblit registriert
Angreifer kennt den Benutzernamen des Opfers und einen seiner public keys (oft auffindbar, z.B. https://github.com/.keys)

Root cause (state leaks between SSH methods)

In RFC 4252 verläuft die public‑key authentication in zwei Phasen: Der Server prüft zuerst, ob ein bereitgestellter public key für einen Benutzernamen akzeptabel ist, und erst nach einem Challenge/Response mit einer Signatur authentifiziert er den Benutzer. In MINA SSHD wird der PublickeyAuthenticator zweimal aufgerufen: beim Key‑Acceptance (noch keine Signatur) und später, nachdem der Client eine Signatur zurücksendet.

Der PublickeyAuthenticator von Gitblit veränderte den Sitzungskontext beim ersten, pre‑signature Aufruf, indem er das authentifizierte UserModel an die Session bindete und true zurückgab ("key acceptable"). Wenn die Authentifizierung später auf Passwort zurückfiel, vertraute der PasswordAuthenticator dem veränderten Session‑Zustand und machte einen Short‑Circuit, indem er true zurückgab, ohne das Passwort zu validieren. Infolgedessen wurde nach einer vorherigen public‑key "acceptance" für denselben Benutzer jedes Passwort (einschließlich leerer) akzeptiert.

Fehlerhafter Ablauf (auf hoher Ebene):

Client bietet username + public key an (noch keine Signatur)
Server erkennt den Key als zum Benutzer gehörig, bindet vorzeitig den Benutzer an die Session und gibt true zurück ("acceptable")
Client kann nicht signieren (kein private key), daher fällt die Auth auf Passwort zurück
Password auth sieht bereits einen Benutzer in der Session und gibt bedingungslos Erfolg zurück

Step‑by‑step exploitation

Sammle den Benutzernamen des Opfers und einen seiner public keys:
GitHub stellt public keys unter https://github.com/.keys bereit
Öffentliche Server geben oft authorized_keys preis
Konfiguriere OpenSSH so, dass nur die public‑Hälfte präsentiert wird, sodass die Signaturerzeugung fehlschlägt und ein Fallback auf Passwort erzwungen wird, während gleichzeitig der public‑key acceptance‑Pfad auf dem Server ausgelöst wird.

Example SSH client config (no private key available):

# ~/.ssh/config
Host gitblit-target
HostName <host-or-ip>
User <victim-username>
PubkeyAuthentication yes
PreferredAuthentications publickey,password
IdentitiesOnly yes
IdentityFile ~/.ssh/victim.pub   # public half only (no private key present)

Verbinden und drücken Sie Enter bei der Passwortabfrage (oder geben Sie eine beliebige Zeichenfolge ein):

ssh gitblit-target
# or Git over SSH
GIT_SSH_COMMAND="ssh -F ~/.ssh/config" git ls-remote ssh://<victim-username>@<host>/<repo.git>

Die Authentifizierung gelingt, weil die vorherige public‑key‑Phase den Session‑Zustand in einen authentifizierten Benutzer verändert hat, und password auth diesem Zustand fälschlicherweise vertraut.

Hinweis: Wenn ControlMaster‑Multiplexing in Ihrer SSH‑Konfiguration aktiviert ist, können nachfolgende Git‑Befehle die bereits authentifizierte Verbindung wiederverwenden, was die Auswirkungen erhöht.

Impact

Vollständige Identitätsübernahme jedes Gitblit‑Benutzers mit mindestens einem registrierten SSH public‑key
Lese-/Schreibzugriff auf Repositories entsprechend den Berechtigungen des Opfers (Source‑Exfiltration, unautorisierte Pushes, Supply‑Chain‑Risiken)
Potenzielle administrative Auswirkungen bei Zielvorgabe eines Admin‑Benutzers
Reiner Netzwerk‑Exploit; kein Brute‑Force oder private key erforderlich

Detection ideas

Überprüfen Sie SSH‑Logs auf Sequenzen, in denen ein publickey‑Versuch von einer erfolgreichen password‑Authentifizierung mit leerem oder sehr kurzem Passwort gefolgt wird
Suchen Sie nach Abläufen: publickey‑Methode bietet nicht unterstütztes/inkompatibles Key‑Material an, gefolgt von sofortigem password‑Erfolg für denselben Benutzernamen

Mitigations

Upgrade auf Gitblit v1.10.0+
Bis zum Upgrade:
Git over SSH auf Gitblit deaktivieren, oder
Netzwerkzugriff auf den SSH‑Dienst einschränken, und
Auf die oben beschriebenen verdächtigen Muster überwachen
Betroffene Benutzeranmeldeinformationen rotieren, falls ein Kompromiss vermutet wird

General: abusing SSH auth method state‑leakage (MINA/OpenSSH‑based services)

Pattern: Wenn der public‑key‑Authenticator eines Servers Benutzer-/Session‑Zustand während der pre‑signature "key acceptable"‑Phase verändert und andere Authenticators (z. B. password) diesem Zustand vertrauen, kann man die Authentifizierung umgehen, indem man:

Einen legitimen public key für den Zielbenutzer präsentiert (kein private key)
Den Client dazu bringt, beim Signieren zu scheitern, sodass der Server auf password zurückfällt
Beliebiges Passwort angibt, während der password‑Authenticator aufgrund des geleakten Zustands kurzschließt

Praktische Tipps:

Public key harvesting at scale: public keys aus üblichen Quellen abrufen, z. B. https://github.com/.keys, organisatorische Verzeichnisse, Team‑Seiten, leaked authorized_keys
Forcing signature failure (client‑side): IdentityFile nur auf die .pub zeigen lassen, IdentitiesOnly yes setzen, PreferredAuthentications so belassen, dass publickey zuerst und dann password versucht wird
MINA SSHD integration pitfalls:
PublickeyAuthenticator.authenticate(...) darf Benutzer-/Session‑Zustand nicht anhängen, bevor der post‑signature‑Verifizierungs‑Pfad die Signatur bestätigt
PasswordAuthenticator.authenticate(...) darf keinen Erfolg aus einem während einer vorherigen, unvollständigen Authentifizierungsmethode veränderten Zustand ableiten

Related protocol/design notes and literature:

SSH userauth protocol: RFC 4252 (publickey method is a two‑stage process)
Historical discussions on early acceptance oracles and auth races, e.g., CVE‑2016‑20012 disputes around OpenSSH behavior

7.2 KiB Raw Blame History Unescape Escape