ra2 studio - Fotolia

Evaluar Conozca los pros y contras de las tecnologías, productos y proyectos que está considerando.

Cómo las APIs de Docker pueden ser mal usadas para plantar malware

Investigadores descubrieron cómo las API de Docker pueden explotarse para ocultar malware. Dave Shackleford explica el método de ataque y la amenaza que representa para el contenedor y las máquinas virtuales.

En Black Hat 2017, los investigadores de Aqua Security demostraron una nueva técnica de ataque que permite a los atacantes utilizar las APIs de Docker para ocultar el malware en los sistemas, e incluso potencialmente ejecutar código en algunos casos. En los últimos años, los contenedores han crecido constantemente en popularidad en muchos entornos de desarrollo y operaciones debido a su modelo de implementación ligero y eficiente. Sin embargo, los nuevos ataques, como el abuso de las APIs de Docker, generan inquietudes para los equipos de seguridad de la información.

El ataque Docker

El ataque es posible en cualquier instalación que expone las APIs de Docker a través del protocolo TCP, que ha sido el predeterminado en Docker basado en Windows para Windows, y se usa principalmente para probar escenarios por los desarrolladores. Para que el ataque tenga éxito, el usuario que ejecuta una versión vulnerable de Docker debe ser atraído a un sitio que envía JavaScript malicioso a través de su navegador al punto final. Al usar las APIs de Docker, este script se personaliza para eludir las medidas de seguridad del navegador que restringen la ejecución del código bajo la política del mismo origen. Esto genera un contenedor Docker local que llama a un repositorio Git para el control del comando, lo que permite que se descargue código malicioso adicional. Después de que esto ocurre, el contenedor local se une a los protocolos locales de resolución de nombres de Microsoft a través de una interfaz virtual en el host para mantener el control sobre el sistema. Con esta técnica, un "contenedor sombra" local genera gradualmente un código de persistencia local para sobrevivir a un reinicio Docker o al reinicio del host local.

Si se está diciendo: "Eso es complicado", está 100% en lo correcto. Este ataque es, de hecho, enormemente complejo y requiere que un conjunto muy específico de APIs REST de Docker sean expuestos de una manera específica. Aunque definitivamente sirve como una revelación sobre cómo Docker podría ser abusado en entornos de desarrollo y operaciones, la probabilidad de que este problema se manifieste es probablemente bajo. Docker respondió a los investigadores que informaron el problema y desde entonces ha cambiado la configuración predeterminada de la API en Docker para Windows, para no permitir HTTP de forma remota. Esta actualización ha impedido aún más que se produzca el secuestro de la secuencia de comandos inicial. La mejor recomendación para cualquier organización que ejecute Docker para Windows es actualizar a la última versión que tiene implementada esta actualización de configuración. Además, Docker recomienda restringir el acceso remoto de Docker a clientes autenticados mediante el uso de certificados u otros medios para bloquear los puertos del motor Docker en ciertas interfaces donde sea apropiado, y potencialmente deshabilitar los servicios de resolución de nombres específicos de Microsoft, como NetBIOS y LLMNR.

Las mejores prácticas de seguridad de Docker

En muchos sentidos, la implementación de controles más estrictos sobre cómo los desarrolladores usan los contenedores Docker en escenarios de desarrollo y prueba puede recorrer un largo camino para mitigar estos problemas. Primero, cualquier implementación de una herramienta, como Docker para Windows, agrega varias capas nuevas de complejidad y vulnerabilidad de seguridad potencial al sistema de un desarrollador. Como mínimo, habrá una máquina virtual Moby Linux ejecutando el motor Docker, y también será necesario asegurar el sistema operativo de contenedores y las pilas de aplicaciones.

Idealmente, cualquier sistema utilizado para el desarrollo de esta manera debería aislarse del resto de la red principal y evitar que obtenga código directamente de internet. Uno de los principales elementos de este ataque es la recuperación de código malicioso de repositorios en línea que un nuevo contenedor buscará e instalará; esto debería estar expresamente prohibido en las estaciones de trabajo de los desarrolladores. En su lugar, configure los repositorios internos de los que los contenedores Docker pueden extraer, y asegúrese que solo esos estén en uso dentro del entorno.

Además, solo permita que se utilicen compilaciones Docker de máquinas virtuales e instancias de contenedores aprobadas, de ser posible, especialmente en cualquier etapa de los entornos de desarrollo y prueba que están conectados a la red. Las herramientas de escaneo y seguridad, como Docker Bench y CoreOS Clair, también pueden ser útiles para validar imágenes de prueba y las nuevas configuraciones de desarrollo que está probando.

Próximos pasos

Más sobre contenedores:

La relación entre DevOps, contenedores, microservicios y la computación nativa de nube

¿Es la tecnología de contenedores adecuada para mi organización?

Qué deben saber los administradores para dominar la tecnología de contenedores

Este artículo se actualizó por última vez en noviembre 2017

Profundice más

PRO+

Contenido

Encuentre más contenido PRO+ y otras ofertas exclusivas para miembros, aquí.

Inicie la conversación

Envíenme notificaciones cuando otros miembros comenten sobre este artículo.

Enviando esta solicitud usted acepta recibir correos electrónicos de TechTarget y sus socios. Si usted reside afuera de Estados Unidos, esta dando autorización para que transfiramos y procesemos su información personal en Estados Unidos.Privacidad

Por favor cree un Nombre de usuario para poder comentar.

- ANUNCIOS POR GOOGLE

Close