Détection d’un logiciel malveillant spécifique à AWS Lambda qui exploite la crypto-monnaie • The Register

Cado Security dit avoir découvert une souche de logiciels malveillants spécialement conçus pour s’exécuter dans les environnements sans serveur AWS Lambda et exploiter la crypto-monnaie.

L’équipe a admis qu’elle ne savait pas très bien comment le logiciel méchant, surnommé Denonia, est déployé, bien que vous soyez invités à deviner.

« Il peut s’agir simplement de compromettre l’accès AWS et les clés secrètes, puis de les déployer manuellement dans des environnements Lambda compromis », a suggéré Matt Muir de Cado dans un article technique mercredi.

Bien que l’entreprise de sécurité n’ait vu le logiciel malveillant s’exécuter que dans AWS Lambda, il peut être exécuté dans d’autres environnements à saveur Linux, a déclaré Chris Doman, CTO Security CTO et co-fondateur. Le registre cette semaine.

Et bien que Denonia ne soit pas utilisé, à notre connaissance, pour quoi que ce soit de pire que des activités minières illicites, « cela montre comment les attaquants utilisent des connaissances avancées spécifiques au cloud pour exploiter une infrastructure cloud complexe, et est révélateur d’un avenir potentiel, plus néfaste attaques », a écrit Muir, qui a remercié Doman, Al Carchrie et Paul Scott pour leur aide dans l’exploration du code.

Interrogé sur Denonia, un porte-parole d’AWS nous a dit que c’était à vous, le client, de décider ce qui s’exécute dans votre environnement cloud :

Dans le cadre du modèle de sécurité à responsabilité partagée d’Amazon et d’autres fournisseurs de cloud, AWS sécurise l’environnement sous-jacent – Lambda, dans ce cas – tandis que le client est responsable de la sécurisation de ses propres données et des fonctions Lambda elles-mêmes. En d’autres termes, si vous obtenez Denonia dans votre environnement Lamba, vous ne l’avez probablement pas sauvegardé ou protégé complètement.

Muir a souligné les avantages de sécurité de Lambda. « L’environnement d’exécution géré réduit la surface d’attaque par rapport à un environnement de serveur plus traditionnel », écrit-il.

« Cependant, les courtes durées d’exécution, le volume considérable d’exécutions et la nature dynamique et éphémère des fonctions Lambda peuvent rendre difficile la détection, l’investigation et la réponse à un compromis potentiel. »

A l’intérieur du code

Cado a déclaré que l’échantillon de malware qu’il avait étudié avait un hachage SHA256 de A31a…cbbca.

Le code est écrit dans le langage de programmation Go de Google, qui, selon Muir, est attrayant pour les développeurs de logiciels malveillants, car il est facile à utiliser pour créer des exécutables multiplateformes, autonomes et liés de manière statique. Le code résultant peut être un blob monolithique, ce qui rend la rétro-ingénierie laborieuse, et les chaînes ne sont pas stockées avec des terminateurs nuls de style C, ce qui rend à nouveau l’étude du binaire un peu fastidieuse.

Dans l’analyse de Cado, il est apparu que Denonia contenait une variante personnalisée du XMRig Monero-mining « ainsi que d’autres fonctions inconnues ». Au cours de son analyse dynamique, Denonia a cessé de s’exécuter et a consigné une erreur concernant une variable d’environnement AWS Lambda non définie. Cela a donné à l’équipe Cado un indice sur la manière dont ce logiciel malveillant est censé être déployé.

Comme l’a noté Muir :

Une analyse plus approfondie de Denonia dans le bac à sable de Cado après avoir défini manuellement les variables d’environnement requises a montré que le logiciel « s’exécutera avec plaisir » en dehors de Lambda et dans un environnement Linux. Muir a suggéré que cela était dû au fait que Lambda est basé sur Linux, « donc le logiciel malveillant pensait qu’il était exécuté dans Lambda ».

L’équipe infosec a également noté que le logiciel malveillant comprend plusieurs bibliothèques Go tierces, notamment des outils pour écrire des fonctions Lambda, des aides pour récupérer des informations contextuelles à partir d’une demande d’appel Lambda, des kits de développement logiciel AWS généraux pour Go et DNS-over-HTTPS in Go.

Cette utilisation du DNS sur HTTPS (DoH) est intéressante, a noté Muir. Le DoH crypte les requêtes DNS et envoie les demandes de nom de domaine sous forme de trafic HTTPS normal, ce qui est un « choix assez inhabituel » pour les auteurs de logiciels malveillants, a-t-il écrit. Cependant, cette approche offre quelques avantages.

