DISCLAIMER

Todo el contenido de esta presentación es únicamente con fines didácticos y

educativos. El uso indebido de las técnicas y/o conocimientos utilizadas en esta
presentación puede ir en contra de las leyes nacionales e internacionales. El
autor no se hace responsable por el uso del conocimiento contenido en la
siguiente presentación. La información contenida debe ser utilizada únicamente
para fines éticos y con la debida autorización.
 Cómo se “publica” una vulnerabilidad

➢ Un criminal la descubre y empieza a ofrecer esa información en foros y

markets especializados
➢ Un investigador independiente la descubre y contacta directamente al
fabricante o a alguien de confianza
➢ Un investigador independiente la descubre y la publica en su blog o canal
público
➢ Un investigador, contratado específicamente por el fabricante (directa o
indirectamente), la descubre y la reporta
➢…
 Cómo se “publica” una vulnerabilidad

Revelar todo lo que se VS No revelar nunca ni a

conoce acerca de una nadie la vulnerabilidad
vulnerabilidad, tan pronto lo descubierta
descubriste

Ninguno de los dos extremos es óptimo:

Disclosure Responsable o Coordinado de
vulnerabilidades
 Principios del Disclosure Coordinado de vulnerabilidades

✓ Reducir el daño
✓ Presumir benevolencia
✓ Evitar sorpresas OJO!! La ausencia de
evidencia no significa
✓ Incentivar el comportamiento deseado evidencia de ausencia
✓ Consideraciones éticas
✓ Mejora de los procesos
 Vulnerability Disclosure – Fases y actores

Validación y Publicación /
Descubrimiento Reporte Remediación
Triage Comunicación

✓ Finder
✓ Reporter
✓ Vendor / Fabricante
✓ Coordinador
✓ Deployer
 Tipos de Disclosure de vulnerabilidades
✓ No disclosure: el fabricante u organización no revela a nadie la vulnerabilidad que le fue
revelada y no permite que el investigador (Finder) lo revele

✓ Disclosure privado: el fabricante, organización y/o investigador lo revela solamente a sus

clientes del componente afectado

✓ Disclosure parcial o limitado: el fabricante, organización y/o investigador revela información

sobre la vulnerabilidad al público, pero limitando los detalles divulgados

✓ Full Disclosure: el fabricante, organización y/o investigador publica todos los detalles
conocidos de la vulnerabilidad, en muchos casos, incluido una prueba de concepto
https://resources.sei.cmu.edu/asset_files/SpecialReport/2017_003_001_503340.pdf
https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html
 Algunas estadísticas y números
➢ Un promedio de 52 nuevas vulnerabilidades únicas son conocidas diariamente por la
industria / comunidad
➢ Un promedio diario de 186 vulnerabilidades se actualiza sus detalles
➢ Tiempo promedio entre el reporte de la vulnerabilidad y la publicación de un parche es de
9 días
➢ Regla 80/20 – el 20% de las vulnerabilidades generan el 80% del riesgo

PRIORIZACIÓN

https://www.fireeye.com/blog/threat-research/2020/04/time-between-
disclosure-patch-release-and-vulnerability-exploitation.html
 Common Vulnerabilities and Exposure
CVE es un sistema estándar de identificación único de vulnerabilidades conocidas
Formato:
● CVE-YYYY-NNNN donde YYYY= año y NNNN= número de vulnerabilidad
● El formato para las entradas candidatas a entrar en el CVE es: CAN-YYYY-NNNN
Ejemplo: CVE-2012-4608, CVE-2017-16537 , CVE-1999-0095

➢ Definido y mantenido por The MITRE Corporation con fondos de la National Cyber Security
Division del gobierno de EEUU.
➢ La información y nomenclatura de esta lista es usada en la National Vulnerability Database
(NIST).
 Escala CVSS
Sistema de métrica utilizado para estimar el impacto de una vulnerabilidad de
acuerdo a las cualidades de la misma

Dimensiones de medición:
● Base: Engloba las cualidades intrínsecas de una vulnerabilidad y que son independientes del
tiempo y el entorno.
● Temporal: Características de la vulnerabilidad que cambian en el tiempo.
● Environmental: Características de la vulnerabilidad relacionadas con el entorno del usuario.

➢ El valor CVSS Base representa la criticidad de una vulnerabilidad en el peor escenario posible
➢ El valor CVSS Environmental de una vulnerabilidad debe ser calculado por cada organización
y por cada sistema afectado.
Métricas CVSS v3.1
 Métricas CVSS - BASE
