AWS - Informations de base

Tip

Apprenez & pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez & pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez & pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Soutenez HackTricks

• Consultez les subscription plans!
• Rejoignez le 💬 Discord group ou le telegram group ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des hacking tricks en soumettant des PRs aux HackTricks et HackTricks Cloud github repos.

Hiérarchie de l’organisation

Comptes

Dans AWS, il y a un compte root, qui est le conteneur parent pour tous les comptes de votre organisation. Cependant, vous n’avez pas besoin d’utiliser ce compte pour déployer des ressources, vous pouvez créer d’autres comptes pour séparer différentes infrastructures AWS entre elles.

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 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 :

• Créer des comptes dans l’organisation

• Inviter d’autres comptes existants à l’organisation

• Supprimer des comptes de l’organisation

• Gérer les invitations

• Appliquer des politiques aux entités (roots, OUs ou comptes) au sein de l’organisation

• Activer l’intégration avec les services AWS pris en charge pour fournir des fonctionnalités de service à tous les comptes de l’organisation.

• Il est possible de se connecter en tant qu’utilisateur root en utilisant l’email et le mot de passe utilisés pour créer ce compte/organisation root.

Le compte de gestion a les responsabilités d’un compte payeur et est responsable du paiement de tous les frais accumulés par les comptes membres. Vous ne pouvez pas changer le compte de gestion d’une organisation.

• Les comptes membres constituent tous les autres comptes d’une organisation. Un compte ne peut être membre que d’une seule organisation à la fois. Vous pouvez attacher une politique à un compte pour appliquer des contrôles uniquement à ce compte.
• Les comptes membres doivent utiliser une adresse email valide et peuvent avoir un nom, en général ils ne pourront pas gérer la facturation (mais ils pourraient y avoir accès).

aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com

Unités d’Organisation

Les comptes peuvent être regroupés en Unités d’Organisation (OU). De cette manière, vous pouvez créer des politiques pour l’Unité d’Organisation qui vont être appliquées à tous les comptes enfants. Notez qu’une OU peut avoir d’autres OUs comme enfants.

# You can get the root id from aws organizations list-roots
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.

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é).

Warning

Notez que les SCP ne restreignent que les principaux dans le compte, donc d’autres comptes ne sont pas affectés. Cela signifie qu’avoir une SCP qui refuse s3:GetObject n’arrêtera pas les gens d’accéder à un bucket S3 public dans votre compte.

Exemples de SCP :

• Refuser complètement le compte root
• Autoriser uniquement des régions spécifiques
• Autoriser uniquement des services sur liste blanche
• 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 la création d’utilisateurs IAM et de clés d’accès

Trouvez des exemples JSON dans 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 ne font que plafonner 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 des 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
• Plafonner les permissions sur les files d’attente SQS pour empêcher 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

ARN

Amazon Resource Name est le nom unique que chaque ressource à l’intérieur d’AWS possède, il est composé comme ceci :

arn:partition:service:region:account-id:resource-type/resource-id
arn:aws:elasticbeanstalk:us-west-1:123456789098:environment/App/Env

Notez qu’il y a 4 partitions dans AWS mais seulement 3 façons de les appeler :

• AWS Standard : aws
• AWS China : aws-cn
• AWS US public Internet (GovCloud) : aws-us-gov
• AWS Secret (US Classified) : aws

IAM - Gestion des identités et des accès

IAM est le service qui vous permettra de gérer l’authentification, l’autorisation et le contrôle d’accès au sein de votre compte AWS.

• Authentification - Processus de définition d’une identité et de vérification de cette identité. Ce processus peut être subdivisé en : Identification et vérification.
• Autorisation - Détermine ce qu’une identité peut accéder au sein d’un système une fois qu’elle a été authentifiée.
• Contrôle d’accès - La méthode et le processus par lesquels l’accès est accordé à une ressource sécurisée.

IAM peut être défini par sa capacité à gérer, contrôler et gouverner les mécanismes d’authentification, d’autorisation et de contrôle d’accès des identités à vos ressources au sein de votre compte AWS.

Utilisateur racine du compte AWS

Lorsque vous créez pour la première fois un compte Amazon Web Services (AWS), vous commencez avec une identité de connexion unique qui a un accès complet à tous les services et ressources AWS dans le compte. C’est l’utilisateur racine du compte AWS et il est accessible en se connectant avec l’adresse e-mail et le mot de passe que vous avez utilisés pour créer le compte.

