mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-30 06:30:35 -08:00
Translated ['.github/pull_request_template.md', 'src/README.md', 'src/pe
This commit is contained in:
Translator
@@ -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
|
||||
|
||||
|
||||
Reference in New Issue
Block a user