¿Qué es una vulnerabilidad conocida?

Esta publicación se publicó originalmente en CSO Online, el 15 de diciembre de 2017.

Oímos hablar mucho sobre la importancia de corregir las vulnerabilidades conocidas. La mayoría de los informes anuales de seguridad señalan que las vulnerabilidades conocidas son responsables de la gran mayoría de los ataques exitosos, y no faltan vulnerabilidades de renombre —desde Heartbleed hasta ImageTragick— que nos recuerdan su gravedad. Así que, si son tan importantes, tomémonos un momento para definir qué es una vulnerabilidad conocida.

Respuesta 1: Una vulnerabilidad con un ID de CVE

Un término que se usa prácticamente como sinónimo de «vulnerabilidad conocida» es CVE, sigla de «Common Vulnerabilities and Exposures» de MITRE. Cuando se descubre una nueva vulnerabilidad, una autoridad de numeración de CVE (CNA) puede asignarle un número de CVE, que luego se usa para identificarla en distintas bases de datos y herramientas.

Cabe señalar que CVE no es una base de datos, sino un identificador. La National Vulnerability Database (NVD) es la fuente oficial de información relacionada con CVE. Cuando se agrega un CVE a la NVD, normalmente incluye cierta información, como una breve descripción y una definición de los productos afectados por la vulnerabilidad en forma de CPE (Common Platform Enumeration). La calidad de la información de la NVD varía mucho según la fuente que la aporta.

Salvo en el caso de los CVE reservados antes de una divulgación futura, se puede afirmar que una vulnerabilidad con un número de CVE es una vulnerabilidad conocida. Sin embargo, una gran cantidad de vulnerabilidades tienen un número de CVE, pero nunca llegan a la NVD, lo que dificulta comprenderlas realmente. Además, muchas vulnerabilidades conocidas no tienen ningún CVE.

Respuesta 2: Una vulnerabilidad divulgada en internet

Con bastante frecuencia, se descubren, comparten y (con suerte) corrigen vulnerabilidades sin que nadie les asigne un CVE. Esto es especialmente común en los proyectos de código abierto, donde prácticamente todo se hace de forma pública. No es raro que los usuarios divulguen una vulnerabilidad sin darse cuenta al abrir un issue en un proyecto de GitHub, tal como reportarían otros errores, sin considerar que así llaman la atención sobre una falla de seguridad que aún no se ha corregido.

Incluso si los issues se reportan de forma privada y responsable, la corrección de la vulnerabilidad inevitablemente será de código abierto. En ese momento, la vulnerabilidad suele mencionarse en las notas de la versión, en un issue o junto con los detalles del cambio de código. Estos detalles se agregan intencionalmente, ya que es la única forma de informar a los usuarios del proyecto que existe un riesgo de seguridad (y una solución). Algunos responsables de mantenimiento de proyectos obtienen un CVE para estas vulnerabilidades, pero en la práctica esto es poco común, debido a la falta de conocimiento o al esfuerzo que implica.

Estas vulnerabilidades también son conocidas y podrían considerarse peores que las que tienen un CVE. Quienes usan un proyecto pueden revisarlo para encontrarlas, pero hacerlo lleva tiempo y es difícil a gran escala. Por otro lado, un atacante puede examinar los proyectos de bibliotecas populares y encontrar estos problemas con relativa facilidad, ya que solo necesita revisar los proyectos más populares para llegar a muchas personas. Se las conoce como vulnerabilidades no detectadas. Incorporarlas a una base de datos nos lleva a la siguiente categoría de vulnerabilidades conocidas.

Respuesta 3: Una vulnerabilidad registrada en bases de datos abiertas

Aunque la NVD es la base de datos de vulnerabilidades más oficial, existen otras. VictimsDB, RedHat y Openwall son ejemplos de bases de datos públicas de vulnerabilidades, disponibles para que cualquiera las consulte. Muchas vulnerabilidades en estas bases de datos no tienen un CVE —por ejemplo, las vulnerabilidades no detectadas mencionadas antes— o se publican allí antes de que se les asigne un CVE.

Una vulnerabilidad en una base de datos abierta es casi tan conocida como una que tiene un CVE. Está almacenada en un lugar público, disponible tanto para defensores como para atacantes, y les informa a ambos sobre el riesgo. La única diferencia entre la NVD y estas bases de datos es el proceso de filtrado para incluir vulnerabilidades, que varía de una base a otra.

Respuesta 4: Una vulnerabilidad registrada en bases de datos cerradas

No todas las bases de datos de vulnerabilidades están abiertas al público. Muchas empresas crean y mantienen una base de datos de vulnerabilidades, pero la mantienen bajo estricta reserva. Los clientes pueden pagar para acceder a la lista de vulnerabilidades, lo que les permite clasificarlas por prioridad e intentar mitigar las que más les afectan.

Las bases de datos cerradas de vulnerabilidades son una forma útil de descubrir vulnerabilidades que te resultaría difícil encontrar por tu cuenta y de protegerte en caso de que los atacantes también las encuentren. Sin embargo, no las llamaría vulnerabilidades conocidas. A menos que el proveedor de la base de datos también se la haya vendido a los atacantes (lo cual dudo que hagan), es igual de probable que un atacante encuentre otra vulnerabilidad en tu sistema que la que acabas de comprar.

Respuesta 5: Una vulnerabilidad compartida en la web oscura

Al igual que el negocio legítimo de las bases de datos de vulnerabilidades, la web oscura tiene sus propios repositorios de vulnerabilidades y las vende en el mercado negro. Como el retorno financiero es muy distinto para los atacantes, estas vulnerabilidades pueden costar millones cada una, o bien regalarse o venderse a bajo precio.

Definitivamente, estas no son vulnerabilidades conocidas. De hecho, suelen llamarse vulnerabilidades «zero-day», ya que los atacantes están al tanto de ellas antes de que se hagan conocidas (cero días después de su divulgación). A veces, estas vulnerabilidades se publican, y en ese momento las consideraría vulnerabilidades no detectadas, como en la respuesta 2.

Las vulnerabilidades zero-day son importantes, sin duda, pero la probabilidad de que los atacantes las usen (antes de que se hagan públicas) es mucho menor que la de que usen vulnerabilidades verdaderamente conocidas.

Resumen

Una vulnerabilidad es una vulnerabilidad, sea conocida o no. La diferencia clave entre ambas es la probabilidad de que un atacante esté al tanto de ella y, por lo tanto, intente explotarla. Por eso, cuanto más conocida sea la vulnerabilidad, más urgente debería ser corregirla.

Se recomienda priorizar los tres primeros tipos de vulnerabilidades, quizás en ese orden. Cuando los tengas bajo control, trabaja para corregir las que aparecen más abajo en la lista.