Verificación de vulnerabilidades en dependencias

En este nodo encontrarás lo básico para diferenciar si una dependencia es vulnerable o se trata de un falso positivo.

 

Importante

Para validar las dependencias, es muy recomendable que el proyecto este compilado y es necesarios que las dependencias estén instaladas. De lo contrario puede que no exista un reporte completo y se produzca una falsa sensación de seguridad.

En casos como Java y NodeJS se requiere instalar las dependencias.

 

Cómo leer los informes

La parte superior del informe contiene una lista de los componentes vulnerables identificados. Al hacer clic en el enlace "Showing Vulnerable Dependencies", la lista se ampliará para incluir todas las dependencias escaneadas. La tabla muestra:

  • Dependency  (Dependencia): el nombre del archivo de la dependencia escaneada.

  • CPE: cualquier identificador de Enumeración de Plataforma Común encontrado.

  • GAV: el Grupo, Artefacto, Versión (GAV) de Maven.

  • Highest Severity (Severidad más alta): la severidad más alta de cualquier CVE asociado.

  • CVE Count (Recuento de CVE): el número de CVEs asociados.

  • CPE Confidence (Confianza en el CPE): una clasificación de la confianza que tiene la comprobación de la dependencia en que el CPE fue identificado correctamente. Este parámetro es muy interesante tenerlo en cuenta, ya que nos da nociones de que dependencias pueden ser falsos positivos.

  • Evidence Count (Recuento de pruebas) la cantidad de datos extraídos de la relación que se utilizó para identificar el CPE.


La versión HTML del informe contiene mucha información. Al analizar los resultados, lo primero que hay que hacer es determinar si el CPE identificado es correcto. Debido a la forma en que funciona el dependency-check (véase How it worksel informe puede contener falsos positivos. Estos falsos positivos están principalmente en los valores de CPE. Si el valor de CPE es incorrecto, esto suele ser obvio, se debe utilizar la función de supresión en el informe para generar un archivo XML de supresión que se puede utilizar en futuras exploraciones. Además de mirar los valores de CPE en comparación con el nombre de la dependencia, también se puede considerar la confianza del CPE (como se explica en How does dependency-check work).

 

Suprimir falsos positivos

Puede consultar la página de supresión de falsos positivos para obtener más información sobre cómo generar y utilizar el archivo de supresión en la documentación de DependencyCheck.

https://jeremylong.github.io/DependencyCheck/general/suppression.html

No obstante, la supresión de falsos positivos debe ser debidamente justificada.


Una vez que haya eliminado los falsos positivos obvios, puede mirar las entradas restantes y determinar si alguna de las entradas CVE identificadas es realmente explotable en su entorno. Determinar si un CVE es explotable en su entorno puede ser complicado, por lo que actualmente no tenemos ningún consejo, aparte de actualizar la dependencia si puede, para estar seguro. Algunas de las entradas de CVE pueden arreglarse actualizando la dependencia o cambiando las opciones de configuración.

Un elemento que la comprobación de dependencias marca y que muchos pueden pensar que es un falso positivo son los controladores de base de datos antiguos. Una cosa a tener en cuenta sobre un controlador de base de datos antiguo es que los CPE/CVEs identificados son normalmente para el servidor y no para el controlador. Sin embargo, la presencia de un controlador antiguo puede indicar que existe una versión antigua del servidor que se ejecuta en su entorno y que el servidor puede necesitar ser parcheado o actualizado. No obstante, en algunos casos los controladores de base de datos antiguos son en realidad dependencias transitivas no utilizadas.

En cuanto a los falsos negativos

Como se ha indicado anteriormente, debido a la naturaleza de dependency-check puede haber vulnerabilidades públicamente reveladas en las dependencias del proyecto analizadas por dependency-check que no se identifican. Con la versión actual de dependency-check el informe HTML tiene una tabla en la parte superior que inicialmente muestra sólo las dependencias con vulnerabilidades identificadas. Esto se puede cambiar para mostrar todas las dependencias. Examinando las filas que no tienen entradas CPE/CVE identificadas, se puede ver "evidence count". Si el "evidence count"  o recuento de pruebas es extremadamente bajo (0-5 entradas), es posible que la relación no contenga suficiente información para identificar un CPE y los CVE asociados.

Hay que tener en cuenta que aunque los falsos positivos descritos anteriormente son malos, lo más preocupante es que puede haber vulnerabilidades dentro de las dependencias del proyecto que aún no se han conocido públicamente. Si es posible, considere realizar evaluaciones de seguridad en las dependencias del proyecto.

Obtener excepción

En el reporte, veremos cada CVE. Podemos pulsar en "suppress":

 

Aparecerá una ventana similar a esta:

 

Podemos copiar el contenido y pegarlo en nuestro archivo de supresión o descargar uno completo pulsando en:

 

Donde aparecerá:

 

Ejemplo de archivo de supresión:

Ejemplo de archivo de supresión

<?xml version="1.0" encoding="UTF-8"?> <suppressions xmlns="https://jeremylong.github.io/DependencyCheck/dependency-suppression.1.1.xsd">    <suppress>       <notes><![CDATA[       file name: configure.ac       ]]></notes>       <sha1>94d7acda832dc53ab91892dcdd4b1ac9fc191e75</sha1>       <cve>CVE-2009-0792</cve>    </suppress> </suppressions>

Ejemplo de reporte

https://jeremylong.github.io/DependencyCheck/general/SampleReport.html

Verificar el CPE del reporte de los CVE de Dependency Check

Para verificar el reporte:

  • Se verifica que el CVE es realmente el mismo que el que se esta analizando, para esto es útil utilizar el CPE.

  • Se comprueba que la versión esta afectada en la lista del CVE.

Si todo concuerda, esta librería es vulnerable. En caso de no coincidir al completo, podemos estar ante un falso positivo, lo cual requiere que se compruebe de manera más minuciosa.

 

Ejemplo del proceso

En este ejemplo, utilizaremos de referencia una aplicación en Java.

Para obtener el reporte de las dependencias utilizamos DepenendencyCheck (le sugerimos que visite: Draft- Herramientas de Seguridad y Draft- Plugins de Seguridad).

Reporte

Una vez obtenido el reporte en HTML, podemos ver algo similar a:

 

Donde vemos los CVE de cada librería.

CVE

Para estar seguros de que se trata de un reporte fiable (y no un falso positivo) comprobamos el CPE en el CVE.

Vemos un CVE de ejemplo: CVE-2019-2692

 

Podemos observar la descripción de la vulnerabilidad (para evaluar el riesgo) y también ver la criticidad así como el vector que la genera.

 

Verificación

Ahora revisamos que el CPE de la librería es el mismo que el del reporte de la aplicación y la versión que le afecta

 

Posible mitigación

Por último, dependiendo del proveedor de la librería, podemos ver en la siguiente sección del CVE enlaces de interés, donde a veces se sugieren mitigaciones (a parte de evidentemente actualizar la versión):

 

Javascript

Recomendaciones de uso de librerías de terceros en Javascript

Referencia: https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.html

NodeJS

Para poder verificar las dependencias de Node, debe estar instalada la versión de Node compatible y realizar la instalación de las dependencias.

 

Referencias

Recomendamos revisar la siguiente referencia: https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html