Análise ao novo componente do Win32/Sality que altera o DNS primário dos Routers

O Win32/Sality é uma família de malware que tem vindo a utilizar uma botnet peer-to-peer, pelo menos desde 2003. Infecta ficheiros e descarrega troianos, sendo que estes últimos são utilizados principalmente para enviar spam, embora já tenham sido usados em diferentes fins, tais como publicidade falsa, distribuição de ataques Denial of Service ou invasão de contas VoIP. Todos os comandos e ficheiros trocados através da rede P2P do Sality são assinados digitalmente, tornando-os resistentes à manipulação de protocolo. A sua arquitetura modular e a longevidade da botnet revelam boas práticas de programação e um projeto de software eficiente.

Temos seguido a rede Win32/Sality há já algum tempo e observámos mais de 115.000 endereços IP acessíveis a partir da Internet. Esses peers são chamados de “super peers”, uma vez que mantêm a botnet viva e propagam os commandos para as redes peer to peer comuns.

Importa salientar que temos visto também os mesmos componentes a serem descarregados ao longo dos anos, com poucas alterações ao seu comportamento. Porém, mais recentemente, tem vindo a surgir um novo componente que se destaca pelas suas características únicas, nomeadamente, pela capacidade de alterar o endereço de DNS primário do gateway do router de banda larga residencial, o que difere do habitual “ladrão” de palavras-passe FTP ou do spambot implantado pelo Win32/Sality. De acordo com os nossos dados de telemetria, este componente surgiu pela primeira vez no final de Outubro de 2013 e foi o primeiro a ser discutido publicamente pelo Dr. Web, que publicou uma análise técnica a um componente, o scanner de IP que foi chamado de Nomearam-Win32/RBrute.

Um novo propósito: mudar o DNS do Router

Esta funcionalidade adiciona uma nova dimensão à operação Win32/Sality. O primeiro componente, detectado pela ESET como Win32/RBrute.A, analisa a Internet em busca de páginas de administração dos routers, de modo a alterar os dados alusivos ao servidor primário de DNS. O servidor DNS falso redirecciona os utilizadores para uma página de instalação do Google Chrome (versão falsa e manipulada) sempre que o router tenta resolver os domínios que contêm as palavras “google” ou “facebook”. O binário distribuído através desta página de instalação é o próprio Win32/Sality, fornecendo uma forma de os operadores da botnet Sality aumentarem ainda mais a sua dimensão, através da infecção dos utilizadores que estão ligados ao router.

O endereço de IP utilizado como DNS primário do router comprometido, é parte da rede do Win32/Sality. De facto, outro malware, detectado pela ESET como Win32/RBrute.B, é instalado pelo Win32/Sality em computadores comprometidos e pode actuar como um DNS, ou como um servidor de proxy HTTP para disponibilizar o falso instalador do Google Chrome.

A operação

Longe de ser uma nova técnica, a alteração do DNS primário num router é algo muito utilizado actualmente, sendo utilizada para o roubo de credenciais bancárias ou para bloquear a comunicação com os sistema de segurança.

O Win32/RBrute.A tenta encontrar as páginas administração via web dos routers, descarregando uma lista de endereços IP do servidor C&C e analisando e reportando, de seguida, as conclusões. A nossa investigação concluiu que os principais routers na mira Win32/RBrute.A são os seguintes:

  • Routers Cisco com “level_15_” no 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

Se for encontrada uma página de administração via web, o C&C envia uma pequena lista de cerca de dez palavras-passe para o bot e dá instruções para que ele execute um ataque de força bruta contra o router. Se o bot for capaz de fazer login no router, ele irá então alterar as configurações do servidor primário de DNS. É interessante notar que o ataque de força bruta só é utilizado para obter acesso à página de administração do router. A autenticação é feita com nomes de “admin” e “support”, embora as versões anteriores também tentassem “root” e “Administrator”. Abaixo está uma lista de senhas que têm sido transmitidas pelo servidor C&C:

  • <empty string>
  • 111111
  • 12345
  • 123456
  • 12345678
  • abc123
  • admin
  • Administrator
  • consumer
  • dragon
  • gizmodo
  • iqrquksm
  • letmein
  • lifehack
  • monkey
  • password
  • qwerty
  • root
  • soporteETB2006
  • support
  • tadpassword
  • trustno1
  • we0Qilhxtx4yLGZPhokY

