|
|
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.
Em reportagem do Globo de hoje, o Ministro Ayres Britto do TSE afirmou:
- É um blefe, uma bravata e um estelionato. O sistema é absolutamente inviolável. Disseram até que têm minha senha. Nem eu fiz ainda a minha assinatura digital. E de qualquer modo é impossível fraudar, entrar no programa ou desfigurá-lo. Fizemos um software que é inviolável e inacessível aos hackers. Se o programa é alterado, a urna se autodefende imediatamente - disse Britto.
Eu não ví a reportagem do JN citada, não sei o que exatamente a imprensa vem falando do assunto. Vamos analisar apenas o que disse o Ministro.
O sistema é absolutamente inviolável.
Citamos aqui, há algum tempo(veja links relacionados), que o TSE deve saber algo que a Nasa não sabe. Porque o orçamento da Nasa é quase equivalente ao PIB do Brasil e os softwares da Nasa vivem dando pane. A Nasa não faz mistério disso porque é uma Lei Científica, provada matematicamente, que não existe software perfeito.
A última pessoa que afirmou algo semelhante ao que disse o Ministro foi Larry Ellison, Presidente da Oracle. Em 2005, Ellison estava tão entusiasmado com a segurança do Oracle 9i que ele veio a público e fez o desafio-mór: afirmou que o Oracle “era inviolável”. Não durou nem 2 semanas, pesquisadores foram à Black Hat Conference e mostraram um festival de buracos no Oracle, para deleite de Bill Gates. Outro paralelo que podemos traçar é o fato da Oracle ter um orçamento bem maior que o TSE e milhares dos melhores programadores do mundo.
Fizemos um software que é inviolável e inacessível aos hackers.
Quando o Ministro fala em “hacker”, ao que se refere exatamente? A um cabeludo com seus 20epoucos anos, diante de uma tela preta com letras verdes, fumando cigarros Camel Light, ouvindo Dead Kennedys e tentando violar as urnas do quarto escuro de sua casa? Ou o Ministro fala de um vândalo institucional, corrupto, dentro do TSE, disposto pra entregar a urna e seus segredos em troca de uma pequena soma de dinheiro? Kevin Mitnick fez tudo o que quis com tecnologia e, segundo ele, a grande parte foi apenas usando engenharia social.
Quanto ao software ser inviolável e inacessível: Entendo que o Ministro tente tranquilizar as pessoas com esse tipo de superlativo, mas certas coisas podem se virar contra sua causa.
Se o programa é alterado, a urna se autodefende imediatamente - disse Britto.
A premissa apresentada pelo Ministro invalida a afirmação anterior. Se o “programa é alterado”, significa que houve violação do mesmo. Se houve violação, o software não é inviolável. Certo? Ou estou entendendo tudo errado?
Por fim, mesmo admitindo que a urna é vulnerável e que o software foi alterado, nesse caso o software não pode ser mais confiável pra completar a rotina de autodefesa. Como é que se pode confiar num software que foi alterado?
Se o TSE quiser melhorar o sistema basta obrigar a impressão dos votos. O ideal seria que a contagem dos votos demorasse mais um pouco, e que fosse feito através de um sistema mecânico um pouco mais tradicional.
Links relacionados:
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!
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.