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

Resumo

CVE-2024-28080 é um bypass de autenticação no serviço SSH embutido do Gitblit devido ao manuseio incorreto do estado da sessão ao integrar com Apache MINA SSHD. Se uma conta de usuário tiver pelo menos uma chave pública SSH registrada, um atacante que conhece o nome de usuário e qualquer uma das chaves públicas desse usuário pode se autenticar sem a chave privada e sem a senha.

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)

Root cause (state leaks between SSH methods)

No RFC 4252, a autenticação por chave‑pública procede em duas fases: o servidor primeiro verifica se uma chave pública fornecida é aceitável para um nome de usuário, e somente após um challenge/response com uma assinatura é que autentica o usuário. No MINA SSHD, o PublickeyAuthenticator é invocado duas vezes: na aceitação da chave (ainda sem assinatura) e mais tarde, depois que o cliente retorna uma assinatura.

O PublickeyAuthenticator do Gitblit mutou o contexto da sessão na primeira chamada pré‑assinatura ao vincular o UserModel autenticado à sessão e retornar true ("key acceptable"). Quando a autenticação depois recorria à senha, o PasswordAuthenticator confiava naquele estado de sessão mutado e encurtava o fluxo, retornando true sem validar a senha. Como resultado, qualquer senha (incluindo vazia) era aceita após uma aceitação prévia por chave pública para o mesmo usuário.

Fluxo com falha em alto nível:

Cliente oferece username + public key (ainda sem assinatura)
Servidor reconhece a chave como pertencente ao usuário e prematuramente associa o usuário à sessão, retornando true ("acceptable")
Cliente não consegue assinar (sem private key), então a autenticação recorre à senha
A autenticação por senha vê um usuário já presente na sessão e retorna sucesso incondicionalmente

Exploração passo a passo

Colete o username da vítima e uma de suas public keys:
GitHub expõe public keys em https://github.com/.keys
Servidores públicos frequentemente expõem authorized_keys
Configure o OpenSSH para apresentar apenas a metade pública para que a geração da signature falhe, forçando o fallback para password enquanto ainda aciona o caminho de aceitação por public‑key no servidor.

Exemplo de configuração do cliente SSH (no private key disponível):

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

Conecte-se e pressione Enter no prompt de senha (ou digite qualquer string):

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

A autenticação ocorre com sucesso porque a fase anterior de public‑key alterou a sessão para um usuário autenticado, e o password auth confia incorretamente nesse estado.

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

Impacto

Impersonar completamente qualquer Gitblit user com pelo menos uma SSH public key registrada
Acesso de leitura/escrita aos repositórios conforme as permissões da vítima (source exfiltration, unauthorized pushes, supply‑chain risks)
Impacto administrativo potencial se o alvo for um admin user
Exploração puramente de rede; sem brute force ou private key necessários

Detecção

Revise os SSH logs por sequências onde uma tentativa publickey é seguida por uma autenticação password bem‑sucedida com uma senha vazia ou muito curta
Procure fluxos: método publickey oferecendo material de chave não suportado/incompatível seguido por sucesso imediato do password para o mesmo username

Mitigações

Atualize para Gitblit v1.10.0+
Até a atualização:
Desative Git over SSH no Gitblit, ou
Restrinja o acesso de rede ao serviço SSH, e
Monitore por padrões suspeitos descritos acima
Altere as credenciais dos usuários afetados se houver suspeita de comprometimento

Geral: abusando do SSH auth method state‑leakage (MINA/OpenSSH‑based services)

Padrão: Se o public‑key authenticator de um servidor muta o estado do usuário/sessão durante a fase pré‑assinatura "key acceptable" e outros authenticators (e.g., password) confiam nesse estado, você pode contornar a autenticação por:

Apresentar uma public key legítima para o usuário alvo (sem private key)
Forçar o cliente a falhar ao assinar para que o servidor caia de volta para password
Fornecer qualquer password enquanto o password authenticator ignora a verificação devido ao leaked state

Dicas práticas:

Public key harvesting at scale: pull public keys from common sources such as https://github.com/.keys, organizational directories, team pages, leaked authorized_keys
Forçar falha de assinatura (lado cliente): aponte IdentityFile somente para o .pub, defina IdentitiesOnly yes, mantenha PreferredAuthentications incluindo publickey then password
Armadilhas de integração do MINA SSHD:
PublickeyAuthenticator.authenticate(...) não deve anexar estado do usuário/sessão até que o caminho de verificação pós‑assinatura confirme a assinatura
PasswordAuthenticator.authenticate(...) não deve inferir sucesso a partir de qualquer estado mutado durante um método de autenticação prévio incompleto

Notas e literatura relacionadas ao protocolo/design:

SSH userauth protocol: RFC 4252 (publickey method is a two‑stage process)
Discussões históricas sobre early acceptance oracles e auth races, e.g., CVE‑2016‑20012 disputes around OpenSSH behavior

6.7 KiB Raw Blame History Unescape Escape