No caso de um login bem-sucedido, o malware altera o servidor DNS primário para um falso, e informa o servidor C&C acerca de uma infecção bem sucedida, prosseguindo a sua análise pela Internet em busca de novas vítimas.

Assim que o endereço de DNS primário do router for comprometido, todas as consultas DNS feitas pelos utilizadores vão passar pelo  servidor falso de DNS, modificando-as para apontarem para a página do instalador falso do Chrome sempre que os domínios “facebook” ou “google” são resolvidos.

google_doesntexist

 

Esta operação é similar ao DNSChanger, que leva os utilizadores a instalarem software comprometido para espalharem malware utilizando um servidor falso de DNS.

Assim que o computador fica infectado pela execução do instalador falso do Google Chrome, o servidor DNS primário é alterado para “8.8.8.8”, sendo utilizado para o efeito a seguinte chave de Registo:

HKLM/SYSTEM/ControlSet001/Services/Tcpip/Parameters/Interfaces/{network interface UUID}/NameServer = “8.8.8.8”

Note-se que o endereço IP “8.8.8.8” pertence ao Google Public DNS, um serviço legítimo de nome de domínios operado pela Google, e que não está relacionado de algum modo com o Win32/RBrute.

Já que os PCs infectados não vão usar o DNS do router, eles deixam se ser afectados pelos redirecionamentos falsos. Por outro lado, o router ainda estará comprometido e vai continuar a tentar infectar os utilizadores que a ele se liguem. Esta táctica está longe de ser furtiva, até porque para todos os efeitos,  tenta levar o utilizador  a infectar o seu próprio sistema com uma instalação falsa do Chrome.

Atualmente, esta operação parece ter como principal objectivo aumentar o tamanho da botnet do Sality.

Análise Técnica

O Componente do Win32/Sality que modifica os DNS é composto por dois binários: um que analisa os routers e outro que consiste num servidor DNS / HTTP. Ambos os malwares são instalados pelo Win32/Sality.

Binário de Análise ao Router – Win32/RBrute.A

No início, o malware cria uma mutação com o nome de “19867861872901047sdf” para evitar a execução de várias instâncias.

Posteriormente, verifica a cada minuto um endereço IP encriptado para obter um determinado comando. Esse commando pode ser uma instrução de análise ou um pedido para tentar aceder a um endereço IP e mudar o DNS primário.

A instrução de análise contém o endereço IP onde se deverá iniciar a análise e o número de endereços a experimentar. O Win32/RBrute.A vai tentar fazer um HTTP GET na porta TCP/80, na esperança de receber um erro HTTP 401 – não autorizado. Depois, o modelo do router é extraído do atributo de autenticação HTTP. Se um dos routers que referimos acima for encontrado, o malware envia de volta o seu endereço IP para o C&C.

win32.rbrutea_flowchart

O C&C, emite então um pedido para aceder ao router utilizando uma palavra-passe fornecida pelo C&C. Se o login for bem sucedido, o servidor DNS primário será alterado, no router, para um host que esteja a executar o malware Win32/RBrute.B.

DNS e Servidor HTTP – Win32/RBrute.B

Este componente está dividido em três partes: a parte de controlo, a instância do servidor DNS e o servidor HTTP.

Embora tanto o servidor DNS, como o servidor HTTP possam ser usados ao mesmo tempo, o malware irá escolher, com base num valor aleatório, se será um servidor de DNS ou um servidor HTTP. Uma constante na fórmula assegura que 80% das infecções vão agir como servidores DNS.

serv

 

Se o servidor escolhido não arrancar, o malware irá avançar com o outro módulo:

random

O operador também poderá forçar o ínicio através de uma solicitação por HTTP ou através de um determinado DNS. Uma mutação com o nome “SKK29MXAD” garante que apenas uma instância pode ser executada no host.

A instância de controlo

A instância de controlo é utilizada para informar o C&C e para reconfigurar a instância do servidor.

A cada dois minutos, o malware envia um pacote para um endereço IP encriptado que contém informações acerca da máquina na qual ele está a ser executado. O C&C, então, responde com um endereço IP que será usado para fornecer a instalação infectada do Chrome. Se o malware estiver no modo DNS, o endereço IP servido pelo C&C será o de um servidor HTTP falso instalado numa máquina comprometida pelo Sality. No outro caso, o C&C vai enviar o endereço IP de um servidor fora da rede P2P do Sality, que estará a servir a página de instalação falsa do Chrome.

