¿Qué hay en el contenedor? Análisis de vulnerabilidades, riesgos y protección con Kaspersky Container Security y el asistente de IA KIRA

Introducción

La contenedorización mediante Docker se consolidó firmemente en los estándares de desarrollo modernos, lo que aumentó significativamente la velocidad y la comodidad de la implementación de diversos servicios. Los desarrolladores suelen usar imágenes de Docker ya preparadas, realizando solo cambios mínimos. El repositorio más grande de imágenes de contenedores es el servicio Docker Hub.

La infraestructura basada en contenedores es un objetivo atractivo para los atacantes. Como mínimo, un contenedor en riesgo puede usarse para ataques de denegación de servicio distribuido (DDoS, por sus siglas en inglés), minería de criptomonedas o redireccionamiento de tráfico. La lista de amenazas no termina ahí: una vez que un atacante obtiene el control de un contenedor, puede robar o destruir datos directamente de él, acceder a contenedores vecinos o incluso intentar escapar del contenedor, comprometiendo toda la red empresarial.

Al mismo tiempo, la infraestructura dentro de los contenedores suele actualizarse con menos frecuencia y puede contener versiones de software desactualizadas y vulnerables. Al implementar imágenes de terceros o modificarlas para un entorno específico, es fácil cometer errores de configuración que los atacantes pueden aprovechar posteriormente. Debido a las características arquitectónicas de los contenedores, los desarrolladores a menudo enfrentan limitaciones al preparar imágenes; para superarlas, pueden recurrir a soluciones inseguras que encuentran en línea.

En otras palabras, la infraestructura en contenedores puede ser tanto el objetivo más simple como el más lucrativo para abusar. Por lo tanto, su seguridad requiere una atención especial. Para minimizar el riesgo de ataques exitosos a la infraestructura de contenedores, es esencial revisar las imágenes finales de Docker, incluidas todas las capas subyacentes, en busca de vulnerabilidades y configuraciones incorrectas. La forma más fácil de hacerlo es analizando el Dockerfile; sin embargo, no siempre está disponible para su inspección. Además, por lo general define cómo crear capas sobre una imagen base procedente de un repositorio externo cuya confiabilidad no se puede garantizar.

Resultados del análisis de imágenes en Kaspersky Container Securit

Para ayudar a los usuarios a identificar configuraciones inseguras y posibles vulnerabilidades en ellas, agregamos nuestro asistente de IA a Kaspersky Container Security. KIRA (el nombre del asistente) usa inteligencia artificial para analizar la imagen e identificar posibles problemas, además de ofrecer recomendaciones sobre cómo solucionarlos.

Como parte de este estudio, le pedimos a KIRA que analizara varias imágenes populares de la comunidad y más adelante en este artículo mostraremos los resultados.

Vulnerabilidades de software y compromiso de las fuentes de actualización

Uno de los principales problemas de seguridad al usar imágenes ya compiladas es que los desarrolladores no las actualizan de manera oportuna. Una imagen de Docker es, por su propia naturaleza, una instantánea de una distribución específica de Linux después de que se le instalaran los paquetes. Sin embargo, en la mayoría de los casos, no recibe actualizaciones de seguridad por sí sola, a diferencia de los servidores Linux tradicionales, donde estas actualizaciones son instaladas automáticamente por servicios especializados, como unattended-upgrades en las distribuciones basadas en Debian y dnf-automatic en las distribuciones basadas en RedHat.

Para aplicar actualizaciones a una imagen de Docker, es necesario volver a compilarla y a implementarla. A menudo, este proceso no está automatizado, y algunas actualizaciones requieren un esfuerzo adicional para verificar su correcto funcionamiento, modificar configuraciones al actualizar a nuevas versiones de software, etc. Como resultado, muchas imágenes populares no reciben actualizaciones oportunas, lo que aumenta significativamente los riesgos asociados a su uso.

Una imagen que era segura en el momento de su compilación acumula vulnerabilidades a medida que estas se descubren en los paquetes instalados en su interior, lo que con el tiempo aumenta significativamente las posibilidades de que se produzca un ataque exitoso contra el contenedor.