Notez qu’un nouvel utilisateur admin aura moins de permissions que l’utilisateur racine.

D’un point de vue sécurité, il est recommandé de créer d’autres utilisateurs et d’éviter d’utiliser celui-ci.

Utilisateurs IAM

Un utilisateur IAM est une entité que vous créez dans AWS pour représenter la personne ou l’application qui l’utilise pour interagir avec AWS. Un utilisateur dans AWS se compose d’un nom et de références (mot de passe et jusqu’à deux clés d’accès).

Lorsque vous créez un utilisateur IAM, vous lui accordez des permissions en le rendant membre d’un groupe d’utilisateurs qui a des politiques de permission appropriées attachées (recommandé), ou en attachant directement des politiques à l’utilisateur.

Les utilisateurs peuvent avoir MFA activé pour se connecter via la console. Les jetons API des utilisateurs avec MFA activé ne sont pas protégés par MFA. Si vous souhaitez restreindre l’accès des clés API d’un utilisateur en utilisant MFA, vous devez indiquer dans la politique qu’en vue d’effectuer certaines actions, MFA doit être présent (exemple ici).

CLI

• ID de clé d’accès : 20 caractères alphanumériques majuscules aléatoires comme AKHDNAPO86BSHKDIRYT
• 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é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

Il est utilisé pour créer un facteur supplémentaire pour l’authentification en plus de vos méthodes existantes, telles que le mot de passe, créant ainsi un niveau d’authentification multi-facteurs.
Vous pouvez utiliser une application virtuelle gratuite ou un appareil physique. Vous pouvez utiliser des applications comme Google Authenticator gratuitement pour activer un MFA dans AWS.

Les politiques avec des conditions MFA peuvent être attachées aux éléments suivants :

• Un utilisateur ou un groupe IAM
• Une ressource telle qu’un bucket Amazon S3, une file d’attente Amazon SQS ou un sujet Amazon SNS
• La politique de confiance d’un rôle IAM qui peut être assumé par un utilisateur

Si vous souhaitez accéder via CLI à une ressource qui vérifie MFA, vous devez appeler GetSessionToken. Cela vous donnera un jeton avec des informations sur MFA.
Notez que les informations d’identification AssumeRole ne contiennent pas cette information.

aws sts get-session-token --serial-number <arn_device> --token-code <code>

Comme indiqué ici, il existe de nombreux cas où MFA ne peut pas être utilisé.

Groupes d’utilisateurs IAM

Un groupe d’utilisateurs IAM 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 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 cela, 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.

Rôles 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é 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 :

Credentials temporaires dans IAM

Les credentials temporaires sont principalement utilisés avec des rôles IAM, mais il existe également d’autres utilisations. Vous pouvez demander des credentials temporaires qui ont un ensemble de permissions plus restreint que votre utilisateur IAM standard. Cela empêche que vous effectuiez accidentellement des tâches qui ne sont pas autorisées par les credentials plus restreints. Un avantage des credentials temporaires est qu’ils expirent automatiquement après une période déterminée. Vous avez le contrôle sur la durée pendant laquelle les credentials sont valides.

Politiques

Permissions de politique

Sont utilisées pour attribuer des permissions. Il existe 2 types :

• Politiques gérées par AWS (préconfigurées par AWS)
• Politiques gérées par le client : configurées par vous. Vous pouvez créer des politiques basées sur des politiques gérées par AWS (en modifiant l’une d’elles et en créant la vôtre), en utilisant le générateur de politiques (une vue GUI qui vous aide à accorder et refuser des permissions) ou en écrivant la vôtre.

Par défaut, l’accès est refusé, l’accès sera accordé si un rôle explicite a été spécifié.
Si un “Deny” unique existe, il remplacera le “Allow”, sauf pour les demandes qui utilisent les credentials de sécurité root du compte AWS (qui sont autorisées par défaut).

{
"Version": "2012-10-17",  //Version of the policy
"Statement": [  //Main element, there can be more than 1 entry in this array
{
"Sid": "Stmt32894y234276923" //Unique identifier (optional)
"Effect": "Allow", //Allow or deny
"Action": [  //Actions that will be allowed or denied
"ec2:AttachVolume",
"ec2:DetachVolume"
],
"Resource": [ //Resource the action and effect will be applied to
"arn:aws:ec2:*:*:volume/*",
"arn:aws:ec2:*:*:instance/*"
],
"Condition": { //Optional element that allow to control when the permission will be effective
"ArnEquals": {"ec2:SourceInstanceARN": "arn:aws:ec2:*:*:instance/instance-id"}
}
}
]
}