Tout d’abord, il empêche AWS de voir les recherches DNS, ce qui réduit les chances que le logiciel malveillant soit détecté et arrêté à partir de ses requêtes de nom de domaine. De plus, selon leurs paramètres VPC, certains environnements Lambda peuvent ne pas être en mesure d’effectuer des recherches DNS.

Dans ce cas particulier, le logiciel malveillant a envoyé une requête DoH pour gw[.]dénonia[.]xyz au service DNS de Google, qui a renvoyé une adresse IP pour le domaine. Ces informations sont enregistrées dans un fichier de configuration. Denonia exécute ensuite XMRig à partir de la mémoire et communique avec un pool de minage, permettant ainsi à l’auteur du malware d’utiliser les ressources cloud de la victime pour extraire la cryptographie.

C’est la responsabilité de qui ?

Les analystes de sécurité tiers ont été mitigés dans leurs réactions à la recherche sur les logiciels malveillants Lambda.

« Rien dans le rapport ne suggère que l’infrastructure d’AWS est vulnérable », a écrit Casey Bisson, responsable des relations produits et développeurs de la société de sécurité de code BluBracket, dans un e-mail à Le registre.

Au contraire, cela suggère que la mise en œuvre de l’automatisation de la sécurité par les entreprises est à la traîne, a-t-il déclaré, ajoutant qu’une meilleure surveillance et une gestion automatisée des secrets peuvent aider car il est probable que tous les environnements Lamba infectés par Denonia ont été compromis via des fuites de jetons ou de clés.

« Les instances Lambda sont nombreuses et souvent mal surveillées, ce qui les rend prêtes à être attaquées et potentiellement difficiles à sécuriser », a déclaré Bisson. « C’est une circonstance similaire aux nombreux appareils IoT, non surveillés et mal sécurisés qui ont rendu possible le botnet Mirai. »

Le PDG d’Orca Security, Avi Shua, a fait écho à l’appel de Bisson pour une analyse automatisée du code afin d’aider les développeurs à supprimer les secrets qui pourraient être utilisés à mauvais escient. Il a noté les recherches de son entreprise de sécurité cloud sur Lambda et les secrets qu’elle utilise. « Près de 30 % des fonctions Lambda contiennent des secrets dans leurs variables d’environnement », a déclaré Shua dans un e-mail.

« Ces secrets peuvent être des clés, des jetons d’autorisation, des mots de passe et tout ce qui doit rester privé », a-t-il ajouté. « S’ils sont volés par des logiciels malveillants, ces secrets peuvent également être utilisés pour accéder à d’autres zones connectées comme les compartiments S3 pour atteindre les PII et d’autres données de joyaux de la couronne. »

D’autres analystes de la sécurité ont noté que Denonia montre une confusion continue sur le modèle de sécurité à responsabilité partagée, en particulier avec les nouveaux modèles informatiques tels que les fonctions sans serveur.

La responsabilité partagée « sonne bien en tant que notion abstraite », a noté Oliver Tavakoli, CTO de la société de sécurité AI Vectra dans un e-mail. Mais, a-t-il ajouté, de nombreuses organisations qui utilisent Lambda ne comprennent pas les implications en matière de sécurité.

« Il est de la responsabilité des fournisseurs de services cloud d’éduquer leurs clients sur ces implications et de choisir des valeurs par défaut qui augmentent la probabilité de déploiements sécurisés plutôt que celles qui réduisent les frictions de déploiement tout en exposant les clients à des risques mal compris », a-t-il déclaré.

John Bambenek, principal chasseur de menaces au sein de la société d’opérations de sécurité Netenrich, a déclaré que si le cryptominage est un « fruit à portée de main » pour les mécréants, c’est la première fois qu’il les voit cibler spécifiquement les environnements Lambda.

« Cet incident expose une DMZ floue du modèle de responsabilité partagée », a déclaré Bambenek dans un e-mail. « Alors qu’Amazon sécurise l’environnement Lambda et que le client sécurise son code et ses informations d’identification de compte, la question est de savoir comment les prises de contrôle de compte sont gérées ? Amazon pense que c’est la responsabilité du client, et de nombreuses organisations pensent qu’Amazon devrait mettre en place des contrôles. »

« De toute façon, il est probablement évident pour Amazon de simplement détecter et empêcher l’extraction de crypto-monnaie dans son environnement (à l’exception des instances spécialement conçues pour cela) », a-t-il ajouté. ®