mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-29 14:13:20 -08:00
Translated ['.github/pull_request_template.md', 'src/README.md', 'src/pe
This commit is contained in:
Translator
@@ -8,7 +8,7 @@ Bevor Sie mit OpenShift arbeiten, stellen Sie sicher, dass Sie mit der Kubernete
|
||||
|
||||
### Einführung
|
||||
|
||||
OpenShift ist die Container-Anwendungsplattform von Red Hat, die eine Erweiterung der Kubernetes-Funktionen bietet. OpenShift hat strengere Sicherheitsrichtlinien. Zum Beispiel ist es verboten, einen Container als Root auszuführen. Es bietet auch eine standardmäßig sichere Option zur Verbesserung der Sicherheit. OpenShift verfügt über eine Webkonsole, die eine Ein-Klick-Anmeldeseite umfasst.
|
||||
OpenShift ist die Container-Anwendungsplattform von Red Hat, die eine Superset von Kubernetes-Funktionen bietet. OpenShift hat strengere Sicherheitsrichtlinien. Zum Beispiel ist es verboten, einen Container als Root auszuführen. Es bietet auch eine standardmäßig sichere Option zur Verbesserung der Sicherheit. OpenShift verfügt über eine Webkonsole, die eine Ein-Klick-Login-Seite umfasst.
|
||||
|
||||
#### CLI
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@ Diese Seite gibt einige Hinweise, wie Sie eine Jenkins-Instanz angreifen können
|
||||
|
||||
## Haftungsausschluss
|
||||
|
||||
Eine Jenkins-Instanz kann sowohl in einem Openshift- als auch in einem Kubernetes-Cluster bereitgestellt werden. Je nach Kontext müssen Sie möglicherweise jede gezeigte Payload, YAML oder Technik anpassen. Für weitere Informationen zum Angreifen von Jenkins können Sie [diese Seite](../../../pentesting-ci-cd/jenkins-security/) besuchen.
|
||||
Eine Jenkins-Instanz kann sowohl in einem Openshift- als auch in einem Kubernetes-Cluster bereitgestellt werden. Je nach Kontext müssen Sie möglicherweise jede angezeigte Payload, YAML oder Technik anpassen. Für weitere Informationen zum Angreifen von Jenkins können Sie [diese Seite](../../../pentesting-ci-cd/jenkins-security/) besuchen.
|
||||
|
||||
## Voraussetzungen
|
||||
|
||||
@@ -18,7 +18,7 @@ Grundsätzlich funktioniert fast alles im Hintergrund genauso wie bei einer regu
|
||||
|
||||
### Builds
|
||||
|
||||
Wenn ein Build ausgelöst wird, wird er zuerst vom Jenkins-Masterknoten verwaltet/orchestriert und dann an einen Agenten/Sklaven/Arbeiter delegiert. In diesem Kontext ist der Masterknoten nur ein regulärer Pod, der in einem Namespace läuft (der möglicherweise anders ist als der, in dem die Arbeiter laufen). Dasselbe gilt für die Arbeiter/Sklaven, jedoch werden sie zerstört, sobald der Build abgeschlossen ist, während der Master immer aktiv bleibt. Ihr Build wird normalerweise innerhalb eines Pods ausgeführt, unter Verwendung einer standardmäßigen Pod-Vorlage, die von den Jenkins-Administratoren definiert wurde.
|
||||
Wenn ein Build ausgelöst wird, wird er zuerst vom Jenkins-Masterknoten verwaltet/orchestriert und dann an einen Agenten/Sklaven/Arbeiter delegiert. In diesem Kontext ist der Masterknoten nur ein regulärer Pod, der in einem Namespace läuft (der möglicherweise anders ist als der, in dem die Arbeiter laufen). Das Gleiche gilt für die Arbeiter/Sklaven, jedoch werden sie zerstört, sobald der Build abgeschlossen ist, während der Master immer aktiv bleibt. Ihr Build wird normalerweise innerhalb eines Pods ausgeführt, unter Verwendung einer standardmäßigen Pod-Vorlage, die von den Jenkins-Administratoren definiert wurde.
|
||||
|
||||
### Auslösen eines Builds
|
||||
|
||||
@@ -26,7 +26,7 @@ Sie haben mehrere Hauptmöglichkeiten, um einen Build auszulösen, wie zum Beisp
|
||||
|
||||
1. Sie haben UI-Zugriff auf Jenkins
|
||||
|
||||
Eine sehr einfache und bequeme Möglichkeit ist die Verwendung der Replay-Funktionalität eines vorhandenen Builds. Damit können Sie einen zuvor ausgeführten Build erneut abspielen und gleichzeitig das Groovy-Skript aktualisieren. Dies erfordert Berechtigungen für einen Jenkins-Ordner und eine vordefinierte Pipeline. Wenn Sie unauffällig sein müssen, können Sie Ihre ausgelösten Builds löschen, wenn Sie genügend Berechtigungen haben.
|
||||
Eine sehr einfache und bequeme Möglichkeit ist die Verwendung der Replay-Funktionalität eines vorhandenen Builds. Sie ermöglicht es Ihnen, einen zuvor ausgeführten Build erneut abzuspielen, während Sie das Groovy-Skript aktualisieren können. Dies erfordert Berechtigungen für einen Jenkins-Ordner und eine vordefinierte Pipeline. Wenn Sie unauffällig sein müssen, können Sie Ihre ausgelösten Builds löschen, wenn Sie genügend Berechtigungen haben.
|
||||
|
||||
2. Sie haben Schreibzugriff auf das SCM und automatisierte Builds sind über Webhook konfiguriert
|
||||
|
||||
|
||||
@@ -34,10 +34,9 @@ sh 'mvn -B -ntp clean install'
|
||||
}
|
||||
}
|
||||
```
|
||||
## Einige Missbräuche, die Pod-YAML-Overrides ausnutzen
|
||||
## Einige Missbräuche unter Verwendung von Pod-YAML-Overrides
|
||||
|
||||
Es kann jedoch missbraucht werden, um jedes zugängliche Image wie Kali Linux zu verwenden und beliebige Befehle mit vorinstallierten Tools aus diesem Image auszuführen.
|
||||
Im folgenden Beispiel können wir das Serviceaccount-Token des laufenden Pods exfiltrieren.
|
||||
Es kann jedoch missbraucht werden, um jedes zugängliche Image wie Kali Linux zu verwenden und beliebige Befehle mit vorinstallierten Tools aus diesem Image auszuführen. Im folgenden Beispiel können wir das Serviceaccount-Token des laufenden Pods exfiltrieren.
|
||||
```groovy
|
||||
podTemplate(yaml: '''
|
||||
apiVersion: v1
|
||||
@@ -128,7 +127,7 @@ sh 'env'
|
||||
}
|
||||
}
|
||||
```
|
||||
Ein weiteres Beispiel, das versucht, ein serviceaccount zu mounten (das möglicherweise mehr Berechtigungen hat als das Standardkonto, das Ihren Build ausführt), basierend auf seinem Namen. Möglicherweise müssen Sie zuerst vorhandene serviceaccounts erraten oder auflisten.
|
||||
Ein weiteres Beispiel, das versucht, ein Servicekonto zu mounten (das möglicherweise mehr Berechtigungen hat als das Standardkonto, das Ihren Build ausführt), basierend auf seinem Namen. Möglicherweise müssen Sie zuerst vorhandene Servicekonten erraten oder auflisten.
|
||||
```groovy
|
||||
pipeline {
|
||||
stages {
|
||||
@@ -174,7 +173,7 @@ Stellen Sie sich die folgenden Fragen:
|
||||
- Kann ich weitere Build-Pods auflisten?
|
||||
- Kann ich von einem kompromittierten sa aus Befehle auf dem Master-Knoten/Pod ausführen?
|
||||
- Kann ich den Cluster weiter auflisten, um woanders zu pivotieren?
|
||||
- Welches SCC wird angewendet?
|
||||
- Welches SCC ist angewendet?
|
||||
|
||||
Sie können herausfinden, welche oc/kubectl-Befehle auszuführen sind [hier](../openshift-basic-information.md) und [hier](../../kubernetes-security/kubernetes-enumeration.md).
|
||||
|
||||
@@ -220,7 +219,7 @@ Je nach Ihrem Zugriff müssen Sie entweder Ihren Angriff vom Build-Skript aus fo
|
||||
```bash
|
||||
oc login --token=$token --server=https://apiserver.com:port
|
||||
```
|
||||
Wenn dieser sa über ausreichende Berechtigungen verfügt (wie pod/exec), können Sie auch die gesamte Jenkins-Instanz übernehmen, indem Sie Befehle im Pod des Master-Knotens ausführen, sofern er im selben Namespace läuft. Sie können diesen Pod leicht anhand seines Namens und der Tatsache identifizieren, dass er ein PVC (Persistent Volume Claim) einbinden muss, das zur Speicherung von Jenkins-Daten verwendet wird.
|
||||
Wenn dieser sa über ausreichende Berechtigungen verfügt (wie pod/exec), können Sie auch die gesamte Jenkins-Instanz übernehmen, indem Sie Befehle im Pod des Masterknotens ausführen, sofern er im selben Namespace läuft. Sie können diesen Pod leicht anhand seines Namens und der Tatsache identifizieren, dass er ein PVC (Persistent Volume Claim) einbinden muss, das zur Speicherung von Jenkins-Daten verwendet wird.
|
||||
```bash
|
||||
oc rsh pod_name -c container_name
|
||||
```
|
||||
|
||||
@@ -1,22 +1,22 @@
|
||||
# OpenShift - Fehlender Service-Account
|
||||
# OpenShift - Fehlendes Service-Konto
|
||||
|
||||
## Fehlender Service-Account
|
||||
## Fehlendes Service-Konto
|
||||
|
||||
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.
|
||||
Es kommt vor, dass ein Cluster mit einer vorkonfigurierten Vorlage bereitgestellt wird, die automatisch Rollen, RoleBindings und sogar SCC für ein Service-Konto festlegt, das 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 das fehlende SA Teil eines fehlenden Projekts ist; in diesem Fall, wenn Sie das Projekt und dann das 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>
|
||||
|
||||
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.
|
||||
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 ein AbsentServiceAccount.
|
||||
|
||||
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.
|
||||
Wenn wir ein Projekt und das fehlende SA darin erstellen können, wird das SA von der Rolle oder dem SCC erben, die auf das AbsentServiceAccount abzielten. Dies kann zu einer Privilegieneskalation führen.
|
||||
|
||||
Das folgende Beispiel zeigt einen fehlenden SA, dem node-exporter SCC gewährt wird:
|
||||
Das folgende Beispiel zeigt ein fehlendes SA, dem node-exporter SCC gewährt wird:
|
||||
|
||||
<figure><img src="../../../images/openshift-missing-service-account-image2.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
## Tools
|
||||
|
||||
Das folgende Tool kann verwendet werden, um dieses Problem zu enumerieren und allgemeiner, um einen OpenShift-Cluster zu grafieren:
|
||||
Das folgende Tool kann verwendet werden, um dieses Problem zu enumerieren und allgemeiner ein OpenShift-Cluster zu grafisch darzustellen:
|
||||
|
||||
{{#ref}}
|
||||
https://github.com/maxDcb/OpenShiftGrapher
|
||||
|
||||
@@ -13,7 +13,7 @@ Standardmäßig wird SCC nicht auf folgenden Projekten angewendet:
|
||||
- **openshift-infra**
|
||||
- **openshift**
|
||||
|
||||
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.
|
||||
Wenn Sie Pods in einem dieser Namespaces bereitstellen, wird kein SCC durchgesetzt, was die Bereitstellung von privilegierten Pods oder das Einbinden des Host-Dateisystems ermöglicht.
|
||||
|
||||
## Namespace-Label
|
||||
|
||||
@@ -28,7 +28,7 @@ yes
|
||||
$ oc auth can-i patch namespaces
|
||||
yes
|
||||
```
|
||||
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.
|
||||
Das 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>
|
||||
|
||||
@@ -94,7 +94,7 @@ Jetzt ist es einfacher geworden, Privilegien zu eskalieren, um auf das Hostsyste
|
||||
|
||||
### Benutzerdefinierte Labels
|
||||
|
||||
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.
|
||||
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 oder eine bestimmte Ressource einzuschränken oder nicht.
|
||||
|
||||
Versuchen Sie, nach benutzerdefinierten Labels zu suchen, wenn Sie einige Ressourcen lesen können. Hier ist eine Liste interessanter Ressourcen:
|
||||
|
||||
@@ -113,11 +113,11 @@ $ oc get project -o yaml | grep 'run-level' -b5
|
||||
```
|
||||
## Fortgeschrittener 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, 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 Teil des Designs von OpenShift ist.
|
||||
|
||||
Allerdings können Maßnahmen wie **Open Policy Agent GateKeeper** verhindern, dass Benutzer dieses Label setzen.
|
||||
|
||||
Um die Regeln von GateKeeper zu umgehen und dieses Label zu setzen, um eine Cluster-Übernahme durchzuführen, **müssten Angreifer alternative Methoden identifizieren.**
|
||||
Um die Regeln von GateKeeper zu umgehen und dieses Label zu setzen, um eine Cluster-Übernahme durchzuführen, **müssen Angreifer alternative Methoden identifizieren.**
|
||||
|
||||
## Referenzen
|
||||
|
||||
|
||||
@@ -43,7 +43,7 @@ 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.
|
||||
Der Tekton-Operator wird dem Pipeline-Dienstkonto im `test-namespace` die Fähigkeit geben, die scc privileged zu verwenden. Dies ermöglicht das Mounten des Knotens.
|
||||
|
||||
### Die Lösung
|
||||
|
||||
|
||||
@@ -4,16 +4,16 @@
|
||||
|
||||
## Definition
|
||||
|
||||
Im Kontext von OpenShift steht SCC für **Security Context Constraints**. Security Context Constraints sind Richtlinien, die Berechtigungen für Pods steuern, die auf OpenShift-Clustern ausgeführt werden. Sie definieren die Sicherheitsparameter, unter denen ein Pod ausgeführt werden darf, einschließlich der Aktionen, die er ausführen kann, und der Ressourcen, auf die er zugreifen kann.
|
||||
Im Kontext von OpenShift steht SCC für **Security Context Constraints**. Security Context Constraints sind Richtlinien, die Berechtigungen für Pods, die auf OpenShift-Clustern ausgeführt werden, steuern. Sie definieren die Sicherheitsparameter, unter denen ein Pod ausgeführt werden darf, einschließlich der Aktionen, die er ausführen kann, und der Ressourcen, auf die er zugreifen kann.
|
||||
|
||||
SCCs helfen Administratoren, Sicherheitsrichtlinien im gesamten Cluster durchzusetzen, indem sichergestellt wird, dass Pods mit angemessenen Berechtigungen ausgeführt werden und den organisatorischen Sicherheitsstandards entsprechen. Diese Einschränkungen können verschiedene Aspekte der Podsicherheit spezifizieren, wie zum Beispiel:
|
||||
|
||||
1. Linux-Fähigkeiten: Einschränkung der für Container verfügbaren Fähigkeiten, wie die Fähigkeit, privilegierte Aktionen auszuführen.
|
||||
2. SELinux-Kontext: Durchsetzung von SELinux-Kontexten für Container, die definieren, wie Prozesse mit Ressourcen im System interagieren.
|
||||
3. Nur-Lese-Wurzel-Dateisystem: Verhinderung, dass Container Dateien in bestimmten Verzeichnissen ändern.
|
||||
3. Nur-Lese-Root-Dateisystem: Verhinderung von Änderungen an Dateien in bestimmten Verzeichnissen durch Container.
|
||||
4. Erlaubte Hostverzeichnisse und -volumes: Spezifizierung, welche Hostverzeichnisse und -volumes ein Pod einbinden kann.
|
||||
5. Ausführen als UID/GID: Spezifizierung der Benutzer- und Gruppen-IDs, unter denen der Containerprozess läuft.
|
||||
6. Netzwerkrichtlinien: Steuerung des Netzwerkzugriffs für Pods, wie z.B. Einschränkung des ausgehenden Datenverkehrs.
|
||||
6. Netzwerkrichtlinien: Steuerung des Netzwerkzugriffs für Pods, wie z.B. Einschränkung des Egress-Verkehrs.
|
||||
|
||||
Durch die Konfiguration von SCCs können Administratoren sicherstellen, dass Pods mit dem angemessenen Maß an Sicherheitsisolierung und Zugriffskontrollen ausgeführt werden, wodurch das Risiko von Sicherheitsanfälligkeiten oder unbefugtem Zugriff innerhalb des Clusters verringert wird.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user