Escuchaste sobre Log4j y en las primeras búsquedas en google te habrás 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 debes hacerte 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 mas 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 tu organización este afectada por esta vulnerabilidad. Esto significa que los actores maliciosos tendrían una forma muy simple de atacarte y hacer lo que ya sabemos: Robar tus datos y extorsionarte entre otras cosas. El impacto que podría tener en tu 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 lees 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) ¿Cuales son mis sistemas críticos?
Es muy probable que algo en tu ambiente esté afectado a la vulnerabilidad de Log4j, sin embargo, es fundamental entender qué tan críticos son los sistemas afectados, de manera de 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 cuales de todos los sistemas utilizan Log4j o tienen dependencia con otros sistemas que lo utilizan.
¿Cómo saberlo?, una de las recomendaciones es la utilización 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 mas definitiva a una vulnerabilidad consiste en emparchar el sistema. Sin embargo, el esfuerzo para emparchar 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) ¿Cual es el plan para emparchar los sistemas?
Asumiendo que existe un plan, debería dimensionar los esfuerzos y tiempo requerido
5) ¿Que 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 ti 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
Authors