Root DNS, CA e AS - uma questão de (des)confiança

[ Update - 27/05/2010 ]


Sobre o ítem II abaixo - ROOT CA's - hoje tomei conhecimento de um experimento interessante feito por Nasko (do site http://netsekure.org).

Da lista inicial de mais de 100 certificados raiz instalados nos navegadores Internet Explorer, Chrome (ambos lêem isto da lista do Windows) e no Firefox, apenas 10 foram realmente necessários depois de um mês de navegação intensiva.

Recomendado também são os demais posts do NetSekure, incluindo um sobre como remover os certificados raiz "confiáveis" do Windows.


[ Post Original - 12/04/2010 ]


Uma das bases psicológicas da segurança é a confiança. Por mais matemática e tecnologia que sejam continuamente aplicadas, muitos dos protocolos e sistemas que garantem o funcionamento "seguro" da infraestrutura de Internet são baseados neste princípio de delegação de segurança (confiança) em diferentes níveis, como por exemplo:

I) Domain Name System (DNS)

II) Certificados raiz SSL (ou Root CAs)

III) Autonomous Systems (ASs)

Vários incidentes recentes - descritos abaixo - chamam a nossa atenção para a fragilidade da dependência no modelo de confiança - e especialmente na implementação deste.

I) DNS

O DNS (Domain Name System) é um sistema hierárquico para resolução de nomes. Existem 13 root servers (A->M).

O ataque de redirecionamento de navegação através do controle da resolução de nome (DNS) pode ser feito de diversas formas, incluindo dns cache poisoning, a edição de arquivo hosts (muito usada em ataques de phishing), e a alteração ou criação de entradas nas tabelas de resolução de servidores DNS comprometidos, por exemplo.

Como sabemos, alguns países controlam a Internet usando técnicas similares às descritas. A China é um exemplo: ela obriga os provedores que atuam no país a redirecionar a resolução de nomes de sites proibidos (como YouTube, Twitter e FaceBook) para sites chineses onde o governo tem total controle do conteúdo.

Há poucos dias, o DNS raiz I - i.root-servers.net - começou a resolver endereços alterados chineses mesmo para clientes em países ocidentais, como o Chile e os Estados Unidos.

Depois do problema a empresa sueca NetNod - responsável pelo servidor DNS raiz "I" - deixou de fazer anúncio de rotas a partir desta instância do servidor DNS raiz localizada na China.

Mais tarde a empresa explicou que a instância do servidor I que roda na China é exatamente igual aos demais root servers e que as entradas de DNS alteradas foram inseridas em trânsito pelo governo Chinês. Este tipo de situação poderia ser evitada se os clientes utilizassem o DNSSEC.

Recentemente publicamos um post sobre o DNSSEC - que traz melhorias significativas de segurança no uso do serviço DNS e que já começou a ser implementada.

II - SSL/TLS

Outra implementação falha de confiança hierárquica é o baseado na utilização de certificados digitais assinados por "certificados raiz".

Os Root Certificates são a base do sistema de confiança de comunicações criptografadas de comércio eletrônico, personal banking, etc - São utilizados em comunicações criptografadas e pré-cadastrados e autorizados por sistemas operacionais e navegadores, que possuem listas independentes que são enviadas aos usuários sem sua anuência.

Num exemplo corriqueiro, uma vez que um certificado SSL/TLS seja apropriadamente assinado por um destes certificados raiz, ele passa a ser "confiável" e o usuário verá o cadeado ao lado da URL iniciada por https no navegador - gerando uma sensação de confiança que muitas vezes pode não corresponder à realidade.

Um paper (pdf) recentemente publicado por Christopher Soghoian e Sid Stamm mostra que a interceptação de comunicações SSL pode ser mais comum do que se pensa.

Qualquer um que possa obter um certificado falso - de qualquer autoridade certificadora confiada pelo S.O ou navegador - pode criar um website "seguro" com qualquer endereço. Os navegadores não emitirão nenhum aviso e aceitarão o certificado como se fosse legítimo. Mais detalhes aqui.

O vendor PacketForensics comercializa um appliance para interceptação de tráfego SSL que executa as ações descritas acima. Porém proxies SSL podem também ser criados usando ferramentas open-source como o nginx ou o httpd da apache.

Portanto, a questão importante para o sucesso da interceptação não é necessariamente o vendor usado e sim quão "bem falsificado" será o certificado. E em última instância, se você pode obter um (legalmente via mandado judicial ou ilegalmente via hacking) de uma das várias Autoridades Certificadores aceitas pelos navegadores.

Os autores do paper desenvolveram um plugin para Firefox chamado CertLock que gera um aviso caso seja detectada uma tentativa de forjar um certificado SSL e controla / avisa o usuário qual AC assinou um determinado certificado.

Minha opinião sobre o assunto - você não deve assumir que uma comunicação é segura a não ser que você tenha real controle sobre as chaves privadas envolvidas na comunicação.

Além disto, não se esqueça que existem computadores envolvidos na comunicações e portanto programas especialmente criados para monitoração de computadores podem ser utilizados - inclusive pelas Forças da Lei - quando autorizadas - (vide o software CIPAV usado pelo FBI)

III - Autonomous Systems

A RFC 1930, seção 3 descreve o funcionamento dos AS (Autonomous Systems). De forma simplificada - desde a criação da Internet na década de 60, houve um enorme crescimento das tabelas de roteamento, o que trouxe a necessidade de protocolos de roteamento hierárquicos. Os roteadores desde então são divididos em regiões chamadas Autonomous Systems. (ex: AS4230 - Embratel - gráfico de peering).

No começo deste mês um Provedor da China Telecom fez um hijack de uma parte considerável da Internet. Trata-se do AS23724 - gráfico de peering).

Apesar de ser responsável por apenas 40 prefixos, este AS começou a anunciar quase 40.000 prefixos que não eram de sua responsabilidade - em um ataque conhecido como BGP hijack ou prefix hijack.

Resultado? Sites como dell.com, cnn.com, www.amazon.de, www.rapidshare.com, www.geocities.jp, entre outros foram afetados diretamente.

Uma situação semelhante havia ocorrido em fevereiro de 2008 quando um provedor paquistanês fez hijack dos prefixos utilizados pelo Youtube.

O acesso ao site Youtube foi também afetado em 2007, no caso do vídeo na praia de Daniela Cicarelli - quando alguns AS´s brasileiros acataram a decisão judicial do Tribunal de Justiça do Estado de São Paulo e redirecionaram para 'null/0' todo o tráfego destinado ao Youtube.

Estamos acostumados a considerar a "boa fé" de usuários - que clicam em links, abrem anexos suspeitos, passam informações confidenciais a qualquer interlocutor - como um elo fraco da Segurança da Informação.

Os três exemplos citados (DNS, CA/SSL e AS/BGP) mostram que as fragilidades baseadas no modelo de confiança pré-existente são sérios e influenciam negativamente também a segurança da infraestrutura da Internet.