Quando se trabalha no apoio ao cliente, ficamos a conhecer todo o tipo de problemas informáticos sentidos pelo utilizador, o que pode levar a situações muito interessantes.

Um caso particular que temos seguido é um interessante hijack de DNS que programa o computador do utilizador para usar determinados servidores DNS. Este tipo de ataque pode não parecer muito importante, e até sugere ser de rápida resolução; mas… e se não for facilmente detetado pelo utilizador? E se existir um meio de estabelecer entradas DNS estáticas de forma a que os servidores DNS primário e secundário não surjam na usual área do GUI? Pior ainda, as suas definições podem mostrar que está a usar DHCP, como seria normal, mas, na verdade, não está. Isto mesmo foi o que aconteceu recentemente com uma PUA (Potentially Unwanted Application) denominada DNS Unlocker, assim como algumas outras ameaças.

O DNS Unlocker modifica os registos da rede da vítima para passar a usar servidores DNS “desonestos”. Quando a vítima navega até google-analytics.com, estes DNS apontam para um servidor malicioso que injeta Javascript adicional. Isto acontece para que os banners publicitários da DNS Unlocker sejam inseridos nas páginas web através do Google Analytics. Normalmente, um computador infetado pelo DNS Unlocker exibe os anúncios com uma nota na base da imagem com a legenda “Ads by DNSUnlocker” (figura 1) ou algo muito semelhante e múltiplas variações de pop-ups “support scam” (figura 2).

Figure1-243gn-1024x644
Figura 1: Anúncios injetados na página web
Figure2-9wffa-1024x618
Figura 2: “Support scam” que tenta assustar o utilizador

Modificar configurações DNS

OS sequestradores de DNS não são uma novidade, nem normalmente chegam a ser dignos de comentário. O que torna interessantes estas versões recentes do DNS Unlocker é o truque usado para configurar sub-repticiamente configurações de DNS do computador da vítima.

Ao examinar as propriedades de TCP / IPv4 no Windows, poderíamos esperar pela exibição da entrada de um DNS estático na metade inferior da janela do Painel de Controle, visível na Figura 3.

Se a opção Usar os seguintes endereços de servidor DNS for selecionada, deve sempre surgir um endereço IP no campo de servidor DNS preferencial e, opcionalmente, pode haver outro no campo do servidor DNS alternativo. No entanto, se usarmos o DHCP para obter seus endereços DNS (como a maioria dos ambientes de Casa / Emprego), então a opção Obter endereço do servidor DNS automaticamente será selecionada, como mostrado na Figura 3.

Figure3-34qp8
Figura 3: Painel de Controlo com as Propriedades TCP/IPv4 predefinidas do Windows

Aqui está o truque: O PUA DNS Unlocker irá definir as configurações de DNS estáticos de forma a que o TCP / Painel de Controle IPv4 mostre à vítima que obtém automaticamente o DNS. Na verdade, o comando ipconfig / all na linha de comando também irá indicar que se está a usar o DHCP, mas a vítima irá ver os endereços DNS estáticos.

Ao usar o comando ipconfig, embora nos permita ver os endereços DNS estáticos, não há nenhuma maneira de saber se estamos a usar um endereço DNS estático ou se é obtido automaticamente; na GUI, no entanto, surge a informação que estamos a usar um endereço de servidor DNS atribuído automaticamente quando, na verdade, estamos a usar o (não visível) estático(s). Mas porque não consegue a GUI perceber que se está a usar o DNS estático? Para entender esta situação, precisamos de ver como o Windows olha para DNS estático no registo.

DNS no registo do Windows…

Examine a seguinte localização no registo:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\

Provavelmente, você vai ver que existem configurações para várias interfaces de rede, cada uma identificada com um GUID. As configurações para cada adaptador de rede podem conter valores DhcpNameServer e NameServer.

Vamos examinar o valor NameServer. Normalmente, se quisermos usar DNS estáticos, iremos ajustá-los no Painel de controle (ou através do comando netsh) e endereços DNS estáticos serão armazenados no valor de registo NameServer como uma lista delimitada por vírgulas, assim:

