OpenShift - SCC bypass
Der ursprüngliche Autor dieser Seite ist Guillaume
Privilegierte Namespaces
Standardmäßig gilt SCC nicht für die folgenden Projekte:
default
kube-system
kube-public
openshift-node
openshift-infra
openshift
Wenn Sie Pods in einem dieser Namespaces bereitstellen, wird kein SCC durchgesetzt, was die Bereitstellung privilegierter Pods oder das Einhängen des Host-Dateisystems ermöglicht.
Namespace-Label
Laut der RedHat-Dokumentation gibt es eine Möglichkeit, die SCC-Anwendung auf Ihrem Pod zu deaktivieren. Sie benötigen mindestens eine der folgenden Berechtigungen:
Erstellen Sie einen Namespace und erstellen Sie einen Pod in diesem Namespace.
Bearbeiten Sie einen Namespace und erstellen Sie einen Pod in diesem Namespace.
Die spezifische Bezeichnung openshift.io/run-level
ermöglicht es Benutzern, SCCs für Anwendungen zu umgehen. Gemäß der RedHat-Dokumentation, wenn dieses Label verwendet wird, werden keine SCCs auf alle Pods innerhalb dieses Namensraums durchgesetzt, wodurch alle Einschränkungen effektiv aufgehoben werden.
Label hinzufügen
Um das Label in Ihrem Namensraum hinzuzufügen:
Um einen Namespace mit dem Label über eine YAML-Datei zu erstellen:
Nun sollten alle neuen Pods, die im Namespace erstellt werden, keine SCC haben
In Abwesenheit von SCC gibt es keine Einschränkungen für Ihre Pod-Definition. Dies bedeutet, dass ein bösartiger Pod problemlos erstellt werden kann, um auf das Host-System zu entkommen.
Jetzt ist es einfacher geworden, Berechtigungen zu eskalieren, um auf das Host-System zuzugreifen und anschließend die gesamte Cluster-Kontrolle zu übernehmen und 'cluster-admin'-Berechtigungen zu erlangen. Suchen Sie nach dem Node-Post Exploitation-Teil auf der folgenden Seite:
Benutzerdefinierte Labels
Darüber hinaus können je nach Zielsetup einige benutzerdefinierte Labels / Annotationen auf die gleiche Weise wie im vorherigen Angriffsszenario verwendet werden. Auch wenn es nicht dafür vorgesehen ist, könnten Labels verwendet werden, um Berechtigungen zu erteilen, Ressourcen einzuschränken oder nicht einzuschränken.
Versuchen Sie, benutzerdefinierte Labels zu finden, wenn Sie auf einige Ressourcen zugreifen können. Hier ist eine Liste interessanter Ressourcen:
Pod
Deployment
Namespace
Service
Route
Liste aller privilegierten Namespaces
Fortgeschrittener Exploit
In OpenShift kann das Berechtigen zum Bereitstellen eines Pods in einem Namespace mit dem Label openshift.io/run-level
wie zuvor demonstriert zu einer unkomplizierten Übernahme des Clusters führen. Aus der Perspektive der Cluster-Einstellungen kann diese Funktionalität nicht deaktiviert werden, da sie inherent für das Design von OpenShift ist.
Jedoch können Maßnahmen zur Minderung wie Open Policy Agent GateKeeper Benutzer daran hindern, dieses Label zu setzen.
Um GateKeeper-Regeln zu umgehen und dieses Label zu setzen, um eine Cluster-Übernahme durchzuführen, müssten Angreifer alternative Methoden identifizieren.
Referenzen
Last updated