English
Español
Français
Deutsch
日本語
한국어
العربيةDétourner le rôle d'instance via une commande SSM
Peut exécuter une commande sur une instance via SSM et voler son rôle de profil d'instance.
N'accorde l'escalade qu'en combinaison. Tous ces éléments sont nécessaires ensemble :
ssm:SendCommandec2:DescribeInstancesssm:SendCommand peut exécuter une commande sur une instance via SSM et voler le rôle de son profil d'instance, mais uniquement lorsqu'elle est détenue conjointement avec ec2:DescribeInstances. Détenues ensemble, elles atteignent l'accès administrateur.
Pourquoi c'est dangereux
Un principal peut appeler ssm:SendCommand pour exécuter un document AWS-RunShellScript sur une instance gérée par SSM qui porte déjà le rôle de profil d'instance, exécutant des commandes de l'attaquant qui lisent les identifiants actifs de l'instance depuis IMDS et les expédient, de manière non interactive, sans session shell, clé ni port ouvert. Comme l'instance est déjà liée à la machine, l'exécution de commandes sur celle-ci suffit à voler le rôle, sans iam:PassRole. Si l'instance est privilégiée, il s'agit d'une escalade de privilèges complète contre une instance qui était déjà de confiance, et c'est scriptable sur de nombreuses instances à la fois.
En termes MITRE ATT&CK, cela correspond à T1578, Modification de l'infrastructure de calcul cloud, dans la tactique escalade de privilèges. AWS l'enregistre dans CloudTrail sous SendCommand, DescribeInstances. L'appel apparaît dans CloudTrail mais se fond dans l'administration normale, il lui faut donc une règle pour ressortir.
Détection
SendCommandDescribeInstancesPrérequis
Une instance gérée par SSM existante portant un profil d'instance ; la permission ssm:SendCommand. ec2:DescribeInstances énumère les cibles et est vérifié par rapport à un caractère générique. L'agent SSM doit être enregistré sur l'instance.
Tactique
Escalade de privilèges
Un contrôle qui le supprimerait : Restreindre ssm:SendCommand aux principaux break-glass ; réduire les permissions du rôle du profil d'instance.
La décision de l'appliquer dépend de la façon dont la permission est utilisée dans votre environnement, il s'agit donc d'une décision métier plutôt que d'un correctif automatique. La même permission peut être porteuse dans un compte et pur risque dans un autre.
Pathbreak confirme si ce chemin se résout dans votre compte, le classe par rapport aux autres selon l'ampleur de ce qu'il ouvre, et utilise votre modèle de menace et votre contexte métier pour montrer quels chemins valent la peine d'être coupés.
Questions
Que permet ssm:SendCommand ?
Peut exécuter une commande sur une instance via SSM et voler son rôle de profil d'instance.
Que faut-il d'autre pour que ssm:SendCommand soit dangereux ?
Cela ne devient une escalade que lorsqu'il est détenu conjointement avec ec2:DescribeInstances. À lui seul, il ne suffit pas, ce qui rend la combinaison facile à manquer.
Comment détecter le détournement du rôle d'instance via une commande SSM ?
Surveillez SendCommand, DescribeInstances dans CloudTrail. Cet appel apparaît dans CloudTrail mais se fond dans l'administration normale, il faut donc une règle pour le faire ressortir.
Comment briser ce chemin ?
Un contrôle qui le supprimerait est : Limitez ssm:SendCommand aux principaux d'urgence (break-glass) ; réduisez les permissions du rôle de profil d'instance. L'appliquer ou non dépend de la manière dont l'autorisation est utilisée dans votre compte, il s'agit donc d'une décision métier plutôt que d'un correctif automatique.
De quelle technique MITRE ATT&CK s'agit-il ?
T1578, Modification de l'infrastructure de calcul cloud, dans la tactique escalade de privilèges.
Chemins associés
Références
Trouvez ceci dans votre propre compte
Nous réalisons un scan en lecture seule d'un compte AWS et vous montrons lesquels de ces chemins existent, classés par rayon d'impact, avec le changement qui brise chacun d'eux. Premiers chemins validés en moins d'une heure.