mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-08 05:17:43 -07:00
Translated ['.github/pull_request_template.md', 'src/README.md', 'src/pe
This commit is contained in:
Translator
@@ -1,4 +1,4 @@
|
||||
# OpenShift - Escalação de Privilégios
|
||||
# OpenShift - Escalada de Privilégios
|
||||
|
||||
## Conta de Serviço Ausente
|
||||
|
||||
|
||||
+4
-4
@@ -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
|
||||
|
||||
+3
-3
@@ -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.
|
||||
|
||||
|
||||
+3
-3
@@ -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/
|
||||
|
||||
Reference in New Issue
Block a user