Las versiones vulnerables de aplicaciones web y servicios de red accesibles desde Internet se convierten inmediatamente en objetivos de diversas campañas maliciosas. Por ejemplo, apenas un día después del descubrimiento de la vulnerabilidad CVE-2025-55182 en React Server Components, nuestros honeypots registraron numerosos intentos de ataque relacionados con esta vulnerabilidad. Fue adoptada por los operadores de muchas campañas maliciosas, que van desde los clásicos mineros de criptomonedas hasta variantes de Mirai y Gafgyt. Los atacantes agregan constantemente nuevos métodos de distribución y pueden usar docenas de exploits dirigidos a diversas vulnerabilidades y errores de configuración en servicios populares. A menudo, las mismas vulnerabilidades se usan en mecanismos de autopropagación desde hosts ya en riesgo. Por ejemplo, en una campaña maliciosa para propagar el minero Dero, los atacantes usan contenedores infectados para buscar e infectar automáticamente nuevos objetivos.

Además de las vulnerabilidades que pueden abusarse de forma remota, los atacantes están agregando rápidamente vulnerabilidades locales a su arsenal, que usan para obtener privilegios de administrador y escapar del contenedor: en la campaña de malware Kinsing, los atacantes usaron CVE-2023-4911 (Looney Tunables) para elevar privilegios, y en la campaña perfctl, se usó la vulnerabilidad CVE-2021-4034 (PwnKit) con el mismo propósito. El acceso obtenido se usó para instalar un rootkit que oculta la presencia de perfctl en el sistema.

Para evaluar la situación con respecto a las vulnerabilidades sin corregir con parches en los contenedores, tomamos una muestra aleatoria de 100 imágenes, que incluía diversas soluciones populares con entre 10 000 y 1 millón de descargas en DockerHub. En las 64 imágenes que escaneamos, encontramos versiones de software desactualizadas con vulnerabilidades críticas. Por ejemplo, algunas imágenes tenían la vulnerabilidad CVE-2025-49844 en el servidor Redis, lo que daba lugar a RCE al aprovechar una vulnerabilidad en el analizador Lua; la vulnerabilidad actual CVE-2026-24061 en nginx, que en algunas configuraciones provoca el fallo del proceso del servidor y, con ASLR deshabilitado, también la RCE; y las vulnerabilidades CVE-2025-32463 en sudo y CVE-2023-4911 en glibc, que permiten a un atacante obtener privilegios de administrador con acceso local. Al mismo tiempo, solo una de cada diez imágenes de Docker de la muestra analizada está completamente actualizada.

Las 10 vulnerabilidades críticas principales con PoC/exploits disponibles, tal como se muestra en el panel de control de Kaspersky Container Security

Vale la pena señalar que, por supuesto, no todas las vulnerabilidades descubiertas pueden ser abusadas directamente por los atacantes. El riesgo real surge cuando la aplicación o biblioteca vulnerable se encuentra realmente en uso y se cumplen las condiciones necesarias para el abuso, las cuales varían significativamente de una vulnerabilidad a otra. No obstante, no se deben ignorar las actualizaciones, ya que el riesgo de que las vulnerabilidades sean abusadas (tanto individualmente como en diversas combinaciones) no se puede predecir en cada caso específico, e incluso las vulnerabilidades que a primera vista parecen inofensivas pueden, en última instancia, representar un grave riesgo.

Una cantidad récord de vulnerabilidades en una sola imagen

Sin embargo, las actualizaciones frecuentes tienen una desventaja. Cada reconstrucción que descarga nuevos paquetes de los repositorios de origen introduce un riesgo adicional de un ataque a la cadena de suministro: una dependencia en riesgo o una imagen base modificada podrían inyectar silenciosamente código malicioso en el entorno precisamente a través de una actualización. En nuestro análisis de las imágenes de muestra, no encontramos ningún indicio de ataques a la cadena de suministro. Sin embargo, en marzo de 2026, ocurrió un incidente en la cadena de suministro en los proyectos Trivy y LiteLLM. En el caso de Trivy, el archivo infectado se inyectó directamente en la imagen del contenedor en los repositorios oficiales.

Detección de software potencialmente malicioso usando una de las imágenes como ejemplo

Esto conlleva una decisión difícil: las actualizaciones poco frecuentes dejan vulnerabilidades conocidas sin corregir con parches en la imagen, mientras que las actualizaciones frecuentes aumentan el riesgo de que se vea comprometida la cadena de suministro. Por lo tanto, para proteger la infraestructura, no solo se debe actualizar regularmente las imágenes base, sino también se debe adoptar un enfoque más integral, específicamente fijando las dependencias a versiones que se sabe que funcionan bien y escaneando las imágenes resultantes en busca de malware después de la actualización.

