A Banalidade dos Vazamentos de Dados Pessoais

Decepcionei alguns amigos ontem quando vieram comentar comigo sobre o recente vazamento de 12 milhões de registros do cadastro do ENEM, reportado originalmente pelo Estadão. Eles aparentemente esperavam que eu ficasse muito impressionado e eu os desapontei quando soltei um muxoxo e disse apenas "normal."

Para os que talvez não tenham lido a notícia, chegou ao conhecimento da reportagem do jornal Estado de São Paulo que, simplesmente digitando uma URL específica no navegador, era possível baixar um arquivo chamado "inscritos2009.zip" contendo uma cópia do banco de dados de inscritos nos ENEMs de vários anos, totalizando 12 milhões de registros, com nome, CPF, RG, data de nascimento e nome da mãe dos inscritos, além do seu desempenho nos exames. Assim que foi informado do caso, o INEP tirou removeu o arquivo e pouco tempo depois emitiu uma nota curta dizendo que iria apurar responsabilidades, mas que só iria tomar ação jurídica se fosse constatada má fé, o que sem dúvida já deixa um cheiro de pizza no ar.

No jargão técnico de segurança da informação, essa "vulnerabilidade" é conhecida como "acesso direto não autenticado". A razão da minha indiferença é que se trata de uma vulnerabilidade relativamente comum e que vazamento de dados é um incidente banal hoje em dia. Esse caso ganhou notoriedade simplesmente porque era um cadastro especialmente grande e de um processo seletivo de certa visibilidade.

Colocar dados sensíveis diretamente no site é comum por vários motivos. Um deles é quando o operador do site faz um backup (cópia "estepe" ou de reserva) rápido dos dados, simplesmente compactando a pasta com um programa tipo "WinZip" e esquece de apagá-lo da pasta acessível pelo servidor web. Ou às vezes ele o faz de propósito, sabendo plenamente dos riscos, para permitir que alguém mais (ou ele mesmo) acesse os dados posteriormente. Outras vezes, ele incorretamente configura o servidor web para permitir acesso a pastas que não deveria – esse caso é relativamente comum quando o operador do site não entende muito bem como funciona o sistema que ele usa.

Para convencer meus amigos com quem conversava sobre esse assunto e, quem sabe, o leitor aqui do Blog, proponho a seguinte experiência: vão no Google e façam as seguintes consultas:

Vocês vão achar dezenas de arquivos de backups de bancos de dados de sistemas de controle de conteúdo (Drupal, Joomla), bem como de sistemas desenvolvidos internamente nas várias empresas donas dos sites que aparecem. Vai aparecer muita coisa aparentemente inútil, mas, se você garimpar com atenção, mesmo não sendo técnico em informática, verá alguns cadastros com nomes de pessoas, emails; às vezes aparecem também CPFs e CNPJs de empresas, às vezes os endereços completos delas.

E eu usei esses exemplos deliberadamente porque não dão resultados tão impressionantes assim, pra não piorar muito uma situação já nada boa. Se você alterar um pouquinho as consultas acima de forma criativa (não me pergunte que formas são essas), achará muito mais. Mas aqui vão duas dicas: o "inurl:.br" restringe os resultados a URLs que contenham .br, o que mais ou menos limita os resultados a sites Brasileiros; além disso, existem outras extensões de arquivo além de "sql" que são comumente usadas para backups. Boa pescaria!

Esse problema é tão comum que o próprio Google tenta limitá-lo: se você repetir algumas vezes as consultas acima, o Google vai desconfiar que se trata de um programa, e não você pessoalmente, que está minerando os dados, e mostrará um CAPTCHA (aquele teste com letrinhas distorcidas) pra você resolver antes de liberar os novos resultados de consulta.

Se você for um experiente programador de computadores, poderá facilmente escrever seu próprio programa para navegar a Web e procurar por arquivos de bancos de dados, zips de backups e outras coisas que os operadores de sites esquecem de remover. Certamente conseguirá achar muito mais do que usando apenas o Google. Eu sempre recomendo essa brincadeira a todos os programadores que conheço – todos os que tentaram ficam impressionados o quanto é possível descobrir apenas se aproveitando do descuido alheio.

"Como resolver esse problema?", perguntaram meus amigos. Há duas grandes vertentes: a primeira delas é punir aqueles que vazam dados pessoais sem permissão; a segunda é tornar as pessoas intrinsecamente difíceis de rastrear. Nenhuma das duas é muito fácil. Meus amigos tiveram de ir antes que eu pudesse enveredar nesse assunto. Prometemo-nos continuar o assunto quando nos encontrarmos novamente pra tomar café. Na ocasião, reportarei pra vocês por onde nossa conversa foi.

Próximas partes

Comentários
Aceita-se formatação à la TWiki. HTML e scripts são filtrados. Máximo 15KiB.

 
Enviando... por favor aguarde...
Comentário enviado com suceso -- obrigado.
Ele aparecerá quando os moderadores o aprovarem.
Houve uma falha no envio do formulário!
Deixei uma nota para os admins verificarem o problema.
Perdoe-nos o transtorno. Por favor tente novamente mais tarde.
Aldo Albuquerque | 2010-08-09 22:59:16 | permalink | topo

Se já não fosse o bastante, dá uma lida nessa matéia aqui: http://g1.globo.com/tecnologia/noticia/2010/08/orgaos-publicos-deixam-rg-cpf-e-ate-conta-corrente-de-cidadao-na-web.html

Henrique Arcoverde | 2010-08-09 14:42:18 | permalink | topo

Marco,

Discordo da idéia de que 'arquivo de backup acessível externamente' seja um caso particular de 'acesso direto não autenticado'. Na minha opinião não faz sentido a existência de 'acesso direto não autenticado' se não houver algum mecanismo de controle de acesso, seja este implementado através de cookies de sessão, range de IPs, certificado digital, etc. Por sua vez, ao meu ver, faz sentido a existência de 'arquivos de backup acessível externamente', mesmo que não haja um mecanismo de controle de acesso. No frigir dos ovos, eu considero o 'acesso direto não autenticado' uma falha de software introduzida por um desenvolvedor desatento (quando utilizados cookies de sessão), sendo necessário para corrigir o problema reavaliar o mecanismo de sessão implementado pela aplicação. O problema de 'arquivo de backup acessível externamente' por sua vez, ao meu ver, é um problema de -forçando a barra- configuração, sendo necessário para corrigi-lo, tão somente alterar a sua localização no sistema de arquivos para uma pasta fora do diretório de publicação do servido web.

Abraço!

Marco Carnut | 2010-08-09 12:23:03 | permalink | topo

Petuti,

Sempre louvo o rigor à terminologia, de sorte que sua colocação é totalmente pertinente. Todavia, encaro o termo 'arquivo de backup acessível externamente' como um caso particular do 'acesso direto não autenticado'.

Além disso, como deixei claro na conclusão, pretendo continuar esse assunto em um outro post, de sorte que a formulação genérica me facilitará as coisas.

Joao Lins | 2010-08-09 12:11:34 | permalink | topo

"No jargão técnico de segurança da informação, essa "vulnerabilidade" é conhecida como "acesso direto não autenticado"."

Acredito que para este caso específico alguns autores, e nós aqui de Pentest, costumamos nos referir a essa vulnerabilidade como "arquivo de backup acessível externamente", apenas pelo fato de não ser possível concluir que existiria uma interface onde fosse necessário autenticar para então ter acesso ao arquivo.

No mais um ótimo post e com ótimos exemplos dos cuidados e problemas que devemos ter cuidado.

[]'s

João Lins