OpenShift - SCC bypass
本页面的原作者是 Guillaume
特权命名空间
默认情况下,SCC不适用于以下项目:
default
kube-system
kube-public
openshift-node
openshift-infra
openshift
如果您在这些命名空间之一部署Pod,将不会执行任何SCC,允许部署特权Pod或挂载主机文件系统。
命名空间标签
根据RedHat文档,有一种方法可以禁用Pod上的SCC应用程序。您将需要至少具备以下权限之一:
在命名空间上创建Pod
编辑命名空间并在该命名空间上创建Pod
特定标签 openshift.io/run-level
使用户能够绕过应用程序的 SCC。根据 RedHat 文档,当使用此标签时,在该命名空间中的所有 pod 上不会执行任何 SCC,有效地移除了任何限制。
添加标签
要在您的命名空间中添加标签:
要通过一个YAML文件创建一个带有标签的命名空间:
现在,在该命名空间上创建的所有新 pod 不应该有任何 SCC
在没有 SCC 的情况下,对您的 pod 定义没有任何限制。这意味着可以轻松创建恶意 pod 以逃逸到主机系统。
现在,提升权限以访问主机系统并随后接管整个集群,获取 'cluster-admin' 权限变得更加容易。在以下页面中查找 Node-Post Exploitation 部分:
Attacking Kubernetes from inside a Pod自定义标签
此外,根据目标设置,一些自定义标签 / 注释可能会以与先前攻击场景相同的方式使用。即使不是为此目的,标签也可以用于授予权限、限制或不限制特定资源。
尝试查找自定义标签,如果可以读取一些资源的话。以下是一些有趣的资源列表:
Pod
Deployment
Namespace
Service
Route
列出所有特权命名空间
高级利用
在 OpenShift 中,正如之前演示的,拥有在带有 openshift.io/run-level
标签的命名空间中部署 pod 的权限可能导致对集群的简单接管。从集群设置的角度来看,这种功能无法被禁用,因为它是 OpenShift 设计的固有部分。
然而,诸如Open Policy Agent GateKeeper之类的缓解措施可以阻止用户设置此标签。
为了绕过 GateKeeper 的规则并设置此标签以执行集群接管,攻击者需要识别替代方法。
参考资料
Last updated