Si escuchó sobre Log4j y en las primeras búsquedas en Google se habrá encontrado con mucha información que casi inmediatamente ingresa en un lenguaje extremadamente técnico y complejo.
En este artículo me enfoco en los porqués y un poco del cómo, proponiendo las 5 preguntas principales que debe hacerse y hacerle al staff de TI y seguridad.
El 9 de diciembre se divulgó una vulnerabilidad crítica. ¿Qué tan crítica? Algo así como de lo más crítico que se ha visto en estos tiempos, con un puntaje de 10, en el CVSS (Sistema de puntuación de vulnerabilidad comunes), en una escala de…. 1 a 10, y de 93/100 basado en la inteligencia de vulnerabilidades de Cisco Kenna.
¿Por qué es tan crítico?, básicamente porque afecta potencialmente a millones de aplicaciones.
Entonces, es muy probable que su organización este afectada por esta vulnerabilidad. Esto significa que los actores maliciosos tendrían una forma muy simple de atacarle y hacer lo que ya sabemos: Robar sus datos y extorsionarle entre otras cosas. El impacto que podría tener en su organización es muy grande.
¿Teoría o realidad? Desde el 1 de diciembre, el centro de inteligencia de amenazas de Cisco fue el primero en detectar ataques y al momento en que lee esto los hackers, tanto los delincuentes como los éticos, están activamente escaneando Internet para detectar sistemas expuestos.
Entonces, estamos frente a una vulnerabilidad masiva, fácilmente explotable, que está siendo atacada en este momento y que permite ejecución de código remoto en tu ambiente, en otras palabras, provocar mucho daño.
Por ello, aquí proponemos las 5 preguntas fundamentales que debemos hacernos y hacerle a quienes estarán trabajando duro para mitigar este problema.
1) ¿Cuáles son mis sistemas críticos?
Es muy probable que algo en su ambiente esté afectado a la vulnerabilidad de Log4j, sin embargo, es fundamental entender qué tan críticos son los sistemas afectados, para calcular el impacto y establecer los esfuerzos para controlar el problema.
2) ¿Están mis sistemas expuestos a esta vulnerabilidad?
Esta pregunta puede no ser tan trivial de responder porque es difícil saber de forma rápida cuáles de todos los sistemas utilizan Log4j o tienen dependencia con otros sistemas que lo utilizan.
¿Cómo saberlo? Una de las recomendaciones es el uso de escáneres que permiten automatizar la detección de sistemas vulnerables de forma rápida y escalable.
3) ¿Qué capacidades tenemos para proteger los sistemas?
La solución más definitiva a una vulnerabilidad consiste en parchar el sistema. Sin embargo, el esfuerzo para parchar es grande, lleva tiempo y muchas veces tiene algunas complicaciones.
Por ello, existen una serie de mitigaciones complementarias para lograr una protección efectiva y a tiempo. Aquí hay que tener cuidado en validar las recomendaciones porque también pueden ser incorrectas, o parcialmente eficaces.
Como siempre en seguridad, no hay balas de plata y una estrategia de “defensa en profundidad” ofrece capas de protección complementarias para mitigar este tipo de amenazas.
4) ¿Cuál es el plan para emparchar los sistemas?
Asumiendo que existe un plan, debería dimensionar los esfuerzos y tiempo requerido
5) ¿Qué protección existe pos-explotación?
Sin perder de vista que la explotación a la vulnerabilidad de Log4j representa un vector de ataque para luego infectar el sistema con diversas formas de malware, es importante reconocer qué protección existe para mitigar la ejecución de la cadena de ataque.
Si a usted también te fastidia encontrar siglas y términos confusos en los artículos que hablan de este tema, puede ser útil este glosario con definiciones relacionadas a Log4j.
• Log4j: Es una biblioteca de código abierto desarrollada en Java por la Apache Software Foundation que permite a los desarrolladores de software escribir mensajes de registro, cuyo propósito es dejar constancia de una determinada transacción en tiempo de ejecución.
• Log4Shell: nombre otorgado a la vulnerabilidad de día cero que permite ejecución de código arbitrario en Log4j
• RCE: Remote Code Execution / Ejecución de Código de Forma Remota
• Java: Lenguaje de programación de amplia adopción global
• CVE: Common Vulnerabilities and Exposures. Método de referencia para la divulgación de vulnerabilidades y exposición
• CVSS: Common Vulnerability Scoring System / Sistema de Puntuación de Vulnerabilidades
• JNDI: Java Naming and Directory Interface es una Interfaz de Programación de Aplicaciones (API) de Java para servicios de directorio. En el contexto de la vulnerabilidad de Log4j, JNDI es utilizado para insertar una instrucción tomando provecho de la vulnerabilidad
• LDAP: Lightweight Directory Access Protocol / Protocolo Liviano de Acceso al Directorio. En el contexto de la vulnerabilidad de Log4j, el sistema comprometido se podría comunicar con un servidor LDAP malicioso para descargar código malicioso