192.168.1.21,192.168.1.22

O que acontecerá se usarmos uma lista delimitada por espaços?

192.168.1.21 192.168.1.22

Trata-se de uma mudança pequena e o Windows continua capaz de usar os dois endereços  – um como primário e o outro como DNS secundário. Mas o GUI Windows não é capaz de exibir na metade inferior do painel de controle que o computador está a usar o DNS estático, como mostrado na Figura 3. O que é exibido é que o computador utiliza DHCP para DNS, quando na verdade, não é o que está a acontecer.

E o que se torna frustrante é que estamos a trabalhar com um cliente que está a receber anúncios injetados em sites ou está tendo redirecionamentos quando navega na web. Quando decidimos testar se as definições conhecem bons servidores DNS para corrigir o erro manualmente através do Painel de Controle, não conseguiremos resolver o problema.

Como o Windows considera que os servidores DNS primário e secundário já estão definidos (mas não visíveis para nós), ao preenchermos os campos Preferred e Alternate, o Windows simplesmente acrescenta essas novas configurações para o fim da lista no registo, desta forma:

192.168.1.21 192.168.1.22,208.67.222.123,208.67.220.123

Como podemos ver, o Windows usa a limitação de vírgulas para as entradas de terceira e quarta entradas de servidor DNS, mas deixa como delimitador o espaço existente entre o primeiro e segundo endereços.

Agora que sabemos como tudo funciona, a verdadeira questão é como é permitido isto acontecer? Não temos uma boa resposta. A hipótese que levantamos é baseada em como o valor DhcpNameServer pretende usar uma lista separada por espaços e como a Microsoft explica este comportamento no TechNet:

Se o valor do nome do servidor é válido, ele tem precedência sobre o valor da DhcpNameServer

(Fonte: artigo sobre DhcpNameServer no Microsoft TechNet)

Se o DhcpNameServer pode ter delimitação espacial, o NameServer também pode. Além disso, há evidências de que o valor NameServer destina-se a utilizar “espaço” delimitado (ler aqui). Na verdade, esta documentação sugere que apenas a delimitação do espaço é permitida.

No entanto, tudo isto não passa de uma conjetura. A verdade é que esta é uma propriedade não-padrão que o Windows tem e o Painel de Controle não sabe como lidar, não permitindo inserir uma lista delimitada por espaço ou por vírgulas, mas vai criar uma lista delimitada por vírgulas sobre tudo o que o utilizador inserir nos campos de servidor DNS preferencial e alternativo de sua interface gráfica, mas o resto do código num outro local e “funciona corretamente”, com quer delimitador.

O Painel de Controle GUI, no entanto, não funciona da mesma forma, uma vez que não apresenta as entradas delimitadas por espaço que não surjam da tab avançada (advanced tab).

E DNS nas suas configurações de rede…

Pior, no entanto, é que este recurso está sendo utilizado por PUAs, a fim de continuar a forçar o uso de seus servidores DNS na preferência para os servidores destinados em computadores que tenham sido atingidos. Em suma, este é um sequestro de DNS que força o uso de servidores de DNS “escondidos”. Chamamos-lhe “escondidos”, porque os servidores DNS estaticamente definidos não aparecem nos campos primários e secundários esperados do TCP / Propriedades IPv4.

Agora que sabemos como o DNS está sendo definido indevidamente no registo, vamos olhar para mais uma área de Propriedades de TCP / IPv4. A área de interesse é a janela Configurações avançadas de TCP / IP no separador DNS na Figura 4. A parte superior deste guia tem uma lista que determina a ordem de utilização de servidores DNS e permite que especifiquemos o uso de mais de dois endereços IP como servidores DNS. Cada endereço deve estar em sua própria linha. Agora, se o seu DNS foi sequestrado e escondido, então suas configurações TCP / IP surgirão algo semelhantes com a Figura 4.

