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

Translated ['.github/pull_request_template.md', 'src/README.md', 'src/pe

Browse Source
This commit is contained in:
Translator
2025-01-02 00:01:28 +00:00
parent 4bcd54c1b6
commit c0ee8b41f2
215 changed files with 1371 additions and 1387 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -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