dariusiakabos/log4jCompilation OSINT organisée sur Log4Shell (CVE-2021-44228) couvrant les méthodes de détection, la surface d'attaque, les étapes d'atténuation et les indicateurs de compromission pour la réponse à incident.
Compilation de découvertes OSINT sur log4j, incluant la Détection, la Surface d'Attaque, l'Atténuation et les IoC.
Cette vulnérabilité permet à tout attaquant capable d'injecter du texte dans les messages de journalisation ou les paramètres de messages de journalisation des journaux serveur de charger du code depuis un serveur distant. Le serveur ciblé exécute ensuite ce code via des appels à l'interface Java Naming and Directory Interface (JNDI).
JNDI interagit avec un certain nombre de services réseau :
Au 13.12.2021, les attaques observées jusqu'à présent étaient soit des cryptomineurs, soit des botnets automatisés (Mirai, Tsunami et Kinsing)
La meilleure solution est de mettre à niveau vers la version corrigée, mais le défi consiste à trouver où log4j a été déployé en tant que composant et/ou à attendre que le fournisseur publie un correctif.
À court terme :
À long terme :
https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/ - par @TychoTithonus (Royce Williams).
Une compilation d'exemples d'exploits. https://github.com/YfryTchsGD/Log4jAttackSurface
Ressources de Florian Roth (la section des commentaires contient également des informations utiles) https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
/.({|%7B)[Jj][Nn][Dd][Ii]./
https://twitter.com/ThinkstCanary/status/1469439743905697797 Vous pouvez utiliser un canarytoken en un clic depuis https://canarytokens.org pour aider à tester le problème #log4j / #Log4Shell.
Détails sur leur page https://log4shell.huntress.com/
"Comment détecter si vous êtes concerné : lancez netcat en parallèle de votre application : "nc -lp 1234", puis saisissez ce qui suit dans l'application là où cela est journalisé (par exemple la chaîne de requête de votre recherche) : "${jndi:ldap://127.0.0.1:1234/abc}" Si vous voyez ensuite des données parasites/emojis dans la console netcat, vous êtes vulnérable !"
"J'ai écrit un programme Java simple (autonome, sans dépendances) qui corrige JndiLookup.lookup() pour renvoyer une chaîne fixe et ne pas analyser ses arguments. Cela devrait corriger CVE-2021-44228 (c'est-à-dire l'exécution de code à distance dans Log4j) sans redémarrer votre processus JVM." https://github.com/simonis/Log4jPatch "Ceci est une preuve de concept d'un outil simple qui injecte un agent Java dans un processus JVM en cours d'exécution. L'agent corrigera la méthode lookup() de toutes les instances chargées de org.apache.logging.log4j.core.lookup.JndiLookup pour renvoyer inconditionnellement la chaîne "Patched JndiLookup::lookup()". Cela devrait corriger la vulnérabilité d'exécution de code à distance CVE-2021-44228 dans Log4j sans redémarrer le processus Java. Cela n'a pour l'instant été testé qu'avec JDK 8 et 11 !"
Source : Greynose.io
API communautaire https://docs.greynoise.io/reference/get_v3-community-ip
Appel API : curl -X POST https://threatfox-api.abuse[.]ch/api/v1/ -d '{ "query": "taginfo", "tag": "log4j" }
"Veuillez trouver ci-dessous les payloads bruts CVE-2021-44228 Log4J / Logshell que GreyNoise a détectés jusqu'à présent." https://gist.github.com/nathanqthai/01808c569903f41a52e7e7b575caa890
Plus de payloads https://gist.github.com/yt0ng/8a87f4328c8c6cde327406ef11e68726
"Observation de 45[.]155[.]205[.]233 effectuant le scan initial avec une chaîne encodée en base64. Une fois décodée, elle tente d'exécuter curl wget bash etc....pour mettre en place un shell. Les étapes 2, 3 et 4 ont également été observées avec les payloads finaux : Malware nspps/Kingsing via les IP suivantes 44.240.146.137 45.137.155.55 185.154.53.140 185.191.32.198"
45.155.205.233 - IP russe observée en exploitation. https://twitter.com/VessOnSecurity/status/1469950517010968582 https://twitter.com/entropyqueen_/status/1469961345848299520
