Lecciones de las vulnerabilidades de OpenSSL, parte 1: prepara tu cadena de suministro para la próxima vulnerabilidad crítica

Es temprano, una mañana de martes de octubre inusualmente cálida. Revisas tu correo mientras disfrutas tu primera taza de café o té del día y casi escupes lo que tienes en la boca al leer que OpenSSL lanzará próximamente una actualización para corregir una vulnerabilidad CRÍTICA. De inmediato, te viene a la mente Heartbleed. Redactas rápidamente un mensaje de Slack para tu jefe y, justo antes de hacer clic en «enviar», te das cuenta de que sabes exactamente qué te va a preguntar: ¿dónde nos afecta y cómo vamos a solucionarlo?

El equipo del proyecto OpenSSL avisó con aproximadamente una semana de anticipación sobre la vulnerabilidad. Cuando finalmente publicó las correcciones de la versión 3.0.7, terminó reduciendo la gravedad a alta y compartió dos vulnerabilidades nuevas. Pero ¿y si esta hubiera sido la próxima Heartbleed? ¿Habrías estado preparado? ¿Cómo te habrías enterado de si te afecta y dónde? ¿Dónde tendrías que buscar? Después de todo, no es cuestión de «si» aparecerá otra vulnerabilidad crítica en una biblioteca de uso común, sino de «cuándo».

En esta serie de dos partes, repasaremos algunos aspectos que debes tener en cuenta para encontrar casos de vulnerabilidades en tu cadena de suministro de software. Aunque esta serie se centrará en OpenSSL y las bibliotecas relacionadas, también consideraremos vulnerabilidades en general. Empecemos por hablar de dónde buscar bibliotecas vulnerables y revisar algunos consejos y trucos para hacerlo.

Dónde buscar bibliotecas vulnerables en tu cadena de suministro

Los dos nuevos CVE de OpenSSL (CVE-2022-3602 y CVE-2022-3786) son problemas de desbordamiento de búfer que afectan a las versiones de OpenSSL de la 3.0.0 a la 3.0.6. Por suerte, las versiones 1.x, mucho más extendidas, no se vieron afectadas. «Genial», podrías pensar: «solo tengo que buscar los hosts que tengan instalado OpenSSLv3». Aunque ese es un paso en la dirección correcta, hay otros aspectos que tener en cuenta y muchos más lugares (y formas) en los que podrían esconderse versiones vulnerables.

Hosts, máquinas virtuales e imágenes de contenedor

Los recursos que usas para ejecutar cargas de trabajo no suelen considerarse parte de la cadena de suministro, pero no los pases por alto. Además de revisar los hosts físicos para detectar versiones afectadas de OpenSSL —servidores, equipos de escritorio, laptops y estaciones de trabajo—, también debes tener en cuenta los hosts virtuales. Pueden ser máquinas virtuales (VM) que ejecutas en tus propios hipervisores, pero también instancias de cómputo en AWS, GCP, Azure u otros proveedores de nube. Estas instancias en la nube, ya sean EC2, GCE o cualquier otro acrónimo de marca, son posibles puntos de explotación. Una buena configuración de nube y red puede limitar el acceso a estas instancias, pero es mejor mantener un inventario que puedas consultar. Puedes hacerlo instalando protección de endpoints en tus hosts o mediante herramientas nativas de nube, como AWS Inspector (que detecta cargas de trabajo de AWS en el entorno de AWS, incluidas las de EC2). En este artículo, nos centraremos en el software.

Además de contar con hosts físicos y virtuales, más del 90 % de las organizaciones que encuestamos también ejecutan cargas de trabajo en contenedores y sin servidor, dinámicas y efímeras, que pueden ser un poco más difíciles de analizar. Estas cargas de trabajo son efímeras porque pueden tener una vida corta, y son dinámicas porque podrían iniciarse según una programación o al activarse determinados eventos. Por eso, no basta con revisar los contenedores que están en ejecución: también debes revisar las imágenes de contenedor de tu inventario, que podrían ser cientos o miles.

Las imágenes de contenedor suelen almacenarse en un registro de contenedores, como Docker Hub, Quay o JFrog Artifactory, o en un repositorio de imágenes proporcionado por el proveedor de nube. Además, las imágenes pueden implementarse como cargas de trabajo o usarse como base —o imagen base— para otras imágenes. Las vulnerabilidades suelen ser transitivas. Si identificas un paquete vulnerable en una imagen de contenedor, es posible, e incluso probable, que también se vean afectadas las imágenes derivadas que usan `FROM` con esa imagen.

Esto te da una buena idea de dónde buscar OpenSSL desde la perspectiva de los «hosts» (físicos, virtuales y efímeros). Es probable que OpenSSL se haya instalado en estos lugares mediante administradores de paquetes —por ejemplo, `brew (or yum, or apt) install openssl`— o con paquetes descargados e instalados manualmente. Sin embargo, los paquetes vulnerables pueden llegar a tus sistemas de otras maneras.

Código fuente y dependencias

Es posible que tengas versiones específicas de OpenSSL instaladas en tus hosts, por ejemplo, para permitirte conectarte por SSH a otros hosts o desde ellos. Independientemente de que estas instancias de nivel superior sean vulnerables o no, podría haber instancias adicionales instaladas por el software que usas o junto con él, o por el software que desarrollas e implementas. Estas instancias se incorporan a tu cadena de suministro cuando tu código depende directamente de las bibliotecas de OpenSSL. Por ejemplo, si tu aplicación especifica bibliotecas de OpenSSL en sus dependencias, como en `requirements.txt`, `pom.xml` o `Gemfile`. También puede ocurrir si algo en el árbol de dependencias de tu aplicación requiere OpenSSL, incluso cuando las dependencias transitivas tienen muchas capas de profundidad. Por ejemplo, tu aplicación usa una biblioteca auxiliar que, a su vez, depende de una biblioteca criptográfica; la cadena continúa hasta que el árbol de dependencias muestra que la biblioteca «qux» incorporó OpenSSL 3.05, aunque ninguna de las bibliotecas intermedias siquiera aparezca en tu `Gemfile` de tres líneas. Si algo en el árbol de dependencias de tu aplicación incorpora bibliotecas de OpenSSL, la lista de materiales de software (SBOM) de tu aplicación también las incluirá.

A veces, los desarrolladores de aplicaciones simplemente copian y distribuyen las bibliotecas de OpenSSL junto con sus aplicaciones, en lugar de incluirlas mediante administradores de paquetes. En este caso, la aplicación básicamente incorpora la biblioteca durante el proceso de compilación, en vez de depender de la presencia de bibliotecas externas.

Prepárate para la próxima vulnerabilidad en la cadena de suministro con Snyk

Al usar Snyk Container y Snyk Open Source para proteger tu cadena de suministro de software, puedes supervisar de forma proactiva tus contenedores y proyectos de código abierto. En lugar de tener que apresurarte a buscar imágenes de contenedor o paquetes de código abierto vulnerables, puedes saber si te afecta antes incluso de que se publiquen las vulnerabilidades. Así, tendrás la confianza de contar con las respuestas cuando hagas clic en el ícono de enviar de Slack para mandarle ese mensaje a tu jefe.

Si aún no tienes una, crea hoy una cuenta gratuita de Snyk para ahorrar tiempo y esfuerzo en tu búsqueda. Y vuelve la próxima semana para continuar nuestra conversación sobre cómo encontrar y corregir vulnerabilidades en la cadena de suministro.