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

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

@@ -1,10 +1,10 @@
-# Segurança do Gitblit
+# Gitblit Segurança
 
 {{#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.
+Gitblit é um servidor Git auto‑hospedado escrito em Java. Pode ser executado como um JAR standalone ou em contêineres de servlet e fornece um serviço SSH embutido (Apache MINA SSHD) para Git sobre SSH.
 
 ## Tópicos
 

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

@@ -4,7 +4,7 @@
 
 ## 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.
+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
@@ -13,27 +13,27 @@ CVE-2024-28080 é um bypass de autenticação no serviço SSH embutido do Gitbli
 - 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)
+## Root cause (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.
+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é‑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.
+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.
 
-High‑level flawed flow:
+Fluxo com falha em alto nível:
 
-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
+1) Cliente oferece username + public key (ainda sem assinatura)  
+2) Servidor reconhece a chave como pertencente ao usuário e prematuramente associa o usuário à sessão, retornando true ("acceptable")  
+3) Cliente não consegue assinar (sem private key), então a autenticação recorre à senha  
+4) 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 das suas public keys:
+- Colete o username da vítima e uma de 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.
+- 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 SSH client config (no private key available):
+Exemplo de configuração do cliente SSH (no private key disponível):
 ```sshconfig
 # ~/.ssh/config
 Host gitblit-target
@@ -44,58 +44,58 @@ 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):
+Conecte-se e pressione Enter no prompt de senha (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.
+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.
 
-Nota: Se o ControlMaster multiplexing estiver habilitado na sua configuração SSH, comandos Git subsequentes podem reutilizar a conexão autenticada, aumentando o impacto.
+Note: If ControlMaster multiplexing is enabled in your SSH config, subsequent Git commands may reuse the authenticated connection, increasing impact.
 
-## Impact
+## Impacto
 
-- 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
+- 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
 
-## Detection ideas
+## Detecção
 
-- 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
+- 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
 
-## Mitigations
+## 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
-- Rotacione as credenciais dos usuários afetados se houver suspeita de comprometimento
+- Altere as credenciais dos usuários afetados se houver suspeita de comprometimento
 
-## General: abusing SSH auth method state‑leakage (MINA/OpenSSH‑based services)
+## Geral: abusando do 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:
+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 client a falhar na assinatura para que o servidor recorra ao password
-- Fornecer qualquer password enquanto o password authenticator short‑circuits em leaked state
+- 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:
 
-- 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
+- Public key harvesting at scale: pull public keys from common sources such as https://github.com/<username>.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 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
+- 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
 
-Related protocol/design notes and literature:
+Notas e literatura relacionadas ao protocolo/design:
 - 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
+- Discussões históricas sobre early acceptance oracles e auth races, e.g., CVE‑2016‑20012 disputes around OpenSSH behavior
 
-## References
+## Referências
 
 - [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)