Bypass di autenticazione SSH integrata in Gitblit (CVE-2024-28080)

Reading time: 6 minutes

Sommario

CVE-2024-28080 è un bypass di autenticazione nel servizio SSH integrato di Gitblit dovuto a una gestione errata dello stato della sessione durante l'integrazione con Apache MINA SSHD. Se un account utente ha almeno una chiave pubblica SSH registrata, un attacker che conosce lo username della vittima e una delle sue chiavi pubbliche può autenticarsi senza la chiave privata e senza la password.

• Affected: Gitblit < 1.10.0 (observed on 1.9.3)
• Fixed: 1.10.0
• Requirements to exploit:
• Git over SSH enabled on the instance
• Victim account has at least one SSH public key registered in Gitblit
• Attacker knows victim username and one of their public keys (often discoverable, e.g., https://github.com/.keys)

Causa principale (state leaks between SSH methods)

Nell'RFC 4252, l'autenticazione con chiave pubblica procede in due fasi: il server verifica prima se una chiave pubblica fornita è accettabile per uno username, e solo dopo un challenge/response con una firma autentica procede all'autenticazione dell'utente. In MINA SSHD, il PublickeyAuthenticator viene invocato due volte: al momento dell'accettazione della chiave (ancora senza firma) e successivamente dopo che il client ritorna la firma.

Il PublickeyAuthenticator di Gitblit mutava il contesto della sessione nella prima chiamata pre‑firma legando lo UserModel autenticato alla sessione e restituendo true ("key acceptable"). Quando più tardi l'autenticazione ricadeva sulla password, il PasswordAuthenticator si fidava di quello stato di sessione mutato e terminava prematuramente, restituendo true senza validare la password. Di conseguenza, qualsiasi password (inclusa la vuota) veniva accettata dopo una precedente "accettazione" della chiave pubblica per lo stesso utente.

Flusso difettoso ad alto livello:

1. Client offre username + chiave pubblica (ancora senza firma)
2. Server riconosce la chiave come appartenente all'utente e collega prematuramente l'utente alla sessione, restituendo true ("acceptable")
3. Client non può firmare (nessuna chiave privata), quindi l'autenticazione ricade sulla password
4. L'autenticazione via password vede un utente già presente nella sessione e ritorna success senza ulteriori controlli

Sfruttamento passo-passo

• Raccogliere lo username della vittima e una delle sue chiavi pubbliche:
• GitHub espone le chiavi pubbliche su https://github.com/.keys
• I server pubblici spesso espongono authorized_keys
• Configurare OpenSSH per presentare solo la metà pubblica in modo che la generazione della firma fallisca, forzando il fallback alla password pur attivando il percorso di accettazione della chiave pubblica sul server.

Esempio di configurazione client SSH (nessuna chiave privata disponibile):

# ~/.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)

Collegati e premi Invio al prompt della password (o digita qualsiasi stringa):

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

L'autenticazione ha successo perché la fase public‑key precedente ha mutato lo stato della sessione trattandola come un utente autenticato, e password auth si fida erroneamente di quello stato.

Nota: Se ControlMaster multiplexing è abilitato nella tua configurazione SSH, comandi Git successivi possono riutilizzare la connessione autenticata, aumentando l'impatto.

Impatto

• Impersonificazione completa di qualsiasi utente Gitblit che possieda almeno una SSH public key registrata
• Accesso in lettura/scrittura ai repository secondo i permessi della vittima (source exfiltration, unauthorized pushes, supply‑chain risks)
• Potenziale impatto amministrativo se si prende di mira un utente admin
• Exploit puramente di rete; non è richiesto brute force né la private key

Idee per il rilevamento

• Controllare i log SSH per sequenze in cui un tentativo publickey è seguito da una password authentication riuscita con una password vuota o molto corta
• Cercare flussi: publickey method che offre materiale chiave non supportato/non corrispondente seguito da un successo immediato della password per lo stesso username

Mitigazioni

• Aggiornare a Gitblit v1.10.0+
• Fino all'aggiornamento:
• Disabilitare Git over SSH su Gitblit, oppure
• Restringere l'accesso di rete al servizio SSH, e
• Monitorare per i pattern sospetti descritti sopra
• Ruotare le credenziali degli utenti interessati se si sospetta compromissione

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

Pattern: Se il public‑key authenticator di un server muta lo stato utente/sessione durante la fase pre‑signature "key acceptable" e altri authenticators (es. password) si fidano di quello stato, è possibile bypassare l'autenticazione mediante:

• Presentare una public key legittima per l'utente target (senza private key)
• Forzare il client a fallire la firma in modo che il server ricorra alla password
• Fornire qualsiasi password mentre il password authenticator short‑circuits sullo state‑leakage

Consigli pratici:

• Public key harvesting at scale: pull public keys from common sources such as https://github.com/.keys, organizational directories, team pages, leaked authorized_keys
• Forzare il fallimento della signature (client‑side): puntare IdentityFile solo al .pub, impostare IdentitiesOnly yes, mantenere PreferredAuthentications in modo da includere publickey poi password
• MINA SSHD integration pitfalls:
• PublickeyAuthenticator.authenticate(...) non deve allegare lo stato utente/sessione fino a quando il percorso di verifica post‑signature non confermi la signature
• PasswordAuthenticator.authenticate(...) non deve inferire successo da qualsiasi stato mutato durante un metodo di autenticazione precedente e incompleto

Note e letteratura correlate su protocollo/progettazione:

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

Riferimenti

• Gitblit CVE-2024-28080: SSH public‑key fallback to password authentication bypass (Silent Signal blog)
• Gitblit v1.10.0 release notes
• Apache MINA SSHD project
• PublickeyAuthenticator API
• RFC 4252: The Secure Shell (SSH) Authentication Protocol