Vulnerabilidades de configuración

Incluso un contenedor con una imagen totalmente actualizada puede verse en riesgo si está configurado incorrectamente. La inclusión de claves y secretos en la imagen, la desactivación de la autenticación en los servicios de red, las contraseñas predeterminadas y los permisos de acceso a archivos inseguros: todo esto puede ser abusado por los atacantes de una forma u otra para lograr sus objetivos.

Configuraciones inseguras de imágenes detectadas por KCS basándose en reglas

La situación se agrava por el hecho de que los autores de la imagen original pueden introducir errores, lo que complica su detección, ya que esto requiere analizar cada capa y el comando que la generó. Al igual que con las vulnerabilidades, no todo error de configuración conduce a un riesgo de seguridad: todo depende de la función del contenedor, su accesibilidad a la red y muchos otros factores. Sin embargo, el uso de configuraciones inseguras, tarde o temprano, provocará la aparición de errores en las imágenes, donde sus consecuencias serán significativamente más peligrosas.

Las reglas estándar suelen ser insuficientes para analizar configuraciones problemáticas. Para comprender mejor el contexto y evaluar los riesgos potenciales, se pueden usar herramientas de IA. Más adelante en esta sección, examinaremos ejemplos de configuraciones inseguras típicas que descubrimos al escanear imágenes públicas de Docker Hub, junto con las descripciones de los problemas y los métodos de mitigación de riesgos proporcionados por el asistente de IA KIRA.

Ejemplo de análisis de contenedores con KIRA

Manejo inseguro de credenciales

Uso de contraseñas predeterminadas

En algunos casos, los contenedores pueden usar contraseñas predeterminadas configuradas a través de variables de entorno o directamente en el Dockerfile. Si estas contraseñas no se anulan, los atacantes podrán acceder a la aplicación usando la contraseña predeterminada.

Según el análisis de KIRA, la contraseña del usuario se almacena en texto sin cifrar en el historial de capas de la imagen. Cualquiera que obtenga acceso a la imagen, ya sea a través de un registro público, un entorno de compilación en riesgo u otros medios, podrá extraer la contraseña. Si se habilita SSH u otra forma de acceso interactivo en el contenedor, esto podría llevar a su compromiso total y permitir que los atacantes se desplacen lateralmente dentro de la infraestructura.

Las contraseñas pueden estar presentes en las variables de entorno. Considera el siguiente fragmento de Dockerfile:

En este ejemplo, la variable de entorno PKP_DB_PASSWORD está establecida como changeMePlease. Si el usuario olvida modificarla, la aplicación usará la contraseña que se puede obtener del Dockerfile.

Veamos otra imagen:

En esta imagen, el archivo Dockerfile especifica que la contraseña de administrador está codificada de forma fija en la directiva ENV y permanece en los metadatos de la imagen (historial de capas, docker inspect). Cualquier persona que obtenga acceso a la imagen (registro, caché de compilación) podrá extraer este secreto y comprometer la cuenta.

Para eliminar estos riesgos, asegúrate de que no se especifiquen contraseñas en el archivo Dockerfile. Si se requiere autenticación, se pueden usar mecanismos del orquestador (secretos) o generar una contraseña temporal al iniciar el contenedor mediante el script de punto de entrada, sin guardarla en las capas. También recomendamos usar mecanismos para pasar secretos de manera segura en tiempo de ejecución (secretos de Docker, secretos de Kubernetes) o, como último recurso, pasarlos mediante --secret durante la compilación con BuildKit, pero bajo ninguna circunstancia deben dejarse en la imagen final.

Pasar contraseñas mediante argumentos de comando

En algunos casos, las contraseñas pueden quedar expuestas al pasarse mediante argumentos de línea de comandos, ya que estos argumentos son visibles para todos los usuarios del sistema:

En el ejemplo proporcionado, la contraseña del superusuario de MySQL se pasa al comando healthcheck en texto sin cifrar, lo que la hace visible al ver la lista de procesos (ps aux), en los registros de auditoría y en los sistemas de control. Si un atacante obtiene acceso de lectura a los procesos o registros del contenedor, puede extraer la contraseña y obtener control total de la base de datos.