Les champs globaux qui peuvent être utilisés pour des conditions dans n’importe quel service sont documentés ici.
Les champs spécifiques qui peuvent être utilisés pour des conditions par service sont documentés ici.

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 à l’identité sont également supprimées. C’est parce qu’elles font partie de l’entité principale.

Politiques de Bucket de Ressources

Ce sont des politiques qui peuvent être définies dans des ressources. Toutes les ressources d’AWS ne les prennent pas en charge.

Si un principal n’a pas de refus explicite à leur sujet, et qu’une politique de ressource leur accorde l’accès, alors ils sont autorisés.

Limites IAM

Les limites IAM peuvent être utilisées pour limiter les autorisations auxquelles un utilisateur ou un rôle devrait avoir accès. De cette façon, même si un ensemble différent d’autorisations est accordé à l’utilisateur par une politique différente, l’opération échouera s’il essaie de les utiliser.

Une limite est simplement une politique attachée à un utilisateur qui indique le niveau maximum d’autorisations que l’utilisateur ou le rôle peut avoir. Donc, même si l’utilisateur a un accès Administrateur, si la limite indique qu’il ne peut lire que des buckets S·, c’est le maximum qu’il peut faire.

Cela, les SCPs et le respect du principe du moindre privilège sont les moyens de contrôler que les utilisateurs n’ont pas plus d’autorisations que celles dont ils ont besoin.

Politiques de Session

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.

