Anatomía de los programas de criptominería: cierre de los botnets de minería
Contenido
Introducción
Le damos la bienvenida a la última entrega de nuestra serie de blogs Anatomía de los programas de criptominería:
En nuestra primera publicación, hablamos sobre los fundamentos de las criptomonedas, sus diversos atributos y lo que hace que algunas de ellas sean más atractivas que otras para los atacantes.
En la segunda parte, analizamos varias muestras de criptominería que detectamos que explotaban las diferentes topologías de minería.
En esta tercera y última publicación de blog de la serie, exploraremos dos novedosas técnicas proactivas que se pueden usar para derrotar a los programas de criptominería.
Además de estas publicaciones de blog, hemos lanzado varias herramientas de análisis que se pueden encontrar en nuestro repositorio.
Todos sabemos que la mejor defensa es un buen ataque. Debido a la naturaleza distribuida de las campañas de criptominería, interrumpirlas puede ser bastante complicado.
En esta publicación de blog, mostramos cómo superar este problema explotando el diseño de las topologías de minería comunes para cerrar eficazmente el proceso de minería. Aunque las técnicas que describimos se utilizaron para dirigirse a la los programas de criptominería de Monero, se pueden aplicar los mismos principios también a otras criptomonedas.
Cierre de las operaciones de criptominería
Cuando se detecta una operación de criptominería maliciosa, actualmente hay dos formas de intentar cerrarla:
Podemos solicitar al servicio de pool que prohíba la cuenta del atacante
Podemos intentar anular otros servicios en la infraestructura del atacante para interferir con la campaña
El problema con estas opciones es que pueden hacerse bastante complejas y llevar mucho tiempo debido a la dependencia de terceros.
Hemos encontrado una opción mejor.
Hemos desarrollado dos técnicas utilizando las topologías de minería y las políticas de pool que nos permiten reducir la eficacia de un botnet de criptominería hasta el punto de cerrarlo por completo, lo que fuerza al atacante a realizar cambios radicales en su infraestructura o incluso a abandonar la campaña por completo.
Ambas técnicas se basan en la explotación de las comunicaciones de Stratum de forma que sea posible prohibir componentes críticos como proxies o carteras que se relacionan con las cuentas de la operación de minería.
De 3,3 millones a cero
Nos centramos en una operación de criptominería maliciosa que lleva activa seis años. Al prohibir el proxy de minería del atacante, un punto central de fallo en la topología de minería, pudimos reducir su tasa de hash de 3,3 millones de hashes por segundo a cero (Figura 1).
Con la misma facilidad que los atacantes ganaban dinero, pudimos determinar los posibles ingresos anuales del atacante en cuestión de segundos. Con un simple portátil, provocamos que el operador de criptominería perdiera su gallina de los huevos de oro de 26 000 $ al año con el desplome de la tasa de hash.
En el vídeo de la Figura 2 se hace una demostración de esta técnica, a la que llamamos "malos recursos compartidos". Representa a una víctima de criptominería que está conectada a un proxy de minería malicioso. Mediante la ejecución de "malos recursos compartidos", pudimos prohibir el proxy de minería de la red, con lo que cerramos la operación de minería y redujimos el uso de la CPU de la víctima del 100 % al 0 %.
Fig. 2: Aplicación de la técnica de malos recursos compartidos en nuestra configuración de laboratorio
Si no puede vencerlos, prohíbalos
La criptominería a través de un pool se basa en enviar cálculos de hash válidos, que se conocen como recursos compartidos. Para generar ingresos, un programa de criptominería debe enviar recursos compartidos al pool de minería. Al recibir un recurso compartido, el pool de minería valida el resultado del hash y su dificultad.
La validación de los recursos compartidos es una de las tareas más intensivas de las que se tiene que encargar el servidor de pools, especialmente en el caso de recursos compartidos no válidos. Como todo en la vida, es posible que se produzcan errores. Por ejemplo, un funcionamiento incorrecto del hardware podría generar que se envíen al pool recursos compartidos incorrectos.
La gestión de recursos compartidos no válidos consume muchos recursos, por lo que los pools deben protegerse del colapso debido a la carga de envíos masivos de recursos compartidos no válidos. Por lo tanto, cuando un recurso compartido enviado no supera la validación del servidor, la mayoría de los pools impondrán una sanción al minero, normalmente en forma de prohibición temporal.
Esta interacción puede ser muy interesante al intentar cerrar una operación de minería maliciosa. Si podemos crear un nodo back-end o un pool para prohibir a los mineros del atacante (es decir, las víctimas), podemos detener la explotación de recursos del programa de criptominería y, esencialmente, liberar a las víctimas.
En las siguientes secciones, realizamos una demostración de este concepto con dos campañas de minería que habíamos explorado previamente como objetivo, cada una con una topología de minería diferente: un proxy de minería y una conexión directa a un pool público.
Uso de malos recursos compartidos para prohibir el proxy de minería de un atacante
Una de las topologías de minería más populares entre los programas de criptominería maliciosos es un proxy de minería (Figura 3). Esta configuración mejora la privacidad, ya que se ocultan tanto el back-end como la cartera digital de los atacantes, con lo que protegen sus identidades y reducen la trazabilidad dentro de la red.
Los proxies de minería plantean desafíos únicos para la detección de la red, ya que "ocultan" el pool objetivo al que se conecta el minero, que suele poder detectarse con una inspección de la red. También ocultan la dirección de la cartera, lo que reduce aún más la presencia detectable del minero. Sin embargo, hemos descubierto que los proxies de minería pueden ser el talón de Aquiles de los programas de criptominería.
Al realizar la minería con un proxy, todas las víctimas se conectan a un único servidor, por lo que interferir con el proxy puede acabar con toda la operación de minería. Hemos desarrollado una técnica que nos permite hacer justo eso.
La idea es sencilla: si nos conectamos a un proxy malicioso como minero, podemos enviar resultados no válidos de los trabajos de minería (malos recursos compartidos) que omitirán la validación del proxy y se enviarán al pool. Los malos recursos compartidos consecutivos acabarán prohibiendo el proxy, deteniendo eficazmente las operaciones de minería de todo el botnet de criptominería.
Comunicación con el proxy
El programa de criptominería debe conectarse primero al proxy utilizando el método de inicio de sesión Stratum. Si no se ha establecido otra configuración, el minero se identifica como x de forma predeterminada en el servidor proxy XMRig (Figura 4).
Si la conexión se establece correctamente, significa que hay un listener en el extremo del proxy. Podemos asegurarnos de que es efectivamente un proxy de minería analizando la respuesta: una respuesta válida será un documento JSON que cumple el protocolo Stratum y el resultado será un trabajo.
Aunque el proceso de minería completo es complejo (como se describe en Zero to Monero), diseñar un recurso compartido personalizado es relativamente sencillo. Solo es necesario extraer algunos valores de la respuesta del proxy: los valores de id, job id y nicehash nonce del trabajador. Los tres son necesarios para realizar un seguimiento de un trabajo de minería específico, por lo que si queremos que el proxy acepte nuestros malos recursos compartidos, debemos rellenar estos campos correctamente (Figura 5).
Al recibir un recurso compartido de un minero, el proxy lo reenviará al pool casi tal cual, con una diferencia clave: se envía con la dirección de la cartera del atacante. Por eso nunca podíamos conocer la cartera o cualquier otra información de la cuenta del atacante o el pool de la muestra de criptominería.
XMRogue
No es difícil infiltrarse en el botnet de criptominería como una de las víctimas. Por lo general, no hay una autorización especial y, en muchos casos, se utilizan aplicaciones estándar como XMRig como minero y XMRig-proxy como proxy de minería.
Eso nos llevó a desarrollar XMRogue. XMRogue es una herramienta que nos permite suplantar a un minero, conectarnos a un proxy de minería, enviar malos recursos compartidos consecutivos y finalmente prohibir el proxy de minería del pool (Figura 6).
Una consideración importante es la validación de los recursos compartidos en el nivel de proxy. Como el proxy reenvía nuestros malos recursos compartidos al pool, tiene la oportunidad de identificarlos y eliminarlos.
Por ejemplo, la popular XMRig-proxy validará el nicehash nonce que proporciona con el trabajo y la dificultad del resultado. Si el nonce o la dificultad son incorrectos, el mal recurso compartido no se reenviará al pool back-end. En la Figura 7, podemos ver la validación dentro del código, donde los recursos compartidos con hashes de baja dificultad o valores incorrectos de nicehash se descartan.
Podemos superar estas validaciones analizando la solicitud de trabajo y diseñando cuidadosamente un resultado de trabajo "malo" que el proxy considere válido, lo que provoca que nuestros recursos compartidos se reenvíen al pool.
Comprobación de la teoría
Para probar nuestra técnica, elegimos como objetivo una de las campañas de minería que identificamos en la segunda parte de esta serie. Pudimos extraer las direcciones de todos los proxies de minería utilizados por las campañas elegidas, lo que nos proporcionó bastante información con la que trabajar. Por ejemplo, podemos ver que el proxy del atacante central (llamado de forma creativa "proxy") tiene una calificación máxima de Nanopool, lo que indica un uso extendido (Figura 8).
Este proxy genera 3 millones de hashes por segundo, lo que equivale aproximadamente a unos ingresos de 3 $ por hora o 26 000 $ al año. Al dirigirnos a este proxy con XMRogue, pudimos prohibirlo rápidamente del pool y detener la minería de todas las víctimas que estaban conectados a él. Si inspeccionamos la tasa de hash del proxy, podemos ver que se redujo completamente a cero (Figura 9).
Si consideramos el impacto de XMRogue en toda la campaña del atacante, podemos ver una reducción sustancial de su rentabilidad. Cuando documentamos esta campaña por primera vez, generaba casi 50 000 $ al año. Después de interrumpirla y desequilibrarla, los ingresos anuales de la campaña se redujeron un 76 % hasta 12 000 $. Dirigiéndonos a más proxies, los ingresos podrían haberse reducido a cero. Este tipo de impacto podría forzar fácilmente a los atacantes a abandonar totalmente la campaña o a asumir el riesgo de ser identificados al realizar cambios que se supervisan.
Uso de otras políticas de pools de minería
Los atacantes no siempre utilizan un proxy. En muchos casos, las victimas se conectarán directamente al pool, por lo que no se podrá aplicar la técnica anterior. El envío de malos recursos compartidos simplemente prohibirá nuestra dirección IP en el pool, sin que esto afecte a la operación de minería.
Cuando inspeccionamos el código fuente del pool de minería, nos vino a la mente otra opción: dirigirnos a la dirección de la cartera. Aunque la política de malos recursos compartidos anterior se dirigía a las direcciones IP del minero, identificamos una política adicional que se aplica en el nivel de cartera: el pool prohibirá la dirección de la cartera durante una hora si tiene más de 1000 trabajadores.
Al utilizar la minería de proxy, un atacante puede incrustar la dirección de su cartera exclusivamente en el servidor proxy, lo que le permite enmascararla eficazmente. Sin embargo, en las situaciones en las se realiza minería directa, la dirección de la cartera debe estar presente en el equipo de la víctima, lo que nos permite extraerla.
Prohibir al atacante en este caso es sencillo: solo tenemos que enviar más de 1000 solicitudes de inicio de sesión simultáneamente utilizando la cartera del atacante, lo que forzará al pool a prohibir la cartera del atacante. Esta técnica se ha añadido como modo de funcionamiento a la herramienta XMRogue.
Para ilustrar esta idea, utilizamos otra campaña que descubrimos que utiliza el pool público MoneroOcean. El estado inicial de la campaña era de una tasa de hash de 22 kH/s (Figura 11). Esta campaña es mucho más pequeña que la comentada anteriormente, pero la técnica debería cubrir una mayor variedad de configuraciones de campañas de criptominería.
Tras iniciar nuestro script, que inicia al instante miles de inicios de sesión, observamos una caída en picado de la tasa de minería, que acabó deteniéndose por completo (Figura 12).
Red más ancha, detección más superficial
Esta táctica podría interrumpir más operaciones de minería, aunque no es una solución permanente. Una vez que detuvimos las múltiples conexiones de inicio de sesión, la tasa de hash de la campaña se recuperó (Figura 13).
Resumen
Las técnicas presentadas anteriormente muestran como los defensores pueden cerrar eficazmente las campañas de criptominería maliciosas sin interrumpir la operación legítima del pool gracias al uso de las políticas de pool. Un minero legítimo podrá recuperarse rápidamente de este tipo de ataque, ya que puede modificar fácilmente su IP o cartera de forma local.
Esta tarea sería mucho más difícil para un programa de criptominería malicioso, ya que requeriría modificar todo el botnet. Sin embargo, en el caso de los mineros menos sofisticados, esta defensa podría desactivar completamente el botnet.
Conclusión de la serie
Esta publicación es la última de nuestra serie Anatomía de los programas de criptominería. Hemos tratado los aspectos básicos de la criptominería y explorado la mentalidad del atacante a través de la búsqueda de campañas activas que implementan diferentes topologías de minería.
Creemos que la amenaza de los programas de criptominería seguirá creciendo con el tiempo. Pero ahora podemos devolver el golpe e interrumpir las operaciones del atacante, haciendo que sea mucho más difícil rentabilizar eficazmente los programas de criptominería.