Primer contacto del mas allá
No pasó mucho tiempo hasta que alguien del país de la gran muralla diera con el password de mi usuario ubuntu. Para ser mas preciso luego de 56 intentos a las 06:40 del 21 de Julio don 106.2.197.34 dió con el password correcto.
Al parecer esta IP está hosteando un sitio web que por las imágenes (porque no entiendo nada) me da a pensar que se trata de un sitio de cambio de monedas.
Luego de haber encontrado el password la IP dejó de insistir y no pasó a mayores. Esto último me da a pensar que podría ser un sistema infectado a los efectos de encontrar y recolectar usuarios/passwords de otros sistemas, probablemente parte de una botnet. En particular esta nueva IP siguió el mismo diccionario que las IPs (108.51.89.92, 180.250.223.10 y 77.222.137.46) mencionadas en Una instancia a la deriva I.
Pasó un día y no hubo novedades, al punto que supuse que había hecho algo mal.
Guess who's back!
Ayer por la mañana mientras desayunaba y leía los mails me encontré con esto
Lo primero que pensé fue "Que! casualidad dos IPs diferentes adivinaron el password del usuario ubuntu al mismo tiempo!" No tenía ganas de husmear demasiado en ese momento para que no se me hiciera tarde, pero no me resistí a logearme en la instancia para ver qué habían hecho y...
juan@moon:~/Escritorio/SH$ ssh root@52.6.74.XXX
ssh: connect to host 52.6.74.XXX port 22: Connection timed out
juan@moon:~/Escritorio/SH$
booom! La instancia estaba inaccesible! A este punto ya era irresistible y abrí la consola de AWS, para encontrarme con la siguiente imagen
La instancia se apagó por si sola. Esto era lo que debía pasar en caso de que se detuviera el proceso que capturaba el tráfico de red que entraba y salía de la instancia o por ejemplo en caso de que se diera una condición desfavorable para audit (como disco lleno...).
Desde la misma consola controlé el uso de recursos para ver si encontraba algo interesante
se puede ver claramente como poco antes de las 02:30 algo se desencadenó dentro de la instancia que incrementó el trafico de red en ambos sentidos. Si vemos el mismo período, pero en este caso las estadísticas del volumen se puede apreciar un incremento en todas las operaciones
Un comportamiento análogo se puede ver también en la utilización de CPU
Sea lo que sea que pasó, comenzó poco antes de las 02:30 y terminó tempestivamente poco después de las 04:30. Por último pegué una mirada a los console logs para ver si había algo interesante y...
A las 04:40 del 23 de Julio se inició un shutdown. Esto me dio a entender que posiblemente pudieron matar el proceso tcpdump que corría como root (oO) y cuando el cronjob detectó que tcpdump ya no corría mandó a apagar el sistema a las 04:40.
En este punto terminé el desayuno y partí a mis obligaciones xD.
Antes de abrir la caja de pandora
Antes de ir directamente a analizar el volumen raíz de la instancia o siquiera volver a prenderla vamos a mirar qué información se pudo obtener desde las capturas de tráfico y los logs.
Desde los logs de audit que se enviaban por mail
El último archivo de logs de auditd fue enviado por mail a las 02:00 del 23 de Julio, una hora y media antes del acceso (en principio absolutamente inútil). Sumado a eso por algún motivo el archivo contiene el siguiente time frame de logs
root@moon:/home/juan/Escritorio/SH/logs/audit# aureport -t -if audit.log.1
Log Time Range Report
=====================
audit.log.1: 19/07/15 20:13:01.249 - 21/07/15 07:35:55.417
root@moon:/home/juan/Escritorio/SH/logs/audit#
más inútil todavía. Al parecer cometí un error leyendo la documentación y estuve mandando por correo el mismo archivo cada 2hs, en lugar de mandar el archivo con los últimos logs... shit happens.
Desde las capturas de tráfico con tcpdump
La salvación debería estar en las capturas!! Viendo los mails, a las 02:32 del 23 de Julio se subió la captura número 104 (la captura previa, la 103, se había subido a las 17:05 del día anterior, 22 de Julio) y a partir de allí comenzaron a generarse capturas de manera increíble hasta que a las 04:36 se subí la última, la número 1099!!! Es decir que en 2 horas se generaron al menos 995 capturas de 5 MB (~5GB), esto me hace pensar que es poco probable que se haya llenado el disco de la instancia ya que si no me equivoco quedaba mas espacio libre.
Lamentablemente por el número de capturas generadas, y consecuentemente la cantidad de mails enviados, muchas de ellas fueron rebotadas por los mecanismos de google anti spam.
A pesar de que muchas no llegaron a ser enviadas a la cuenta, es probable que aún se encuentren en el volumen de la instancia.
En la cuenta de correo se puede esto por el orden en que llegaron los correos:
File sample104 Thu Jul 23 02:32:31 UTC 2015
File sample106 Thu Jul 23 02:35:29 UTC 2015
File sample129 Thu Jul 23 02:43:26 UTC 2015
File sample111 Thu Jul 23 02:37:39 UTC 2015
File sample108 Thu Jul 23 02:36:26 UTC 2015
File sample157 Thu Jul 23 02:50:11 UTC 2015
el 105 que posiblemente sería el mas interesante nunca llegó. La captura 108 llegó después que la 129 que llegó antes que la 111 xD, en fin...
Un análisis simple de las capturas 103, 104, 106 y 108 muestra que la IP 54.196.232.229 actuó entre las 17:05 del 22 de Julio (fin captura 103) y antes de las 02:35 del 23 de Julio (fin captura 106). Esto comprende las capturas 104 y 105, no hay rastros de dicha IP en la captura 106 ni en la 108.
juan@moon:~/Escritorio/SH/traffic captures/root$ tcpdump -r sample103 host 54.196.232.229 | wc -l
reading from file sample103, link-type EN10MB (Ethernet)
0
juan@moon:~/Escritorio/SH/traffic captures/root$ tcpdump -r sample104 host 54.196.232.229 | wc -l
reading from file sample104, link-type EN10MB (Ethernet)
339
juan@moon:~/Escritorio/SH/traffic captures/root$ tcpdump -r sample106 host 54.196.232.229 | wc -l
reading from file sample106, link-type EN10MB (Ethernet)
0
juan@moon:~/Escritorio/SH/traffic captures/root$ tcpdump -r sample108 host 54.196.232.229 | wc -l
reading from file sample108, link-type EN10MB (Ethernet)
0
juan@moon:~/Escritorio/SH/traffic captures/root$
Dado que los logs de ese día no fueron enviados por correo, tampoco fueron cargados en la BD así que aún no puedo saber cuantos intentos fallidos se realizaron.
Misteriosamente no hay rastos de la IP 59.188.237.12 en ninguna de las capturas anteriores...
juan@moon:~/Escritorio/SH/traffic captures/root$ tcpdump -r sample103 host 59.188.237.12 | wc -l
reading from file sample103, link-type EN10MB (Ethernet)
0
juan@moon:~/Escritorio/SH/traffic captures/root$ tcpdump -r sample104 host 59.188.237.12 | wc -l
reading from file sample104, link-type EN10MB (Ethernet)
0
juan@moon:~/Escritorio/SH/traffic captures/root$ tcpdump -r sample106 host 59.188.237.12 | wc -l
reading from file sample106, link-type EN10MB (Ethernet)
0
juan@moon:~/Escritorio/SH/traffic captures/root$ tcpdump -r sample108 host 59.188.237.12 | wc -l
reading from file sample108, link-type EN10MB (Ethernet)
0
juan@moon:~/Escritorio/SH/traffic captures/root$
esto podría indicar que dicha IP tuvo intervención durante la captura 105 (entre las 02:32:31 y las 02:35:29) y fue lo suficientemente breve como para no aparecer en la 106.
Viendo las capturas con wireshark con un poco de paciencia noté que en la captura 106 parecía haber conexiones SSH iniciadas desde la instancia hacia un número razonable de IPs. Aca va un ejemplo:
Ahora era mi instancia la que se encontraba disparando al mundo conexiones SSH utilizando el cliente libssh-0.5.2 !!! Para que se den una idea, miren esto
juan@moon:~/Escritorio/SH/traffic captures/root$ tcpdump -n -r sample103 src host 172.31.54.250 and "tcp[13] & 2 != 0" and "tcp[13] & 16 == 0"| wc -l
reading from file sample103, link-type EN10MB (Ethernet)
0
juan@moon:~/Escritorio/SH/traffic captures/root$ tcpdump -n -r sample104 src host 172.31.54.250 and "tcp[13] & 2 != 0" and "tcp[13] & 16 == 0"| wc -l
reading from file sample104, link-type EN10MB (Ethernet)
0
juan@moon:~/Escritorio/SH/traffic captures/root$ tcpdump -n -r sample106 src host 172.31.54.250 and "tcp[13] & 2 != 0" and "tcp[13] & 16 == 0"| wc -l
reading from file sample106, link-type EN10MB (Ethernet)
28457
juan@moon:~/Escritorio/SH/traffic captures/root$ tcpdump -n -r sample108 src host 172.31.54.250 and "tcp[13] & 2 != 0" and "tcp[13] & 16 == 0"| wc -l
reading from file sample108, link-type EN10MB (Ethernet)
22196
juan@moon:~/Escritorio/SH/traffic captures/root$ tcpdump -n -r sample111 src host 172.31.54.250 and "tcp[13] & 2 != 0" and "tcp[13] & 16 == 0"| wc -l
reading from file sample111, link-type EN10MB (Ethernet)
19930
juan@moon:~/Escritorio/SH/traffic captures/root$
Las capturas 103 y 104 no registraron conexiones SSH iniciadas desde la instancia, sin embargo las capturas 106, 108 y 111 registraron y MUCHAS.
En este punto parece que el acceso se produjo entre las capturas 104 y 105 y que la infección y ejecución del software malicioso se podría haber producido durante la captura 105, dado que en la 106 ya se registra el comportamiento anómalo.
La primer hipótesis es que la IP 54.196.232.229 (USA) dio con la clave en el lapso de las capturas 104 y 105, para que luego la IP 59.188.237.12 (HNK) se encargue de la infección durante lo que fue la captura 105. Una vez infectado el sistema no se registraron mas contactos de ninguna de estas dos direcciones.
Pensamientos en el aire...
- 54.196.232.229 parece ser un sistema infectado comportándose como se comportó mi instancia. De hecho, sin hacer demasiado escándalo, es otra instancia en EC2.
- 59.188.237.12 podría ser el nodo recolector de las tuplas usuario,password,ip para proceder a infectar.
No hay comentarios:
Publicar un comentario