Tabla de contenidos

Title
Title
Tabla de contenidos
Tabla de contenidos
Tabla de contenidos
Title
Title
Title

Ataques

Pararse sobre hombros de gigantes: Sobre el análisis de composición de software

portada-sobre-hombros-gigantes (https://unsplash.com/photos/exKQ01AmzNA)
portada-sobre-hombros-gigantes (https://unsplash.com/photos/exKQ01AmzNA)
portada-sobre-hombros-gigantes (https://unsplash.com/photos/exKQ01AmzNA)
portada-sobre-hombros-gigantes (https://unsplash.com/photos/exKQ01AmzNA)
Rafael Ballestas

Analista de seguridad

Actualizado

14 feb 2018

5 min

En nuestro último artículo, difundimos el descubrimiento de una vulnerabilidad en libpng. Tú podrías decir que esa es solo una pequeña biblioteca con un alcance muy limitado y solo 556 KiB instalados. Sin embargo, montones de paquetes dependen de ella. Para ver cuántos paquetes del repositorio de Arch Linux dependen de libpng podemos usar el pacgraph de Kylee Keen:

Dependiendo de libpng
Dependencias inversas de libpng en Arch Linux.

¡Más de 14 GiB de software dependen de libpng! Y eso solo en los repositorios de Arch Linux, que no es precisamente la distribución más popular de Linux. Además, esta biblioteca es la referencia oficial de PNG y es multiplataforma, por lo que seguramente muchos otros paquetes en otros sistemas operativos dependen de ella.

Ahora bien, en el año 2015, cuando libpng aún no había corregido el error low-high palette, todos los programas y bibliotecas anteriores también eran automáticamente vulnerables al mismo problema. De hecho esto es lo que le pasó a Equifax con una vulnerabilidad en Apache Struts. Al igual que muchos servicios web que utilizan OpenSSL con Heartbleed.

Si esto pudo pasarle a productos tan emblemáticos como Bash, Qt, TeX y Xfce, también podría pasarle a tu organización. De hecho, este problema es tan común que forma parte del Top 10 de OWASP de 2017; lo llaman "A9: Uso componentes con vulnerabilidades conocidas."

Dada la rápida adopción del software libre y de código abierto (FOSS, por su nombre en inglés) por parte de grandes empresas, de repente la vulnerabilidad de las dependencias parece ser un problema tremendo. O más bien, como les gustaría señalar a los yuppies, ¿una "oportunidad de negocio"?

Desde entonces han aparecido en la escena de la seguridad muchos proveedores del llamado análisis de composición de software (SCA) (no lo busques en Google). Algunos de ellos están respaldados por empresas de larga trayectoria; la mayoría, no. De hecho, este negocio ha tomado tanto impulso que se espera que crezca más de un 20% cada año de aquí al 2022.

Estas empresas, que tanto deben al FOSS, tienden a hacerlo quedar mal cuando comercializan su SCA. Sin embargo, la adopción del FOSS no se está reduciendo. Como intentaremos demostrar aquí, no es culpa del FOSS si las aplicaciones lo utilizan con vulnerabilidades conocidas, sino de los propietarios de dichas aplicaciones.

Las aplicaciones de hoy en día utilizan en promedio más de 30 bibliotecas, lo que representa hasta un 80% de su código. Piensa en ello como si tu código fuera solo una fina capa sobre un edificio de algunas cajas pequeñas y otras más grandes. Lo que el SCA hace entonces es buscar vulnerabilidades dentro de esas cajas con información de bases de datos externas, las cuales pasan a ser consideradas vulnerabilidades en tu propia aplicación:

Escaneo SCA
SCA escanea todos los bloques del edificio de tu app.

En lugar de ir desde la supuesta solución hacia el origen del problema, hagámoslo al revés.

Lo malo

El FOSS es desarrollado y utilizado por miles de personas en todo el mundo. Esto puede ser un arma de doble filo: Por un lado, según la "Ley de Linus", la búsqueda de errores y la aplicación de parches deberían ser más fáciles al haber más implicados. Por otro lado, la falta de una guía centralizada favorece la aparición de fallas.

Una diferencia del FOSS con el software propietario está en que, debido a todas sus restricciones, es "menos probable" que las fallas de este último se hagan públicas tan pronto como en el caso del primero. Así que suele esperarse que todas las vulnerabilidades en el software propietario sean de día cero.

Entonces, si el origen del problema no es el FOSS, ¿cuál es? Las principales razones por las que tantas empresas sufren de A9:

  • Desconocimiento de las dependencias utilizadas

  • Desconocimiento de sus vulnerabilidades

  • No escanear continuamente en busca de fallas

  • No realizar pruebas de compatibilidad

  • Mala configuración de los componentes

En definitiva, todo se reduce a una falta de comunicación entre el usuario y la fuente de los componentes.

Lo bueno

¿Qué puedes hacer? OWASP recomienda las siguientes directrices para prevenir A9:

  • Recorta dependencias innecesarias, características, componentes, etc. Así tendrás menos para revisar.

  • Supervisa continuamente los componentes en búsqueda de actualizaciones y reportes de vulnerabilidades.

  • Obtén solo componentes de fuentes fiables.

  • Convierte estas directrices en una política de empresa.

Existen herramientas específicas que comparan la versión de la dependencia que estás utilizando tanto con repositorios remotos (para comprobar si hay actualizaciones) como con bases de datos de vulnerabilidades (para averiguar si alguna de tus dependencias contiene vulnerabilidades reportadas que aún no han sido corregidas).

Ten en cuenta que las herramientas específicas del lenguaje tienen que estar integradas con el gestor de paquetes apropiado, como npm o yarn con retire.

Una vista panorámica de cómo el proceso debería integrarse con tu flujo de desarrollo se representa en el siguiente diagrama proporcionado por SourceClear.

Integrando SCA
Integrando SCA en tu flujo de desarrollo. Vía SourceClear.

Vemos que cada vez que se añade código, todo el sistema es escaneado en búsqueda de vulnerabilidades de software de terceros y otros problemas fácilmente identificables por análisis estático cuando el código no está disponible. Esto se hace siguiendo este procedimiento:

  1. Identificar las dependencias en las que tu software se basa.

  2. Detectar las versiones de esas dependencias.

  3. Comprobar si hay actualizaciones en el repositorio maestro de dependencias.

  4. Comprobar una o varias bases de datos de vulnerabilidades, como CVE y NVD o las propias.

  5. Reportar los hallazgos.

En realidad, se trata de un proceso sencillo.

Ten en cuenta que la integración no es totalmente automática, y no debería serlo, ya que estas herramientas podrían dar (y suelen dar) falsas alarmas, por lo que son revisadas por especialistas en seguridad.

Internamente, el proceso de escaneo de software de terceros es el mismo tanto para el propietario como para el FOSS, y es una simple cuestión de consultar las bases de datos de vulnerabilidades como hemos descrito anteriormente.

Hablando de integración, puede que te preguntes: ¿Qué pasa si mi aplicación se despliega dentro de un contenedor? "El 30% de las imágenes oficiales de Docker Hub contienen vulnerabilidades de seguridad de alta prioridad", según PenTestIt. Afortunadamente, hay herramientas que entran en tu contenedor y realizan SCA dentro de él (y más), como Anchore y Dockerscan.

Lo feo

Sé que buscaste "análisis de composición de software" cuando te sugerí que no lo hicieras. Solo sé que lo hiciste. Si no lo hiciste, ¡bien por ti! Esto es lo que te estás perdiendo:

Mercadeo de SCA
Proveedores de "análisis de composición de software".

Todos estos líderes de la industria, galardonados, creadores de avances, oráculos del futuro de la tecnología, quieren venderte una cosa: análisis de código estático más las herramientas que hemos comentado antes.

Aunque el análisis estático es una técnica válida, es solo una técnica. Escanea código y detecta vulnerabilidades y prácticas poco saludables, pero también fomenta la detección tardía y produce muchos falsos positivos.

Podrías contratar un servicio de este tipo e incluso intentar complementarlo con herramientas de análisis dinámico como fuzzing y debuggers, pero estas tienen sus propios problemas.

Cabe señalar que no sustituyen a la revisión de código a la antigua, por humanos. Al menos por el momento. Según Contrast Security,

La única forma de afrontar el riesgo de vulnerabilidades desconocidas en las bibliotecas es que alguien que entienda de seguridad analice el código fuente. El análisis estático de las bibliotecas es mejor concebirlo como una forma de dar señales de dónde pueden estar localizadas las vulnerabilidades de seguridad en el código, y no como un sustituto de los expertos.

En el futuro, es posible que veamos cosas como pruebas de seguridad distribuidas bajo demanda y algoritmos de machine learning que utilicen máquinas de vectores de soporte para intentar predecir qué commits tienen más probabilidades de abrir vulnerabilidades, pero mientras tanto, quédate con lo probado y comprobado.

Empieza ya con la solución de SSCS de Fluid Attacks

Etiquetas:

pruebas-de-seguridad

software

vulnerabilidad

Suscríbete a nuestro boletín

Mantente al día sobre nuestros próximos eventos y los últimos blog posts, advisories y otros recursos interesantes.

Inicia tu prueba gratuita de 21 días

Descubre los beneficios de nuestra solución Hacking Continuo, de la que ya disfrutan empresas de todos los tamaños.

Inicia tu prueba gratuita de 21 días

Descubre los beneficios de nuestra solución Hacking Continuo, de la que ya disfrutan empresas de todos los tamaños.

Inicia tu prueba gratuita de 21 días

Descubre los beneficios de nuestra solución Hacking Continuo, de la que ya disfrutan empresas de todos los tamaños.

Inicia tu prueba gratuita de 21 días

Descubre los beneficios de nuestra solución Hacking Continuo, de la que ya disfrutan empresas de todos los tamaños.

Las soluciones de Fluid Attacks permiten a las organizaciones identificar, priorizar y remediar vulnerabilidades en su software a lo largo del SDLC. Con el apoyo de la IA, herramientas automatizadas y pentesters, Fluid Attacks acelera la mitigación de la exposición al riesgo de las empresas y fortalece su postura de ciberseguridad.

SOC 2 Type II

SOC 3

Suscríbete a nuestro boletín

Mantente al día sobre nuestros próximos eventos y los últimos blog posts, advisories y otros recursos interesantes.

Las soluciones de Fluid Attacks permiten a las organizaciones identificar, priorizar y remediar vulnerabilidades en su software a lo largo del SDLC. Con el apoyo de la IA, herramientas automatizadas y pentesters, Fluid Attacks acelera la mitigación de la exposición al riesgo de las empresas y fortalece su postura de ciberseguridad.

SOC 2 Type II

SOC 3

Suscríbete a nuestro boletín

Mantente al día sobre nuestros próximos eventos y los últimos blog posts, advisories y otros recursos interesantes.

Las soluciones de Fluid Attacks permiten a las organizaciones identificar, priorizar y remediar vulnerabilidades en su software a lo largo del SDLC. Con el apoyo de la IA, herramientas automatizadas y pentesters, Fluid Attacks acelera la mitigación de la exposición al riesgo de las empresas y fortalece su postura de ciberseguridad.

SOC 2 Type II

SOC 3

Suscríbete a nuestro boletín

Mantente al día sobre nuestros próximos eventos y los últimos blog posts, advisories y otros recursos interesantes.