Ir al contenido principal
BlogSeguridadLinode Security Digest 19-26 de diciembre de 2021

Resumen de seguridad de Linode del 19 al 26 de diciembre de 2021

Linode Security Digest

Esta semana, hablaremos de la evolución de las vulnerabilidades de Log4j2 y de algunas medidas útiles de mitigación que puede utilizar para protegerse de ellas. 

La evolución de la vulnerabilidad

Las vulnerabilidades de "Log4Shell" comenzaron con el descubrimiento de una vulnerabilidad crítica de ejecución remota de código en la forma en que Log4j2 manejaba las búsquedas mientras registraba eventos en los sistemas afectados. Esta vulnerabilidad crítica(CVE-2021-44228) obtuvo una puntuación de 10 sobre 10 en el CVSS. Apache declaró que era menos probable que las versiones 1.x de Log4j fueran vulnerables a este hallazgo, ya que JNDI tendría que estar habilitado deliberadamente. Apache publicó la versión 2.15.0 para solucionar esta vulnerabilidad.

Después de que Apache publicara métodos de mitigación para los usuarios que no podían actualizar Log4j2 a la versión 2.15.0, se descubrió otra vulnerabilidad gracias a la atención que este proyecto de código abierto obtuvo al estar en el ojo público. Esta vulnerabilidad(CVE-2021-45046) era inicialmente una vulnerabilidad DOS que tenía una puntuación de 3,7 sobre 10, pero más tarde fue declarada también como una vulnerabilidad de ejecución de código crítica, y la puntuación subió a 9 sobre 10 en CVSS. Apache declaró que las versiones 1.x no eran vulnerables y recomendó a los usuarios de Log4j2 que actualizaran a la versión 2.16.0 para solucionar este segundo problema. Se recomendó el método de eliminación de la clase JNDI Lookup para los usuarios que no pudieran actualizar.

Luego llegó la tercera vulnerabilidad. Aunque (a fecha de 22 de diciembre) no se menciona la ejecución remota de código en la página de seguridad de la versión 2.16.0 de Log4j2, esta vulnerabilidad(CVE-2021-45105) recibió una puntuación de 7,5 sobre 10 en el CVSS, y sólo podía causar un ataque de denegación de servicio en los sistemas vulnerables. Apache publicó la versión 2.17.0 y recomendó a sus usuarios que se actualizaran para solucionar el problema. También han compartido nuevas medidas de mitigación para los usuarios que no puedan actualizar.

Es importante señalar que estas vulnerabilidades estaban siendo explotadas o intentaban serlo durante las fases de descubrimiento y mitigación. Según el blog de 360 Netlab, múltiples familias de malware intentaron propagarse utilizando estas vulnerabilidades. Los actores maliciosos que han explotado con éxito la vulnerabilidad fueron vistos implantando mineros de monedas e instalando ransomware. Estos informes subrayan la importancia de mitigar estas vulnerabilidades lo antes posible.

Métodos oficiales de mitigación

Según la página de seguridad de Log4j2, la actualización del componente a la versión 2.17 mitiga los tres problemas de seguridad conocidos. Para las personas que no pueden actualizar su Log4j2, Apache recomienda eliminar la clase JNDI Lookup de su archivo vulnerable log4j2-core-*.jar. Sin embargo, esto no es suficiente para mitigar la vulnerabilidad de denegación de servicio descubierta recientemente(CVE-2021-45105). Puedes mitigar esta vulnerabilidad de DOS cambiando el PatternLayout en la configuración del registro. Puedes leer la página de seguridad Log4j2 de Apacheenlazada al principio de este párrafo para conocer los detalles de estos métodos de mitigación.

Búsqueda de componentes vulnerables

Si está buscando componentes vulnerables, puede utilizar las herramientas Log4j realizadas por jfrog. Las herramientas de este repositorio son útiles cuando se buscan llamadas vulnerables de Log4j JNDI Lookup en una base de código en la que no se está seguro de si una pieza de código llama a Log4j para funcionar. También puede ayudarle a determinar el estado de vulnerabilidad de los archivos locales. También puede consultar las reglas de uso y explotación de Log4j de Cisco CX Security Labs para escanear sus archivos locales con reglas YARA para determinar si un archivo contiene las clases Java vulnerables; aunque este método puede proporcionar resultados más rápidos, puede dar lugar a más falsos positivos; sin embargo, estas reglas pueden ayudarle a localizar también los componentes dependientes de Log4j. 

El repositorio Log4Shell Hashes de mubix contiene hashes MD5, SHA1 y SHA256 de los archivos log4j2-core vulnerables a la vulnerabilidad crítica inicial RCE(CVE-2021-44228). Por último, puede consultar la base de datos de software vulnerable de CISA (sólo se aplica a CVE-2021-44228) para obtener una lista completa de software vulnerable por proveedor.

Protección contra los ataques

Si no puedes actualizar tu instalación de Log4j2 y si estás usando Fail2Ban en tu servidor, Fail2Ban regex contra Log4Shell por Jay Gooby puede ayudarte a bloquear los intentos de Log4Shell. Si está utilizando CloudFlare, puede utilizar sus reglas WAF para protegerse contra estos ataques. Sin embargo, según el consejo de CISA, se recomienda actualizar a Log4j 2.17.0 o aplicar las mitigaciones recomendadas inmediatamente. También es importante consultar las declaraciones del proveedor sobre otro software que utiliza Log4j2, ya que algunos programas pueden venir incluidos con una versión vulnerable de Log4j que podría necesitar atención.

Búsqueda de COIs y escaneo

Si estás buscando indicadores de compromiso en tus registros, puede ser difícil determinar si hubo intentos de explotar esta vulnerabilidad, principalmente porque hay muchas cargas útiles diferentes que se pueden enviar para explotar el vector de ataque JNDI conocido. Un atacante puede codificar las cadenas de la carga útil, ofuscarlas o dificultar su detección al buscar cargas útiles simples. Aquí es donde Log4Shell-Rex de back2root puede ser útil. Log4Shell-Rex es una expresión regular creada para coincidir con posibles cargas útiles maliciosas codificadas con diferentes métodos. Puedes usarla en tus archivos de registro locales o usarla en tu SIEM para comparar los resultados. Sin embargo, hay que tener en cuenta que la búsqueda con esta expresión regular (con cualquier expresión regular en realidad) puede generar falsos positivos o falsos negativos.

También puede consultar la herramienta Log4j-scan de FullHunt que puede ayudar a descubrir y hacer fuzzing para la vulnerabilidad RCE(CVE-2021-44228), también puede utilizar esta herramienta para probar las derivaciones de WAF para obtener resultados de escaneo más completos.

Esperamos ayudar a nuestros clientes compartiendo información útil en estos resúmenes de seguridad. Como siempre, no dudes en compartir tu opinión dejando un comentario a continuación.


Comentarios

Dejar una respuesta

Su dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *.