Será que o BB anda instalando pequenos satélites do Big Brother(BB) em cada computador que utiliza o home banking?

A dúvida surgiu quando percebí que o home banking do BB aparentemente não faz uso somente dos recursos de segurança de seu navegador para comunicar-se com a central do Banco. Em vez disso, instala um sistema que, até onde compreendi, abre uma conexão paralela à do navegador criando um “canal seguro” com o endereço IP 170.66.1.60. Por que não fazem uso dos recursos de segurança já fornecidos pela Microsoft ou, caso utilize outros navegadores, aqueles do ambiente Java(JSSE ou JCE ou J*) conforme fornecidos pela Sun?

Temendo estar informando minha senha à um site que não fosse o BB, verifiquei se o referido IP é de propriedade do Banco. Aparentemente sim, ele está dentro da faixa 170.66.0.0 a 170.66.255.255 compreendendo cerca de 65.535 endereços, todos alocados ao Banco do Brasil.

Fonte: http://lacnic.net/cgi-bin/lacnic/whois?lg=EN

inetnum:     170.66/16

status:      assigned

owner:       Banco do Brasil S.A.

ownerid:     BR-BBSA-LACNIC

responsible: Edi Domingues

address:     STN 716 bloco C Brazil, 000,

address:     70770-100 – Brasília – DF

Verifiquei se os dados que essa conexão paralela enviam ficam dentro do Brasil. Aparentemente eles ficam aqui mesmo em Brasília, até o último salto visível publicamente.

Esta é uma conexão normal da home page do home banking:



Esta é a conexão ao www14.bancobrasil.com.br – mesmo usando TCP para rastrear os pacotes “somem” após sairem da rede da Brasil Telecom:

O arquivo hosts dentro de windows\system32\drivers\etc continha uma entrada que atribuia ao host www14.bancobrasil.com.br o endereço IP 170.66.1.60. Normalmente isso significa que alguém está tentando sequestrar seu acesso ao home banking, mas neste caso significa apenas que o BB não confia em seu servidor DNS e que decidiram forçar o endereço no registro local. Esta medida auxilia na proteção contra o “envenenamento” do DNS.

O sistema que cria o canal seguro é desenvolvido pela GAS Informática e, até onde entendí, se chama G-Buster. Os arquivos instalados em seu computador incluem bibliotecas DLL diversas e arquivos aparentemente compactados (ou criptografados) com extensões proprietárias(GPC, GMD, etc). Nada pessoal contra o sistema da GAS, mas este é um dos sistemas mais intrusivos que já conhecí.

Observando o formato desses arquivos superficialmente ví apenas algumas semelhanças no “número mágico” do arquivo(alguns começam com “STM!”, outros com “STF!”).

São instalados arquivos na pasta Documents and Settings, é alterado o arquivo hosts da máquina e são instalados, no mínimo, 2 BHO’s(Browser Helper Objects) que se auto-carregam toda vez que voce ligar o Internet Exploder. Não fúi muito além disso na exploração, mas até onde observei trata-se deveras de um sistema intrusivo que, se desejar, possui total controle do computador(salvo engano, essas DLL’s rodam todas em modo nativo, ou seja, como “código confiável” e sem restricões quanto ao que podem ler ou enviar pela internet).

Existe “Espião do bem”?
Quando comentei sobre o espião do BB, agora há pouco, um analista de sistemas conhecido meu afirmou já ter tido problemas com o sistema do BB em sua empresa. Aparentemente esse sistema verifica todas as páginas que o usuário visita. Caso a página aparente ser uma daquelas “falsas” telas do BB(as que roubam sua senha – o famoso phishing) o sistema direciona o usuario automaticamente para o site “original” do BB. O problema é que o “espião do bem” pode servir também para piorar a situacão(ou dar uma impressão de falsa seguranca), pois ele acusa vários “falsos positivos”. Experiencias mostram que determinadas imagens GIF, não seu conteúdo, mas o nome das mesmas, podem disparar o sistema redirecionando o usuário para o BB mesmo quando estava numa página totalmente inócua. Outro problema é que nada disso resolve o risco de envenenamento do DNS, pois o hacker pode entrar em acão após a verificacão do sistema de seguranca do BB. Entra-se então num jogo de quem veio primeiro : o hacker ou o BB?

Será necessário mesmo que o BB vigie tudo que fazemos na Internet em nome do combate à fraude?

Detalhes técnicos da falha de segurança no sistema DNS descoberta no início do mês de Julho começam a se tornar públicos, e alguns provedores de acesso já são vítimas do problema, segundo esta matéria do site Security Focus. A grande imprensa tem noticiado esta falha como sendo uma das piores da história. E, pelo pouco que foi divulgado ao distinto público pelos técnicos envolvidos na correção da mesma, parece que desta vez a imprensa não está exagerando.

