Translated ['src/pentesting-cloud/aws-security/aws-privilege-escalation/

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md

@@ -8,7 +8,7 @@
 
 Un attaquant ayant ces permissions sur des buckets intéressants pourrait être en mesure de détourner des ressources et d'escalader des privilèges.
 
-Par exemple, un attaquant avec ces **permissions sur un bucket cloudformation** appelé "cf-templates-nohnwfax6a6i-us-east-1" pourra détourner le déploiement. L'accès peut être accordé avec la politique suivante :
+Par exemple, un attaquant ayant ces **permissions sur un bucket cloudformation** appelé "cf-templates-nohnwfax6a6i-us-east-1" pourra détourner le déploiement. L'accès peut être accordé avec la politique suivante :
 ```json
 {
 "Version": "2012-10-17",
@@ -53,14 +53,14 @@ Voici quelques exemples :
 ### `s3:PutObject`, `s3:GetObject` (optionnel) sur le fichier d'état terraform
 
 Il est très courant que les fichiers d'état [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) soient sauvegardés dans le stockage blob des fournisseurs de cloud, par exemple AWS S3. Le suffixe de fichier pour un fichier d'état est `.tfstate`, et les noms de bucket indiquent souvent qu'ils contiennent des fichiers d'état terraform. En général, chaque compte AWS a un tel bucket pour stocker les fichiers d'état qui montrent l'état du compte.\
-De plus, dans les comptes du monde réel, presque tous les développeurs ont généralement `s3:*` et parfois même les utilisateurs professionnels ont `s3:Put*`.
+De plus, dans les comptes du monde réel, presque toujours tous les développeurs ont `s3:*` et parfois même les utilisateurs professionnels ont `s3:Put*`.
 
-Donc, si vous avez les permissions énumérées sur ces fichiers, il existe un vecteur d'attaque qui vous permet d'obtenir RCE dans le pipeline avec les privilèges de `terraform` - la plupart du temps `AdministratorAccess`, vous rendant l'admin du compte cloud. De plus, vous pouvez utiliser ce vecteur pour effectuer une attaque par déni de service en faisant en sorte que `terraform` supprime des ressources légitimes.
+Donc, si vous avez les permissions énumérées sur ces fichiers, il existe un vecteur d'attaque qui vous permet d'obtenir RCE dans le pipeline avec les privilèges de `terraform` - la plupart du temps `AdministratorAccess`, vous faisant l'admin du compte cloud. De plus, vous pouvez utiliser ce vecteur pour effectuer une attaque par déni de service en faisant en sorte que `terraform` supprime des ressources légitimes.
 
 Suivez la description dans la section *Abusing Terraform State Files* de la page *Terraform Security* pour un code d'exploitation directement utilisable :
 
 {{#ref}}
-terraform-security.md#abusing-terraform-state-files
+pentesting-ci-cd/terraform-security.md#abusing-terraform-state-files
 {{#endref}}
 
 ### `s3:PutBucketPolicy`

src/pentesting-cloud/azure-security/az-privilege-escalation/az-app-services-privesc.md

@@ -7,7 +7,7 @@
 Pour plus d'informations sur les services d'application Azure, consultez :
 
 {{#ref}}
-../az-services/az-app-service.md
+../az-services/az-app-services.md
 {{#endref}}
 
 ### Microsoft.Web/sites/publish/Action, Microsoft.Web/sites/basicPublishingCredentialsPolicies/read, Microsoft.Web/sites/config/read, Microsoft.Web/sites/read
@@ -94,7 +94,7 @@ az webapp deployment list-publishing-profiles --name <app-name> --resource-group
 }
 ]
 ```
-Notez que le **nom d'utilisateur est toujours le même** (sauf dans FTP qui ajoute le nom de l'application au début) mais le **mot de passe est le même** pour tous.
+Notez que le **nom d'utilisateur est toujours le même** (sauf dans FTP qui ajoute le nom de l'application au début) mais que le **mot de passe est le même** pour tous.
 
 De plus, l'**URL SCM est `<app-name>.scm.azurewebsites.net`**.
 
@@ -129,7 +129,7 @@ Ensuite, vous pouvez utiliser ces identifiants pour **accéder aux plateformes S
 N'oubliez pas que pour accéder à la plateforme SCM depuis le **web, vous devez accéder à `<SCM-URL>/BasicAuth`**.
 
 > [!WARNING]