Figure4-3carv
Figura 4: Windows Advanced TCP / Configurações DNS Painel de Controle IP com configurações de DNS “escondidos”

Como podemos observar, existem dois endereços numa linha separados por um espaço. Se tentar usar o botão Adicionar… para adicionar dois endereços separados por um espaço, vai receber um erro informando endereço inválido IP e não seremos capaz de adicioná-lo. Se quisermos indicar manualmente os servidores de DNS para o servidor DNS preferencial e “servidor DNS alternativo” na página de propriedades TCP / IPv4 enquanto tivermos DNS escondidos, vamos encontrar o que especificámos abaixo das entradas de DNS escondidas, algo como o exemplo na Figura 5.

Figure5-3znec
Figura 5: A configuração manual conhece “bons” DNS quando os DNS “ocultos” já estão em vigor

Solucionar

Felizmente, podemos remover as más entradas de DNS na guia DNS da página Configurações TCP / IP avançadas. Só temos de nos lembrar de olhar para ela.

Divulgação responsável

A ESET relatou esta questão ao Centro Microsoft Security Response (MSRC) a 10 de maio de 2016. Um representante MSRC reconheceu o problema, mas disse que não foi classificada como uma vulnerabilidade de segurança. A razão para tal foi que “como para modificar o registo são necessários privilégios administrativos, não consideramos que esta ameaça reúna os atributos necessários para a submetermos à MSRC”. Mas enviaram esta questão para as equipas dedicadas para ser considerada nas versões futuras.

Resumo

Uma vez que o Windows irá ler e usar uma lista delimitada por espaço de endereços de servidor DNS no valor NameServer para uma interface, em vez de aplicar estritamente as listas separadas por vírgula, as PUAs podem usar esse método para esconder as suas configurações de DNS no sistema do utilizador. Este método que esconde as configurações de DNS “desonestos”, tem sido observado desde dezembro de 2015, no DNS Unlocker no Windows XP, Vista, 7, 8 / 8.1 e 10 (x86 e x64). Finalmente, e como especial interesse: aplicar a mesma técnica para ocultar endereços de DNS estaticamente definidos usando uma lista delimitada por ponto e vírgula funciona bem, embora não tivéssemos vimos este ser utilizado por malware ou PUAs a partir de 05 de maio de 2015, quando foi escrito.

Indicadores de compromisso (IoC)

A versão do DNS Unlocker aqui descrito foi detetado pela ESET como a aplicação MSIL / Adware.CloudGuard.C. Usa os seguintes endereços IP para sequestrar DNS:

  • 203.131.145
  • 203.131.150 a 199.203.131.152
  • 163.142.2 a 82.163.142.7
  • 163.142.66 a 82.163.142.70
  • 163.142.130 a 82.163.142.189
  • 163.143.131 a 82.163.143.190
  • 211.158.129 a 95.211.158.135
  • 211.158.145 a 95.211.158.151

Os seguintes endereços IP são usados como servidores HTTP para injetar o JavaScript malicioso, que mostra os anúncios em páginas da web:

  • 163.143.23 a 82.163.143.250
  • 88.193.133 a 209.88.193.141

Amostras de malware usando esta técnica:

SHA-1 ESET Detection Name Valores NameServer usados
E7108973D9AE0BDB97801C959622E1ECECDCE80E MSIL/Adware.CloudGuard.C application 82.163.143.17
182.163.142.173
AEEEA6C3697D983337598E2D3B940DB0225A05CB Win32/Agent.XSF trojan 199.203.131.145 82.163.143.167
A9AC712B4D31F20AC3DEFC066D66C2982A4ADC0C Win32/DNSChanger.NDI trojan 199.203.131.151 82.163.143.181
1A1764F7AA3E9F81B23997982E1BDB300D3707B1 Win32/Adware.Adposhel.F application 82.163.142.3 95.211.158.130

 

James Rodewald
Malware Removal Support Supervisor
ESET

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *

*