Resolviendo dudas sobre el papel del listado de vulnerabilidades CVE

Javier Muñoz, de HackerCar, me pasaba unas preguntas hace unos días en relación al porqué, y el funcionamiento, de los CVE, es decir, a ese listado público que aglutina casi todas las vulnerabilidades informáticas conocidas.

¿La razón? La noticia, por parte de Palo Alto, de que, de media, los cibercriminales tardaban tan solo una hora (EN) en explotar dichas vulnerabilidades una vez éstas eran publicadas.

Me pasó las preguntas y gustoso se las respondí, aprovechándolas entonces para escribir una pieza en la que me menciona, y que puedes leer en su página (ES).

Dejo por aquí mis respuestas completas al tema presentado.

¿Por qué las vulnerabilidades se publican en el CVE antes de que las ponga solución el responsable del sistema? 

En un mundo ideal, en efecto, antes de que el CVE se publique, el organismo encargado sacaría un parche que lo arreglase. Por la simple razón de que para que un CVE se publique, deben cumplir JUNTOS estos tres puntos:

1. Se puede solucionar de forma independiente: Es decir, no forma parte de otro fallo de seguridad que lo engloba.
2. Afecta a un código informático: Es decir, que dicha vulnerabilidad aparece siempre que se utilice ese código en particular, dejando por ejemplo fuera cualquier ataque basado en ingeniería social o abuso del diseño (diseños no intencionados).
3. El proveedor lo confirma, o hay justificación clara de que existe: El punto que más nos interesa en esta ocasión, y es que para publicarse debe informarse a la organización que está detrás del fallo de seguridad, y esta, o bien debe confirmarlo, o bien quien lo haya notificado puede presentar un informe donde se demuestre sin posible duda que esa vulnerabilidad está afectando al código.

Como puedes ver, para que llegue el CVE a buen puerto, como mínimo quién está detrás debe estar al tanto de que existe. Otra cosa es que destine los recursos necesarios para solucionarlo antes de que en efecto se publique…

¿Qué utilidad tiene el CVE? ¿Qué lo diferencia de un programa de Bug Bounty?

A ver, son dos cosas diferentes, aunque pueden ir de la mano.

El CVE es un listado de vulnerabilidades que históricamente publicaba MITRE Corporation, una empresa subvencionada por el Departamento de Seguridad Nacional de EEUU.

Es por tanto una suerte de proyecto de transparencia, que con el auge de Internet y el dominio, al menos hasta ahora, estadounidense, del mundo digital, se ha vuelto, de facto, un estándar.

Pero su papel es puramente informativo. Y es más, en los CVE solo se informa del código afectado y el tipo de vulnerabilidad. Ni tan siquiera incluye datos técnicos sobre su funcionamiento, sus efectos o sus posibles aplicativos o soluciones.

Es decir, que mirando solo un CVE lo único que sabemos es que tal herramienta tiene un fallo de seguridad de X tipo. Pero no cómo aprovecharnos de él.

Caso aparte son los programas de Bug Bounty. Estos no tienen por qué depender de un organismo público (lo puede ofrecer quien quiera), y normalmente vienen de parte de las propias empresas, con el objetivo de externalizar esa identificación de vulnerabilidades antes de que en efecto les afecten.

Es decir, que mientras que un CVE es, por así decirlo, un sistema de catalogación de vulnerabilidades público (y gratuito), el bug bounty es más bien un programa de cazarrecompensas, en la que cualquiera puede informar de una vulnerabilidad específica, y si es aceptada, cobrar por ello.

Puesto que ahora el mundo de la informática es un «pelín» más grande que lo que fue en su día con el nacimiento de este listado público, es cierto que no resulta extraño que muchas vulnerabilidades se descubran precisamente de programas de bug bounty, ya que de cara a informar sobre una vulnerabilidad, al menos yo preferiría hacerlo en un programa que me va a pagar, que simplemente en un listado público gratuito.

¿Cómo se puede evitar que los ciberdelincuentes se aprovechen de lo publicado en el CVE? ¿Qué pueden hacer las empresas para adelantarse a los crackers?

Esta es la pregunta del millón. Y, lamentablemente, tiene poca respuesta.

La base del listado de CVE es, como decía por arriba, un mero informador de vulnerabilidades. En ningún momento informan, como por cierto sí lo hacen otros listados como el de la National Vulnerability Database de Estados Unidos (EN) o la CERT/CC Vulnerability Notes Database (EN), de cómo aprovecharse de dicha vulnerabilidad.

Ahora bien, está claro que están sirviendo a los cibercriminales para identificar vectores de ataque (sabes que hay una vulnerabilidad en tal componente y de tal tipo, ahora toca encontrarla).

¿Qué se puede hacer? Pues he intentado buscar a ver si existe un tiempo mínimo de respuesta antes de que el CVE esté publicado, y al menos yo no lo he encontrado (lo que no quiere decir que no exista).

Lo cierto es que puesto que para que se publique el CVE, éste tiene que pasar los controles anteriormente detallados, y ser aceptado por uno de los 100 CNA que hay en todo el globo (o por la propia MITRE). Es de esperar entonces que entre que se informa de la vulnerabilidad, y esta pasa los controles oportunos, haya unas cuantas semanas. Semanas que en principio podrían ser aprovechadas por el proveedor para parchear el código.

Sin ir más lejos, hay grupos de trabajo en grandes compañía como Google o Microsoft que se dedican, precisamente, a sacar vulnerabilidades tanto en sus servicios como en los de la competencia. Y parece que ya es bastante habitual que exista un «pacto de hombres» en el que se dan alrededor de 8 semanas (dos meses) para que el equipo encargado lo solucione antes de hacerlo público.

Pasado ese tiempo, se entiende que ya pesa más el derecho a la información de la sociedad que el propio interés de la organización por ocultar el fallo.