-> Notez que chaque utilisateur peut configurer ses propres identifiants en appelant la commande précédente, mais si l'utilisateur n'a pas suffisamment de permissions pour accéder au SCM ou FTP, les identifiants ne fonctionneront pas.
+> Notez que chaque utilisateur peut configurer ses propres identifiants en appelant la commande précédente, mais si l'utilisateur n'a pas suffisamment de permissions pour accéder au SCM ou au FTP, les identifiants ne fonctionneront pas.
 
 - Si vous voyez que ces identifiants sont **REDACTED**, c'est parce que vous **devez activer l'option d'authentification de base SCM** et pour cela, vous avez besoin de la deuxième permission (`Microsoft.Web/sites/basicPublishingCredentialsPolicies/write`):
 ```bash
@@ -153,9 +153,9 @@ az rest --method PUT \
 ```
 ### Publier du code en utilisant des identifiants SCM
 
-Il suffit d'avoir des identifiants SCM valides pour **publier du code** sur le service App. Cela peut être fait en utilisant la commande suivante.
+Il suffit d'avoir des identifiants SCM valides pour **publier du code** dans le service App. Cela peut être fait en utilisant la commande suivante.
 
-Pour cet exemple en python, vous pouvez télécharger le dépôt depuis https://github.com/Azure-Samples/msdocs-python-flask-webapp-quickstart, apporter les **modifications** que vous souhaitez, puis **zippez-le en exécutant : `zip -r app.zip .`**.
+Pour cet exemple en python, vous pouvez télécharger le dépôt depuis https://github.com/Azure-Samples/msdocs-python-flask-webapp-quickstart, apporter les **modifications** que vous souhaitez et ensuite **le compresser en exécutant : `zip -r app.zip .`**.
 
 Ensuite, vous pouvez **publier le code** dans une application web avec la commande suivante :
 ```bash
@@ -205,7 +205,7 @@ curl -X PUT \
 ```
 ### Microsoft.Web/sites/write, Microsoft.Web/sites/read, Microsoft.ManagedIdentity/userAssignedIdentities/assign/action
 
-Ces autorisations permettent de **attribuer une identité gérée** au service App, donc si un service App a été précédemment compromis, cela permettra à l'attaquant d'attribuer de nouvelles identités gérées au service App et **d'escalader les privilèges** vers celles-ci.
+Ces autorisations permettent de **attribuer une identité gérée** au service d'application, donc si un service d'application a été précédemment compromis, cela permettra à l'attaquant d'attribuer de nouvelles identités gérées au service d'application et **d'escalader les privilèges** vers celles-ci.
 ```bash
 az webapp identity assign --name <app-name> --resource-group <res-group> --identities /subscriptions/<subcripttion-id>/resourceGroups/<res_group>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<managed-identity-name>
 ```

src/pentesting-cloud/azure-security/az-services/az-function-apps.md

@@ -9,13 +9,13 @@
 > [!NOTE]
 > Notez que **les fonctions sont un sous-ensemble des App Services**, par conséquent, de nombreuses fonctionnalités discutées ici seront également utilisées par les applications créées en tant qu'Azure Apps (`webapp` dans cli).
 
-### Différents plans
+### Différents Plans
 
