Por primera vez en la historia, los investigadores han descubierto un gusano de criptojacking. Los Investigadores de seguridad de la Unidad 42 de Palo Alto Network Inc. hicieron el hallazgo de este gusano cryptojacking que se propaga utilizando contenedores de software Docker. Este gusano cryptojacking explota la solución de plataforma como servicio (PaaS) que utilizan los desarrolladores de software para probar e implementar aplicaciones en plataformas Windows y Linux.
Ya que docker permite que las aplicaciones se ejecuten en un entorno virtual separado de otras aplicaciones de Windows, lo que permite a los desarrolladores ejecutar aplicaciones en recursos compartidos del sistema. Apodado «Graboid», el gusano se extendió a más de 2,000 hosts Docker no seguros y utiliza los hosts infectados para extraer la criptomoneda “Monero”.
Monero es una criptomoneda favorita de los piratas informáticos porque es anónima y extremadamente difícil de rastrear. Por el contrario, bitcoin se puede rastrear a través de un libro público.
Los investigadores encontraron varias imágenes de contenedores asociados con el ataque en diferentes etapas de la cadena de infección. Estos contenedores fueron eliminados por el soporte de Docker Hub, después de ser alertado por los investigadores, una de las imágenes del contenedor que ejecutaba CentOS intentaba conectarse a servidores de comando y control (C2) predefinidos para descargar y ejecutar cuatro scripts de shell.
Los que están detrás de Graboid identifican motores Docker inseguros para iniciar el proceso de infección. Una vez que se identifica el punto de entrada, el gusano se despliega para comenzar su camino.
Al descargar algunas secuencias de comandos de un servidor de comando y control, el gusano es esencialmente autosuficiente, comienza a criptominar en el host Docker infectado mientras busca nuevas víctimas. Graboid comienza seleccionando aleatoriamente tres objetivos potenciales para la infección, instalando el gusano en el primer objetivo y detiene al minero en el segundo objetivo, comenzando a minar en el tercer objetivo.
«Este procedimiento conduce a un comportamiento minero muy aleatorio», explicaron los investigadores hoy. “Si mi host se ve comprometido, el contenedor malicioso no se inicia de inmediato. En cambio, tengo que esperar hasta que otro host comprometido me elija y comience mi proceso de minería … Esencialmente, el minero en cada host infectado es controlado aleatoriamente por todos los demás hosts infectados «.
En promedio, cada minero estuvo activo el 63% del tiempo y cada período de minería duró 250 segundos, lo que dificulta la detección de la actividad, ya que la mayoría del software de protección de punto final no inspecciona los datos y las actividades dentro de los contenedores.
Los investigadores de la Unidad 42 trabajaron con el equipo de Docker para eliminar las imágenes maliciosas del contenedor, pero el riesgo de futuras infecciones por variantes que utilizan técnicas similares es real.
«Si alguna vez se crea un gusano más potente para adoptar un enfoque de infiltración similar, podría causar un daño mucho mayor, por lo que es imperativo que las organizaciones protejan a sus anfitriones Docker», advirtieron los investigadores.
En la publicación del blog sobre Graboid, los investigadores de seguridad ofrecen algunos consejos que pueden ayudar a prevenir la infección. Dentro de ellos, los investigadores de Palo Alto aconsejan a las empresas que nunca expongan sus demonios Docker directamente a Internet sin una autenticación adecuada.
De hecho, Docker Engine no está expuesto a Internet de forma predeterminada, por lo que las implementaciones no seguras explotadas por este gusano se han configurado manualmente para que estén disponibles públicamente.
Otro de los consejos que dan los investigadores es que las compañías que usen SSH con autenticación una fuerte si necesitan conectarse remotamente a un demonio Docker y combinarlo con reglas de firewall que limitan las conexiones a una lista de direcciones IP fiables.
Además, recomiendan que los administradores se aseguren de que nunca implementen imágenes de contenedores Docker de fuentes poco confiables en Docker Hub y que verifiquen con frecuencia sus implementaciones de Docker para eliminar contenedores o imágenes desconocidas.