Translated ['src/pentesting-ci-cd/gitblit-security/README.md', 'src/pent

src/pentesting-ci-cd/gitblit-security/README.md

@@ -0,0 +1,21 @@
+# Segurança do Gitblit
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## O que é o Gitblit
+
+Gitblit é um servidor Git auto-hospedado escrito em Java. Pode ser executado como um JAR standalone ou em containers de servlet e inclui um serviço SSH embutido (Apache MINA SSHD) para Git over SSH.
+
+## Tópicos
+
+- Gitblit Embedded SSH Auth Bypass (CVE-2024-28080)
+
+{{#ref}}
+gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md
+{{#endref}}
+
+## Referências
+
+- [Gitblit project](https://gitblit.com/)
+
+{{#include ../../banners/hacktricks-training.md}}

src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md

@@ -0,0 +1,107 @@
+# Gitblit Embedded SSH Auth Bypass (CVE-2024-28080)
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## Resumo
+
+CVE-2024-28080 é um bypass de autenticação no serviço SSH embutido do Gitblit devido ao tratamento 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 conheça o username e qualquer uma das public keys desse usuário pode autenticar sem a private key e sem a 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/<username>.keys)
+
+## Causa raiz (state leaks between SSH methods)
+
+No RFC 4252, a autenticação por public‑key ocorre em duas fases: o servidor primeiro verifica se uma public key fornecida é aceitável para um username, e somente após um challenge/response com uma signature é que autentica o usuário. Em MINA SSHD, o PublickeyAuthenticator é invocado duas vezes: na aceitação da key (ainda sem signature) e mais tarde depois que o cliente retorna uma signature.
+
+O PublickeyAuthenticator do Gitblit mutou o contexto da sessão na primeira chamada pré‑signature ao vincular o UserModel autenticado à sessão e retornar true ("key acceptable"). Quando a autenticação mais tarde caía para password, o PasswordAuthenticator confiava naquele estado de sessão mutado e atalhava o fluxo, retornando true sem validar a password. Como resultado, qualquer password (incluindo vazia) era aceita após uma "acceptance" prévia por public‑key para o mesmo usuário.
+
+High‑level flawed flow:
+
+1) Client offers username + public key (no signature yet)
+2) Server recognizes the key as belonging to the user and prematurely attaches user to the session, returns true ("acceptable")
+3) Client cannot sign (no private key), so auth falls back to password
+4) Password auth sees a user already present in session and unconditionally returns success
+
+## Exploração passo a passo
+
+- Colete o username da vítima e uma das suas public keys:
+- GitHub expõe public keys em https://github.com/<username>.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 dispara o caminho de aceitação por public‑key no servidor.
+
+Exemplo SSH client config (no private key available):
+```sshconfig
+# ~/.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 password prompt (ou digite qualquer string):
+```bash
+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 tem sucesso porque a fase anterior de public‑key mutou a sessão para um usuário autenticado, e a autenticação por password confia incorretamente nesse estado.
+
+Nota: Se o ControlMaster multiplexing estiver habilitado na sua configuração SSH, comandos Git subsequentes podem reutilizar a conexão autenticada, aumentando o impacto.
+
+## Impact
+
+- Impersonação total de qualquer usuário do Gitblit com pelo menos uma SSH public key registrada
+- Acesso de leitura/escrita aos repositórios conforme as permissões da vítima (exfiltração de código, pushes não autorizados, supply‑chain risks)
+- Impacto administrativo potencial se o alvo for um usuário admin
+- Exploração puramente de rede; no brute force ou private key requerido
+
+## Detection ideas
+
+- Revise os logs do SSH procurando sequências onde uma tentativa de publickey é seguida por uma autenticação por password bem‑sucedida com uma password vazia ou muito curta
+- Procure por fluxos: método publickey oferecendo material de key não suportado/descasado seguido por sucesso imediato de password para o mesmo username
+
+## Mitigations
+
+- 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
+- Rotacione as credenciais dos usuários afetados se houver suspeita de comprometimento
+
+## General: abusing SSH auth method state‑leakage (MINA/OpenSSH‑based services)
+
+Pattern: 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 (ex.: password) confiam nesse estado, você pode contornar a autenticação ao:
+
+- Apresentar uma public key legítima para o usuário alvo (sem private key)
+- Forçar o client a falhar na assinatura para que o servidor recorra ao password
+- Fornecer qualquer password enquanto o password authenticator short‑circuits em leaked state
+
+Dicas práticas:
+
+- Coleta de public keys em escala: obtenha public keys de fontes comuns como https://github.com/<username>.keys, diretórios organizacionais, páginas de equipe, leaked authorized_keys
+- Forçar falha de assinatura (client‑side): aponte IdentityFile somente para o .pub, defina IdentitiesOnly yes, mantenha PreferredAuthentications para incluir publickey e depois password
+- Armadilhas de integração do MINA SSHD:
+- PublickeyAuthenticator.authenticate(...) não deve anexar o estado de 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 anterior incompleto
+
+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
+
+- [Gitblit CVE-2024-28080: SSH public‑key fallback to password authentication bypass (Silent Signal blog)](https://blog.silentsignal.eu/2025/06/14/gitblit-cve-CVE-2024-28080/)
+- [Gitblit v1.10.0 release notes](https://github.com/gitblit-org/gitblit/releases/tag/v1.10.0)
+- [Apache MINA SSHD project](https://mina.apache.org/sshd-project/)
+- [PublickeyAuthenticator API](https://svn.apache.org/repos/infra/websites/production/mina/content/sshd-project/apidocs/org/apache/sshd/server/auth/pubkey/PublickeyAuthenticator.html)
+- [RFC 4252: The Secure Shell (SSH) Authentication Protocol](https://datatracker.ietf.org/doc/html/rfc4252)
+
+
+{{#include ../../banners/hacktricks-training.md}}