mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-31 07:00:38 -08:00
Translated ['.github/pull_request_template.md', 'src/README.md', 'src/pe
This commit is contained in:
Translator
@@ -1,6 +1,6 @@
|
||||
# OpenShift - Informations de base
|
||||
|
||||
## Kubernetes connaissances b**asiques** <a href="#a94e" id="a94e"></a>
|
||||
## Connaissances préalables en Kubernetes <a href="#a94e" id="a94e"></a>
|
||||
|
||||
Avant de travailler avec OpenShift, assurez-vous d'être à l'aise avec l'environnement Kubernetes. Tout le chapitre OpenShift suppose que vous avez des connaissances préalables en Kubernetes.
|
||||
|
||||
@@ -8,11 +8,11 @@ Avant de travailler avec OpenShift, assurez-vous d'être à l'aise avec l'enviro
|
||||
|
||||
### Introduction
|
||||
|
||||
OpenShift est la plateforme d'application conteneurisée de Red Hat qui offre un surensemble des fonctionnalités de Kubernetes. OpenShift a des politiques de sécurité plus strictes. Par exemple, il est interdit d'exécuter un conteneur en tant que root. Il offre également une option sécurisée par défaut pour améliorer la sécurité. OpenShift dispose d'une console web qui inclut une page de connexion en un clic.
|
||||
OpenShift est la plateforme d'application conteneurisée de Red Hat qui offre un surensemble des fonctionnalités de Kubernetes. OpenShift a des politiques de sécurité plus strictes. Par exemple, il est interdit d'exécuter un conteneur en tant que root. Il offre également une option sécurisée par défaut pour améliorer la sécurité. OpenShift dispose d'une console web qui inclut une page de connexion à un seul clic.
|
||||
|
||||
#### CLI
|
||||
|
||||
OpenShift est livré avec sa propre CLI, que vous pouvez trouver ici :
|
||||
OpenShift vient avec sa propre CLI, qui peut être trouvée ici :
|
||||
|
||||
{{#ref}}
|
||||
https://docs.openshift.com/container-platform/4.11/cli_reference/openshift_cli/getting-started-cli.html
|
||||
|
||||
@@ -6,27 +6,27 @@ Cette page donne quelques indications sur la façon dont vous pouvez attaquer un
|
||||
|
||||
## Avertissement
|
||||
|
||||
Une instance Jenkins peut être déployée dans un cluster Openshift ou Kubernetes. Selon votre contexte, vous devrez peut-être adapter tout payload, yaml ou technique montrée. Pour plus d'informations sur l'attaque de Jenkins, vous pouvez consulter [cette page](../../../pentesting-ci-cd/jenkins-security/).
|
||||
Une instance Jenkins peut être déployée à la fois dans un cluster Openshift ou Kubernetes. Selon votre contexte, vous devrez peut-être adapter tout payload, yaml ou technique montrée. Pour plus d'informations sur l'attaque de Jenkins, vous pouvez consulter [cette page](../../../pentesting-ci-cd/jenkins-security/).
|
||||
|
||||
## Prérequis
|
||||
|
||||
1a. Accès utilisateur dans une instance Jenkins OU 1b. Accès utilisateur avec permission d'écriture à un dépôt SCM où une construction automatisée est déclenchée après un push/merge.
|
||||
1a. Accès utilisateur dans une instance Jenkins OU 1b. Accès utilisateur avec autorisation d'écriture à un dépôt SCM où une construction automatisée est déclenchée après un push/merge.
|
||||
|
||||
## Comment ça fonctionne
|
||||
|
||||
Fondamentalement, presque tout ce qui se passe en arrière-plan fonctionne de la même manière qu'une instance Jenkins régulière fonctionnant dans une VM. La principale différence est l'architecture globale et la façon dont les constructions sont gérées à l'intérieur d'un cluster Openshift (ou Kubernetes).
|
||||
Fondamentalement, presque tout ce qui se passe en arrière-plan fonctionne de la même manière qu'une instance Jenkins régulière fonctionnant dans une VM. La principale différence est l'architecture globale et la façon dont les constructions sont gérées à l'intérieur d'un cluster openshift (ou kubernetes).
|
||||
|
||||
### Constructions
|
||||
|
||||
Lorsqu'une construction est déclenchée, elle est d'abord gérée/orchestrée par le nœud maître Jenkins, puis déléguée à un agent/esclave/travailleur. Dans ce contexte, le nœud maître est juste un pod régulier fonctionnant dans un namespace (qui peut être différent de celui où les travailleurs fonctionnent). Il en va de même pour les travailleurs/esclaves, cependant, ils sont détruits une fois la construction terminée, tandis que le maître reste toujours actif. Votre construction est généralement exécutée à l'intérieur d'un pod, en utilisant un modèle de pod par défaut défini par les administrateurs Jenkins.
|
||||
Lorsqu'une construction est déclenchée, elle est d'abord gérée/orchestrée par le nœud maître Jenkins, puis déléguée à un agent/esclave/travailleur. Dans ce contexte, le nœud maître est juste un pod régulier fonctionnant dans un namespace (qui pourrait être différent de celui où les travailleurs fonctionnent). Il en va de même pour les travailleurs/esclaves, cependant, ils sont détruits une fois la construction terminée, tandis que le maître reste toujours actif. Votre construction est généralement exécutée à l'intérieur d'un pod, en utilisant un modèle de pod par défaut défini par les administrateurs Jenkins.
|
||||
|
||||
### Déclenchement d'une construction
|
||||
|
||||
Vous avez plusieurs façons principales de déclencher une construction, telles que :
|
||||
|
||||
1. Vous avez accès à l'interface utilisateur de Jenkins
|
||||
1. Vous avez un accès UI à Jenkins
|
||||
|
||||
Une manière très facile et pratique est d'utiliser la fonctionnalité Replay d'une construction existante. Cela vous permet de rejouer une construction précédemment exécutée tout en vous permettant de mettre à jour le script groovy. Cela nécessite des privilèges sur un dossier Jenkins et un pipeline prédéfini. Si vous devez être furtif, vous pouvez supprimer vos constructions déclenchées si vous avez suffisamment de permissions.
|
||||
Une façon très facile et pratique est d'utiliser la fonctionnalité Replay d'une construction existante. Cela vous permet de rejouer une construction précédemment exécutée tout en vous permettant de mettre à jour le script groovy. Cela nécessite des privilèges sur un dossier Jenkins et un pipeline prédéfini. Si vous devez être furtif, vous pouvez supprimer vos constructions déclenchées si vous avez suffisamment de permissions.
|
||||
|
||||
2. Vous avez un accès en écriture au SCM et des constructions automatisées sont configurées via webhook
|
||||
|
||||
|
||||
@@ -34,9 +34,9 @@ sh 'mvn -B -ntp clean install'
|
||||
}
|
||||
}
|
||||
```
|
||||
## Some abuses leveraging pod yaml override
|
||||
## Certains abus tirant parti de l'override yaml de pod
|
||||
|
||||
Il peut cependant être abusé pour utiliser n'importe quelle image accessible, comme Kali Linux, et exécuter des commandes arbitraires en utilisant des outils préinstallés de cette image. Dans l'exemple ci-dessous, nous pouvons exfiltrer le jeton de service du pod en cours d'exécution.
|
||||
Il peut cependant être abusé pour utiliser n'importe quelle image accessible comme Kali Linux et exécuter des commandes arbitraires en utilisant des outils préinstallés de cette image. Dans l'exemple ci-dessous, nous pouvons exfiltrer le token de serviceaccount du pod en cours d'exécution.
|
||||
```groovy
|
||||
podTemplate(yaml: '''
|
||||
apiVersion: v1
|
||||
@@ -179,7 +179,7 @@ Vous pouvez découvrir quels commandes oc/kubectl émettre [ici](../openshift-ba
|
||||
|
||||
### Scénarios possibles de privesc/pivoting
|
||||
|
||||
Supposons que lors de votre évaluation, vous ayez découvert que tous les builds Jenkins s'exécutent dans un espace de noms appelé _worker-ns_. Vous avez découvert qu'un compte de service par défaut appelé _default-sa_ est monté sur les pods de build, cependant il n'a pas beaucoup de permissions à part l'accès en lecture sur certaines ressources mais vous avez pu identifier un compte de service existant appelé _master-sa_.
|
||||
Supposons que lors de votre évaluation, vous ayez découvert que tous les builds Jenkins s'exécutent dans un espace de noms appelé _worker-ns_. Vous avez découvert qu'un compte de service par défaut appelé _default-sa_ est monté sur les pods de build, cependant il n'a pas tant de permissions à part un accès en lecture sur certaines ressources mais vous avez pu identifier un compte de service existant appelé _master-sa_.
|
||||
Supposons également que vous ayez la commande oc installée à l'intérieur du conteneur de build en cours d'exécution.
|
||||
|
||||
Avec le script de build ci-dessous, vous pouvez prendre le contrôle du compte de service _master-sa_ et énumérer davantage.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# OpenShift - Escalade de Privilèges
|
||||
# OpenShift - Escalade de privilèges
|
||||
|
||||
## Compte de Service Manquant
|
||||
## Compte de service manquant
|
||||
|
||||
{{#ref}}
|
||||
openshift-missing-service-account.md
|
||||
|
||||
@@ -2,13 +2,13 @@
|
||||
|
||||
## Compte de Service Manquant
|
||||
|
||||
Il arrive que le cluster soit déployé avec un modèle préconfiguré définissant automatiquement des Rôles, des Liens de Rôle et même des SCC pour un compte de service qui n'est pas encore créé. Cela peut conduire à une élévation de privilèges dans le cas où vous pouvez les créer. Dans ce cas, vous seriez en mesure d'obtenir le jeton du compte de service nouvellement créé et le rôle ou le SCC associé. Le même cas se produit lorsque le compte de service manquant fait partie d'un projet manquant, dans ce cas, si vous pouvez créer le projet puis le compte de service, vous obtenez les Rôles et le SCC associés.
|
||||
Il arrive qu'un cluster soit déployé avec un modèle préconfiguré définissant automatiquement des Rôles, des Liens de Rôle et même des SCC pour un compte de service qui n'est pas encore créé. Cela peut conduire à une élévation de privilèges dans le cas où vous pouvez les créer. Dans ce cas, vous seriez en mesure d'obtenir le jeton du compte de service nouvellement créé et le rôle ou le SCC associé. Le même cas se produit lorsque le compte de service manquant fait partie d'un projet manquant, dans ce cas, si vous pouvez créer le projet puis le compte de service, vous obtenez les Rôles et le SCC associés.
|
||||
|
||||
<figure><img src="../../../images/openshift-missing-service-account-image1.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Dans le graphique précédent, nous avons plusieurs AbsentProject signifiant plusieurs projets qui apparaissent dans les Liens de Rôle ou le SCC mais qui ne sont pas encore créés dans le cluster. Dans le même ordre d'idées, nous avons également un AbsentServiceAccount.
|
||||
|
||||
Si nous pouvons créer un projet et le compte de service manquant à l'intérieur, le compte de service héritera du Rôle ou du SCC qui visaient l'AbsentServiceAccount. Ce qui peut conduire à une élévation de privilèges.
|
||||
Si nous pouvons créer un projet et le compte de service manquant dans celui-ci, le compte de service héritera du Rôle ou du SCC qui visaient l'AbsentServiceAccount. Ce qui peut conduire à une élévation de privilèges.
|
||||
|
||||
L'exemple suivant montre un compte de service manquant qui se voit accorder le SCC node-exporter :
|
||||
|
||||
@@ -16,7 +16,7 @@ L'exemple suivant montre un compte de service manquant qui se voit accorder le S
|
||||
|
||||
## Outils
|
||||
|
||||
L'outil suivant peut être utilisé pour énumérer ce problème et plus généralement pour représenter un cluster OpenShift :
|
||||
L'outil suivant peut être utilisé pour énumérer ce problème et plus généralement pour cartographier un cluster OpenShift :
|
||||
|
||||
{{#ref}}
|
||||
https://github.com/maxDcb/OpenShiftGrapher
|
||||
|
||||
@@ -28,13 +28,13 @@ yes
|
||||
$ oc auth can-i patch namespaces
|
||||
yes
|
||||
```
|
||||
L'étiquette spécifique `openshift.io/run-level` permet aux utilisateurs de contourner les SCC pour les applications. Selon la documentation de RedHat, lorsque cette étiquette est utilisée, aucune SCC n'est appliquée à tous les pods dans cet espace de noms, supprimant ainsi toute restriction.
|
||||
Le label spécifique `openshift.io/run-level` permet aux utilisateurs de contourner les SCC pour les applications. Selon la documentation de RedHat, lorsque ce label est utilisé, aucune SCC n'est appliquée à tous les pods dans cet espace de noms, supprimant ainsi toutes les restrictions.
|
||||
|
||||
<figure><img src="../../../images/Openshift-RunLevel4.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
## Ajouter une étiquette
|
||||
## Ajouter un label
|
||||
|
||||
Pour ajouter l'étiquette dans votre espace de noms :
|
||||
Pour ajouter le label dans votre espace de noms :
|
||||
```bash
|
||||
$ oc label ns MYNAMESPACE openshift.io/run-level=0
|
||||
```
|
||||
@@ -99,7 +99,7 @@ De plus, en fonction de la configuration cible, certaines étiquettes / annotati
|
||||
Essayez de rechercher des étiquettes personnalisées si vous pouvez lire certaines ressources. Voici une liste de ressources intéressantes :
|
||||
|
||||
- Pod
|
||||
- Deployment
|
||||
- Déploiement
|
||||
- Namespace
|
||||
- Service
|
||||
- Route
|
||||
@@ -113,11 +113,11 @@ $ oc get project -o yaml | grep 'run-level' -b5
|
||||
```
|
||||
## Exploit avancé
|
||||
|
||||
Dans OpenShift, comme démontré précédemment, avoir la permission de déployer un pod dans un espace de noms avec l'étiquette `openshift.io/run-level` peut conduire à une prise de contrôle directe du cluster. Du point de vue des paramètres du cluster, cette fonctionnalité **ne peut pas être désactivée**, car elle est inhérente à la conception d'OpenShift.
|
||||
Dans OpenShift, comme démontré précédemment, avoir la permission de déployer un pod dans un namespace avec le label `openshift.io/run-level` peut conduire à une prise de contrôle directe du cluster. Du point de vue des paramètres du cluster, cette fonctionnalité **ne peut pas être désactivée**, car elle est inhérente à la conception d'OpenShift.
|
||||
|
||||
Cependant, des mesures d'atténuation comme **Open Policy Agent GateKeeper** peuvent empêcher les utilisateurs de définir cette étiquette.
|
||||
Cependant, des mesures d'atténuation comme **Open Policy Agent GateKeeper** peuvent empêcher les utilisateurs de définir ce label.
|
||||
|
||||
Pour contourner les règles de GateKeeper et définir cette étiquette pour exécuter une prise de contrôle du cluster, **les attaquants devraient identifier des méthodes alternatives.**
|
||||
Pour contourner les règles de GateKeeper et définir ce label pour exécuter une prise de contrôle du cluster, **les attaquants devraient identifier des méthodes alternatives.**
|
||||
|
||||
## Références
|
||||
|
||||
|
||||
@@ -34,7 +34,7 @@ Dans n'importe quel espace de noms, si vous pouvez obtenir le jeton de compte de
|
||||
|
||||
### La mauvaise configuration
|
||||
|
||||
Le problème est que le scc par défaut que le sa de pipeline peut utiliser est contrôlable par l'utilisateur. Cela peut être fait en utilisant une étiquette dans la définition de l'espace de noms. Par exemple, si je peux créer un espace de noms avec la définition yaml suivante :
|
||||
Le problème est que le scc par défaut que le compte de service de pipeline peut utiliser est contrôlable par l'utilisateur. Cela peut être fait en utilisant une étiquette dans la définition de l'espace de noms. Par exemple, si je peux créer un espace de noms avec la définition yaml suivante :
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Namespace
|
||||
@@ -47,7 +47,7 @@ L'opérateur tekton donnera au compte de service de pipeline dans `test-namespac
|
||||
|
||||
### La solution
|
||||
|
||||
Les documents Tekton sur la façon de restreindre l'override de scc en ajoutant une étiquette dans l'objet `TektonConfig`.
|
||||
Les documents Tekton expliquent comment restreindre l'override de scc en ajoutant une étiquette dans l'objet `TektonConfig`.
|
||||
|
||||
{{#ref}}
|
||||
https://tekton.dev/docs/operator/sccconfig/
|
||||
|
||||
@@ -41,12 +41,12 @@ Tous les utilisateurs ont accès aux SCC par défaut "**restricted**" et "**rest
|
||||
|
||||
## Utiliser SCC
|
||||
|
||||
Le SCC utilisé pour un pod est défini à l'intérieur d'une annotation :
|
||||
Le SCC utilisé pour un pod est défini dans une annotation :
|
||||
```bash
|
||||
$ oc get pod MYPOD -o yaml | grep scc
|
||||
openshift.io/scc: privileged
|
||||
```
|
||||
Lorsque un utilisateur a accès à plusieurs SCC, le système utilisera celui qui correspond aux valeurs de contexte de sécurité. Sinon, cela déclenchera une erreur interdite.
|
||||
Lorsque un utilisateur a accès à plusieurs SCC, le système utilisera celui qui correspond aux valeurs de contexte de sécurité. Sinon, cela déclenchera une erreur d'interdiction.
|
||||
```bash
|
||||
$ oc apply -f evilpod.yaml #Deploy a privileged pod
|
||||
Error from server (Forbidden): error when creating "evilpod.yaml": pods "evilpod" is forbidden: unable to validate against any security context constrain
|
||||
|
||||
Reference in New Issue
Block a user