Identificar una botnet, o red zombi, a veces puede resultar difícil, especialmente cuando uno se pierde entre distintos componentes como los droppers, infectadores y otros de la misma calaña. Hace un par de semanas, Jose Nazario de Arbor Networksme mostraba un nuevo rufián que parecía ser otro bot peer-to-peer que al ejecutarse instalaba un gran volumen de programas con muchas sorpresas, como por ejemplo:
- Un programa ejecutable oculto en un Flujo alternativo de datos.
- Tres explotadores de Bitcoin: Ufasoft miner, the RCP miner y Phoenix miner
- Un archivo con información de geo-posicionamiento para rangos de direcciones IP.
Sin embargo, por el momento los dejaremos de lado y nos concentraremos en la arquitectura de la red zombi, que es en realidad sólo un canal para inyectar software en equipos infectados. Tras analizar los programas instalados finalmente apareció el bot mismo, que lo detectamos como Trojan.Win32.Miner.h. El binario cuenta con algunos niveles de ofuscación que dificultan el análisis, pero al final escribe un paquete ejecutable UPX en una sección de memoria desde la cual se puede restaurar el binario original.
Una de las primeras cosas que llamó nuestra atención es una lista de 1.953 hilos de direcciones IP de sólida codificación que están incluidos en el binario. El bot se pone en contacto con estas direcciones durante la fase de arranque del sistema para ingresar a la red peer-to-peer.
Para verificar si un anfitrión es realmente parte de la red zombi, primero se lo prueba en el puerto 62999/tcp. Posteriormente, toda consiguiente comunicación con el anfitrión se realiza a través de conexiones HTTP por el puerto 8080/tcp. Si un bot pretende recibir información desde la red zombi, envía una petición GET para la URL /search=[resource] a otro peer (ver la parte en rojo abajo). La respuesta (en azul) contiene la información solicitada. En el siguiente ejemplo, el bot pregunta si existe un archivo llamado ip_list_2:
GET /search=ip_list_2.txt HTTP/1.1
Connection: close
Host: 67.230.63.171
HTTP/1.1 200 OK
Server: nginx
Date: Thu, 28 Jul 2011 1:46:30 PM GMT
Content-Type: application/octet-stream
Content-Length: 36
Last-Modified: Thu, 28 Jul 2011 1:46:30 PM GMT
Connection: close
Expires: Thu, 28 Jul 2011 1:46:30 PM GMT
Cache-Control: no-cache
Accept-Ranges: bytes
0|8E2105CC235624452CF4CA5ED5880636
El peer remoto confirma la existencia del archivo respondiendo con un mensaje MD5 de control de su contenido. Un archivo no existente u otra petición inválida estaría indicada en el hilo null. Para descargar el archivo requerido, el sufijo .txt desaparece en la solicitud:
GET /search=ip_list_2 HTTP/1.1
Connection: close
Host: 67.230.63.171
HTTP/1.1 200 OK
Server: nginx
Date: Thu, 28 Jul 2011 1:46:32 PM GMT
Content-Type: application/octet-stream
Content-Length: 11107
Last-Modified: Thu, 28 Jul 2011 1:46:32 PM GMT
Connection: close
Expires: Thu, 28 Jul 2011 1:46:32 PM GMT
Cache-Control: no-cache
Accept-Ranges: bytes
86.121.101.197
194.44.169.112
77.123.56.166
65.75.122.227
79.115.121.40
89.208.252.138
213.135.179.130
31.43.66.129
67.230.65.87
94.76.96.80
...
La respuesta contiene una lista de direcciones IP que pertenecen a otros peers de la red zombi. Esta información es suficiente para enumerar repetidamente la red peer-to-peer, o al menos la parte de esta que vive de direcciones IP públicas. Exploramos una parte de la red y registramos las direcciones IP que obtuvimos. Un gráfico del resultado de los datos obtenidos muestra una red altamente interconectada. El gráfico se expande muy rápidamente y ya no puede mostrar resultados en un tiempo razonable, por lo que suspendimos nuestra exploración tras unos cuantos segundos. Como resultado, algunos nodos conectan a “callejones sin salida”, es decir, peers a los que no se les hizo un mayor seguimiento.
Existen tres listas separadas de anfitriones: ip_list, ip_list_2 y ip_list_3: Sin embargo, durante las pruebas que realizamos, la última lista siempre aparecía vacía. Una exploración de siete horas realizada en las redes correspondientes a las primeras dos listas arrojó 9.141 anfitriones para ip_list y 28.675 anfitriones para ip_list_2, con sólo 57 anfitriones que comparten ambas listas y un total de casi 38.000 distintas direcciones IP públicas. Tomando en cuenta que hoy en día la mayoría de los equipos están tras la Traducción de direcciones de red o de alguna pasarela, el número real de equipos infectados puede fácilmente ser muchísimo mayor.
Un bot puede recuperar su dirección IP de acceso a Internet a través de /search=get_my_ip y verificar si se puede acceder desde el exterior con /search=listen_test. Otro elemento interesante es la petición de /search=soft_list, una lista de ejecutables:
GET /search=soft_list HTTP/1.1
Connection: close
Host: 91.124.141.114
HTTP/1.1 200 OK
Server: nginx
Date: Thu, 28 Jul 2011 21:54:04 GMT
Content-Type: application/octet-stream
Content-Length: 1235
Last-Modified: Thu, 28 Jul 2011 21:54:04 GMT
Connection: close
Expires: Thu, 28 Jul 2011 21:54:04 GMT
Cache-Control: no-cache
Accept-Ranges: bytes
1881|37055143655159895100072920
1864|74659789337208584676889842
1861|50130190106950587675951378
1859|17628191893358990544434624
1855|70418953044346961647340893
1816|63902848972275419049312273
1714|71450190375046068004318922
873|450976523626203858415918223
Esta lista contiene una cantidad de archivos que el bot descarga desde la red peer-to-peer para luego ejecutarlos. Una vez más, los solicita enviando el nombre del archivo como un parámetro para una petición /search=. Cada archivo tiene una identificación única, que es el número que aparece antes del primer guión. La cadena numérica en el siguiente campo se ha acortado en el ejemplo de arriba para que pueda leerse mejor. Aún se desconoce su objetivo. Los nuevos archivos parecen tener una identificación con números mayores. Por ejemplo, los archivos client_3.exe, client_4.exe, client_6.exe y client_7.exe, que no aparecen en la lista de software pero que están disponibles para descargar, tienen una identificación con números ascendentes:
- client_3.exe: 1555
- client_4.exe: 1596
- client_6.exe: 1607
- client_7.exe: 1611
- client_8.exe: 1864
Es fácil verificar si se está propagando nuevo software en la red zombi: sólo hay que descargar la lista de software y buscar nuevas identificaciones. Seguiremos haciéndolo y añadiendo firmas de nuevos elementos dañinos a nuestra detección a medida que vayan apareciendo.
Botnet Miner: La explotación de Bitcoin en redes Peer-To-Peer