mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-02-05 11:26:11 -08:00
Translated ['.github/pull_request_template.md', 'src/README.md', 'src/pe
This commit is contained in:
Translator
@@ -27,7 +27,7 @@ oc login -s=<server> --token=<bearer token>
|
||||
|
||||
Além dos [recursos RBAC](https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#architecture-additional-concepts-authorization) que controlam o que um usuário pode fazer, a OpenShift Container Platform fornece _restrições de contexto de segurança_ (SCC) que controlam as ações que um pod pode realizar e o que ele tem a capacidade de acessar.
|
||||
|
||||
SCC é um objeto de política que possui regras especiais que correspondem à própria infraestrutura, ao contrário do RBAC, que possui regras que correspondem à Plataforma. Ele nos ajuda a definir quais recursos de controle de acesso do Linux o contêiner deve ser capaz de solicitar/executar. Exemplo: Capacidades do Linux, perfis SECCOMP, montar diretórios localhost, etc.
|
||||
SCC é um objeto de política que possui regras especiais que correspondem à infraestrutura em si, ao contrário do RBAC que possui regras que correspondem à Plataforma. Ele nos ajuda a definir quais recursos de controle de acesso do Linux o contêiner deve ser capaz de solicitar/executar. Exemplo: Capacidades do Linux, perfis SECCOMP, Montar diretórios localhost, etc.
|
||||
|
||||
{{#ref}}
|
||||
openshift-scc.md
|
||||
|
||||
@@ -2,23 +2,23 @@
|
||||
|
||||
**O autor original desta página é** [**Fares**](https://www.linkedin.com/in/fares-siala/)
|
||||
|
||||
Esta página fornece algumas dicas sobre como você pode atacar uma instância do Jenkins em execução em um cluster Openshift (ou Kubernetes)
|
||||
Esta página fornece algumas dicas sobre como você pode atacar uma instância do Jenkins em execução em um cluster Openshift (ou Kubernetes).
|
||||
|
||||
## Isenção de responsabilidade
|
||||
|
||||
Uma instância do Jenkins pode ser implantada tanto em um cluster Openshift quanto em um cluster Kubernetes. Dependendo do seu contexto, você pode precisar adaptar qualquer payload, yaml ou técnica mostrada. Para mais informações sobre como atacar o Jenkins, você pode dar uma olhada [nesta página](../../../pentesting-ci-cd/jenkins-security/)
|
||||
Uma instância do Jenkins pode ser implantada tanto em um cluster Openshift quanto em um cluster Kubernetes. Dependendo do seu contexto, você pode precisar adaptar qualquer payload, yaml ou técnica mostrada. Para mais informações sobre como atacar o Jenkins, você pode dar uma olhada [nesta página](../../../pentesting-ci-cd/jenkins-security/).
|
||||
|
||||
## Pré-requisitos
|
||||
|
||||
1a. Acesso de usuário em uma instância do Jenkins OU 1b. Acesso de usuário com permissão de gravação em um repositório SCM onde uma construção automatizada é acionada após um push/merge
|
||||
1a. Acesso de usuário em uma instância do Jenkins OU 1b. Acesso de usuário com permissão de gravação em um repositório SCM onde uma construção automatizada é acionada após um push/merge.
|
||||
|
||||
## Como funciona
|
||||
|
||||
Fundamentalmente, quase tudo nos bastidores funciona da mesma forma que uma instância regular do Jenkins em execução em uma VM. A principal diferença é a arquitetura geral e como as construções são gerenciadas dentro de um cluster openshift (ou kubernetes).
|
||||
Fundamentalmente, quase tudo nos bastidores funciona da mesma forma que uma instância regular do Jenkins em execução em uma VM. A principal diferença é a arquitetura geral e como as construções são gerenciadas dentro de um cluster Openshift (ou Kubernetes).
|
||||
|
||||
### Construções
|
||||
|
||||
Quando uma construção é acionada, ela é primeiro gerenciada/orquestrada pelo nó mestre do Jenkins e, em seguida, delegada a um agente/escravo/trabalhador. Nesse contexto, o nó mestre é apenas um pod regular em execução em um namespace (que pode ser diferente daquele onde os trabalhadores estão em execução). O mesmo se aplica aos trabalhadores/escravos, no entanto, eles são destruídos uma vez que a construção é concluída, enquanto o mestre permanece sempre ativo. Sua construção geralmente é executada dentro de um pod, usando um modelo de pod padrão definido pelos administradores do Jenkins.
|
||||
Quando uma construção é acionada, ela é primeiro gerenciada/orquestrada pelo nó mestre do Jenkins e, em seguida, delegada a um agente/escravo/trabalhador. Nesse contexto, o nó mestre é apenas um pod regular em execução em um namespace (que pode ser diferente daquele onde os trabalhadores são executados). O mesmo se aplica aos trabalhadores/escravos, no entanto, eles são destruídos uma vez que a construção é concluída, enquanto o mestre sempre permanece ativo. Sua construção é geralmente executada dentro de um pod, usando um modelo de pod padrão definido pelos administradores do Jenkins.
|
||||
|
||||
### Acionando uma construção
|
||||
|
||||
@@ -26,11 +26,11 @@ Você tem várias maneiras principais de acionar uma construção, como:
|
||||
|
||||
1. Você tem acesso à interface do usuário do Jenkins
|
||||
|
||||
Uma maneira muito fácil e conveniente é usar a funcionalidade Replay de uma construção existente. Isso permite que você reproduza uma construção executada anteriormente, permitindo que você atualize o script groovy. Isso requer privilégios em uma pasta do Jenkins e um pipeline predefinido. Se você precisar ser discreto, pode excluir suas construções acionadas se tiver permissão suficiente.
|
||||
Uma maneira muito fácil e conveniente é usar a funcionalidade Replay de uma construção existente. Isso permite que você reproduza uma construção executada anteriormente, permitindo que você atualize o script groovy. Isso requer privilégios em uma pasta do Jenkins e um pipeline pré-definido. Se você precisar ser discreto, pode excluir suas construções acionadas se tiver permissão suficiente.
|
||||
|
||||
2. Você tem acesso de gravação ao SCM e construções automatizadas estão configuradas via webhook
|
||||
|
||||
Você pode simplesmente editar um script de construção (como Jenkinsfile), fazer commit e push (eventualmente criar um PR se as construções forem acionadas apenas em merges de PR). Lembre-se de que esse caminho é muito barulhento e precisa de privilégios elevados para limpar suas pistas.
|
||||
Você pode simplesmente editar um script de construção (como Jenkinsfile), fazer commit e push (eventualmente criar um PR se as construções forem acionadas apenas em merges de PR). Lembre-se de que esse caminho é muito barulhento e precisa de privilégios elevados para limpar suas trilhas.
|
||||
|
||||
## Substituição do YAML do Pod de Construção do Jenkins
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## Plugin Kubernetes para Jenkins
|
||||
Este plugin é principalmente responsável pelas funções principais do Jenkins dentro de um cluster openshift/kubernetes. Documentação oficial [aqui](https://plugins.jenkins.io/kubernetes/)
|
||||
Ele oferece algumas funcionalidades, como a capacidade dos desenvolvedores de substituir algumas configurações padrão de um pod de build do jenkins.
|
||||
Ele oferece algumas funcionalidades, como a capacidade de os desenvolvedores substituírem algumas configurações padrão de um pod de build do jenkins.
|
||||
|
||||
## Funcionalidade principal
|
||||
|
||||
@@ -34,10 +34,10 @@ sh 'mvn -B -ntp clean install'
|
||||
}
|
||||
}
|
||||
```
|
||||
## Alguns abusos aproveitando a substituição do yaml do pod
|
||||
## Alguns abusos aproveitando a sobreposição de yaml do pod
|
||||
|
||||
No entanto, pode ser abusado para usar qualquer imagem acessível, como Kali Linux, e executar comandos arbitrários usando ferramentas pré-instaladas dessa imagem.
|
||||
No exemplo abaixo, podemos exfiltrar o token do serviceaccount do pod em execução.
|
||||
No exemplo abaixo, podemos exfiltrar o token da serviceaccount do pod em execução.
|
||||
```groovy
|
||||
podTemplate(yaml: '''
|
||||
apiVersion: v1
|
||||
@@ -165,16 +165,16 @@ A mesma técnica se aplica para tentar montar um Secret. O objetivo final aqui s
|
||||
|
||||
## Indo mais longe
|
||||
|
||||
Uma vez que você se acostume a brincar com isso, use seu conhecimento sobre Jenkins e Kubernetes/Openshift para encontrar misconfigurações / abusos.
|
||||
Uma vez que você se acostume a brincar com isso, use seu conhecimento sobre Jenkins e Kubernetes/Openshift para encontrar configurações incorretas / abusos.
|
||||
|
||||
Pergunte a si mesmo as seguintes questões:
|
||||
|
||||
- Qual conta de serviço está sendo usada para implantar pods de construção?
|
||||
- Quais papéis e permissões ela possui? Pode ler segredos do namespace em que estou atualmente?
|
||||
- Quais papéis e permissões ela possui? Pode ler secrets do namespace em que estou atualmente?
|
||||
- Posso enumerar outros pods de construção?
|
||||
- A partir de um sa comprometido, posso executar comandos no nó/pod mestre?
|
||||
- Posso enumerar mais o cluster para pivotar para outro lugar?
|
||||
- Qual SCC está aplicado?
|
||||
- Qual SCC está aplicada?
|
||||
|
||||
Você pode descobrir quais comandos oc/kubectl emitir [aqui](../openshift-basic-information.md) e [aqui](../../kubernetes-security/kubernetes-enumeration.md).
|
||||
|
||||
@@ -216,15 +216,15 @@ sh 'oc --token=$token whoami'
|
||||
}
|
||||
}
|
||||
```
|
||||
Dependendo do seu acesso, ou você precisa continuar seu ataque a partir do script de build ou pode fazer login diretamente como este sa no cluster em execução:
|
||||
Dependendo do seu acesso, você precisa continuar seu ataque a partir do script de build ou pode fazer login diretamente como este sa no cluster em execução:
|
||||
```bash
|
||||
oc login --token=$token --server=https://apiserver.com:port
|
||||
```
|
||||
Se este sa tiver permissões suficientes (como pod/exec), você também pode assumir o controle de toda a instância do jenkins executando comandos dentro do pod do nó mestre, se estiver sendo executado dentro do mesmo namespace. Você pode identificar facilmente este pod pelo seu nome e pelo fato de que ele deve estar montando um PVC (persistant volume claim) usado para armazenar dados do jenkins.
|
||||
Se este sa tiver permissões suficientes (como pod/exec), você também pode assumir o controle de toda a instância do jenkins executando comandos dentro do pod do nó master, se estiver sendo executado dentro do mesmo namespace. Você pode identificar facilmente este pod pelo seu nome e pelo fato de que ele deve estar montando um PVC (persistent volume claim) usado para armazenar dados do jenkins.
|
||||
```bash
|
||||
oc rsh pod_name -c container_name
|
||||
```
|
||||
Caso o pod do nó mestre não esteja em execução dentro do mesmo namespace que os trabalhadores, você pode tentar ataques semelhantes direcionando o namespace mestre. Vamos supor que se chama _jenkins-master_. Lembre-se de que a serviceAccount master-sa precisa existir no namespace _jenkins-master_ (e pode não existir no namespace _worker-ns_).
|
||||
Caso o pod do nó mestre não esteja em execução dentro do mesmo namespace que os trabalhadores, você pode tentar ataques semelhantes direcionando o namespace mestre. Vamos supor que ele se chama _jenkins-master_. Lembre-se de que a serviceAccount master-sa precisa existir no namespace _jenkins-master_ (e pode não existir no namespace _worker-ns_).
|
||||
```groovy
|
||||
pipeline {
|
||||
stages {
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# OpenShift - Escalação de Privilégios
|
||||
# OpenShift - Escalada de Privilégios
|
||||
|
||||
## Conta de Serviço Ausente
|
||||
|
||||
|
||||
@@ -2,13 +2,13 @@
|
||||
|
||||
## Conta de Serviço Ausente
|
||||
|
||||
Acontece que o cluster é implantado com um modelo pré-configurado que define automaticamente Roles, RoleBindings e até mesmo SCC para uma conta de serviço que ainda não foi criada. Isso pode levar a uma escalada de privilégios no caso de você conseguir criá-las. Nesse caso, você seria capaz de obter o token da SA recém-criada e o papel ou SCC associado. O mesmo caso ocorre quando a SA ausente faz parte de um projeto ausente; nesse caso, se você conseguir criar o projeto e, em seguida, a SA, obterá os Roles e SCC associados.
|
||||
Acontece que o cluster é implantado com um modelo pré-configurado que define automaticamente Roles, RoleBindings e até mesmo SCC para uma conta de serviço que ainda não foi criada. Isso pode levar a uma escalada de privilégios no caso de você conseguir criá-las. Nesse caso, você seria capaz de obter o token da SA recém-criada e o papel ou SCC associado. O mesmo caso ocorre quando a SA ausente faz parte de um projeto ausente; nesse caso, se você conseguir criar o projeto e, em seguida, a SA, você obterá os Roles e SCC associados.
|
||||
|
||||
<figure><img src="../../../images/openshift-missing-service-account-image1.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
No gráfico anterior, temos múltiplos AbsentProject, significando múltiplos projetos que aparecem em Roles Bindings ou SCC, mas ainda não foram criados no cluster. Na mesma linha, também temos uma AbsentServiceAccount.
|
||||
No gráfico anterior, temos múltiplos AbsentProject, significando múltiplos projetos que aparecem em Roles Bindings ou SCC, mas que ainda não foram criados no cluster. Da mesma forma, também temos uma AbsentServiceAccount.
|
||||
|
||||
Se conseguirmos criar um projeto e a SA ausente nele, a SA herdará o Role ou o SCC que estavam direcionados à AbsentServiceAccount. O que pode levar a uma escalada de privilégios.
|
||||
Se conseguirmos criar um projeto e a SA ausente nele, a SA herdará do Role ou do SCC que estavam direcionando a AbsentServiceAccount. O que pode levar a uma escalada de privilégios.
|
||||
|
||||
O seguinte exemplo mostra uma SA ausente que é concedida ao SCC node-exporter:
|
||||
|
||||
@@ -16,7 +16,7 @@ O seguinte exemplo mostra uma SA ausente que é concedida ao SCC node-exporter:
|
||||
|
||||
## Ferramentas
|
||||
|
||||
A seguinte ferramenta pode ser usada para enumerar esse problema e, mais geralmente, para mapear um cluster OpenShift:
|
||||
A seguinte ferramenta pode ser usada para enumerar esse problema e, de forma mais geral, para mapear um cluster OpenShift:
|
||||
|
||||
{{#ref}}
|
||||
https://github.com/maxDcb/OpenShiftGrapher
|
||||
|
||||
@@ -28,7 +28,7 @@ yes
|
||||
$ oc auth can-i patch namespaces
|
||||
yes
|
||||
```
|
||||
A etiqueta específica `openshift.io/run-level` permite que os usuários contornem os SCCs para aplicativos. De acordo com a documentação da RedHat, quando essa etiqueta é utilizada, nenhum SCC é aplicado a todos os pods dentro desse namespace, efetivamente removendo quaisquer restrições.
|
||||
A etiqueta específica `openshift.io/run-level` permite que os usuários contornem os SCCs para aplicativos. De acordo com a documentação da RedHat, quando essa etiqueta é utilizada, nenhum SCC é aplicado a todos os pods dentro desse namespace, removendo efetivamente quaisquer restrições.
|
||||
|
||||
<figure><img src="../../../images/Openshift-RunLevel4.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -86,7 +86,7 @@ volumes:
|
||||
hostPath:
|
||||
path:
|
||||
```
|
||||
Agora, tornou-se mais fácil escalar privilégios para acessar o sistema host e, subsequentemente, assumir todo o cluster, ganhando privilégios de 'cluster-admin'. Procure pela parte **Node-Post Exploitation** na seguinte página:
|
||||
Agora, tornou-se mais fácil escalar privilégios para acessar o sistema host e, subsequentemente, assumir todo o cluster, ganhando privilégios de 'cluster-admin'. Procure pela parte **Node-Post Exploitation** na página a seguir:
|
||||
|
||||
{{#ref}}
|
||||
../../kubernetes-security/attacking-kubernetes-from-inside-a-pod.md
|
||||
@@ -111,7 +111,7 @@ $ oc get namespace -o yaml | grep labels -A 5
|
||||
```bash
|
||||
$ oc get project -o yaml | grep 'run-level' -b5
|
||||
```
|
||||
## Exploit avançado
|
||||
## Exploit Avançado
|
||||
|
||||
No OpenShift, como demonstrado anteriormente, ter permissão para implantar um pod em um namespace com o rótulo `openshift.io/run-level` pode levar a uma tomada de controle direta do cluster. Do ponto de vista das configurações do cluster, essa funcionalidade **não pode ser desativada**, pois é inerente ao design do OpenShift.
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
### O que é tekton
|
||||
|
||||
De acordo com a documentação: _Tekton é uma estrutura poderosa e flexível de código aberto para criar sistemas de CI/CD, permitindo que os desenvolvedores construam, testem e implantem em provedores de nuvem e sistemas locais._ Tanto Jenkins quanto Tekton podem ser usados para testar, construir e implantar aplicações, no entanto, Tekton é Nativo da Nuvem. 
|
||||
De acordo com a documentação: _Tekton é uma estrutura poderosa e flexível de código aberto para criar sistemas de CI/CD, permitindo que os desenvolvedores construam, testem e implantem em provedores de nuvem e sistemas locais._ Tanto Jenkins quanto Tekton podem ser usados para testar, construir e implantar aplicações, no entanto, Tekton é Cloud Native. 
|
||||
|
||||
Com Tekton, tudo é representado por arquivos YAML. Os desenvolvedores podem criar Recursos Personalizados (CR) do tipo `Pipelines` e especificar várias `Tasks` neles que desejam executar. Para executar um Pipeline, recursos do tipo `PipelineRun` devem ser criados.
|
||||
|
||||
@@ -16,7 +16,7 @@ https://tekton.dev/docs/getting-started/pipelines/
|
||||
|
||||
### As capacidades da conta de serviço do Pipeline
|
||||
|
||||
Por padrão, a conta de serviço do pipeline pode usar a capacidade `pipelines-scc`. Isso se deve à configuração padrão global do tekton. Na verdade, a configuração global do tekton também é um YAML em um objeto do openshift chamado `TektonConfig` que pode ser visto se você tiver alguns papéis de leitor no cluster.
|
||||
Por padrão, a conta de serviço do pipeline pode usar a capacidade `pipelines-scc`. Isso se deve à configuração padrão global do tekton. Na verdade, a configuração global do tekton também é um YAML em um objeto openshift chamado `TektonConfig` que pode ser visto se você tiver alguns papéis de leitor no cluster.
|
||||
```yaml
|
||||
apiVersion: operator.tekton.dev/v1alpha1
|
||||
kind: TektonConfig
|
||||
@@ -47,7 +47,7 @@ O operador tekton dará à conta de serviço do pipeline em `test-namespace` a c
|
||||
|
||||
### A correção
|
||||
|
||||
Documentos do Tekton sobre como restringir a substituição do scc adicionando um rótulo no objeto `TektonConfig`.
|
||||
Os documentos do Tekton sobre como restringir a substituição do scc adicionando um rótulo no objeto `TektonConfig`.
|
||||
|
||||
{{#ref}}
|
||||
https://tekton.dev/docs/operator/sccconfig/
|
||||
|
||||
@@ -6,10 +6,10 @@
|
||||
|
||||
No contexto do OpenShift, SCC significa **Security Context Constraints**. Security Context Constraints são políticas que controlam permissões para pods em execução em clusters OpenShift. Elas definem os parâmetros de segurança sob os quais um pod pode ser executado, incluindo quais ações ele pode realizar e quais recursos pode acessar.
|
||||
|
||||
SCCs ajudam os administradores a impor políticas de segurança em todo o cluster, garantindo que os pods estejam sendo executados com permissões apropriadas e aderindo aos padrões de segurança organizacionais. Essas restrições podem especificar vários aspectos da segurança do pod, como:
|
||||
SCCs ajudam administradores a impor políticas de segurança em todo o cluster, garantindo que os pods estejam sendo executados com permissões apropriadas e aderindo aos padrões de segurança organizacionais. Essas restrições podem especificar vários aspectos da segurança do pod, como:
|
||||
|
||||
1. Capacidades do Linux: Limitando as capacidades disponíveis para contêineres, como a capacidade de realizar ações privilegiadas.
|
||||
2. Contexto SELinux: Aplicando contextos SELinux para contêineres, que definem como os processos interagem com os recursos do sistema.
|
||||
2. Contexto SELinux: Aplicando contextos SELinux para contêineres, que definem como os processos interagem com recursos no sistema.
|
||||
3. Sistema de arquivos raiz somente leitura: Impedindo que contêineres modifiquem arquivos em certos diretórios.
|
||||
4. Diretórios e volumes de host permitidos: Especificando quais diretórios e volumes de host um pod pode montar.
|
||||
5. Executar como UID/GID: Especificando os IDs de usuário e grupo sob os quais o processo do contêiner é executado.
|
||||
@@ -27,7 +27,7 @@ Esta camada de segurança adicional, por padrão, proíbe a criação de pods pr
|
||||
../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/pod-escape-privileges.md
|
||||
{{#endref}}
|
||||
|
||||
## Lista SCC
|
||||
## Listar SCC
|
||||
|
||||
Para listar todos os SCC com o Openshift Client:
|
||||
```bash
|
||||
|
||||
Reference in New Issue
Block a user