Para solucionar este problema, healthcheck debe usar una conexión local a través de un socket de Unix con autenticación predeterminada (si el complemento auth_socket está configurado para root), o bien crear un usuario dedicado con privilegios mínimos (por ejemplo, solo USAGE), sin contraseña o con una contraseña pasada a través de un archivo seguro (--defaults-file con permisos restringidos). También puedes usar la variable de entorno MYSQL_PWD para la autenticación de la comprobación de estado, pero esta permanece visible en /proc.

Escalada de privilegios en el contenedor

Uno de los vectores más comunes para el compromiso inicial de los sistemas Linux es la RCE en aplicaciones web y servicios de red. Por lo general, estos servicios cuentan con privilegios mínimos, lo que complica las acciones posteriores de los atacantes: extraer credenciales, borrar sus rastros, intentar escapar del contenedor y mucho más.

La situación empeora significativamente si el atacante obtiene privilegios de administrador, ya que esto le permite controlar por completo todos los procesos dentro del contenedor, ocultar su actividad y usar métodos para escapar del contenedor. Por ejemplo, pueden comprometer el host si el contenedor cuenta con privilegios, si se monta un socket de Docker en su interior o si existen otras configuraciones inseguras y vulnerabilidades que no pueden explotarse con privilegios de usuario estándar.

Del mismo modo, esto simplifica los ataques de red contra contenedores vecinos, el orquestador y diversos servicios internos, lo que convierte a este error de configuración en un eslabón potencial en la cadena para comprometer toda la red.

Ataques a sudo

Uno de los métodos más simples para la escalada de privilegios es ejecutar comandos arbitrarios como root usando sudo sin ingresar una contraseña. Considera el siguiente ejemplo:

Al analizar esta configuración con KIRA, se destaca de inmediato el problema principal: al instalar el paquete sudo y configurar NOPASSWD: ALL para solr, el usuario viola gravemente el principio del privilegio mínimo. La plataforma Solr no requiere privilegios tan amplios para ejecutarse dentro de un contenedor; por el contrario, estos crean una vía fácil para escalar a root.

En otro ejemplo de configuración insegura, se otorgan privilegios NOPASSWD:ALL a un usuario de la base de datos PostgreSQL, lo cual representa un debilitamiento directo y grave de la política de control de acceso. Si un atacante logra ejecutar código en nombre del usuario postgres (ya sea a través de una vulnerabilidad en un servicio de red, una inyección SQL o al poner en riesgo uno de los procesos), podrá ejecutar de inmediato y sin condiciones cualquier comando en nombre del usuario root. Esto equivale a que todo el contenedor se ejecute como root.

Como medida para mitigar el riesgo, recomendamos eliminar por completo esta directiva. Los comandos mínimos necesarios que requieran privilegios deben delegarse caso por caso mediante sudoers, con la especificación explícita de los ejecutables y parámetros permitidos, usando NOPASSWD solo como último recurso y para utilidades específicas.

Nuestra asistente de IA, KIRA, puede identificar configuraciones inseguras aún más complejas, como permitir el uso de sudo sin contraseña para todo el grupo sudo, mediante la modificación de las reglas existentes.

El riesgo en este ejemplo es que el comando reemplaza las declaraciones estándar que requieren autenticación por la ejecución sin contraseña de todos los comandos para cualquier usuario dentro del grupo sudo; lo que podría incluir a postgres, en caso de que esté asignado a ese grupo. Esto amplía la superficie de ataque a todos los miembros del grupo, convirtiendo a cada uno de ellos en un punto potencial para la escalada instantánea de privilegios.

Para mitigar los riesgos, recomendamos no modificar la política global de sudoers, mantener el requisito estándar de contraseña o usar un mecanismo de escalada más seguro (como gosu) para ejecutar un proceso específico en nombre de otro usuario sin privilegios permanentes.

Permisos de archivo inseguros

Otro vector común para la escalada de privilegios son los permisos de archivos y directorios configurados de manera insegura. Por comodidad, los autores de imágenes de contenedores suelen usar permisos 777, lo que permite a cualquier persona, incluso a usuarios sin privilegios, crear y eliminar archivos libremente, así como modificar su contenido. Esto puede conducir tanto a la escalada de privilegios como a que un atacante sin privilegios pueda eliminar o modificar registros, entre otras consecuencias indeseables.