Abaixo estão listadas as informações enviadas para o C&C:

  • Computer name – GetComputerName()
  • Local time – GetLocalTime()
  • Country – GetLocaleInfoA()
  • Windows directory – GetWindowsDirectoryA()
  • Windows product name – from the registry key “HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows NT/CurrentVersion/Product Name”
  • CPU names – from the registry keys
    “HKEY_LOCAL_MACHINE/HARDWARE/DESCRIPTION/System/CentralProcessor/<CPU #>/          ProcessorNameString”
  • Memory stats – GetMemoryStatusEx()
  • Result of IsDebuggerPresent()
  • Memory usage of the malware – GetProcessMemoryInfo()
  • Uptime of the malware – in minutes
  • Number of threads n use

O pacote de informação tem o formato:

0x00   DWORD         Checksum (CRC32)
0x04   WORD          Payload length
0x06   BYTE          Unused
0x07   BYTE          Mode (HTTP – 0x32 or DNS – 0x64)
0x08   BYTE[]        Host information

A imagem abaixo revela o pacote de informação enviado para o servidor C&C.

example_packet

A informação do host, a verde no exemplo anterior, é a seguinte chave encriptada com 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|

O C&C irá responder com um pacote que contém o serviço do endereço iP a utilizar:

0x00   DWORD         Checksum (CRC32)
0x04   WORD          Payload length
0x06   BYTE          Unused
0x07   BYTE          Command (start – 0x02 or stop – 0x03 the service)
0x08   DWORD         Service IP address (Win32/RBrute.B HTTP server or rogue HTTP server)

Instância do Servidor de DNS

O servidor DNS procura por solicitações que contenham “google” ou “facebook” no nome do domínio. Se encontrar um destes termos, a resposta DNS que vai enviar de volta irá conter o endereço IP de um servidor HTTP Win32/RBrute.B na rede Sality. Se a consulta não contiver “facebook” ou “google”, irá retransmitir a consulta para os servidores DNS do Google (“8.8.8.8” ou “8.8.4.4”) e enviará a resposta para o cliente.

O envio de um pacote para o servidor através do protocolo UDP/53 com “0xCAFEBABE” irá definir a flag “udme” na chave do registo do Windows “HKEY_CURRENT_USER/SOFTWARE/Fihd4”. Esta flag garante que a instância do servidor DNS irá arrancar na próxima reinicialização, substituindo o processo aleatório. O servidor irá responder com “0xDEADCODE” para confirmar o comando.

Instância do Servidor HTTP

Ao receber uma solicitação do browser por um utilizador que tenha sido redirecionado, o servidor HTTP vai olhar em primeiro lugar para o User-Agent do navegador e terá um comportamento diferente, de acordo com a resposta.

Se o User-Agent contiver “linux” ou “PlayStation”, o servidor quebra silenciosamente a ligação. Se o User-Agent fizer referência a um dispositivo móvel (contendo uma das seguintes palavras: “android”, “tablet”, “Windows CE”, “blackberry” ou “mini-opera”), o servidor vai servir o Win32/Sality. Caso contrário, a solicitação será abandonada. Finalmente, se o User-Agent contiver “opera”, “firefox”, “chrome”, “MSIE” ou qualquer outra coisa, o utilizador será brindado com o Win32/Sality.

O User-Agent afetará a porta em que a consulta é feita no servidor HTTP distribuindo o malware.

horse

Qualquer solicitação HTTP GET enviada para estas portas vai servir a página de instalação falsa do Chrome, mesmo se estiver a navegar com o Chrome!

No que diz respeito ao servidor DNS, o botmaster pode afectar o comportamento do servidor HTTP, enviando um pacote criado para o efeito. Mais especificamente, o envio de uma solicitação GET ou POST com o User-Agent “BlackBerry9000/5.0.0.93 Profile/MIDP-2.0 Configuration/CLDC-2.1 VendorID/831” irá definir o flag “htme” na chave de registo “HKEY_CURRENT_USER/SOFTWARE/Fihd4 “, garantindo efectivamente que o malware inicia a instância do servidor HTTP após a reinicialização, substituindo o processo aleatório. O servidor irá enviar “<html> kenji oke </ html>” para confirmar uma execução bem-sucedida.

O servidor HTTP também mantém uma lista de ficheiros permitidos para serem servidos. Se um browser fizer uma consulta HTTP num domínio de correspondência “google” ou “Facebook” para um ficheiro que não está na lista, o servidor irá responder com um HTTP 200 OK, com o seguinte conteúdo:

