dariusiakabos/log4jRecopilación OSINT curada sobre Log4Shell (CVE-2021-44228) que cubre métodos de detección, superficie de ataque, pasos de mitigación e indicadores de compromiso para la respuesta a incidentes.
Recopilación de hallazgos de OSINT sobre log4j, incluyendo Detección, Superficie de Ataque, Mitigación e IoCs.
Esta vulnerabilidad permite que cualquier atacante que pueda inyectar texto en mensajes de registro o en parámetros de mensajes de registro en los logs del servidor pueda cargar código desde un servidor remoto. El servidor objetivo ejecuta entonces ese código mediante llamadas a la Interfaz de Nombres y Directorios de Java (JNDI).
JNDI interactúa con varios servicios de red:
Hasta el 13.12.2021, los ataques hasta ahora eran mineros de criptomonedas y botnets automatizados (Mirai, Tsunami y Kinsing)
La mejor solución es actualizar a la versión parcheada, pero el desafío es encontrar dónde se implementó log4j como componente y/o esperar a que el proveedor lo parchee.
A corto plazo:
A largo plazo:
https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/ - por @TychoTithonus (Royce Williams).
Una recopilación de ejemplos de exploits. https://github.com/YfryTchsGD/Log4jAttackSurface
Recursos de Florian Roth (la sección de comentarios también contiene información útil) https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
/.({|%7B)[Jj][Nn][Dd][Ii]./
https://twitter.com/ThinkstCanary/status/1469439743905697797 Puedes usar un canarytoken de apuntar y hacer clic desde https://canarytokens.org para ayudar a probar el problema de #log4j / #Log4Shell.
Detalles en su página https://log4shell.huntress.com/
"Cómo detectar si está afectado: inicia netcat en paralelo a tu aplicación: "nc -lp 1234", luego escribe lo siguiente en la aplicación donde se registre (por ejemplo, la cadena de consulta de tu búsqueda): "${jndi:ldap://127.0.0.1:1234/abc}" Si luego ves basura/emojis en la consola de netcat, ¡eres vulnerable!"
"He escrito un programa Java simple (es decir, independiente, sin dependencias) que parchea JndiLookup.lookup() para devolver una cadena fija y no analizar sus argumentos. Esto debería corregir CVE-2021-44228 (es decir, RCE en Log4j) sin reiniciar tu proceso JVM." https://github.com/simonis/Log4jPatch "Esta es una POC de una herramienta simple que inyecta un agente Java en un proceso JVM en ejecución. El agente parcheará el método lookup() de todas las instancias cargadas de org.apache.logging.log4j.core.lookup.JndiLookup para devolver incondicionalmente la cadena "Patched JndiLookup::lookup()". Esto debería corregir la vulnerabilidad de ejecución remota de código CVE-2021-44228 en Log4j sin reiniciar el proceso Java. Esto solo se ha probado actualmente con JDK 8 y 11!"
Fuente: Greynose.io
API de la comunidad https://docs.greynoise.io/reference/get_v3-community-ip
Llamada API: curl -X POST https://threatfox-api.abuse[.]ch/api/v1/ -d '{ "query": "taginfo", "tag": "log4j" }
"Encuentra a continuación los payloads crudos de CVE-2021-44228 Log4J / Logshell que GreyNoise ha detectado hasta ahora." https://gist.github.com/nathanqthai/01808c569903f41a52e7e7b575caa890
"Viendo a 45[.]155[.]205[.]233 hacer el escaneo inicial con una cadena codificada en base64. Al decodificarla, intenta hacer un curl wget bash etc....para configurar un shell. También se vieron las etapas 2, 3 y 4 con payloads finales: malware nspps/Kingsing a través de las siguientes IPs 44.240.146.137 45.137.155.55 185.154.53.140 185.191.32.198"
45.155.205.233 - IP rusa vista explotando la vulnerabilidad. https://twitter.com/VessOnSecurity/status/1469950517010968582 https://twitter.com/entropyqueen_/status/1469961345848299520
