Nate Anderson é um competente colunista da Ars Technica. Conhece profundamente tecnologia e os meandros do mercado. Mas não é e nunca foi um programador, portanto seu conhecimento nesta área é praticamente nulo. Também jamais havia se dedicado às práticas usuais dos chamados “hackers” e “crackers”, que se especializam em invadir computadores alheios e em roubar senhas e pouco ou nada sabia sobre seu “modus operandi”.
Há algumas semanas, trocando ideias com Dan Goodin, conhecido e respeitado colunista e editor da área de segurança digital da Ars Technica, Nate ouviu seu interlocutor comentar que a arte – se é que assim se pode chamar tal ação – de “quebrar” senhas, que um dia já foi considerada – e com justa razão – uma ciência arcana, nos últimos anos havia se tornado uma tarefa tão simples que estava à altura dos conhecimentos de qualquer “script kid”.
Nate estranhou. Afinal, “script kid” é a forma depreciativa pela qual os programadores se referem aos “aprendizes de feiticeiro”, geralmente jovens, que se fazem passar por perigosos “hackers”, alegando profundo conhecimento da técnica de programação, quando na verdade dela conhecem apenas o mínimo necessário para usar ferramentas sofisticadas – estas, sim, desenvolvidas por programadores de alto nível – de forma automatizada (ou seja, através do uso de “scripts”) para executar pequenas façanhas como desfechar ataques através da rede, invadir computadores alheios e quebrar senhas. Mas que nada conseguem se abandonados à própria sorte.
Será, pensou Nate, que quebrar senhas guardadas por complexos sistemas de proteção seria algo tão simples como dizia Goodin ou, quem sabe, Goodin apenas achava que assim era devido ao conhecimento que tinha do assunto? Afinal, como bem diz o ditado, “para quem sabe, tudo é fácil”. E para tirar a prova resolveu ele mesmo se converter em um “hacker” e tentar quebrar senhas. Se ele conseguisse fazer isto em pouco tempo, usando computadores comuns e tendo como base apenas seus escassos conhecimentos de programação, então de fato Goodin teria razão.
Com isto em mente, Nate estabeleceu um conjunto de regras e traçou a meta a ser alcançada: recorrendo exclusivamente ao que conseguisse obter na Internet e usando apenas ferramentas gratuitas rodando em simples computadores portáteis de médio a baixo poder de processamento, ele deveria: encontrar uma lista de senhas criptografadas para tentar “quebrar”, achar um programa para fazer isto, descobrir um conjunto de boa qualidade de palavras usualmente empregadas como senha e “quebrar” pelo menos uma senha em menos de um dia de trabalho.
Resultado? Em menos de doze horas ele havia decifrado mais de oito mil senhas e classificou a tarefa como “ridiculamente fácil”.
As venturas e desventuras de Nate Anderson para se converter em um pseudo “cracker” estão detalhadamente descritas em seu artigo “How I became a password cracker”, portanto não perderei tempo em relatá-las. Mas acho que cabe comentar as razões pelas quais, subitamente, tal façanha se despiu de toda dificuldade. E alertar os leitores de que quanto mais fácil se torna a tarefa de “quebrar” senhas, mais cuidados temos que tomar com a concepção das nossas…
Para começar, o que significa exatamente “quebrar” uma senha?
Bem, imagine, por exemplo, que um professor use a Internet para se comunicar com seus alunos. Coisas como esclarecer pequenas dúvidas, marcar datas de provas, fornecer acesso às listas de notas e quejandas. Nada de muito secreto, nada de confidencial. Ele apenas não deseja que aquelas informações se tornem públicas, já que não há interesse que terceiros tomem conhecimento delas. Mas, se tomarem, o prejuízo é nenhum. Então ele estabelece um singelo sistema de proteção por senhas que consiste apenas em uma tabela de dupla entrada: na primeira coluna a matrícula do aluno, na segunda a senha. Quando um aluno deseja ter acesso ao sistema de troca de informações com o mestre, entra com a matrícula e a senha. Uma rotina de programação simplesinha coleta a matrícula, busca por ela na primeira coluna, recolhe a senha correspondente na segunda e compara com a fornecida pelo aluno. Se conferir, toca o bonde. Se não, recusa o acesso. Mais simples, impossível. Menos segura, também. Porque se o arquivo que contém a tabela for surripiado, quem estiver de posse dele tem acesso a todas as informações de todos os alunos. As senhas estão lá, íntegras, portanto não precisam ser “quebradas”,
Por esta razão um sítio que se preza jamais usa um sistema tão simples. Mas, seja lá o que use, não pode ser muito diferente. É aí que entra a criptografia.
Imagine aquela mesma lista de matrículas ou endereços de correio eletrônico, identidades de usuário (“userID”) ou qualquer outro conjunto de caracteres que sirva para identificar o usuário, e as senhas correspondentes. Agora, pegue cada senha e aplique a ela uma função matemática de conversão unidirecional (já explico) capaz de, recebida a senha, convertê-la em um conjunto único de caracteres. Este conjunto é denominado “hash” e é ele que fica arquivado ao lado da “userID” correspondente.
Quando o usuário entra com sua “userID” e senha, o sistema coleta a “userID” e efetua a busca na tabela. Lá ele não encontra a senha, encontra o “hash”. Então, recolhe a senha inserida pelo usuário, aplica nela a mesma função matemática que, naturalmente, gerará o mesmo “hash”. Agora, sim, o compara com o que está arquivado em sua tabela. Se coincidirem, a senha confere e o acesso é permitido. Se não, não.
O sistema é seguro devido a unidirecionalidade da função. Os que não entenderam exatamente o que isto significa quando mencionado acima, entenderão agora: o fato da função ser unidirecional significa que, fornecida a senha, ela gera o “hash” (sempre o mesmo para cada senha e jamais dois iguais para senhas diferentes). Mas não há meios de, fornecido o “hash”, obter-se a senha. Ou seja: ela não funciona no sentido oposto.
Isto quer dizer que se a lista for furtada, tudo o que o ladravaz consegue é uma lista de “userIDs” e “hashes”. E como não há meios de converter um “hash” em uma senha (pois a função é unidirecional), os usuários podem se considerar seguros. Ou podiam…
Por que “podiam”?
Porque alguns “hackers” e “crackers” verdadeiros desenvolveram programas que, com base em uma lista de palavras e expressões que as pessoas usam costumeiramente como senhas e conhecendo o algoritmo de criptografia (ou seja: a função matemática unidirecional usada para gerar o “hash”), são capazes de percorrer a lista de palavras, uma a uma, usando o algoritmo para criar seu “hash” e compará-lo com o armazenado na lista de senhas para um dado usuário. Como é impossível que dois diferentes conjuntos de caracteres gerem o mesmo “hash”, quando houver uma coincidência a senha foi quebrada, ou seja, aquele “hash” corresponde à palavra testada que, por sua vez, é a senha da vítima. Se percorrida toda a lista de palavras não houver coincidência é porque a senha do usuário não consta da lista, o programa passa para o próximo usuário e repete o procedimento. E se, esgotada a relação de usuários, nenhuma senha foi “quebrada”, provavelmente o algoritmo usado pelo sítio não foi o mesmo usado pelo “cracker”. Então basta mudá-lo e recomeçar.
Nesta altura dos acontecimentos creio que você está achando que a tarefa é quase impossível e que demoraria um tempo enorme para criar os “hashes” de cada palavra da lista e compará-los, um a um, com os armazenados na lista de senhas. E se nenhuma coincidência for encontrada, mudar a função usada para criar o “hash” e começar tudo de novo.
Engana-se. Primeiro porque não são muitas as funções usadas para gerar “hashes” e não é difícil para o programa experimentá-las uma após outra, até encontrar a efetivamente adotada pelo sítio que criptografou as senhas (lembre que se uma única coincidência for encontrada, aquela é a função certa). Segundo porque os programas de quebra se senhas são tão otimizados que não consomem muito tempo mesmo rodando em máquinas simples (Nate usou um Core i5 MacBook Air e um velho Dell Core 2 Duo). E terceiro porque os verdadeiros “crackers” usam máquinas poderosíssimas equipadas com múltiplas GPUs (Graphics Processing Units) de última geração para acelerar o processamento, como a exibida na ilustração desta coluna (obtida no sítio Hack A Day). Como as GPUs, embora destinadas originalmente a processamento gráfico, são basicamente processadores matemáticos de alta capacidade de processamento, elas aceleram absurdamente o procedimento. O sítio Hack A Day informa que foi montada uma máquina com 25 GPUs capaz de gerar 348 bilhões de “hashes” por segundo. Bilhões! O preclaro leitor consegue avaliar o que isto significa?
Então, nesta altura dos acontecimentos, você já descobriu o ponto fraco desta técnica, pois não?
Claro que sim: a senha da vítima tem que estar na lista de palavras usadas para gerar os “hashes” que serão comparados com os armazenados no arquivo que guarda as senhas criptografadas. Se ela não estiver lá, jamais será quebrada.
Então tudo, agora, depende da abrangência desta lista.
Nos tempos de antanho, esta lista era gerada compilando palavras de um dicionário e criando “regras” para gerar variações delas. Estas regras incluem substituir minúsculas por maiúsculas, adicionar ao final ou início dos vocábulos um conjunto de números, inserir símbolos no corpo das palavras e pequenas alterações desta ordem. Mas não é preciso idealizá-las: Nate encontrou na Internet diversos arquivos de regras que já vêm prontos para serem aplicados aos programas de “quebra de senha”, também disponíveis na rede. Assim como, disponíveis na rede, há diversas listas de usuários e “hashes” de suas senhas, arquivos estes furtados após invasão de servidores.
Mas ainda assim a coisa era complicada, já que muitas das senhas usadas pelos usuários comuns não constam de qualquer dicionário. A eficiência do processo melhoraria muito caso se dispusesse de uma longa lista de senhas “de verdade”, conjuntos de caracteres efetivamente adotados pelos usuários como senhas.
Foi então que ocorreram alguns fatos que facilitaram muito a vida dos “crackers”, inclusive e principalmente a dos “script kids”.
Em 2009 um dos servidores do sítio RockYou.Com foi invadido. Trata-se de um sítio voltado predominantemente para simples jogos para uso “online” por usuários de redes sociais, portanto nada havia de muito sigiloso a proteger. E seus responsáveis cometeram o erro crasso de simplesmente armazenar sua lista de “userIDs” e senhas como texto puro sem empregar qualquer algoritmo de criptografia, ou seja, juntar tudo em uma tabela parecida com aquela do professor citado lá no começo da coluna. Só que bem maior.
Este arquivo foi furtado e 32 milhões de senhas em texto puro caíram nas mãos dos “crackers”. Depois de removidas as duplicadas, o total caiu para “apenas” 14 milhões de senhas. Depois disto, algo parecido aconteceu com o sítio Gawker (eles não armazenavam as senhas em texto puro, mas sua lista de senhas criptografadas “vazou” e 1,3 milhões delas foram “quebradas” e adicionadas à lista de palavras). E em junho do ano passado o mesmo ocorreu com o LinkedIn. Resultado: mais seis milhões de senhas foram adicionadas à lista de possíveis senhas – também disponível na rede.
Agora, basta pensar um pouco. Pegue a lista de palavras obtidas dos dicionários de diversos idiomas, agregue a elas os milhões de exemplos de senhas efetivamente usadas pelos usuários e aplique a este conjunto as regras mencionadas um pouco acima. O resultado é, sem exagero, bilhões de conjuntos de caracteres que podem – e normalmente são – usados como senhas.
Dificilmente as suas não estarão lá.
E rodando o programa de “quebra de senhas” em uma máquina poderosa, destas que podem gerar centenas de bilhões de “hashes” por segundo, serão “quebradas” em minutos.
E mais: se você é daquele tipo de usuário que adota a mesma senha para tudo, desde as contas bancárias até o correio eletrônico, passando pelas redes sociais, “quebrada” uma estarão “quebradas” todas.
É preocupante, pois não?
Pense a respeito, consulte os artigos sobre criações de senhas “seguras” e cogite seriamente em mudar as suas. Garantidamente seguro você não estará. Mas pelo menos dificultará um pouco a tarefa dos “crackers”.
Ou de suas máquinas e programas…
B. Piropo
Fonte: ITWEB
Nenhum comentário:
Postar um comentário