-- **Plan de consommation flexible** : Offre un **scalabilité dynamique et basée sur les événements** avec un tarif à l'utilisation, ajoutant ou supprimant des instances de fonction en fonction de la demande. Il prend en charge **le réseau virtuel** et **les instances pré-provisionnées** pour réduire les démarrages à froid, ce qui le rend adapté aux **charges de travail variables** qui ne nécessitent pas de support de conteneur.
-- **Plan de consommation traditionnel** : L'option sans serveur par défaut, où vous **ne payez que pour les ressources de calcul lorsque les fonctions s'exécutent**. Il s'adapte automatiquement en fonction des événements entrants et inclut des **optimisations de démarrage à froid**, mais ne prend pas en charge les déploiements de conteneurs. Idéal pour les **charges de travail intermittentes** nécessitant une mise à l'échelle automatique.
-- **Plan Premium** : Conçu pour des **performances constantes**, avec des **travailleurs préchauffés** pour éliminer les démarrages à froid. Il offre **des temps d'exécution prolongés, un réseau virtuel**, et prend en charge **des images Linux personnalisées**, ce qui le rend parfait pour des **applications critiques nécessitant des performances élevées et des fonctionnalités avancées**.
-- **Plan dédié** : Fonctionne sur des machines virtuelles dédiées avec une **facturation prévisible** et prend en charge la mise à l'échelle manuelle ou automatique. Il permet d'exécuter plusieurs applications sur le même plan, fournit **une isolation de calcul**, et garantit un **accès réseau sécurisé** via des environnements de service d'application, ce qui le rend idéal pour des **applications de longue durée** nécessitant une allocation de ressources constante.
-- **Container Apps** : Permet de déployer des **applications de fonction conteneurisées** dans un environnement géré, aux côtés de microservices et d'API. Il prend en charge des bibliothèques personnalisées, la migration d'applications héritées, et le **traitement GPU**, éliminant la gestion des clusters Kubernetes. Idéal pour des **applications conteneurisées évolutives basées sur des événements**.
+- **Flex Consumption Plan** : Offre un **scalabilité dynamique et basée sur les événements** avec un tarif à l'utilisation, ajoutant ou supprimant des instances de fonction en fonction de la demande. Il prend en charge **le réseau virtuel** et **les instances pré-provisionnées** pour réduire les démarrages à froid, ce qui le rend adapté aux **charges de travail variables** qui ne nécessitent pas de support de conteneur.
+- **Traditional Consumption Plan** : L'option sans serveur par défaut, où vous **ne payez que pour les ressources de calcul lorsque les fonctions s'exécutent**. Il s'adapte automatiquement en fonction des événements entrants et inclut des **optimisations de démarrage à froid**, mais ne prend pas en charge les déploiements de conteneurs. Idéal pour les **charges de travail intermittentes** nécessitant une mise à l'échelle automatique.
+- **Premium Plan** : Conçu pour des **performances constantes**, avec des **travailleurs préchauffés** pour éliminer les démarrages à froid. Il offre **des temps d'exécution prolongés, un réseau virtuel**, et prend en charge **des images Linux personnalisées**, ce qui le rend parfait pour des **applications critiques** nécessitant des performances élevées et des fonctionnalités avancées.
+- **Dedicated Plan** : Fonctionne sur des machines virtuelles dédiées avec une **facturation prévisible** et prend en charge la mise à l'échelle manuelle ou automatique. Il permet d'exécuter plusieurs applications sur le même plan, fournit **une isolation de calcul**, et assure un **accès réseau sécurisé** via des environnements de service d'application, ce qui le rend idéal pour des **applications de longue durée** nécessitant une allocation de ressources constante.
+- **Container Apps** : Permet de déployer des **applications de fonction conteneurisées** dans un environnement géré, aux côtés de microservices et d'APIs. Il prend en charge des bibliothèques personnalisées, la migration d'applications héritées, et le **traitement GPU**, éliminant la gestion des clusters Kubernetes. Idéal pour des **applications conteneurisées évolutives basées sur des événements**.
 
 ### **Buckets de stockage**
 
