** artigo publicado na Revista RTI edição de Outubro/2012 **
Um dos temas
que mais chamaram a atenção no últimos meses foi o ataque sofrido pelo jornalista
Matt Honan, da revista Wired. Para aqueles que não acompanharam o caso, ele
teve roubadas suas credenciais de acesso ao Google, Twitter, Amazon e Apple;
além de seu iPhone, iPad e Macbook completamente apagados. Como ele mesmo
declarou, sua vida digital foi arruinada em menos de um dia. A história
completa está contada no endereço próprio do jornalista, http://www.wired.com/gadgetlab/2012/08/apple-amazon-mat-honan-hacking.
Lá também está a descrição de como ele conseguiu recuperar os seus dados, em http://www.wired.com/gadgetlab/2012/08/mat-honan-data-recovery.
O que mais vale
nesse episódio não é o seu resultado, que será ainda contado por anos em
palestras pelo mundo, mas suas entrelinhas. Todo o procedimento seguido, linha
de raciocínio e vulnerabilidades exploradas estão não só descritas como
detalhadas. Temos ainda a revelação de que o ataque não foi pessoal. Phobia, o
invasor, disse à própria vítima que não tinha nada contra ele e que queria
apenas invadir sua conta do Twitter. Algo como um exercício. É a confirmação de
que ninguém pode nem deve sentir-se totalmente seguro na Internet. Há ainda o fato
de que todo o processo de invasão se deu com o uso exclusivo da Engenharia
Social, a técnica de ganhar acesso a um edifício ou sistema, ou de obter um
resultado qualquer através da interação social, sem a quebra da segurança
física ou digital do alvo. O método é normalmente associado à enganação mas na
verdade é mais complexo que isso, pois requer que alguma vulnerabilidade não tecnológica
seja explorada, como processos mal escritos e falhas de treinamento de pessoal.
E foram essas
as vulnerabilidades exploradas pelo hacker Phobia para atingir seu objetivo.
Ele não precisou quebrar a segurança de nenhum sistema dos provedores, tampouco
precisou decodificar senhas ou invadir os equipamentos da vítima para apagar os
dados. Ele apenas se aproveitou de
procedimentos mal definidos ao se fazer passar pelo jornalista ao telefone e
obter o acesso aos serviços. O principal erro das empresas foi o de solicitar
dados de identificação pessoal que podem ser facilmente obtidos na Internet.
A primeira
vista esses erros podem parecer grosseiros, mas não encaro assim. Vejamos o
caso da Amazon. Ela permitiu sem muita dificuldade que o impostor adicionasse
um novo cartão de crédito à conta de Honan. Para isso eles pediram nome, email
e endereço; todas informações fáceis de se obter. Mas o autor desse
procedimento iria com certeza perguntar: mas para que alguém iria incluir um
cartão de crédito na conta de outra pessoa? Não deixa de fazer sentido. Se o
cliente quer incluir um cartão para que criar dificuldades? A resposta não está
nesse procedimento mas em outro, para recuperar a senha. Para isso eles pediam
nome, endereço e o número do cartão de crédito registrado, algo certamente
difícil de se obter a não ser que, sim, o próprio invasor o tenha incluído na
conta. A única maneira de se evitar uma situação assim é pensar como o hacker,
algo que muitas empresas não estão preparadas para fazer.
Há ainda outra
entrelinha. Senhas são a nossa primeira linha de defesa, para muitos serviços
online a única. Quanto maiores e mais variadas, mais “fortes”, seguras, elas
são. Esta certamente não era uma preocupação para o jornalista, já que ele
contou utilizar uma ferramenta de administração de senhas, que gera códigos com
mais de dez dígitos e grande variação de caracteres. Ele se julgava seguro
dessa forma, e ninguém pode dizer que estava enganado. Por muito menos a maior parte dos usuários se sente seguro
apenas porque troca suas senhas a cada 90 dias. Eu sou um crítico dessa “boa
prática”. Não discordo dela mas sim da maneira como é implementada. Em muitos
sites essa é a única medida de segurança para seus usuários, que continuam a
usar senhas compostas de números ou combinações simples, apesar de trocá-las
periodicamente. O pior risco é a falsa sensação de segurança.
Qual então a
solução? Para os usuários infelizmente não há nada o que fazer quando seus
provedores não fornecem recursos melhores. Mas eles existem em alguns casos, e
devemos aprender a utilizá-los. Um bom exemplo é o Google e o Facebook, que possuem
como opção a autenticação em duas fases quando o acesso é feito de um
computador nunca antes usado pelo usuário.
No caso deles o telefone se torna o segundo fator de autenticação, seja
ao receber um SMS com uma segunda senha, ou via aplicativo nele instalado. É o
mesmo método usado por muitos bancos no Brasil para avisar de uma operação de
débito ou crédito. Já o UOL envia mensagem de SMS quando a senha é alterada,
medida também implementada por alguns bancos brasileiros para avisar seus
clientes de operações diversas. Mas para isso é necessário que o telefone
celular esteja cadastrado, o que muita gente não faz.
Para as
empresas é necessário repensar. Por que não implementar um segundo fator de
autenticação para algumas tarefas, como por exemplo, a troca da senha? Não
menos importante são as perguntas de identificação positiva no atendimento
telefônico. Dados tidos como confidenciais, como CPF ou identidade, podem ser
comprados facilmente, ou obtidos no lixo residencial ou empresarial. Um bom
exemplo de identificação positiva, pouco usada e muito mais eficiente, é
permitir que o próprio cliente cadastre suas perguntas e respostas, geralmente
de cunho pessoal e que um impostor dificilmente irá obter. É possível também
fazer um trabalho melhor com as senhas. O primeiro passo é permitir letras
maiúsculas e minúsculas, além de caracteres especiais. Só números e letras minúsculas é muito pouco. Segundo,
não limitar o tamanho da senha em apenas oito caracteres. Este deve ser o
mínimo mas certamente não o máximo. É necessário que as empresas deixem de
seguir somente o que aparenta ser a boa prática e pesquisem casos e exemplos diferentes
em seu e em outros mercados.