Pode uma falha tão absurda existir no software mais testado do mundo?
O responsável pela divulgação da falha, Dan Kaminsky, foi questionado publicamente sobre a veracidade de sua “descoberta”. Foi então que decidiu revelar o problema a um seleto grupo de pesquisadores para que eles confirmassem ao público, ou não, a gravidade do problema. Resulta que todos saíram da reunião acendando um sinal de positivo: o problema era grave.

O megaproblema: A falha é na especificação DNS
A especificação do sistema de DNS se baseia em parte, em confiança entre servidores mestre publicados por donos de domínios, assim como outras tecnologias relacionadas à Internet(o sistema de email, por exemplo). Quando um servidor mestre responde, o DNS tradicional não verifica se a resposta veio do servidor correto, por exemplo.

Há um consenso entre especialistas que o DNS é naturalmente vulnerável a ataques mais sofisticados. O fato de um problema dessa magnitude ter sido descoberto no DNS aos seus 40 anos de idade mostra a complexidade do software: uma falha pode se esconder décadas, e um dia aparecer arriscando a integridade de toda a Internet.

Sentados ao redor de uma mesa em reunião emergencial dia 9 de Julho, alguns dos maiores especialistas de segurança de DNS do mundo solucionaram rapidamente o problema. Bem, em termos. Acontece que o problema não tem solução, é uma falha natural do sistema DNS – ele foi feito assim, e agora descobriu-se que parte da especificação contém uma falha de segurança.

Software é conhecimento. Programar computadores é uma forma de compilar conhecimento computável por uma máquina. E, assim como existem falhas, bugs nos softwares, há falhas também nas suas especificações. Neste caso a especificação DNS tem um bug, e todos os servidores que a implementam corretamente, possuem a falha também. Daí resulta a gravidade do problema: o bug está em toda a infraestrutura da Internet.

A falha
Os detalhes técnicos da falha não foram divulgados, mas eis o que conseguí compreender pelo que foi divulgado na imprensa : quando você pergunta a um servidor DNS de seu provedor “qual o endereço do site www.google.com”, esse servidor deve perguntar aos servidores Google qual o endereço.

Acontece que o Google é um site muito acessado, portanto o servidor DNS de seu provedor mantém os endereços mais comuns em memória, para não consultar os servidores Google bilhões de vezes por dia. Em termos informáticos, como você deve saber se está lendo este post até aqui, o nome de um armazém temporário de dados com finalidade de acelerar uma consulta é um “cache”.

DNS Cache poisoning
O que acontece, então, se você conseguir alterar os dados desse cache dos provedores de acesso? Digamos que o servidor consulta o DNS mestre do Google, e obtém o endereço correto. Porém, o servidor precisará consultar o Google novamente em 24 ou 48 horas para saber se o endereço mudou, e assim manter o cache sincronizado com o servidor principal.

E se, por acaso, fosse possível interferir nessa comunicação do seu servidor cache com o servidor mestre e inserir no cache um endereço IP diferente daquele do Google? Se voce conseguir a proeza, terá sequestrado o site do Google. Você terá “envenenado” o cache DNS. É disso que se trata esta falha de segurança: Dan Kaminskydescobriu que é possível fazer exatamente isso interferindo com a resposta do servidor mestre antes que ela chegue ao servidor cache.

E qual é a falha?
Como poderiam alterar a resposta do servidor mestre? Bem, esse é o detalhe que não foi divulgado. A falha poderia parar a Internet, então Kaminsky trabalhou com os proprietários de redes de infraestrutura para trampar o furo antes que ele se tornasse 100% público. Porém alguns detalhes vazaram, e há exploits na web que exploram a falha com sucesso. O que sabemos é que a solução proposta torna aleatória a porta UDP de origem quando o DNS se conecta ao servidor mestre(sempre porta 53) para renovar o cache.

Tornar a porta UDP de origem aleatória significa que de alguma maneira o atacante estaria conseguindo adivinhar quando o servidor consultava o servidor mestre e conectava-se à essa porta antes da resposta do mestre, com endereço de origem falso, devolvendo informação inválida(e de interesse do vândalo). Seria como substituir o endereço do Google com o de seu site. Imagine o potencial disso…

A solução
Tecnicamente não há nada de novo na solução proposta, pois ela já havia sido descrita há anos atrás pelo matemático e especialista em segurança Daniel J Bernstein : as portas de origem das conexões DNS devem ser aleatórias para dificultar o ataque.

Após algumas horas de trabalho duro (segundo este relato de Kaminsky) o grupo decidiu que a solução do problema era adotar a idéia de Bernstein : remendar todos os principais softwares de DNS tornando a porta de origem das consultas aos servidores mestres aleatória.

