Pararse sobre hombros de gigantes

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:

¡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.

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:

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.

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

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.

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:

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.

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:

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,

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.