Considera el siguiente comando:

El riesgo es que cualquier usuario del contenedor pueda escribir en los directorios que contienen archivos binarios y scripts. Esto permite que un atacante con privilegios bajos reemplace las utilidades incluidas en cargo o agregue nuevos ejecutables maliciosos. Cuando estas herramientas se ejecuten posteriormente, especialmente como usuario root o mediante sudo, el código del atacante se ejecutará con los privilegios heredados del proceso que lo invoca, lo que conducirá directamente a una escalada de privilegios local.

Para mitigar los riesgos, puedes establecer los permisos mínimos necesarios: chmod 0755 para los directorios y chmod 0755/0644 para los archivos correspondientes. El propietario debe ser root, y solo el propietario debe tener permiso de escritura. No uses chmod 777 en ninguna ruta del sistema.

Falta de verificaciones de integridad

Descargar software sin verificar su integridad puede hacer que la infraestructura sea vulnerable a la manipulación del software.

Por ejemplo, este riesgo puede surgir al descargar una distribución a través de HTTP:

El uso de HTTP sin verificar la integridad del archivo crea las condiciones para un ataque man-in-the-middle durante la fase de compilación de la imagen. Un atacante que controle el canal de comunicación o el DNS puede reemplazar el archivo por contenido malicioso, lo que pondrá en riesgo el contenedor y todo el entorno en el que se ejecuta.

Para mitigar los riesgos, puedes configurar las conexiones a los recursos web para que usen únicamente HTTPS, siempre que el recurso admita este protocolo. También puedes descargar el archivo sin extraerlo, comparar su suma de verificación (SHA256) con la de una fuente confiable y solo entonces extraerlo. Es recomendable almacenar el archivo verificado en un repositorio interno de artefactos para evitar descargas directas desde la red.

Seguirá existiendo un riesgo de ataque man-in-the-middle (MitM) incluso si la verificación de certificados está deshabilitada:

La ausencia de verificación de certificados TLS permite que un atacante que controle el segmento de red reemplace el archivo ZIP descargado por contenido malicioso. Dado que el archivo contiene código PHP que será ejecutado por el servidor web, una vulneración durante la fase de compilación dará lugar a la implementación de una puerta trasera o a una fuga de datos.

Para mitigar los riesgos, elimina el indicador --no-check-certificate; después de la descarga, calcula el hash SHA256 del archivo y verifícalo contra un valor de referencia conocido (la página de lanzamiento o un repositorio local de hashes confiables). Además, considera usar una versión fija (etiqueta) en lugar de la rama flotante 7.2-dev.

Conclusión

Los contenedores de Docker se convirtieron en un medio muy popular para implementar software, y los atacantes no pasan por alto esta tendencia en absoluto. Están incorporando rápidamente vulnerabilidades de software y errores de configuración a su arsenal y llevando a cabo ataques contra las cadenas de suministro. Pueden comprometer la infraestructura de contenedores con una amplia variedad de fines, desde la minería de criptomonedas hasta el cifrado de datos para exigir un rescate o el robo de información crítica para la empresa.

Nuestra investigación reveló que 64 de cada 100 imágenes de contenedores para aplicaciones populares tienen software con vulnerabilidades críticas, y solo el 10 % está completamente actualizado. También identificamos numerosas configuraciones inseguras, entre ellas contraseñas almacenadas en texto sin cifrar en archivos Dockerfile y privilegios excesivos otorgados a usuarios y procesos.

Para detectar y prevenir estas amenazas, es esencial cumplir estrictamente con las medidas de seguridad: auditar las configuraciones de las imágenes, administrar de manera segura los secretos usados en las imágenes, aplicar las actualizaciones de seguridad de manera oportuna, escanear su contenido en busca de malware con cada actualización y seguir las mejores prácticas estándar de la industria para mejorar la seguridad.

Este enfoque requiere soluciones especializadas diseñadas para adaptarse a las características únicas de los entornos de contenedores.Kaspersky Container Security garantiza la seguridad de las aplicaciones en contenedores en cada etapa de su ciclo de vida, desde el desarrollo hasta la operación. El producto protege los procesos de negocio de una organización, ayuda a garantizar el cumplimiento de los estándares de la industria y las regulaciones de seguridad, y permite la implementación de prácticas seguras de desarrollo de software.