Sistema Big Data: el inquilino wipefs
Los sistemas Big Data son sistemas con mucha capacidad de proceso lo que los hace muy útiles para ser utilizados por los hackers como máquinas que trabajen para ellos. Ese ha sido nuestro caso y tras analizar el sistema creemos que está siendo utilizado para trabajar en la minería de criptomonedas
Introducción a la minería de criptomonedas
Según la wikipedia: “En los sistemas de criptomonedas, se garantiza la seguridad, integridad y equilibrio de sus estados de cuentas (contabilidad) por medio de un entramado de agentes (transferencia de archivo segmentada o transferencia de archivo multifuente) que se verifican (desconfían) mutuamente llamados mineros, que son, en su mayoría, público en general y protegen activamente la red (el entramado) al mantener una alta tasa de procesamiento de algoritmos, con la finalidad de tener la oportunidad de recibir una pequeña propina, que se reparte de manera aleatoria”
En cuanto a la minería, según bitcoin : “El objetivo principal de la minería es llegar a un consenso entre los nodos de la red en los que las transacciones consideran legítimos”, y “minar es el proceso de agregar registros de transacción al libro de contabilidad de bitcoin sobre transacciones pasadas”
Detectando el problema
Cuando empezamos a plantearnos la métricas observamos que el sistema tenía las CPU al 36%, cuando todavía no le hemos cargado ni los datos de prueba por lo que teníamos un problema
Tras monitorizar el estado de cada uno de los servidores encontramos que, mientras el resto de servidores estaba en reposo, el bigdata1 estaba trabajando a más del 75% por lo que nos centramos en él
Analizamos los procesos que se están ejecutando y vemos que wipefs estaba usando la CPU en más de 500% así que hay está el virus. Decir que aunque lo matamos con kill, al de un tiempo se volvía a poner marcha y el sistema volvía a estar igual
En el siguiente link podéis ampliar la información sobre el problema
https://id.eas.agency/tag/wipefs/
Auditoria
Llegados a este punto decidimos hacer una “auditoría” con los alumnos (en la medida de nuestros conocimientos) con idea de ver hasta donde estaba infectado nuestro equipo y que estaba haciendo
Qué hizo en el servidor
Vemos que se habían modificado varios archivos importantes, entre ellos /etc/init.d/rc.local
Al mirar el contenido de rc.local encontramos una llamada a DDoSCliente, probablemente el programa utilizado para provocar una denegación de servicio o DoS
Probamos el servicio DNS haciendo ping a una página conocida y nos devolvía IP erróneas por lo que deducimos que también ha sido atacado
Como trabaja
Finalmente, con la ayuda un Hub, y utilizando WireShark monitorizamos las conexiones a Internet y detectamos que se comunica principalmente con tres IPs:
- IP= 94.130.206.79
Internet Protocol Version 4, Src: 192.168.123.210, Dst: 94.130.206.79
Transmission Control Protocol, Src Port: 45352, Dst Port: 80, Seq: 0, Len: 0
Buscando en internet vemos que es de Alemania: Hetzner Online GmbH
- IP=163.17.30.212
Internet Protocol Version 4, Src: 192.168.123.210, Dst: 163.17.30.212
Transmission Control Protocol, Src Port: 42324, Dst Port: 8525, Seq: 0, Len: 0
Que es de Taiwan: Taiwan Academic Network (TANet) Information Center
- IP= 124.251.33.242
Internet Protocol Version 4, Src: 192.168.123.210, Dst: 124.251.33.242
Transmission Control Protocol, Src Port: 44342, Dst Port: 3027, Seq: 0, Len: 0
Buscando con whois vemos que pertenece a China
% [whois.apnic.net] % Whois data copyright terms https://www.apnic.net/db/dbcopyright.html % Information related to ‘124.251.0.0 – 124.251.255.255’ % Abuse contact for ‘124.251.0.0 – 124.251.255.255’ is ‘ipas@cnnic.cn’ inetnum: 124.251.0.0 – 124.251.255.255 netname: CHINA-21VIANET descr: 21ViaNet(China),Inc. descr: BOE Science Park, 10 Jiuxianqiao Road, Chaoyang, descr: Beijing 100016, China
Preguntando a gente entendida nos han dicho que en la minería se suele usar unas conexiones para enviar y recibir datos de la máquina y otras para monetizar el trabajo
Cuarentena
Y hasta aquí llegamos. Dado que no es un sistema en producción, para recuperar el sistema hemos optado por volver a instalar todo de nuevo y hemos dejado el bigdata1 apagado y desconectado del resto del sistema con idea de poder profundizar un poco más