Amazon, Apple, Twitter, Minecraft, Cloudflare, Steam: esta es solo una lista muy parcial de las organizaciones afectadas por esta vulnerabilidad. Las implicaciones son de gran alcance, ya que Log4j es una biblioteca de registro extremadamente común que se utiliza en la mayoría de las aplicaciones Java, incluidos los sistemas comerciales, para registrar información de registro. Menos de 24 horas después de que se publicara esta vulnerabilidad, ya se implementó un criptominero para explotar esta vulnerabilidad.
Log4Shell ya estaba siendo explotado durante unos días antes de que se hiciera público. Los intentos de escaneo de Log4shell se detectaron con hasta dos semanas de anticipación. Los atacantes podrían instalar criptomineros, crear botnets y robar datos confidenciales y credenciales del sistema. Hasta la fecha, se estima que más de un millón de máquinas se han visto afectadas.
Los primeros ataques y escaneos, que todavía eran manuales, ahora están siendo seguidos por intentos automatizados de explotar la vulnerabilidad. Después de que algunos expertos especularan con cautela que la vulnerabilidad tenía potencial de gusano, la realidad ahora se está poniendo al día: los expertos en seguridad han detectado variantes de los drones de botnet Mirai que infectan servidores vulnerables similares a gusanos y se propagan automáticamente.
Mientras tanto, el muy activo grupo de extorsión Conti también se subió al carro de Log4j y está utilizando la vulnerabilidad para penetrar servidores y redes y configurar su ransomware. Cybergang revende los accesos obtenidos de esta forma. Su modelo de negocio se llama ransomware-as-a-service.
Los intentos de ataque anteriores probablemente fueron principalmente pruebas. Pero ahora se está poniendo serio. El cibercrimen y los servicios secretos utilizan la brecha para sus propios fines.
La mayoría de los ataques a la vulnerabilidad siguen siendo exploraciones generales de vulnerabilidad. Su gran número ya está disminuyendo un poco. Pero eso no significa que todo esté despejado. El especialista en redes de distribución de contenido Akamai informa que sus sistemas detectan 250 000 intentos de ataques a la vulnerabilidad CVE-2021-44228 cada hora. La compañía asume que este tipo de ataques nos acompañarán durante los próximos meses.
¿Cómo reparar la vulnerabilidad Log4J RCE?
La forma más sencilla y recomendada de solucionar esta vulnerabilidad es actualizar a Log4J versión 2.15.0 o posterior.
Si la actualización no es posible por algún motivo o no es posible con poca anticipación, puede mitigar el peligro en las versiones anteriores 2.10.0 a 2.15.0 con la siguiente configuración del sistema:
log4j2.formatMsgNoLookups=verdadero
Además, se puede establecer una variable de entorno:
LOG4J_FORMAT_MSG_NO_LOOKUPS=verdadero
Para las versiones de 2.0-beta9 a 2.10.0, la solución sería eliminar la clase JndiLookup del classpath. El comando para realizar tal acción es:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Para obtener más detalles, consulte la confirmación de GitHub que corrige esta vulnerabilidad.