Está passando da hora de proteger o seu DNS
O número de exploits para a falha está crescendo, já existem pelo menos 2 sendo divulgados sendo que um deles permite “substituir todos os servidores DNS de um domínio”, efetivamente sequestrando toda uma rede. Imagine o seguinte: o vândalo poderia substituir os servidores do domínio globo.com, por exemplo, e todos os subsites do globo.com passariam a seu controle.

Os detalhes que permitiram aos desenvolvedores de exploits produzirem o código funcional foram compilados até ontem, 7/8. Ou seja, hoje é um bom dia para atualizar seu sistema DNS. Se o seu cache for envenenado, você permanecerá envenenado por 24 a 72 horas, dependendo do TTL(Time To Live, ou tempo depois do qual o cache deve recarregar), então evite perder dias de trabalho e atualize já seu servidor.

Nota: não existe conserto para o BIND 8. Se você estiver rodando a versão 8 será preciso migrar para 9.5. O Yahoo! era o maior usuário de BIND 8 conhecido e foi obrigado a atualizar toda sua infraestrutura.

Link para a página do BIND no Internet Systems Consortium

Steve Jobs admitiu hoje que o iPhone 3G tem uma “chave” remota que permite a Apple remover qualquer software, de qualquer aparelho, que a Empresa julgar ser uma ameaça à segurança dos usuários.

Segundo Jobs, a função serve para “proteger o usuário” contra vírus ou trojans que poderiam se difundir com alta velocidade e que poderiam impedir a rede 3G de funcionar. Ao acionar a função, a Apple poderia “limpar” todos os iPhones remotamente.

O envio do software que controlaria os iPhones 3G se dá pela App Store, loja online da Apple. Especulo que, tendo essa “porta dos fundos” implementada em hardware, nada impede a Apple de enviar esse mesmo comando através de atualizações, ou a qualquer momento que o aparelho acesse os servidores da empresa. Lembre-se que o 3G tem conexão de alta velocidade com a Internet que lhe permite efetuar download de qualquer atualização Apple em questão de segundos.

Tanto a desculpa da Apple quanto o fato deles terem tentado ocultar a função são provas de que a empresa agiu, no mínimo, de maneira traiçoeira com seus clientes. Como já mencionamos aqui em outras críticas à Apple, Steve Jobs tem a estranha mania de atirar no próprio pé.

Na ânsia de controlar(literalmente) o múndo móvel, a Apple inseriu um software completamente intrusivo e inaceitável no seu produto mais popular. Imagine você: é como se a Ford, a Volks e a GM tivessem um botão que parassem o carro de qualquer cliente remotamente para “protegê-lo”.

Leia mais nesta matéria da newsfactor.com reproduzida no Yahoo!

A Brasil Telecom desligou o redirecionador de DNS universal que praticamente sequestrava todos os domínios inexistentes. Não sei exatamente quando se deu esse desligamento, mas hoje percebí que ao digitar um domínio com erro ortográfico não fui parar numa página de anúncios Yahoo! como acontecia até algum tempo atrás.

“War dialing” faz parte do jargão criado por hackers dos Estados Unidos na decada de 1970.

Para encontrar condutos para realizar explorações em BBS e outros sistemas os hackers buscavam linhas de telefone que estivessem conectadas a modems e que estivessem atendendo a chamadas de dados(aquele já quase esquecido barulho da conexão do modem).

Um programa, naturalmente chamado de “war dialer” gerava sequências válidas de números de telefones à partir de dados fornecidos pelo hacker. Por exemplo, em Brasília a região da Asa Norte tem diversos prefixos, entre eles o 3349 e o 3327.

Assim um explorador poderia especificar a seguinte sequência de números …

Dial 3327[0000-9999]

…para discar todos os 10.000 números telefônicos entre 3327-0000 até 3327-9999 e verificar se algum deles atenderia chamadas de dados.

Diversos parâmetros podem ser fornecidos como quantos toques esperar ou registrar apenas canais de dados com determinada velocidade(1200 baud por exemplo seria “chique” em 1981!).

War Driving

Na atualidade o termo “war dialing” tem sido adaptado às novas formas de conexão que temos à nossa disposição. A adaptação mais popular que tenho encontrado tem sido “war driving”. “Drive” vem do inglês “dirigir”. War driving é a busca por redes sem fio abertas usando um automóvel. Levando um iPhone ou notebook no banco do passageiro rodando o aplicativo de descoberta de redes(“war driver”??) é possível marcar a localização GPS das redes sem fio abertas e usá-las posteriormente para explorações online. Lembrando que é sempre bom usar senha em seu ponto de acesso wi-fi.