Varias vulnerabilidades fueron encontradas al escanear contenedores Docker
Hace poco se dio a conocer mediante una publicación de blog, los resultados de las herramientas de prueba para identificar vulnerabilidades sin parche e identificar problemas de seguridad en imágenes de contenedores Docker aislados.
La prueba mostró que 4 de los 6 escáneres de imágenes de Docker conocidos tenían vulnerabilidades críticas que permitían atacar al escáner en sí y ejecutar su código en el sistema, en algunos casos (por ejemplo, al usar Snyk) con privilegios de root.
Para un ataque, un atacante solo necesita iniciar la verificación de su Dockerfile o manifest.json, que incluye metadatos con formato especial, o colocar los archivos Podfile y gradlew dentro de la imagen.
Nos las arreglamos para preparar explotar prototipos para WhiteSource , Snyk , Fossa y sistemas anchore.
El paquete Clair, que originalmente se escribió pensando en la seguridad, mostró la mejor seguridad.
No se identificaron problemas en el paquete Trivy y como resultado, se concluyó que los escáneres de contenedores de Docker deben ejecutarse en entornos aislados o usarse solo para verificar sus propias imágenes, y también tener cuidado al conectar dichas herramientas a sistemas de integración continua automatizados.
Estos escáneres hacen cosas complicadas y propensas a errores. Están lidiando con la ventana acoplable, extrayendo capas / archivos, interactuando con administradores de paquetes o analizando diferentes formatos. Defenderlos, mientras se intenta dar cabida a todos los casos de uso para los desarrolladores, es muy difícil. Veamos cómo las diferentes herramientas intentan y logran hacerlo:
El puntaje en la divulgación responsable refleja mi opinión personal: creo que es importante que los proveedores de software sean receptivos a los problemas de seguridad que se les informan, sean honestos y transparentes sobre las vulnerabilidades, para asegurarse de que las personas que utilizan sus productos estén debidamente informadas para tomar decisiones sobre la actualización. Esto incluye la información más importante de que una actualización tiene cambios relevantes para la seguridad, abrir un CVE para rastrear y comunicarse sobre el problema y potencialmente notificar a sus clientes. Creo que es especialmente razonable suponer esto si el producto trata sobre CVE, proporcionando información sobre vulnerabilidades en el software. Además, me tranquiliza la respuesta rápida, los tiempos de corrección razonables y la comunicación abierta con la persona que divulga el ataque.
En FOSSA, Snyk y WhiteSource, la vulnerabilidad estaba relacionada con llamar a un administrador de paquetes externo para determinar las dependencias y permitirle organizar la ejecución de su código especificando los comandos táctiles y del sistema en los archivos gradlew y Podfile.
En Snyk y WhiteSource se encontró además una vulnerabilidad, asociada con los comandos del sistema de lanzamiento de la organización que analizaban Dockerfile (por ejemplo, en Snyk a través de Dockefile podría reemplazar la utlidad ls (/bin/ls), causado por el escáner y en WhiteSurce podría reemplazar el código a través de los argumentos en forma de «echo ‘; toque /tmp/hacked_whitesource_pip;=1.0’ «).
En Anchore, la vulnerabilidad fue causada por el uso de la utilidad skopeo para trabajar con imágenes de docker. La operación se redujo a agregar parámetros de la forma ‘»os»: «$ (touch hacked_anchore)»‘ al archivo manifest.json, que se sustituyen al llamar a skopeo sin un escape adecuado (solo se eliminaron los caracteres «; & <>», pero la construcción «$ ( ) «).
El mismo autor realizó un estudio sobre la eficacia de la detección de vulnerabilidades no parcheadas mediante escáneres de seguridad de contenedores docker y el nivel de falsos positivos.
Además el autor argumenta que varias de estas herramientas utilizan directamente administradores de paquetes para resolver dependencias. Esto los hace particularmente difíciles de defender. Algunos administradores de dependencias tienen archivos de configuración que permiten la inclusión de código shell.
Incluso si de alguna manera se manejan estas formas sencillas, llamar a estos administradores de paquetes significará inevitablemente desembolsar dinero. Esto, por decirlo suavemente, no facilita la defensa de la aplicación.
Los resultados de las pruebas de 73 imágenes que contienen vulnerabilidades conocidas, así como una evaluación de la efectividad para determinar la presencia de aplicaciones típicas en imágenes (nginx, tomcat, haproxy, gunicorn, redis, ruby, node), pueden ser consultadas dentro de la publicación realizada en el siguiente enlace.
