
El objetivo es clasificar ataques conocidos y aprender cómo los equipos de seguridad responden rápidamente.
Para este laboratorio, el objetivo era hacer triage de otra vulnerabilidad real muy conocida, esta vez EternalBlue, la falla de SMBv1 que fue explotada notoriamente por el brote de ransomware WannaCry.
Fui a la National Vulnerability Database y busqué el CVE:
https://nvd.nist.gov/vuln/search#/nvd/home?resultType=records
Busqué CVE-2017-0144 y abrí la página de resultados.
Después de leer la descripción, respondí algunas preguntas básicas para entender qué está realmente en riesgo:
Encontré la puntuación CVSS y la cadena de vector listadas en la página:
Revisé la cadena de vector parte por parte para ver qué significaba realmente cada elemento:
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Esta requiere pocos privilegios para explotarse (a diferencia de ProxyLogon, que no requería ninguno), pero sigue sin necesitar interacción del usuario, y un ataque exitoso compromete por completo la confidencialidad, la integridad y la disponibilidad. Esa combinación es en gran parte la razón por la que EternalBlue era tan peligroso una vez que se emparejó con un gusano que se autopropaga como WannaCry.
Revisé la sección Weakness Enumeration en la página de NVD para este CVE, pero no se listó ninguna CWE para él.
Consideré si trataría esto como un riesgo mayor o menor en dos escenarios diferentes.
Escenario 1: El software vulnerable está activo y es accesible. Riesgo mayor. Esta vulnerabilidad permite a un atacante acceder remotamente al servidor, ejecutar código y acceder a archivos.
Escenario 2: El software vulnerable está instalado en una máquina que está apagada y no es accesible. Riesgo menor. Sin alimentación ni conexión de red, no hay forma de que un atacante llegue realmente al servidor para explotar la vulnerabilidad en primer lugar.
Comparando esto con el triage de ProxyLogon, es un buen ejemplo de cómo dos vulnerabilidades críticas pueden diferir en los detalles: EternalBlue necesita pocos privilegios mientras que ProxyLogon no requería ninguno, pero ambas siguen cayendo en la categoría de "tratar como alto riesgo" una vez que se observa cuánto daño podría hacer un exploit exitoso. Igual que antes, el riesgo real sigue dependiendo del contexto: la misma vulnerabilidad es mucho menos peligrosa en una máquina que está fuera de línea e inaccesible.