aws sts assume-role \
--role-arn <value> \
--role-session-name <value> \
[--policy-arns <arn_custom_policy1> <arn_custom_policy2>]
[--policy <file://policy.json>]

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, 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.

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’en empêche.

Fédération d’identité

La fédération d’identité permet aux utilisateurs des fournisseurs d’identité qui sont externes à AWS d’accéder aux ressources AWS de manière sécurisée sans avoir à fournir les identifiants d’utilisateur AWS d’un compte IAM valide.
Un exemple de fournisseur d’identité peut être votre propre Microsoft Active Directory (via SAML) ou des services OpenID (comme Google). L’accès fédéré permettra alors aux utilisateurs de celui-ci d’accéder à AWS.

Pour configurer cette confiance, un fournisseur d’identité IAM est généré (SAML ou OAuth) qui fera confiance à la autre plateforme. Ensuite, au moins un rôle IAM est attribué (faisant confiance) au fournisseur d’identité. Si un utilisateur de la plateforme de confiance accède à AWS, il le fera en accédant au rôle mentionné.

Cependant, vous voudrez généralement donner un rôle différent en fonction du groupe de l’utilisateur sur la plateforme tierce. Ensuite, plusieurs rôles IAM peuvent faire confiance au fournisseur d’identité tiers et la plateforme tierce sera celle qui permettra aux utilisateurs d’assumer un rôle ou un autre.

Centre d’identité IAM

AWS IAM Identity Center (successeur d’AWS Single Sign-On) étend les capacités de la gestion des identités et des accès AWS (IAM) pour fournir un endroit central qui regroupe l’administration des utilisateurs et leur accès aux comptes AWS et aux applications cloud.

Le domaine de connexion sera quelque chose comme <user_input>.awsapps.com.

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
• Fournisseur d’identité externe : Tous les utilisateurs et groupes proviennent d’un fournisseur d’identité externe (IdP)

Dans le cas le plus simple du répertoire Identity Center, le Centre d’identité aura une liste d’utilisateurs et de groupes et sera capable d’attribuer des politiques à ceux-ci pour n’importe lequel des comptes de l’organisation.

Pour donner accès à un utilisateur/groupe du Centre d’identité à un compte, un fournisseur d’identité SAML faisant confiance au Centre d’identité sera créé, et un rôle faisant confiance au fournisseur d’identité avec les politiques indiquées sera créé dans le compte de destination.

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 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 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

Non pris en charge :

• Relations de confiance
• Centre d’administration AD
• Prise en charge complète de l’API PS
• Corbeille AD
• Comptes de service gérés par groupe
• Extensions de schéma
• Pas d’accès direct au système d’exploitation ou aux instances

Fédération Web ou authentification OpenID

L’application utilise AssumeRoleWithWebIdentity pour créer des identifiants temporaires. Cependant, cela n’accorde pas l’accès à la console AWS, seulement l’accès aux ressources au sein d’AWS.

Autres options IAM

• 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.

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

Dans cette page, vous pouvez trouver les préfixes d’ID IAM des clés en fonction de leur nature :

| ACCA | Identifiant spécifique au contexte | | AGPA | Groupe d’utilisateurs | | AIDA | Utilisateur IAM | | AIPA | Profil d’instance Amazon EC2 | | AKIA | Clé d’accès | | ANPA | Politique gérée | | ANVA | Version dans une politique gérée | | APKA | Clé publique | | AROA | Rôle | | ASCA | Certificat | | ASIA | Identifiants de clé d’accès temporaires (AWS STS) utilisent ce préfixe, mais sont uniques uniquement en combinaison avec la clé d’accès secrète et le jeton de session. |

Permissions recommandées pour auditer les comptes

Les privilèges suivants accordent divers accès en lecture des métadonnées :

• arn:aws:iam::aws:policy/SecurityAudit
• arn:aws:iam::aws:policy/job-function/ViewOnlyAccess
• codebuild:ListProjects
• config:Describe*
• cloudformation:ListStacks
• logs:DescribeMetricFilters
• directconnect:DescribeConnections
• dynamodb:ListTables

Divers

Authentification CLI

Pour qu’un utilisateur régulier s’authentifie à AWS via CLI, vous devez avoir des identifiants locaux. Par défaut, vous pouvez les configurer manuellement dans ~/.aws/credentials ou en exécutant aws configure.
Dans ce fichier, vous pouvez avoir plus d’un profil, si aucun profil n’est spécifié en utilisant le cli aws, celui appelé [default] dans ce fichier sera utilisé.
Exemple de fichier d’identifiants avec plus d’un profil :

[default]
aws_access_key_id = AKIA5ZDCUJHF83HDTYUT
aws_secret_access_key = uOcdhof683fbOUGFYEQug8fUGIf68greoihef

[Admin]
aws_access_key_id = AKIA8YDCu7TGTR356SHYT
aws_secret_access_key = uOcdhof683fbOUGFYEQuR2EIHG34UY987g6ff7
region = eu-west-2

Si vous devez accéder à différents comptes AWS et que votre profil a été autorisé à assumer un rôle dans ces comptes, vous n’avez pas besoin d’appeler manuellement STS à chaque fois (aws sts assume-role --role-arn <role-arn> --role-session-name sessname) et de configurer les identifiants.

Vous pouvez utiliser le fichier ~/.aws/config pour indiquer quels rôles assumer, puis utiliser le paramètre --profile comme d’habitude (l’assume-role sera effectué de manière transparente pour l’utilisateur).
Un exemple de fichier de configuration :

[profile acc2]
region=eu-west-2
role_arn=arn:aws:iam::<account-id>:role/<role-path>
role_session_name = <session_name>
source_profile = <profile_with_assume_role>
sts_regional_endpoints = regional

Avec ce fichier de configuration, vous pouvez ensuite utiliser aws cli comme :

aws --profile acc2 ...

Si vous recherchez quelque chose de similaire à cela mais pour le navigateur, vous pouvez consulter l’extension AWS Extend Switch Roles.

Automatisation des identifiants temporaires

Si vous exploitez une application qui génère des identifiants temporaires, il peut être fastidieux de les mettre à jour dans votre terminal toutes les quelques minutes lorsqu’ils expirent. Cela peut être résolu en utilisant une directive credential_process dans le fichier de configuration. Par exemple, si vous avez une application web vulnérable, vous pourriez faire :

[victim]
credential_process = curl -d 'PAYLOAD' https://some-site.com

Notez que les identifiants doivent être renvoyés à STDOUT dans le format suivant :

{
"Version": 1,
"AccessKeyId": "an AWS access key",
"SecretAccessKey": "your AWS secret access key",
"SessionToken": "the AWS session token for temporary credentials",
"Expiration": "ISO8601 timestamp when the credentials expire"
}

Références

• https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html
• https://aws.amazon.com/iam/
• 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/

Tip

Apprenez & pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez & pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez & pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Soutenez HackTricks

• Consultez les subscription plans!
• Rejoignez le 💬 Discord group ou le telegram group ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des hacking tricks en soumettant des PRs aux HackTricks et HackTricks Cloud github repos.