Les attaquants peuvent transformer les agents AWS SSM en chevaux de Troie d’accès à distance – Help Net Security

Les chercheurs de Mitiga ont documenté une nouvelle technique de post-exploitation que les attaquants peuvent utiliser pour obtenir un accès à distance persistant aux instances AWS Elastic Compute Cloud (EC2) (serveurs virtuels), ainsi qu’aux machines non-EC2 (par exemple, les serveurs d’entreprise sur site et les serveurs virtuels). machines virtuelles et machines virtuelles dans d’autres environnements cloud).

Le succès de cette technique de « vivre de la terre » repose sur :

• Les attaquants obtiennent un accès initial à la machine (par exemple, en exploitant une vulnérabilité non corrigée sur une instance/un serveur public) et
• La présence de l’agent SSM, un composant logiciel que les administrateurs système d’entreprise utilisent pour gérer les points de terminaison à partir du compte AWS à l’aide du service AWS System Manager

«Après avoir contrôlé l’agent SSM, les attaquants peuvent mener des activités malveillantes, telles que le vol de données, le cryptage du système de fichiers (en tant que ransomware), l’utilisation abusive des ressources des points de terminaison pour l’extraction de crypto-monnaie et la tentative de propagation à d’autres points de terminaison du réseau sous couvert de en utilisant un logiciel légitime, l’Agent SSM », ont expliqué les chercheurs de Mitiga Ariel Szarf et Or Aspir.

Scénarios possibles

Les chercheurs ont essayé deux scénarios différents, et le niveau d’accès requis pour les deux est élevé. Dans le premier scénario, l’acteur de la menace nécessite un accès root sur la machine Linux ciblée ou des privilèges d’administrateur sur le système Windows ciblé, tandis que dans le second, il doit pouvoir s’exécuter au moins en tant qu’utilisateur privilégié non root sur la machine Linux ciblée ou en tant qu’administrateur sur le système Windows ciblé.

« [In the first scenario], l’attaque « détourne » le processus d’origine de l’Agent SSM en enregistrant l’Agent SSM pour qu’il fonctionne en mode « hybride » avec un compte AWS différent, l’obligeant à ne pas choisir le serveur de métadonnées pour la consommation d’identité. Ensuite, l’agent SSM communiquera et exécutera les commandes de l’attaquant du compte AWS détenu », ont-ils expliqué.

Dans le deuxième scénario, l’attaquant exécute un autre processus de l’Agent SSM en utilisant des espaces de noms Linux ou en définissant des variables d’environnement spécifiques sous Windows. « Le processus d’agent malveillant communique avec le compte AWS de l’attaquant, laissant l’agent SSM d’origine continuer à communiquer avec le compte AWS d’origine. »

Et si l’auteur de la menace préfère ne pas utiliser un compte AWS pour gérer les agents, il n’a pas à le faire : il existe une fonctionnalité SSM qui peut être utilisée de manière abusive pour acheminer le trafic SSM vers un serveur contrôlé par l’attaquant (c’est-à-dire, pas via les serveurs AWS ).

Détection et prévention

Transformer l’Agent SSM en un cheval de Troie d’accès à distance permet aux attaquants de compromettre les terminaux sans se faire repérer par les solutions de sécurité installées. Les communications C&C semblent légitimes, il n’est pas nécessaire de développer une infrastructure d’attaque distincte et l’agent SSM peut être utilisé pour manipuler le point de terminaison via des fonctionnalités prises en charge.

Le fait que l’agent SSM soit préinstallé sur certaines Amazon Machine Images populaires et soit donc déjà installé et exécuté sur de nombreuses instances EC2 existantes élargit le bassin de cibles potentielles pour les adversaires, ont souligné les chercheurs.

Heureusement, il existe des moyens de détecter l’utilisation de cette technique. Ils incluent : garder un œil sur les nouveaux ID d’instance, l’utilisation de commandes spécifiques, les connexions perdues aux agents SSM dans le compte AWS, les nouveaux processus et les actions suspectes liées à Sessions Manager dans les journaux Amazon CloudTrail.

Les chercheurs conseillent aux administrateurs système d’entreprise de :

• Supprimer le binaire de l’Agent SSM de la liste d’autorisation de leurs solutions AV et EDR, afin qu’ils puissent être examinés et que le comportement des processus soit analysé pour un comportement anormal/suspect
• Intégrez les techniques de détection décrites dans leurs plates-formes SIEM et SOAR pour faciliter la chasse aux menaces.

« Nous croyons fermement que les acteurs de la menace en abuseront dans les attaques du monde réel, s’ils ne le font pas déjà. Pour cette raison, comprendre et atténuer les risques associés à son utilisation abusive est crucial pour protéger les systèmes contre cette menace en évolution », ont-ils noté, et ont souligné que l’équipe de sécurité AWS a également proposé une solution pour restreindre la réception des commandes de l’AWS d’origine. compte/organisation utilisant le point de terminaison Virtual Private Cloud (VPC) pour Systems Manager.

« Si vos instances EC2 se trouvent dans un sous-réseau privé sans accès au réseau public via une adresse EIP publique ou une passerelle NAT, vous pouvez toujours configurer le service System Manager via un point de terminaison VPC. Ce faisant, vous pouvez vous assurer que les instances EC2 répondent uniquement aux commandes provenant de mandataires au sein de leur compte ou organisation AWS d’origine. Pour implémenter efficacement cette restriction, reportez-vous à la documentation de la stratégie VPC Endpoint.

MISE À JOUR (5 août 2023, 05 h 20 HE) :

« Les logiciels et les systèmes AWS se comportent comme prévu et les clients n’ont aucune action à entreprendre », a commenté un porte-parole d’AWS pour Help Net Security.

« Les problèmes décrits dans la publication Mitiga, intitulée « Mitiga Security Advisory : Abusing the SSM Agent as a Remote Access Trojan », exigent qu’un acteur obtienne à la fois des informations d’identification au niveau racine et accède avec succès à une instance EC2 afin d’être exploité. Comme bonne pratique de sécurité, nous recommandons aux clients AWS de suivre notre documentation sur la configuration correcte des points de terminaison de VPC avec AWS Systems Manager et d’utiliser des clés de condition globales pour les points de terminaison de VPC et les politiques de point de terminaison de VPC afin d’atténuer le risque d’accès inapproprié aux instances EC2.