La semana pasada, discutimos Log4Shell y otras vulnerabilidades , implicaciones y acciones de mitigación recomendadas relacionadas con Log4j. Veo que la vulnerabilidad de Log4Shell, que se ha transformado en múltiples vulnerabilidades, se quedará con nosotros por un tiempo. Entonces, aquí hay una actualización de lo que sabemos hasta ahora, con la información más reciente.
Descripción general del resumen de Log4shell
10 de diciembre de 2021 : la vulnerabilidad original de Log4Shell se reveló bajo CVE-2021-44228 con la posibilidad de que un atacante ejecute código inyectado utilizando la funcionalidad de búsqueda de mensajes. Las versiones afectadas fueron Log4j v2.0-2.14.1.
13 de diciembre de 2021 : la segunda vulnerabilidad revelada bajo CVE-2021-45046 podría permitir a los atacantes crear datos de entrada maliciosos que podrían causar una fuga de información, ejecución remota de código y denegación de servicio (DoS).
16 de diciembre de 2021 : la tercera vulnerabilidad revelada en CVE-2021-45105 podría permitir que un atacante inicie un ataque de denegación de servicio (DoS) al provocar un bucle de recurrencia infinito en las búsquedas autorreferenciales.
¿Qué debes hacer?
Identificar : identificación de activos afectados por Log4Shell y otras vulnerabilidades relacionadas con Log4j.
Parche : actualización de los activos de Log4j y los productos afectados a la última versión disponible.
Hunt : iniciar procedimientos de búsqueda y respuesta a incidentes para detectar una posible explotación de Log4Shell.
Escáner Log4j para encontrar aplicaciones vulnerables
El 21 de diciembre , la Agencia de Seguridad de Infraestructura y Ciberseguridad (CISA) anunció el lanzamiento de un escáner para identificar servicios web afectados por dos vulnerabilidades de ejecución remota de código Apache Log4j, rastreadas como CVE-2021-44228 y CVE-2021-45046.
Según la agencia, "log4j-scanner es un proyecto derivado de otros miembros de la comunidad de código abierto por el equipo Rapid Action Force de CISA para ayudar a las organizaciones a identificar servicios web potencialmente vulnerables afectados por las vulnerabilidades de log4j".
Se recomienda encarecidamente utilizar la herramienta de análisis para identificar los servicios afectados por las vulnerabilidades de Log4j y parchearlos a la última versión de Log4j, que es la 2.17.0.
Otras recomendaciones de mitigación que puede considerar cuando la actualización de Log4j no es una opción:
- Implemente reglas de detección y prevención de firewall de aplicaciones web (WAF) y sistemas de prevención de intrusiones (IPS). Si bien los actores de amenazas podrán eludir esta mitigación, la reducción de las alertas permitirá que el Centro de operaciones de seguridad (SOC) de la organización se concentre en un conjunto más pequeño de alertas.
- Reducción de la superficie de ataque al bloquear los puertos estándar para LDAP, LDAPS y RMI (389, 636, 1099, 1389). Aunque esto no es a prueba de balas, ya que los puertos se pueden aleatorizar, aún puede reducir la superficie de ataque.
- Deshabilite la biblioteca Log4j. Deshabilitar el software que usa la biblioteca Log4j es una medida efectiva, que favorece el tiempo de inactividad controlado sobre los problemas causados por el adversario. Sin embargo, esta opción podría tener impactos operativos y limitar la visibilidad de otros problemas.
- Deshabilite las búsquedas JNDI o deshabilite las bases de código remotas. Esta opción, si bien es efectiva, puede implicar el trabajo del desarrollador y podría afectar la funcionalidad.
- Desconecte las pilas afectadas. Las pilas de soluciones que no están conectadas a las redes de la organización presentan un riesgo de ataque drásticamente menor. Considere desconectar temporalmente la pila de las redes, si es posible.
- Aislar el sistema. Cree una VLAN de "red vulnerable" y segmente la pila de soluciones del resto de la red empresarial.
La solución Allot Traffic Intelligence puede proporcionar detección y prevención de intentos de ataques de Log4Shell a través de HTTP. Tenga en cuenta que el ataque se puede ejecutar sobre diferentes protocolos y servicios, como LDAP, DNS, RMI y CORBA, por lo que es muy recomendable implementar reglas de detección y prevención también en los sistemas de seguridad IPS y WAF.
Una firma que detecta este tipo de ataques ya está disponible en el paquete de protocolo ERT-PP 3.153.90 de Allot, así como en el paquete de protocolo oficial 3.154. Con la nueva firma, Allot proporciona una detección marcada como "vulnerabilidad Log4j RCE" con un alto nivel de confianza en el patrón de ataque Log4j. Se recomienda configurar una política para bloquear dicho tráfico. Además, hay otra firma (con poca confianza) marcada como "Log4j RCE vulnerabilidad II", que se puede usar solo para detecciones, y los equipos de SOC deben realizar un análisis adicional.
La semana pasada, vi una linda anécdota sobre Log4j. El regulador de Internet de China, el Ministerio de Industria y Tecnología de la Información (MIIT), suspendió una asociación con Alibaba Cloud, la subsidiaria de computación en la nube del gigante del comercio electrónico Alibaba Group, durante seis meses debido a que no informó de inmediato al gobierno. sobre una vulnerabilidad de seguridad crítica que afecta a la biblioteca de registro Log4j ampliamente utilizada.
Las empresas chinas están obligadas a informar sobre las vulnerabilidades de su propio software al MIIT a través de su sitio web de la Base de datos nacional de vulnerabilidades, según una nueva regulación aprobada este año. Sin embargo, el Reglamento de gestión de lagunas en la seguridad de los productos de Internet, que entró en vigor en septiembre, sólo “alienta” a las empresas a informar de los errores encontrados en el software de otros.
Fuente: https://www.allot.com/blog/log4j-what-you-should-do/