@@ -56,14 +56,14 @@ Dans une fonction **Windows** utilisant NodeJS, le code était situé dans **`C:
 
 ### **Identités gérées et métadonnées**
 
-Tout comme les [**VMs**](vms/), les fonctions peuvent avoir des **Identités gérées** de 2 types : assignées par le système et assignées par l'utilisateur.
+Tout comme [**VMs**](vms/index.html), les fonctions peuvent avoir des **Identités Gérées** de 2 types : Assignée au système et Assignée à l'utilisateur.
 
-L'identité **assignée par le système** sera une identité gérée que **seule la fonction** qui l'a assignée pourra utiliser, tandis que les identités gérées **assignées par l'utilisateur** sont des identités gérées que **tout autre service Azure pourra utiliser**.
+L'identité **assignée au système** sera une identité gérée que **seule la fonction** qui l'a assignée pourra utiliser, tandis que les identités gérées **assignées à l'utilisateur** sont des identités gérées que **tout autre service Azure pourra utiliser**.
 
 > [!NOTE]
-> Tout comme dans les [**VMs**](vms/), les fonctions peuvent avoir **1 identité gérée assignée par le système** et **plusieurs identités assignées par l'utilisateur**, il est donc toujours important d'essayer de les trouver toutes si vous compromettez la fonction car vous pourriez être en mesure d'escalader les privilèges vers plusieurs identités gérées à partir d'une seule fonction.
+> Tout comme dans [**VMs**](vms/index.html), les fonctions peuvent avoir **1 identité gérée assignée au système** et **plusieurs identités assignées à l'utilisateur**, il est donc toujours important d'essayer de trouver toutes celles-ci si vous compromettez la fonction car vous pourriez être en mesure d'escalader les privilèges à plusieurs identités gérées à partir d'une seule fonction.
 >
-> Si aucune identité gérée par le système n'est utilisée mais qu'une ou plusieurs identités gérées par l'utilisateur sont attachées à une fonction, par défaut vous ne pourrez pas obtenir de jeton.
+> Si aucune identité gérée au système n'est utilisée mais qu'une ou plusieurs identités gérées par l'utilisateur sont attachées à une fonction, par défaut vous ne pourrez pas obtenir de jeton.
 
 Il est possible d'utiliser les [**scripts PEASS**](https://github.com/peass-ng/PEASS-ng) pour obtenir des jetons de l'identité gérée par défaut à partir du point de terminaison des métadonnées. Ou vous pourriez les obtenir **manuellement** comme expliqué dans :
 
@@ -78,14 +78,14 @@ Notez que vous devez trouver un moyen de **vérifier toutes les identités gér
 
 Lors de la création d'un point de terminaison à l'intérieur d'une fonction utilisant un **déclencheur HTTP**, il est possible d'indiquer le **niveau d'autorisation de clé d'accès** nécessaire pour déclencher la fonction. Trois options sont disponibles :
 
-- **ANONYME** : **Tout le monde** peut accéder à la fonction par l'URL.
-- **FONCTION** : Le point de terminaison n'est accessible qu'aux utilisateurs utilisant une **clé de fonction, d'hôte ou maître**.
+- **ANONYMOUS** : **Tout le monde** peut accéder à la fonction par l'URL.
+- **FUNCTION** : Le point de terminaison n'est accessible qu'aux utilisateurs utilisant une **clé de fonction, d'hôte ou maître**.
 - **ADMIN** : Le point de terminaison n'est accessible qu'aux utilisateurs avec une **clé maître**.
 
 **Type de clés :**
 
 - **Clés de fonction :** Les clés de fonction peuvent être soit par défaut soit définies par l'utilisateur et sont conçues pour accorder un accès exclusivement à **des points de terminaison de fonction spécifiques** au sein d'une Function App permettant un accès plus granulaire sur les points de terminaison.
-- **Clés d'hôte :** Les clés d'hôte, qui peuvent également être par défaut ou définies par l'utilisateur, fournissent un accès à **tous les points de terminaison de fonction au sein d'une Function App avec un niveau d'accès FONCTION**.
+- **Clés d'hôte :** Les clés d'hôte, qui peuvent également être par défaut ou définies par l'utilisateur, fournissent un accès à **tous les points de terminaison de fonction au sein d'une Function App avec un niveau d'accès FUNCTION**.
 - **Clé maître :** La clé maître (`_master`) sert de clé administrative qui offre des permissions élevées, y compris l'accès à tous les points de terminaison de fonction (niveau d'accès ADMIN inclus). Cette **clé ne peut pas être révoquée.**
 - **Clés système :** Les clés système sont **gérées par des extensions spécifiques** et sont nécessaires pour accéder aux points de terminaison webhook utilisés par des composants internes. Des exemples incluent le déclencheur Event Grid et les Durable Functions, qui utilisent des clés système pour interagir en toute sécurité avec leurs API respectives.
 
@@ -99,12 +99,12 @@ Lors de la création d'un point de terminaison à l'intérieur d'une fonction ut
 Tout comme dans les App Services, les fonctions prennent également en charge l'authentification de base pour se connecter à **SCM** et **FTP** pour déployer du code en utilisant un **nom d'utilisateur et un mot de passe dans une URL** fournie par Azure. Plus d'informations à ce sujet dans :
 
 {{#ref}}
-az-app-service.md
+az-app-services.md
 {{#endref}}
 
 ### Déploiements basés sur Github
 
-Lorsqu'une fonction est générée à partir d'un dépôt Github, la console web Azure permet de **créer automatiquement un workflow Github dans un dépôt spécifique** afin que chaque fois que ce dépôt est mis à jour, le code de la fonction soit mis à jour. En fait, le fichier yaml de l'action Github pour une fonction Python ressemble à ceci :
+Lorsqu'une fonction est générée à partir d'un dépôt Github, la console web Azure permet de **créer automatiquement un workflow Github dans un dépôt spécifique** afin que chaque fois que ce dépôt est mis à jour, le code de la fonction soit mis à jour. En fait, le yaml de l'action Github pour une fonction Python ressemble à ceci :
 
 <details>
 
@@ -192,10 +192,10 @@ package: ${{ env.AZURE_FUNCTIONAPP_PACKAGE_PATH }}
 ```
 </details>
 
-De plus, une **Identité Gérée** est également créée afin que l'Action Github du dépôt puisse se connecter à Azure avec elle. Cela se fait en générant un identifiant fédéré sur l'**Identité Gérée** permettant à l'**Émetteur** `https://token.actions.githubusercontent.com` et à l'**Identifiant de Sujet** `repo:<org-name>/<repo-name>:ref:refs/heads/<branch-name>`.
+De plus, une **Managed Identity** est également créée afin que l'Action Github du dépôt puisse se connecter à Azure avec elle. Cela se fait en générant une crédential fédérée sur la **Managed Identity** permettant à l'**Issuer** `https://token.actions.githubusercontent.com` et à l'**Subject Identifier** `repo:<org-name>/<repo-name>:ref:refs/heads/<branch-name>`.
 
 > [!CAUTION]
-> Par conséquent, quiconque compromettant ce dépôt pourra compromettre la fonction et les Identités Gérées qui y sont attachées.
+> Par conséquent, quiconque compromettant ce dépôt pourra compromettre la fonction et les Managed Identities qui y sont attachées.
 
 ### Déploiements Basés sur des Conteneurs