O Win32/Spy.Hesperbot é um novo troiano bancário tem atacado utilizadores online de banco em Portugal, Turquia, República Checa e Reino Unido. Neste artigo acerca do Hesperbot, iremos observar a parte mais intrigante deste malware – a forma como lida com a intercepção de tráfego de rede. As campanhas de propagação e as suas vítimas, uma visão geral da arquitectura do malware, a sua componente móvel e outras funcionalidades já foram abordadas no primeiro e no segundo artigos.
Intercepção de Rede e Injecção Web
Outros conhecidos troianos bancários como o Zeus e o SpyEye são capazes de interceptar e modificar tráfego HTTP e HTTPS acoplando funções WinSock (send, WSASend, etc.) e as funções WinInet de alto nível (HttpSendRequest, InternetReadFile, etc.). Quanto às injecções web, captura de forms e outras manobras desempenhadas por este tipo de troianos bancários, estas acontecem dentro do browser de Internet afectado, tendo este método sido rotulado como ataque “Man-in-the-Browser”. O Win32/Spy.Hesperbot, contudo, adopta uma abordagem diferente que não é muito comum mas que foi de facto já utilizado pelo troiano bancário Gataka. Uma boa análise técnica ao Win32/Gataka produzida pelo nosso colega Jean-Ian Boutin pode ser encontrada aqui.
A funcionalidade de intercepção de tráfego de rede e injecção HTML do Win32/Spy.Hesperbot é conseguida através dos módulos plugin nethk, httphk e httpi em conjunto.
Eis uma breve descrição do objectivo de cada módulo:
- nethk – utilizado para configurar um proxy local, acoplar funções de socket para conduzir ligações ao proxy e acoplar funções de verificação de certificados SSL. Também lida com a decriptação e encriptação de tráfego HTTPS que passa pelo proxy.
- httphk – utilizado para interpretar o tráfego HTTP interceptado pelo proxy.
- httpi – utilizado para screenshots, captura de video, captura de forms e injecções web consoante as definições do ficheiro de configuração.
Agora vamos olhar com mais detalhe à forma como estes módulos trabalham em conjunto e cumprem as suas tarefas. Como mencionado acima, os módulos expoêm as suas funções numa vtable para outros módulos as utilizarem. O fluxo de programa entre os módulos e cada pedido ou resposta HTTP é interceptado e assegurado através de funções callback.
nethk
O Nethk é o primeiro módulo plugin a ser carregado pelo módulo ‘core’. O Win32/Spy.Hesperbot executa o ataque ‘man-in-the-middle’ criando um proxy local para o qual redirecciona o tráfego de todas as ligações do browser.
Para conseguir isto, o módulo nethk do troiano cria um proxy num porto aleatório no endereço 127.0.0.1 e acopla as seguintes funções no mswsock.dll, ao nível da biblioteca Winsock SPI:
- WSPSocket
- WSPIoctl
- WSPConnect
- WSPCloseSocket
Os apontadores para estas funções são modificados na WSPPROC_TABLE. Para entender como funciona o redireccionamento do proxy, vamos olhar para a função acoplada WSPConnect.
O socket do browser – ao tentar ligar-se a um banco online através de uma ligação segura, por exemplo – é então ligado ao proxy criado pelo Hesperbot. Noutra thread, é estabelecida a ligação legítima ao website.
É invocada um callback ao httphk cada vez que o proxy intercepta um pedido do browser, antes de o passar ao servidor real. Da mesma forma, um callback httphk é invocado cada vez que o proxy intercepta uma resposta do servidor real, antes de o passar ao browser. O módulo httphk continua então a funcionar desta forma com o restante tráfego.
Há também uma diferença entre a gestão de tráfego HTTP face a tráfego HTTPS. No caso de HTTP, o pedido ou dados de resposta são simplesmente passados ao httphk. No caso de HTTPS, o nethk “livra-se da encriptação” antes. Quando um pedido HTTPS do browser é interceptado (encriptado através do seu próprio certificado SSL falso – explicado mais abaixo), é desencriptado e os dados passados ao httphk através do callback, encriptados usando o certigicado verdadeiro do servidor (ex.: banco online) e então enviados ao destino verdadeiro. Reciprocamente, quando uma resposta HTTPS é recebida pelo servidor, é desencriptada com o certificado real, os dados desencriptados vão novamente ao httphk e são então encriptados com o certificado falso antes de passarem ao browser.
Com efeito, através do proxy “man-in-the-middle”, o Win32/Spy.Hesperbot consegue aceder às comunicações HTTPS da vítima antes de serem encriptadas e as suas ligações HTTPS de entrada depois de desencriptadas. O mesmo efeito é essencialmente conseguido pelas acoplagens MiTB do Zeus e SpyEye, mas esta nova abordagem é algo mais silenciosa.
Agora, este redireccionamento proxy malicioso deverá trazer problemas devido ao certificado inválido para um website com HTTPS. Os autores do Hesperbot também pensaram nisto. O módulo nethk transporta o seu próprio certificado SSL, auto-assinado e estes são substituídos por certificados legítimos.
De forma a enganar o browser a acreditar que o certificado é válido e evitar que mostre a mensagem de aviso, o módulo malicioso também acopla funções responsáveis pela verificação do certificado. A implementação difere de browser. A seguinte tabela mostra que browsers são suportados pelo Win32/Spy.Hesperbot e que funções são acopladas:
Uma característica interessante do código malicioso é que os autores usaram hashes ao invés dos nomes dos processos dos browsers directamente, seja para complicar a análise como, e mais importante, para proteger o malware da detecção baseadas em assinaturas de vírus de soluções antivírus.
A figura abaixo mostra o código da acoplagem CertVerifyCertificateChainPolicy.
No caso de uma verificação de política em cadeia SSL cliente/servidor (outros tipos são negligenciados e passados à função original) a função acoplada simplesmente retorna um resultado indicando que a verificação da política passou.
httphk
O módulo httphk é apenas responsável pela interpretação dos dados do protocolo HTTP. Quando um callback httphk é invocado, este classifica os cabeçalhos HTTP e dados e preenche uma estrutura interna. Esta estrutura será subsequentemente acedida pelo módulo httpi.
Novamente, o httphk expões duas funções de callback para invocar o httpi: httpi_request_callback e httpi_response_callback.
httpi
Este é o módulo principal que realmente se encarrega da modificação de dados HTTP, de acordo com o ficheiro de configuração. Quando httpi_request_callback é invocado, as seguintes acções são desempenhadas:
- Captura de video e ecrã (screenshots) – O módulo lê o ficheiro de configuração e verifica o URL solicitado. Se especificado no ficheiro de configuração, será então iniciada a captura de video e/ou ecrã.
- Captura de formulários – Este módulo verifica se o pedido POST foi feito via esquema HTTPS e se o content-type é “application/x-www-form-urlencoded” ou “text/plain”. Se estas condições forem verdadeiras, é provávelque o utilizador tenha submetido um formulário de login. Se o ficheiro de configuração especificar que o URL actual deve ser monitorizado, os dados são escritos no log.
Quando o httpi_response_callback é invocado, acontece o seguinte:
- Injecção HTML – Primeiro, o troiano verifica se o código de resposta HTTP é 200. Depois, o ficheiro de configuração é lido e se existirem entradas de injecção web para página web que responde, elas são inseridas no conteúdo HTML.
A figura abaixo mostra um ficheiro de configuração desencriptado usado numa botnet Portuguesa. Pode verificar o primeiro grupo de domínios – este são ignorados pelo httpi – que são de pouco interesse aos bot masters. O roubo de credenciais de login do Facebook ou Google poderia ser considerado valioso para outras formas de malware, isto mostra que os cibercriminosos por detrás do Hesperbot estão apenas interessados em dados relacionados com online banking (home banking). Os websites dos bancos visados estão listados depois dos que são ignorados. O resto do ficheiro de configuração contém código HTML que é suporto ser injectado online em websites de bancos.
Parece que as pessoas que escreveram estes scripts de injecção web falavam Russo, como evidenciado pelos comentários no código fonte. Note, contudo, que os scripts podem ter sido, ou não, escritos pelos mesmos autores do malware Win32/Spy.Hesperbot malware e/ou operadores das botnets. Os scripts de injecção web são frequentemente partilhados ou reutilizados – isto é possível quando um formato semelhante é utilizado por diferentes famílias de malware – e a especialização entre cibercriminosos é um lugar comum.
Agradecimentos aos autores – e nossos colegas – desta análise técnica (partes 1 e 2) publicada originalmente no blog ESET www.welivesecurity.com:
Anton Cherepanov (ESET)
Robert Lipovsky (ESET)
Adaptado por ESET Portugal para o blog http://www.eset.pt/blog/
