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

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

Résumé

CVE-2024-28080 est un contournement d’authentification dans le service SSH embarqué de Gitblit dû à une gestion incorrecte de l’état de session lors de l’intégration avec Apache MINA SSHD. Si un compte utilisateur possède au moins une clé publique SSH enregistrée, un attaquant qui connaît le nom d’utilisateur et l’une des clés publiques de cet utilisateur peut s’authentifier sans la clé privée et sans le mot de passe.

  • Affecté : Gitblit < 1.10.0 (observé sur 1.9.3)
  • Corrigé : 1.10.0
  • Conditions nécessaires pour exploiter :
  • Git over SSH activé sur l’instance
  • Le compte victime a au moins une clé publique SSH enregistrée dans Gitblit
  • L’attaquant connaît le nom d’utilisateur de la victime et l’une de ses clés publiques (souvent découvrable, p.ex. https://github.com/.keys)

Cause racine (state leaks between SSH methods)

Dans la RFC 4252, l’authentification par clé‑publique se déroule en deux phases : le serveur vérifie d’abord si une clé publique fournie est acceptable pour un nom d’utilisateur, et ce n’est qu’après un challenge/réponse avec une signature qu’il authentifie l’utilisateur. Dans MINA SSHD, le PublickeyAuthenticator est invoqué deux fois : lors de l’acceptation de la clé (pas encore de signature) et plus tard après que le client renvoie une signature.

Le PublickeyAuthenticator de Gitblit a muté le contexte de session lors du premier appel pré‑signature en liant le UserModel authentifié à la session et en retournant true (“key acceptable”). Lorsque l’authentification est ensuite retombée sur le mot de passe, le PasswordAuthenticator s’est fié à cet état de session muté et a court‑circuité, retournant true sans valider le mot de passe. En conséquence, n’importe quel mot de passe (y compris vide) était accepté après une “acceptation” préalable par clé‑publique pour le même utilisateur.

Flux défaillant (haut niveau) :

  1. Le client propose nom d’utilisateur + clé publique (pas encore de signature)
  2. Le serveur reconnaît que la clé appartient à l’utilisateur et attache prématurément l’utilisateur à la session, retourne true (“acceptable”)
  3. Le client ne peut pas signer (pas de clé privée), donc l’authentification retombe sur le mot de passe
  4. L’authentification par mot de passe voit un utilisateur déjà présent dans la session et renvoie inconditionnellement le succès

Exploitation pas à pas

  • Recueillir le nom d’utilisateur d’une victime et l’une de ses clés publiques :
  • GitHub expose les clés publiques à https://github.com/.keys
  • Les serveurs publics exposent souvent authorized_keys
  • Configurer OpenSSH pour ne présenter que la moitié publique afin que la génération de signature échoue, forçant un retour arrière vers le mot de passe tout en déclenchant quand même le chemin d’acceptation par clé‑publique sur le serveur.

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)

Connectez-vous et appuyez sur Entrée à l’invite du mot de passe (ou tapez n’importe quelle chaîne) :

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

L’authentification réussit parce que la phase précédente de public‑key a muté l’état de session en celui d’un utilisateur authentifié, et password auth fait incorrectement confiance à cet état.

Note : Si le ControlMaster multiplexing est activé dans la configuration SSH, les commandes Git suivantes peuvent réutiliser la connexion authentifiée, augmentant l’impact.

Impact

  • Usurpation complète de n’importe quel utilisateur Gitblit disposant d’au moins une SSH public key enregistrée
  • Accès en lecture/écriture aux repositories selon les permissions de la victime (exfiltration de code source, pushes non autorisés, risques pour la chaîne d’approvisionnement)
  • Impact administratif possible si un utilisateur admin est ciblé
  • Exploit purement réseau ; pas de brute force ni de private key requis

Idées de détection

  • Passer en revue les logs SSH pour des séquences où une tentative publickey est suivie d’une authentification password réussie avec un mot de passe vide ou très court
  • Rechercher des flux : la méthode publickey propose un matériel de clé non pris en charge/incompatible suivi d’un succès immédiat de password pour le même nom d’utilisateur

Atténuations

  • Mettre à jour vers Gitblit v1.10.0+
  • Jusqu’à la mise à jour :
  • Désactiver Git over SSH sur Gitblit, ou
  • Restreindre l’accès réseau au service SSH, et
  • Surveiller les schémas suspects décrits ci‑dessus
  • Réinitialiser les identifiants des utilisateurs affectés si une compromission est suspectée

Général : abus du state‑leakage des méthodes d’auth SSH (services basés sur MINA/OpenSSH)

Modèle : Si l’authenticator public‑key d’un serveur modifie l’état user/session pendant la phase pré‑signature “key acceptable” et que d’autres authenticators (p.ex. password) font confiance à cet état, vous pouvez contourner l’authentification en :

  • Présentant une public key légitime pour l’utilisateur cible (pas de private key)
  • Forçant le client à échouer la signature pour que le serveur retombe sur password
  • Fournissant n’importe quel password pendant que le password authenticator court‑circuite sur l’état leaked

Conseils pratiques :

  • Public key harvesting at scale: pull public keys from common sources such as https://github.com/.keys, organizational directories, team pages, leaked authorized_keys
  • Forcer l’échec de signature (côté client) : pointer IdentityFile vers uniquement le .pub, définir IdentitiesOnly yes, garder PreferredAuthentications pour inclure publickey puis password
  • MINA SSHD integration pitfalls :
    • PublickeyAuthenticator.authenticate(…) ne doit pas attacher l’état user/session tant que le chemin de vérification post‑signature ne confirme la signature
    • PasswordAuthenticator.authenticate(…) ne doit pas inférer le succès à partir d’un état muté pendant une méthode d’authentification antérieure incomplète

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

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks