mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-29 22:20:33 -08:00
Translated ['src/pentesting-cloud/azure-security/az-privilege-escalation
This commit is contained in:
@@ -10,11 +10,11 @@ Pour plus d'informations, consultez :
|
||||
../az-services/az-automation-accounts.md
|
||||
{{#endref}}
|
||||
|
||||
### Hybrid Workers
|
||||
### Hybrid Workers Group
|
||||
|
||||
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.
|
||||
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 travailleur hybride, 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**.
|
||||
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és gérées du compte d'automatisation (**`IDENTITY_ENDPOINT`**).
|
||||
@@ -36,9 +36,9 @@ $runbook_variable
|
||||
$creds.GetNetworkCredential().username
|
||||
$creds.GetNetworkCredential().password'
|
||||
```
|
||||
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.
|
||||
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 d'automatisation.
|
||||
|
||||
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 :
|
||||
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 :
|
||||
```bash
|
||||
az automation runbook publish \
|
||||
--resource-group <res-group> \
|
||||
@@ -64,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 **attribuer une identité gérée par l'utilisateur** au compte d'automatisation en utilisant :
|
||||
Cette permission permet à l'utilisateur de **assigner 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" \
|
||||
@@ -80,7 +80,7 @@ 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 discret) 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 furtif) en utilisant la commande suivante.
|
||||
|
||||
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
|
||||
@@ -245,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 Kali Box
|
||||
- Étape 4 — Préparer la boîte Kali
|
||||
|
||||
Le serveur Kali télécharge le payload RevPS.ps1 depuis un dépôt GitHub.
|
||||
```bash
|
||||
|
||||
@@ -9,24 +9,22 @@ Les comptes d'automatisation Azure sont des services basés sur le cloud dans Mi
|
||||
### Paramètres
|
||||
|
||||
- **Identifiants** : Le mot de passe n'est accessible que dans un runbook à l'intérieur du compte d'automatisation, il est utilisé pour **stocker les noms d'utilisateur et les mots de passe en toute sécurité**.
|
||||
- **Variables** : Utilisées pour stocker des **données de configuration** qui peuvent être utilisées dans les runbooks. Cela pourrait également être des informations sensibles comme des clés API. Si la variable est **stockée de manière chiffrée**, elle n'est disponible que dans un runbook à l'intérieur du compte d'automatisation.
|
||||
- **Variables** : Utilisées pour stocker des **données de configuration** qui peuvent être utilisées dans les runbooks. Cela pourrait également inclure des informations sensibles comme des clés API. Si la variable est **stockée de manière chiffrée**, elle n'est disponible que dans un runbook à l'intérieur du compte d'automatisation.
|
||||
- **Certificats** : Utilisés pour stocker des **certificats** qui peuvent être utilisés dans les runbooks.
|
||||
- **Connexions** : Utilisées pour stocker des **informations de connexion** aux services externes. Cela pourrait contenir des **informations sensibles**.
|
||||
- **Connexions** : Utilisées pour stocker des **informations de connexion** à des services externes. Cela pourrait contenir des **informations sensibles**.
|
||||
- **Accès réseau** : Il peut être défini comme **public** ou **privé**.
|
||||
|
||||
## Runbooks & Jobs
|
||||
### Runbooks & Jobs
|
||||
|
||||
Un Runbook dans Azure Automation est un **script qui exécute des tâches automatiquement** dans votre environnement cloud. Les runbooks peuvent être écrits en PowerShell, Python ou dans des éditeurs graphiques. Ils aident à automatiser des tâches administratives comme la gestion des VM, le patching ou les vérifications de conformité.
|
||||
|
||||
Dans le **code** situé à l'intérieur des **Runbooks** pourrait contenir des **informations sensibles** (comme des identifiants).
|
||||
|
||||
Allez à `Automation Accounts` --> `<Select Automation Account>` --> `Runbooks/Jobs/Hybrid worker groups/Watcher tasks/credentials/variables/certificates/connections`
|
||||
Dans le **code** situé à l'intérieur des **Runbooks** pourrait se trouver des **informations sensibles** (comme des identifiants).
|
||||
|
||||
Un **Job est une instance d'exécution d'un Runbook**. Lorsque vous exécutez un Runbook, un Job est créé pour suivre cette exécution. Chaque job comprend :
|
||||
|
||||
- **Statut** : En attente, En cours, Terminé, Échoué, Suspendu.
|
||||
- **Sortie** : Le résultat de l'exécution du Runbook.
|
||||
- **Heure de début et de fin** : Quand le job a commencé et s'est terminé.
|
||||
- **Heure de début et de fin** : Quand le job a commencé et a été terminé.
|
||||
|
||||
Un job contient la **sortie** de l'exécution du **Runbook**. Si vous pouvez **lire** les **jobs**, faites-le car ils **contiennent** la **sortie** de l'exécution (potentiellement des **informations sensibles**).
|
||||
|
||||
@@ -46,7 +44,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 nécessaire d'indiquer l'ID client de l'ID utilisateur MI dans la variable **`AUTOMATION_SC_USER_ASSIGNED_IDENTITY_ID`**.
|
||||
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'identité gérée utilisateur dans la variable **`AUTOMATION_SC_USER_ASSIGNED_IDENTITY_ID`**.
|
||||
|
||||
### Environnements d'exécution
|
||||
|
||||
@@ -59,18 +57,18 @@ Lors de la création d'un Runbook, il est possible de sélectionner l'environnem
|
||||
- **Python 3.8**
|
||||
- **Python 2.7**
|
||||
|
||||
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.
|
||||
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 seront utilisés. Dans le cas de PowerShell, il est possible de télécharger des packages `.zip` avec les modules à avoir dans l'exécution.
|
||||
|
||||
### Groupes 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.
|
||||
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 que l'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.
|
||||
|
||||
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).
|
||||
Par conséquent, si vous pouvez choisir d'exécuter un **Runbook** dans un **Travailleur Hybride**, 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**.
|
||||
|
||||
@@ -84,7 +82,7 @@ De plus, si le travailleur hybride s'exécute dans Azure avec d'autres identité
|
||||
|
||||
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 pourraient 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 vers les 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
|
||||
@@ -170,7 +168,7 @@ az rest --method GET \
|
||||
|
||||
# Get the source control setting of an automation account (if any)
|
||||
## inside the output it's possible to see if the autoSync is enabled, if the publishRunbook is enabled and the repo URL
|
||||
aaz automation source-control list --automation-account-name <AUTOMATION-ACCOUNT> --resource-group <RG-NAME>
|
||||
az automation source-control list --automation-account-name <AUTOMATION-ACCOUNT> --resource-group <RG-NAME>
|
||||
|
||||
# Get custom runtime environments
|
||||
## Check in defaultPackages for custom ones, by default Python envs won't have anything here and PS1 envs will have "az" and "azure cli"
|
||||
|
||||
Reference in New Issue
Block a user