Graboid: El primer gusano en ser propagado mediante imágenes de Docker

Unos investigadores de Unit 42 descubrieron un worm que lleva a cabo rutinas de cryptojacking y sería el primero en propagarse mediante contenedores en Docker Engine (Community Edition)

¿Cómo se lleva a cabo el ataque?

En primer lugar, el atacante abusaba de Docker daemons inseguros para obtener total control sobre Docker Engine (1), luego ejecutaba sobre ellos un contenedor malicioso que se encuentra público en Docker Hub (2), tras lo cual el malware es descargado desde diversos servidores de Command & Control en forma de scripts de shell y de los cuales también recibe un listado de IPs de otros hosts vulnerables (3), y finalmente comienza sus rutinas de minado de Monero mientras realiza consultas con frecuencia a la Command & Control respecto a nuevos hosts vulnerables para propagarse de forma aleatoria hacia ellos (4).

En mayor detalle, la operación sigue los siguientes pasos:

1. El atacante encuentra un host de docker inseguro y envía comandos de forma remota para descargar y ejecutar la imagen de Docker maliciosa (un ejemplo puntual visto en la investigación fue pocosow/centos:7.6.1810) que contiene la herramienta docker client usada para comunicarse con otros hosts de Docker.
   
   
2. El script de punto de entrada “/var/sbin/bash” descarga cuatro shell scripts (live.sh, worm.sh, cleanxmr.sh y xmr.sh) desde la Command & Control y los ejecuta uno a uno.
   
   
   1. “live.sh” informa la cantidad de CPUs disponibles en el host comprometido a la Command & Control.
      
      
   2. “worm.sh” descarga un archivo llamado “IP” que contiene un listado de miles de IPs de otros hosts con el API de docker inseguro, tras lo cual escoge una de estas IP y utiliza la herramienta docker client para realizar de forma remota un pull y deploy del contenedor malicioso.
      
      
   3. “xmr.sh” elige también aleatoriamente uno de los hosts del archivo “IP” y despliega de forma remota la imagen “gakeaws/nginx” en el host, la cual tiene un binario de XMRig que finge ser nginx.
      
      
   4. “cleanxmr.sh” elige aleatoriamente uno de los hosts en el archivo “IP” y detiene el contenedor de criptojacking “gakeaws/nginx” (parece ser capaz también de detener otros contenedores basados en xmrig, no sólo el distribuido por Graboid)

Durante la infección, los pasos posteriores al punto de entrada inicial se repiten continuamente, alternando el malware así periodos de inactividad y periodos en que mina por varios minutos.

¿Cómo prevenir este tipo de amenazas?

Graboid es toda una novedad porque se trata de la primer amenaza con propagación de tipo gusano y rutinas de cryptojacking que se encuentra siendo propagada mediante imágenes de Docker, por ello es importante incorporar nuevas medidas para hacer frente a esta superficie de ataque:

• Nunca descargar imágenes de Docker desconocidas, no oficiales o sospechosas.
• Revisar de forma periódica los contenedores presentes en el host, ya que un atacante que posea acceso total de forma remota podría desplegar una imagen infectada como en este caso.
• No exponer el docker daemon a Internet si no se va a contar con un mecanismo de autenticación (Por defecto, Docker Engine Community Edition no se expone a Internet)

Cabe también mencionar que la tecnología tradicional no es capaz de analizar ni la información ni las actividades que se llevan a cabo dentro de los contenedores, por lo que es clave implementar tecnologías avanzadas que puedan realizar esto.

En el caso de Trend Micro, por ejemplo, se cuenta con la herramienta Deep Security que permite por un lado analizar el contenido de los contenedores e imágenes (tanto a nivel de malware como de librerías y componentes vulnerables) y también un monitoreo del tráfico tanto entre contenedores como entre ellos, Docker Engine y el host.

Indicadores de compromiso

Imágenes de Docker

6560ddfd4b9af2c87b48ad98d93c56fbf1d7c507763e99b3d25a4d998c3f77cf | pocosow/centos:7.6.1810

4827767b9383215053abe6688e82981b5fbeba5d9d40070876eb7948fb73dedb | gakeaws/nginx:8.9

15319b6ca1840ec2aa69ea4f41d89cdf086029e3bcab15deaaf7a85854774881 | gakeaws/mysql

Servidores de Command & Control

120[.]27[.]32[.]15

103[.]248[.]164[.]38

101[.]161[.]223[.]254

61[.]18[.]240[.]160

182[.]16[.]102[.]97

47[.]111[.]96[.]197

106[.]53[.]85[.]204

116[.]62[.]48[.]5

114[.]67[.]68[.]52

118[.]24[.]222[.]18

106[.]13[.]127[.]6

129[.]211[.]98[.]236

101[.]37[.]245[.]200

106[.]75[.]96[.]126

47[.]107[.]191[.]137