Win32/Sality es una familia de malware que ha estado utilizando una red de pares botnet al menos desde el año 2003. Es un código malicioso que infecta archivos y descarga troyanos; el propósito principal de esta última acción es el envío de spam, aunque se ha usado con distintos objetivos, como falsificar el tráfico de red de anuncios publicitarios, llevar a cabo ataques de denegación de servicio distribuido o descifrar las credenciales de cuentas de VoIP.
Todos los comandos y archivos intercambiados a través de la red P2P de Sality tienen firmas digitales, lo que lo hace resistente a la manipulación de protocolos. Su arquitectura modular, así como la longevidad de la botnet, demuestran una programación libre de fallas y un diseño de software eficiente.
Hemos estado rastreando la red Win32/Sality por bastante tiempo y encontramos más de 115.000 direcciones IP accesibles desde Internet mediante el uso de los llamados “super peers”, que mantienen la botnet con vida y propagan los comandos a los pares normales.
Notamos que se descargaban los mismos componentes año tras otro con pocos cambios en su conducta subyacente. Recientemente, apareció un nuevo componente con características novedosas: cuenta con la capacidad de cambiar la dirección DNS primaria del router para puertas de enlace residenciales de banda ancha, lo que difiere del típico ladrón de contraseñas FTP o del spambot desplegado por Win32/Sality.
Según nuestros datos telemétricos, este componente apareció por primera vez en octubre de 2013. Dr. Web fue el primero en discutirlo y publicó un análisis técnico de uno de sus componentes, el módulo de exploración de direcciones IP (en inglés). Lo llamaron Win32/RBrute.
Un nuevo objetivo: cambiar el DNS primario de un router
Esta funcionalidad añade una nueva dimensión a la operación Win32/Sality. El primer componente, detectado por ESET como Win32/RBrute.A, explora Internet en busca de páginas administradoras de routers con el propósito de cambiar la entrada correspondiente a su servidor DNS primario.
El falso servidor DNS redirige a los usuarios a una página falsificada para la instalación de Google Chrome cuando intentan resolver dominios que contienen las palabras “google” o “facebook”. El binario distribuido a través de esta página de instalación es en realidad Win32/Sality, y les suministra a los operadores de la botnet de Sality una manera de incrementar aún más su tamaño mediante la infección de los demás usuarios que se encuentren tras este router.
La dirección IP usada como el DNS primario en un router comprometido forma parte de la red de Win32/Sality. De hecho, Win32/Sality instala Win32/RBrute.B, en los equipos comprometidos; este puede actuar ya sea como un servidor proxy HTTP o DNS para entregar el programa falso de instalación de Google Chrome.
La operación
Win32/RBrute.A intenta encontrar las páginas de administración web para routers mediante la descarga y exploración de una lista de direcciones IP desde su servidor de comando y control y luego informa los resultados obtenidos. Al momento de nuestra investigación, estaba dirigido a los siguientes modelos:
• Los routers de Cisco con “level_15_” en el atributo HTTP
• D-Link DSL-2520U
• D-Link DSL-2542B
• D-Link DSL-2600U
• Huawei EchoLife
• TP-LINK
• TP-Link TD-8816
• TP-Link TD-8817
• TP-Link TD-8817 2.0
• TP-Link TD-8840T
• TP-Link TD-8840T 2.0
• TP-Link TD-W8101G
• TP-Link TD-W8151N
• TP-Link TD-W8901G
• TP-Link TD-W8901G 3.0
• TP-Link TD-W8901GB
• TP-Link TD-W8951ND
• TP-Link TD-W8961ND
• TP-Link TD-W8961ND
• ZTE ZXDSL 831CII
• ZTE ZXV10 W300
Si se encuentra una página Web, el centro de comando y control le envía al bot una lista corta de alrededor de diez contraseñas y le indica que lleve a cabo un ataque de fuerza bruta para descifrar contraseñas contra dicho router. Si el bot es capaz de iniciar la sesión en él, luego procederá a cambiar la configuración del servidor DNS primario del router. Es interesante notar que únicamente se usa el ataque por fuerza bruta para obtener acceso al portal de administración del router; no se utiliza ningún código malicioso del tipo exploit. La autenticación se realiza con los nombres de usuario “admin” y “support”, aunque las versiones anteriores también probaban con “root” y “Administrator”.
A continuación se muestra una lista de las contraseñas transmitidas desde el servidor de comando y control:
•<empty string>
• 111111
• 12345
• 123456
• 12345678
• abc123
• admin
• Administrator
• consumer
• dragon
• gizmodo
• iqrquksm
• letmein
• lifehack
• monkey
• password
• qwerty
• root
• soporteETB2006
• support
• tadpassword
• trustno1
• we0Qilhxtx4yLGZPhokY
En el caso de un inicio de sesión exitoso, el malware cambia el servidor DNS primario por uno falso, le informa al servidor de comando y control que la infección se realizó correctamente y continúa explorando la Internet.
Una vez que la dirección del DNS primario del router quedó comprometida, todas las solicitudes al DNS realizadas por los usuarios pasan a través del servidor DNS falso y se modifican para que conduzcan a la página falsa del programa de instalación Chrome cada vez que se resuelvan los dominios "facebook" o "google".
El siguiente ejemplo muestra una redirección exitosa para un dominio no registrado pero que contiene la palabra "google":
Esta operación se asemeja bastante al cambiador de DNS, que llevaba a los usuarios a instalar software falso para seguir propagando malware mediante un servicio de DNS falsificado.
Una vez que el equipo ejecuta el programa de instalación falso de Google Chrome y queda infectado, su servidor DNS primario cambia a "8.8.8.8” mediante la actualización de la siguiente llave de registro:
HKLM/SYSTEM/ControlSet001/Services/Tcpip/Parameters/Interfaces/{network interface UUID}/NameServer = “8.8.8.8”
Hay que tener en cuenta que la dirección IP “8.8.8.8″ corresponde al DNS público de Google, un servicio de nombres de dominio legítimo operado por Google, que no tiene que ver con Win32/RBrute.
Como las PC infectadas no seguirán usando el servidor DNS del router, ya no se verán afectadas por sus redirecciones falsas. Por otra parte, el router sigue infectado y molestará a cada equipo en su intento de resolver dominios "facebook" o "google" a través de su servicio de DNS hasta que también se infecten con Win32/Sality. Esta táctica dista mucho de ser furtiva, y de hecho intenta ganar por cansancio al usuario para infectar su sistema o simplemente falsificar esos dominios en los sistemas operativos a los que no está dirigido (por ejemplo, Linux).
Actualmente, parece ser que el único propósito de esta operación es aumentar el tamaño de la red botnet de Sality.
Análisis técnico
El componente modificador de DNS de Win32/Sality está conformado por dos binarios: un módulo de exploración de routers y un servidor DNS / HTTP. Win32/Sality instala ambos programas maliciosos.
Binario para la exploración de routers: Win32/RBrute.A
Al comienzo de la ejecución, el malware crea un mutex con el nombre “19867861872901047sdf” para evitar ejecutar varias instancias.
Luego verifica a cada minuto una dirección IP codificada de forma rígida para buscar un comando; dicho comando puede ser un pedido de exploración o una solicitud para intentar iniciar la sesión en una dirección IP con el objetivo de modificar el DNS primario.
El pedido de exploración incluye una dirección IP para dar inicio a la lista de números de direcciones que se van a probar. Win32/RBrute.A intentará llevar a cabo una solicitud HTTP GET en TCP/80, con la esperanza de recibir un mensaje Error de HTTP 401 – No autorizado. El modelo del router se extrae del atributo de los esquemas de autenticación HTTP. Si se encuentra uno de los routers deseados, el malware envía su dirección IP al comando y control.
El siguiente es un diagrama de flujo de Win32/RBrute.A:
Posteriormente, el comando y control emitirá una solicitud para iniciar la sesión en el router con la contraseña provista. Si el inicio de sesión se realiza con éxito, el servidor DNS primario del router se cambia por un host donde se ejecuta el malware Win32/RBrute.B.
Binario para el servidor DNS y HTTP: Win32/RBrute.B
Este componente está conformado por tres partes: el subproceso de control, el subproceso del servidor DNS y el subproceso del servidor HTTP.
A pesar de que tanto el subproceso del servidor DNS como el de HTTP pueden utilizarse al mismo tiempo, el malware elegirá, según un valor aleatorio, si va a ser un servidor DNS o HTTP. Una constante de la fórmula asegura que 80% de las infecciones actuarán como servidores DNS, aunque a principios de la operación la constante estaba establecida en 50%.
La siguiente captura muestra la elección aleatoria del subproceso del servidor DNS o HTTP:
Si el subproceso del servidor elegido no arranca, el malware recurre al otro modo, como se ve en la siguiente captura:
Asimismo, el operador también puede forzar el inicio de un subproceso mediante el envío de una solicitud DNS o HTTP especialmente diseñada. Un mutex con el nombre “SKK29MXAD” asegura que se ejecute una sola instancia en el host.
Subproceso de control
El subproceso de control se usa para informar los resultados al comando y control, y reconfigurar la instancia del servidor.
Cada dos minutos, el malware envía un paquete a una dirección IP preestablecida con información sobre el equipo en el que se está ejecutando. El comando y control luego responde con una dirección IP que se usará para entregar el programa de instalación infectado de Chrome.
Si el malware está en modo DNS, la dirección IP servida por el C&C será la de un servidor HTTP falso instalado en un equipo infectado con Sality. En el otro caso, el C&C enviará la dirección IP de un servidor fuera de la red de pares P2P de Sality, la cual estará sirviendo la página de instalación falsa de Chrome.
A continuación se muestra una lista de la información del host enviada por el subproceso de control al C&C.
- Nombre del equipo: GetComputerName()
- Hora local: GetLocalTime()
- País: GetLocaleInfoA()
- Directorio de Windows: GetWindowsDirectoryA()
- Nombre del producto Windows: de la llave de registro "KEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows NT/CurrentVersion/Product Name“
- Nombres de la CPU: de la llave de registro
“HKEY_LOCAL_MACHINE/HARDWARE/DESCRIPTION/System/CentralProcessor/<CPU #>/ProcessorNameString“ - Estadísticas de memoria: GetMemoryStatusEx()
- Resultado de IsDebuggerPresent()
- Uso de memoria por el malware: GetProcessMemoryInfo()
- Tiempo activo del malware: en minutos
- Cantidad de subprocesos en uso
El paquete de información tiene el siguiente formato:
La siguiente captura de pantalla muestra el paquete de información enviado al C&C:
En azul está la suma de comprobación de carga; en rojo la longitud de carga; en negro el modo de servidor cifrado; y en verde la información del host cifrada.
La información sobre el host (en verde en el ejemplo anterior) es la siguiente cadena de texto cifrada con RC4:
9BC13555|24.03.2014 21:56:27|United States|C:\WINDOWS|Microsoft Windows XP|proc#0 QEMU Virtual CPU version 1.0|1|358|511|1117|1246|0|2|0|0|
El C&C luego responderá con un paquete con el servicio de dirección IP a utilizar:
Subproceso del servidor DNS
El servidor DNS busca solicitudes que contienen la palabra "google" o "facebook" en el nombre de dominio. Si encuentra una, la respuesta del DNS que enviará contendrá la dirección IP de un servidor de Win32/RBrute.B de la red de Sality. Si la búsqueda no contiene “facebook” ni “google”, retransmitirá la búsqueda a los servidores DNS de Google (“8.8.8.8” o “8.8.4.4”) y reenviará la respuesta al cliente.
El envío de un paquete al servidor mediante el puerto UDP/53 con “0xCAFEBABE” como carga establecerá el indicador “udme” en la llave de registro de Windows “HKEY_CURRENT_USER/SOFTWARE/Fihd4“. Este indicador asegura que el subproceso del servidor DNS se iniciará en el próximo reinicio del sistema, anulando los procesos aleatorios. El servidor responderá “0xDEADCODE” para confirmar el comando.
Subproceso del servidor HTTP
Cuando se recibe una solicitud de un usuario que fue redirigido, el subproceso del servidor HTTP buscará primero en el agente de usuario del navegador y como consecuencia tendrá una conducta distinta.
Si el agente de usuario contiene “linux” o “playstation”, el servidor cancelará la conexión sin ningún aviso. Si el agente de usuario hace referencia a un móvil que coincide con una de las siguientes palabras: “android”, “tablet”, “Windows CE”, “blackberry” u “opera mini”, el servidor servirá el malware Win32/Sality 5% de las veces a pesar de que se trata de agentes de usuario de dispositivos móviles; de lo contrario, se cancela la solicitud. Finalmente, si el agente de usuario contiene “opera”, “firefox”, “chrome”, “msie” o cualquier otra palabra, se entregará Win32/Sality al usuario.
El agente de usuario afectará el puerto en el que se haga la búsqueda en el servidor HTTP falso que distribuye el malware.
Todas las solicitudes HTTP GET enviadas a estos puertos atenderán la página de instalación falsa de Chrome, incluso si el usuario está navegando con él.
En forma similar al subproceso del servidor DNS, el botmaster puede afectar el comportamiento del servidor HTTP mediante el envío de un paquete HTTP especialmente diseñado. Concretamente, el envío de una solicitud GET o POST con el agente de usuario “BlackBerry9000/5.0.0.93 Profile/MIDP-2.0 Configuration/CLDC-2.1 VendorID/831” establecerá el indicador “htme” en la llave de registro “HKEY_CURRENT_USER/SOFTWARE/Fihd4“, asegurando en forma efectiva que el malware iniciará el subproceso del servidor HTTP cuando se reinicie el sistema, anulando los procesos aleatorios.
El servidor enviará “<html>kenji oke</html>” para confirmar la correcta ejecución de la tarea.
El servidor HTTP también incluye una lista de los archivos permitidos que debe servir. Si un navegador hace una búsqueda HTTP con un dominio “google” o “facebook” para un archivo que no está en la lista, el servidor responderá con un HTTP 200 OK, con la siguiente carga:
<html><meta http-equiv=”refresh” content=”0; url=/”></html>
Y redirigirá al navegador a la página inicial, de modo que asimismo servirá la página de instalación falsa de Chrome. Por ejemplo, si el usuario busca “http://google.com/no-existe” y “no-existe” no está en la lista de archivos permitidos, el usuario será redirigido a “http://google.com” en vez de a la típica pantalla de error HTTP 404.
También debemos tener en cuenta que cada búsqueda HTTP GET realizada en el servidor HTTP que contenga la cadena “.exe” será redirigida al servidor HTTP falso, sin importar cuál sea la lista de archivos permitidos. El servidor falso siempre responderá con un binario infectado.
Similitudes con otros componentes de Sality
Basándonos en las siguientes observaciones, creemos que el componente infeccioso del archivo principal así como los componentes descritos previamente fueron desarrollados por el mismo grupo de personas. Al analizar cada uno de los componentes binarios, notamos que todos comparten los mismos detalles técnicos y el mismo estilo de código.
No requieren persistencia
Ninguno de los componentes instalados por Sality, incluyendo los mencionados arriba, requieren una forma de ser persistentes tras los reinicios del sistema, aunque algunos módulos pueden almacenar la configuración en el registro. Siempre son descargados e iniciados por la capa persistente: el componente infeccioso del archivo.
Inicialización del búfer
Los operadores suelen inicializar el búfer con el valor "0". El compilador “visual-c++” no optimiza el siguiente fragmento de código C cuando los operadores compilan un software:
char buf[4096] = {0};
El fragmento se compila en el código mostrado en la siguiente captura de pantalla:
Este fragmento de ensamblado puede encontrarse en cada componente instalado por Win32/Sality.
Evasión del firewall
Todos los componentes que necesitan recibir conexiones de Internet comparten el mismo código para agregar una regla específica en el Firewall de Windows para autorizar el ingreso de las solicitudes entrantes. Agregará el valor “[nombre del archivo de malware]:*:Enabled:ipsec” a la siguiente llave de registro “HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/SharedAccess/Parameters/FirewallPolicy/StandardProfile/AuthorizedApplications/List” para alcanzar su objetivo.
La siguiente captura de pantalla muestra un subgrupo de la función “add_to_firewall_exception()”:
En Win32/RBrute.B, esta función se llama al comienzo de la ejecución del malware:
Puede encontrarse lo mismo en el componente spambot de Win32/Sality:
Estadísticas de la infección
Nuestros datos muestran que las detecciones de Win32/Sality actualmente están disminuyendo, o al menos se mantienen estables desde 2012. Creemos que la menor cantidad de detecciones se debe a la eficiencia reducida de los vectores de infección actuales. Esto podría explicar por qué los operadores están buscando nuevas maneras de propagar la familia de malware.
El siguiente gráfico muestra las detecciones a nivel global de Win32/Sality.
Si observamos las detecciones correspondientes al año pasado, podemos ver un pequeño incremento cerca de diciembre de 2013, que coincide con la fecha de lanzamiento in the wild del componente modificador de DNS, aunque dichos números deberían tomarse entre comillas, ya que existen otros factores que podrían contribuir a las variaciones en la propagación; por ejemplo, que lo esté distribuyendo otra botnet.
No estamos seguros de la efectividad de la operación del modificador de DNS del router de Win32/Sality, ya que muchos portales de configuración escuchan solamente en los espacios de direcciones privadas (por ejemplo, 192.168.0.0/16), lo que los hace inaccesibles desde Internet. Además, el ataque de fuerza bruta para descifrar contraseñas llevado a cabo contra el router no es demasiado agresivo: sólo prueba una lista de alrededor de diez contraseñas.
Conclusión
Es posible que los vectores normales de infección de Win32/Sality no sean suficientes para mantener viva la botnet, por lo cual sus controladores están desplegando nuevos componentes para hacerla crecer. El secuestro del DNS en routers es bastante efectivo si se hace en forma correcta. Puede alcanzar a muchísimos usuarios tras un solo equipo, en especial en puntos de acceso público.
Como normalmente no están protegidos por soluciones de seguridad, suministran un entorno sin restricciones donde los atacantes prueban diversas técnicas para robar la información de los usuarios. Una tecnología existente que podría solucionar el problema es DNSSEC, dado que la respuesta a una solicitud DNS cuenta con una firma cifrada y por lo tanto no es propensa a su falsificación.
Una buena práctica de seguridad que reduciría el alcance del problema es cambiar la contraseña predeterminada en la interfaz Web del router.
Archivo analizado
Los siguientes son los Hashes SHA-1 de los archivos observados durante el monitoreo que hicimos del malware Win32/RBrute.
Win32/RBrute.A
8f4e43675948e806d99125e916191e04f8840b46
f8031d843626ac198a6f3c056f57098012e178e2
21649df3044f2203403a855108c1db1d95a2ab46
Win32/RBrute.B
5d1263c1c707ce163c9b36452dcb7340a7fd8909
73e2fe07a3f875521b5bfe8c3dd8fd6b6819c8f8
Traducción del post de Benjamin Vanheuverzwijn en We Live Security.