<html><meta http-equiv=”refresh” content=”0; url=/”></html>

Isto redireciona o browser para a página inicial – servindo daí a página de instalação falsa do Chrome. Por exemplo, se o utilizador navega para “http://google.com/does-not-exist” e ” does-not-exist ” não faz parte da lista de ficheiros permitidos, ele será redirecionado para o “http:// google.com.

Importa salientar que a cada consulta feita por HTTP GET no servidor HTTP que contenha a string “. Exe” o utilizador sera encaminhado para o servidor HTTP falso, independentemente da lista de ficheiros permitidos. O servidor falso irá sempre responder com um binário infectado.

Semelhança com outros componentes

Com base nas seguintes observações, acreditamos que o principal ficheiro responsável pela infecção e todos os componentes descritos anteriormente são desenvolvidos pelo mesmo grupo de pessoas. Ao olhar para cada um dos componentes binários, todos eles partilham os mesmos detalhes técnicos e estilos de codificação.

Sem persistência

Nenhum dos components descarregados, incluindo aqueles discutidos anteriormente, necessitam de agir de forma persistente em toda a reinicialização do sistema, apesar de alguns módulos poderem armazenar a configuração no Registo.

Inicialização do Buffer

Os operadores têm a prática standard de iniciarem os buffers com o valor ‘0’. O compilador de “visual-c + +” não otimiza o seguinte código C, quando os operadores compilam o software:
char buf[4096] = {0};
Isto é compilado no código revelado nos seguintes screenshots.

initialize_buffer

 

Este esquema  é observado em todos os componentes do Win32/Sality.

Contornar a Firewall

Todos os componentes que necessitam de receber ligações da Internet partilham do mesmo código para adicionar uma regra específica à firewall do Windows autorizando solicitações de entrada. Ela irá adicionar o valor “[nome do malware file]: *: Enabled: IPSec” à chave do Registo “HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/SharedAccess/Parameters/FirewallPolicy/StandardProfile/AuthorizedApplications/List” para atingir esse objetivo. A figura a seguir mostra um subconjunto da função “add_to_firewall_exception ()”.

add_to_firewall_exception-1024x204

No Win32/RBrute.B, esta função é chamada no ínicio da execução de malware:

spammer_firewall_exception

A mesma coisa sucede no component do spambot Win32/Sality.

gibberish

 

Estatísticas da Infecção

Os nossos dados revelam que a detecção do Win32/Sality está actualmente a diminuir ou pelo menos, a estabilizar desde 2012. Acreditamos que a redução do número de detecções se deve à reduzida eficácia dos vectores de infecção actuais. Isto pode explicar por que motivo os operadores estão à procura de novas formas de espalharem o  Win32/Sality.

sality_overall

Se olharmos com atenção para as detecções ocorridas no ano passado, podemos verificar um pequeno aumento, em meados de dezembro de 2013, no que diz respeito ao Win32/Sality e que coincide com a altura em que  o componente que modifica os DNS surgiu “in-the wild”.

sality_last_year

 

Até este momento não temos quaisquer certezas acerca da eficácia do mecanismo que altera o DNS primário nos routers  uma vez que a maioria destes dispositivos, escutam apenas endereços de rede privados (por exemplo, 192.168.0.0/16) – tornando-os não-acessíveis a partir da Internet. Além disso, o ataque de força bruta não é muito agressivo, experimentando apenas uma lista de cerca de dez palavras-passe.

Conclusão

Os vectores de infecção habituais do Win32/Sality podem não ser suficientes para manter a botnet activa, daí os controladores estarem a implementar um novo componente para o crescimento da mesma. A alteração do DNS nos routers pode ser bastante eficaz se for feito corretamente. Pode atingir uma grande quantidade de utilizadores que se encontram ligados a um único router, especialmente no caso de se tratarem de pontos de acesso públicos. Como os routers não estão muitas vezes protegidos, fornecem um ambiente atractivo aos atacantes que vão experimentar várias técnicas para roubarem informações aos utilizadores. Uma tecnologia existente, que poderia resolver o problema é o DNSSEC, uma vez que o resultado de uma solicitação de DNS é encriptada e, portanto, não está sujeito à manipulação indevida. Uma boa prática de segurança seria mudar sempre a palavra-passe de acesso à administração do router com uma boa combinação de letras e números.

DEIXE UMA RESPOSTA

Please enter your comment!
Please enter your name here

19 + thirteen =