gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-07-01 10:35:06 -07:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['.github/pull_request_template.md', 'src/pentesting-cloud/az

Browse Source
This commit is contained in:
Translator
2024-12-31 18:56:17 +00:00
parent 7770a50092
commit ea97a1362c
244 changed files with 8836 additions and 11682 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/README.md
+3 -7
View File
@@ -1,6 +1,6 @@
# OpenShift - Privilege Escalation
# OpenShift - Escalação de Privilégios
## Missing Service Account
## Conta de Serviço Ausente
{{#ref}}
openshift-missing-service-account.md
@@ -12,12 +12,8 @@ openshift-missing-service-account.md
openshift-tekton.md
{{#endref}}
## SCC Bypass
## Bypass de SCC
{{#ref}}
openshift-scc-bypass.md
{{#endref}}
src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-missing-service-account.md
+8 -12
View File
@@ -1,27 +1,23 @@
# OpenShift - Missing Service Account
# OpenShift - Conta de Serviço Ausente
## Missing Service Account
## Conta de Serviço Ausente
It happens that cluster is deployed with preconfigured template automatically setting Roles, RoleBindings and even SCC to service account that is not yet created. This can lead to privilege escalation in the case where you can create them. In this case, you would be able to get the token of the SA newly created and the role or SCC associated. Same case happens when the missing SA is part of a missing project, in this case if you can create the project and then the SA you get the Roles and SCC associated.
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.
<figure><img src="../../../images/openshift-missing-service-account-image1.png" alt=""><figcaption></figcaption></figure>
In the previous graph we got multiple AbsentProject meaning multiple project that appears in Roles Bindings or SCC but are not yet created in the cluster. In the same vein we also got an AbsentServiceAccount.
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.
If we can create a project and the missing SA in it, the SA will inherited from the Role or the SCC that were targeting the AbsentServiceAccount. Which can lead to privilege escalation.
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.
The following example show a missing SA which is granted node-exporter SCC:
O seguinte exemplo mostra uma SA ausente que é concedida ao SCC node-exporter:
<figure><img src="../../../images/openshift-missing-service-account-image2.png" alt=""><figcaption></figcaption></figure>
## Tools
## Ferramentas
The following tool can be use to enumerate this issue and more generally to graph an OpenShift cluster:
A seguinte ferramenta pode ser usada para enumerar esse problema e, mais geralmente, para mapear um cluster OpenShift:
{{#ref}}
https://github.com/maxDcb/OpenShiftGrapher
{{#endref}}
src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-scc-bypass.md
+56 -72
View File
@@ -1,10 +1,10 @@
# Openshift - SCC bypass
**The original author of this page is** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
**O autor original desta página é** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
## Privileged Namespaces
## Namespaces Privilegiados
By default, SCC does not apply on following projects :
Por padrão, o SCC não se aplica aos seguintes projetos:
- **default**
- **kube-system**
@@ -13,130 +13,114 @@ By default, SCC does not apply on following projects :
- **openshift-infra**
- **openshift**
If you deploy pods within one of those namespaces, no SCC will be enforced, allowing for the deployment of privileged pods or mounting of the host file system.
Se você implantar pods dentro de um desses namespaces, nenhum SCC será aplicado, permitindo a implantação de pods privilegiados ou a montagem do sistema de arquivos do host.
## Namespace Label
## Rótulo de Namespace
There is a way to disable the SCC application on your pod according to RedHat documentation. You will need to have at least one of the following permission :
- Create a Namespace and Create a Pod on this Namespace
- Edit a Namespace and Create a Pod on this Namespace
Há uma maneira de desativar a aplicação do SCC em seu pod de acordo com a documentação da RedHat. Você precisará ter pelo menos uma das seguintes permissões:
- Criar um Namespace e Criar um Pod neste Namespace
- Editar um Namespace e Criar um Pod neste Namespace
```bash
$ oc auth can-i create namespaces
yes
yes
$ oc auth can-i patch namespaces
yes
yes
```
The specific label`openshift.io/run-level` enables users to circumvent SCCs for applications. As per RedHat documentation, when this label is utilized, no SCCs are enforced on all pods within that namespace, effectively removing any restrictions.
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.
<figure><img src="../../../images/Openshift-RunLevel4.png" alt=""><figcaption></figcaption></figure>
## Add Label
To add the label in your namespace :
## Adicionar Etiqueta
Para adicionar a etiqueta no seu namespace:
```bash
$ oc label ns MYNAMESPACE openshift.io/run-level=0
```
To create a namespace with the label through a YAML file:
Para criar um namespace com o rótulo através de um arquivo YAML:
```yaml
apiVersion: v1
kind: Namespace
metadata:
name: evil
labels:
openshift.io/run-level: 0
name: evil
labels:
openshift.io/run-level: 0
```
Now, all new pods created on the namespace should not have any SCC
Agora, todos os novos pods criados no namespace não devem ter nenhum SCC
<pre class="language-bash"><code class="lang-bash"><strong>$ oc get pod -o yaml | grep 'openshift.io/scc'
</strong><strong>$
</strong><strong>$
</strong></code></pre>
In the absence of SCC, there are no restrictions on your pod definition. This means that a malicious pod can be easily created to escape onto the host system.
Na ausência de SCC, não há restrições na definição do seu pod. Isso significa que um pod malicioso pode ser facilmente criado para escapar para o sistema host.
```yaml
apiVersion: v1
kind: Pod
metadata:
name: evilpod
labels:
kubernetes.io/hostname: evilpod
name: evilpod
labels:
kubernetes.io/hostname: evilpod
spec:
hostNetwork: true #Bind pod network to the host network
hostPID: true #See host processes
hostIPC: true #Access host inter processes
containers:
- name: evil
image: MYIMAGE
imagePullPolicy: IfNotPresent
securityContext:
privileged: true
allowPrivilegeEscalation: true
resources:
limits:
memory: 200Mi
requests:
cpu: 30m
memory: 100Mi
volumeMounts:
- name: hostrootfs
mountPath: /mnt
volumes:
- name: hostrootfs
hostPath:
path:
hostNetwork: true #Bind pod network to the host network
hostPID: true #See host processes
hostIPC: true #Access host inter processes
containers:
- name: evil
image: MYIMAGE
imagePullPolicy: IfNotPresent
securityContext:
privileged: true
allowPrivilegeEscalation: true
resources:
limits:
memory: 200Mi
requests:
cpu: 30m
memory: 100Mi
volumeMounts:
- name: hostrootfs
mountPath: /mnt
volumes:
- name: hostrootfs
hostPath:
path:
```
Now, it has become easier to escalate privileges to access the host system and subsequently take over the entire cluster, gaining 'cluster-admin' privileges. Look for **Node-Post Exploitation** part in the following page :
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:
{{#ref}}
../../kubernetes-security/attacking-kubernetes-from-inside-a-pod.md
{{#endref}}
### Custom labels
### Rótulos personalizados
Furthermore, based on the target setup, some custom labels / annotations may be used in the same way as the previous attack scenario. Even if it is not made for, labels could be used to give permissions, restrict or not a specific resource.
Além disso, com base na configuração alvo, alguns rótulos / anotações personalizados podem ser usados da mesma forma que no cenário de ataque anterior. Mesmo que não seja feito para isso, rótulos podem ser usados para conceder permissões, restringir ou não um recurso específico.
Try to look for custom labels if you can read some resources. Here a list of interesting resources :
Tente procurar por rótulos personalizados se você puder ler alguns recursos. Aqui está uma lista de recursos interessantes:
- Pod
- Deployment
- Namespace
- Service
- Route
```bash
$ oc get pod -o yaml | grep labels -A 5
$ oc get namespace -o yaml | grep labels -A 5
```
## List all privileged namespaces
## Liste todos os namespaces privilegiados
```bash
$ oc get project -o yaml | grep 'run-level' -b5
```
## Exploit avançado
## Advanced exploit
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.
In OpenShift, as demonstrated earlier, having permission to deploy a pod in a namespace with the `openshift.io/run-level`label can lead to a straightforward takeover of the cluster. From a cluster settings perspective, this functionality **cannot be disabled**, as it is inherent to OpenShift's design.
No entanto, medidas de mitigação como **Open Policy Agent GateKeeper** podem impedir que os usuários definam esse rótulo.
However, mitigation measures like **Open Policy Agent GateKeeper** can prevent users from setting this label.
Para contornar as regras do GateKeeper e definir esse rótulo para executar uma tomada de controle do cluster, **os atacantes precisariam identificar métodos alternativos.**
To bypass GateKeeper's rules and set this label to execute a cluster takeover, **attackers would need to identify alternative methods.**
## References
## Referências
- [https://docs.openshift.com/container-platform/4.8/authentication/managing-security-context-constraints.html](https://docs.openshift.com/container-platform/4.8/authentication/managing-security-context-constraints.html)
- [https://docs.openshift.com/container-platform/3.11/admin_guide/manage_scc.html](https://docs.openshift.com/container-platform/3.11/admin_guide/manage_scc.html)
- [https://github.com/open-policy-agent/gatekeeper](https://github.com/open-policy-agent/gatekeeper)
src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-tekton.md
+32 -40
View File
@@ -1,79 +1,71 @@
# OpenShift - Tekton
**The original author of this page is** [**Haroun**](https://www.linkedin.com/in/haroun-al-mounayar-571830211)
**O autor original desta página é** [**Haroun**](https://www.linkedin.com/in/haroun-al-mounayar-571830211)
### What is tekton
### O que é tekton
According to the doc: _Tekton is a powerful and flexible open-source framework for creating CI/CD systems, allowing developers to build, test, and deploy across cloud providers and on-premise systems._ Both Jenkins and Tekton can be used to test, build and deploy applications, however Tekton is Cloud Native.&#x20;
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.&#x20;
With Tekton everything is represented by YAML files. Developers can create Custom Resources (CR) of type `Pipelines` and specify multiple `Tasks` in them that they want to run. To run a Pipeline resources of type `PipelineRun` must be created.
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.
When tekton is installed a service account (sa) called pipeline is created in every namespace. When a Pipeline is ran, a pod will be spawned using this sa called `pipeline` to run the tasks defined in the YAML file.
Quando o tekton é instalado, uma conta de serviço (sa) chamada pipeline é criada em cada namespace. Quando um Pipeline é executado, um pod será gerado usando esta sa chamada `pipeline` para executar as tarefas definidas no arquivo YAML.
{{#ref}}
https://tekton.dev/docs/getting-started/pipelines/
{{#endref}}
### The Pipeline service account capabilities
By default, the pipeline service account can use the `pipelines-scc` capability. This is due to the global default configuration of tekton. Actually, the global config of tekton is also a YAML in an openshift object called `TektonConfig` that can be seen if you have some reader roles in the cluster.
### 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.
```yaml
apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
name: config
name: config
spec:
...
...
platforms:
openshift:
scc:
default: "pipelines-scc"
...
...
platforms:
openshift:
scc:
default: "pipelines-scc"
```
Em qualquer namespace, se você conseguir obter o token da conta de serviço do pipeline, poderá usar `pipelines-scc`.
In any namespace, if you can get the pipeline service account token you will be able to use `pipelines-scc`.
### The Misconfig
The problem is that the default scc that the pipeline sa can use is user controllable. This can be done using a label in the namespace definition. For instance, if I can create a namespace with the following yaml definition:
### A Misconfiguração
O problema é que o scc padrão que a conta de serviço do pipeline pode usar é controlável pelo usuário. Isso pode ser feito usando um rótulo na definição do namespace. Por exemplo, se eu puder criar um namespace com a seguinte definição em yaml:
```yaml
apiVersion: v1
kind: Namespace
metadata:
name: test-namespace
annotations:
operator.tekton.dev/scc: privileged
name: test-namespace
annotations:
operator.tekton.dev/scc: privileged
```
O operador tekton dará à conta de serviço do pipeline em `test-namespace` a capacidade de usar o scc privilegiado. Isso permitirá a montagem do nó.
The tekton operator will give to the pipeline service account in `test-namespace` the ability to use the scc privileged. This will allow the mounting of the node.
### A correção
### The fix
Tekton documents about how to restrict the override of scc by adding a label in the `TektonConfig` object.
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/
{{#endref}}
This label is called `max-allowed`&#x20;
Esse rótulo é chamado de `max-allowed`&#x20;
```yaml
apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
name: config
name: config
spec:
...
...
platforms:
openshift:
scc:
default: "restricted-v2"
maxAllowed: "privileged"
...
...
platforms:
openshift:
scc:
default: "restricted-v2"
maxAllowed: "privileged"
```