Base: mide las cualidades intrínsecas de una vulnerabilidad, independientes del tiempo y del entorno.
● Access Vector (AV). Valores: [P,L,A,N] (Physical, Local, Adjacent, Network)

● Access Complexity (AC). Valores [H,L] (High, Low)

● Privilege Required (PR). Valores [H,L,N] (High, Low, None)

● User Interaction (UI). Valores [R,N] (Required, None)

● Scope (S). Valores [C,U] (Changed, Unchanged)

● Confidentiality Impact (C) . Valores [N,L,H] (None, Low, High)

● Integrity Impact (I). Valores [N,L,H] (None, Low, High

● Availability Impact (A). Valores [N,L,H] (None, Low, High)

 Métricas CVSS – TEMPORAL Y ENVIRONMENTAL
Temporal: Características de la vulnerabilidad que cambian en el tiempo
● Exploit Code Maturity (E). Valores: [U,POC,F,H,ND] (Unproven, Proof-of-Concept, Functional, High, Not
Defined)
● Remediation Level (RL). Valores: [OF,TF,W,U,ND] (Official Fix, Temporary Fix, Workaround, Unavailable, Not
Defined)
● Report Confidence (RC). Valores: [U,R,C,ND] (Unknow, Reasonable,, Confirmed, Not Defined)

Environmental: Características de la vulnerabilidad relacionadas con el entorno del

usuario
● Security Requirements (CR, IR, AR). Valores: [L,M,H,ND] (Low, Medium, High, Not Defined)
● Valores modificados del Base: Modified AV, Modified AC, Modified PR, etc...
 Herramientas CVSS
Herramientas para la evaluación de vulnerabilidades mediante la escala CVSS:

● Especificación: https://www.first.org/cvss/specification-document
● Guía de Uso: https://www.first.org/cvss/user-guide
● Calculadora CVSS: https://www.first.org/cvss/calculator/3.1

Versión actual de la Escala: 3.1 (Junio 2019)

Vector String: Es la representación en texto en forma concisa del conjunto de métricas CVSS

Curso gratuito:
https://learning.first.org/courses/course-v1:FIRST+CVSSv3+2017/about
 Vector String
Ejemplo: CVE-2019-0708 (BlueKeep)

Vulnerabilidad de ejecución remota de código en los Servicios de escritorio remoto anteriormente conocidos como
Terminal Services, que se produce cuando un atacante no autenticado se conecta al sistema de destino mediante
RDP y envía solicitudes especialmente diseñadas, permitiendo la ejecución arbitraria de código.

CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
 Ejemplo de medición con CVSS

Existe una falla en el lector de pdf VulnApp en la validación de una variable,

que permite un buffer overflow. Un atacante envía un correo electrónico con
un archivo pdf malicioso que explota ese buffer overflow, para permitir la
ejecución de código arbitrario.

Cuál es la puntuación CVSS 3.1 de la vulnerabilidad?

Vector de ataque
 Vector de ataque en el ejemplo
➢ El archivo pdf malformado, que es el exploit, debe ser procesado en el mismo equipo físico en el que se
encuentra el programa vulnerable VulnApp
COMPLEJIDAD de ataque
 COMPLEJIDAD de ataque en el ejemplo
➢ El éxito de la explotación no depende de ninguna condición especial, solo que el usuario abra el archivo del
exploit (ojo! Esto cuenta como interacción de usuario y NO se tiene en cuenta en esta métrica)
INTERACCIÓN DEL USUARIO
 INTERACCIÓN DEL USUARIO en el ejemplo

➢ El éxito de la explotación depende de que el usuario abra el archivo con el programa vulnerable
Privilegios requeridos
 Privilegios requeridos en el ejemplo
➢ No se requiere ningún privilegio especial, no es necesario que se esté utilizando un usuario administrador
ni de ningún tipo especial
 Alcance

Observación: si el alcance (scope) no se cambia, el impacto de confidencialidad, integridad y disponibilidad

refleja las consecuencias en el componente vulnerable, de lo contrario, refleja la consecuencia en aquel
componente que sufre el mayor impacto!
 Alcance afectado en el ejemplo
➢ El componente vulnerable (VulnApp), al ser explotado, tiene un impacto solamente en el mismo sistema
donde dicho componente se está ejecutando
Impacto a la confidencialidad
Impacto a la integridad
Impacto a la disponibilidad
➢ Existe una falla en el lector de pdf VulnApp en la validación de una variable, que permite un
buffer overflow. Un atacante envía un correo electrónico con un archivo pdf malicioso que
explota ese buffer overflow, para permitir la ejecución de código arbitrario.