BT

Ataques a grandes aplicações web: a comunidade brasileira está preparada?

Postado por Eder Ignatowicz em 22 Jun 2012 |

Como noticiado recentemente no InfoQ Brasil e em vários outros meios, o Linkedin foi vítima de um ataque no qual foram comprometidas milhões de senhas de seus usuários. E fontes não oficiais sugerem que o eHarmony e o Last.fm também foram vítimas de ataques do mesmo tipo. Quais medidas preventivas poderiam ser tomadas por estas companhias? A comunidade de desenvolvimento brasileira estaria preparada para enfrentar tais ataques? O InfoQ Brasil realizou uma análise deste episódio e convidou dois especialistas brasileiros para responder estas e outras questões.

O que os ataques citados têm em comum é a exploração de vulnerabilidades no armazenamento seguro das credenciais dos usuários. O suposto método de proteção utilizado (hash "unsalted" SHA1 pelo LinkedIn e hash "unsalted" MD5 no last.fm) estão desatualizados e são notoriamente vulneráveis. O suposto vazamento levanta dúvidas em relação ao nível de atenção e cuidado que as companhias têm com a privacidade dos dados dos usuários. Se ataques desta gravidade ocorrem com empresas de renome mundial, o que podemos esperar do mercado brasileiro?

A fundação Mozilla fez várias considerações em relação aos riscos no armazenamento de senhas e aos erros cometidos neste episódio, que apresentamos a seguir.

  • Nunca armazene as suas senhas em texto claro

Apesar de trivial, muitas empresas ainda armazenam as senhas em texto claro (não criptografado) no banco de dados. Sistemas que utilizam esta abordagem são extremamente vulneráveis, pois em caso de comprometimento da base de dados, todas as senhas dos usuários estarão vulneráveis. A primeira opção para amenizar esse risco é através de técnicas de hashing. Contudo, esta abordagem não é tão segura quanto parte da comunidade de desenvolvimento acredita, e está diretamente ligada ao episódio do Linkedin.

  • Tenha muito cuidado a utilizar técnicas de hashing tradicionais:

A ideia das técnicas de hashing é baseada em funções de "uma via": pelas quais, dada uma entrada de uma função, como a senha do usuário, o algoritmo (MD5 ou SHA-1) retorna um valor hash. Como exemplo, o valor do hash para a palavra "infoq" utilizando MD5 é "63ebae98203740ef1ab6bebfad83c120".

O cálculo do hash a partir de um valor é computacionalmente simples de ser realizado, mas a função inversa (ou seja, dado o valor calculado de um hash encontrar qual é a valor original) é proibitiva, dado seu alto custo computacional. Dessa forma, mesmo que a base de senhas de sua empresa seja comprometida, seria difícil calcular o valor original das senhas dos usuários.

O problema desta abordagem é que grande parte dos usuários utiliza senhas triviais. Como o hash calculado a partir de uma palavra é sempre o mesmo, basta calcular o hash através das palavras de um dicionário e compará-lo com o hash encontrado na base comprometida. Além disso, todos os usuários que possuem a senha idêntica à revelada seriam expostos (pois possuem o mesmo valor de hash calculado).

Ainda é possível encontrar tabelas hash pré-calculadas (Rainbow Tables), em que combinações mais elaboradas envolvendo números e letras (como por exemplo, "password1", "s3nh4", "s3cr3t123") são disponibilizadas facilitando a comparação com os valores encontrados na base comprometida. Esta categoria de ataque é conhecida como ataque de dicionário e se trata de um ataque bastante conhecido. De forma a reduzir o risco de ataques de dicionário, existe uma técnica conhecida como "salted hashing". Quanto a isso, a fundação Mozilla reforça:

  • Senhas tornam-se mais seguras quando são acrescidas de um valor (salt) ao cálculo do hash

Através de um valor aleatório adicionado à senha (denominado salt), reduz-se o risco do ataque de dicionário. Como exemplo, podemos adicionar à senha do usuário um valor aleatório, como algum número de identificação. Dessa forma, um usuário com a senha "password" teria um hash criado para este valor concatenado a um número aleatório. Como o salt é variável para cada usuário e o valor do salt é aleatório, o cálculo através da função inversa torna-se extremamente difícil e lento, pois seria necessário descobrir qual o valor de salt para cada usuário. Dessa forma, a nova função hash é calculada, sendo armazenado o valor correspondente ao hash da senha, acrescido do valor do salt. (Usando notação funcional: H: senha -> H(senha + salt)).


Para avaliar o caso e a situação atual da segurança brasileira, o InfoQ Brasil ouviu dois especialistas brasileiros em segurança da informação: Rodrigo Miani e Antonio Luiz de Almeida Vieira.

Em que ponto você acredita que essas empresas falharam neste episódio?

Antonio Luiz Vieira: Basicamente o que foi explorado nesses ataques foi uma brecha nos sites ou aplicações web. Atualmente, como a maioria das empresas investe bastante em proteção de infraestrutura, com firewall, sistemas de detecção de intrusão, proxy etc., os atacantes exploram o ponto descoberto: as aplicações. Se essas empresas tivessem dado mais atenção a esse ponto tão importante hoje em dia, alguns dos ataques poderiam ter sido evitados, através do desenvolvimento seguro, testes constantes e controle de vulnerabilidades.

Rodrigo Miani: Do meu ponto de vista, a principal falha foi o vazamento das informações. O banco de dados com senhas de clientes, claro, é um ponto extremamente crítico para qualquer organização e merece atenção diferenciada dos profissionais de segurança. Outro ponto importante é a possível utilização de hash simples para o armazenamento de senhas. Outros métodos para o armazenamento de senha que envolvem o uso de salt são importantes para melhorar o nível de segurança de uma base de dados de senhas, em caso de vazamento de informações.

Quais as suas recomendações de segurança em relação ao armazenamento de senhas dos sistemas sobre os quais nossos leitores são responsáveis?

Vieira: Além de utilizar criptografia com algoritmos fortes (de 1024 ou 2048 bits), evitar ao máximo situações em que um possível atacante tenha acesso a esses servidores diretamente, utilizando segregação de rede. Além disso, utilizar uma metodologia de desenvolvimento seguro, que proteja a primeira camada da aplicação de entradas maliciosas digitadas por seus "usuários".

Miani: Na medida do possível, é importante sempre utilizar os métodos de armazenamento mais seguros, além de, vale repetir, evitar o armazenamento em claro; evitar o uso do MD-5 e utilizar métodos de hash com salt, como o Password-Based Key Derivation Function 2 (PBKDF2).

Qual sua impressão quanto ao nível de preocupação com segurança na comunidade de desenvolvimento brasileira?

Vieira: No Brasil ainda é quase desconhecido o conceito de desenvolvimento seguro; quem tem maior conhecimento disso são os profissionais de segurança, e não os desenvolvedores em si. Enquanto nas formações de desenvolvedores esse tema não for abordado, dificilmente um profissional, que nem sabe que isso existe, buscará algum tipo de qualificação nessa área. Conheço empresas em que até mesmo o TDD (desenvolvimento orientado a testes) é proibido, alegando que demanda maior tempo para o desenvolvimento e que não vale a pena.

Outras empresas preferem realizar correções já nas fases de homologação ou produção, o que sai muito mais caro financeiramente do que se os testes e correções forem realizados ainda nas fases iniciais do desenvolvimento. O quesito segurança está mais descoberto ainda, pois é necessário que os desenvolvedores conheçam as falhas e como são exploradas, e profissionais com esse perfil são difíceis de encontrar no mercado atualmente. Isso mostra o quanto as empresas ainda investem pouco na formação e atualização de seus funcionários responsáveis pelo desenvolvimento de seus sistemas.

Miani: Um grande problema em segurança da informação no Brasil está relacionado ao ensino, ou seja, como inserir no currículo dos cursos de computação disciplinas como Criptografia e Programação Segura. Atualmente são raros os cursos relacionados à computação que possuem disciplinas específicas para tratarem de problemas de segurança e quando existem, este tipo de problema geralmente não é abordado. A ausência de profissionais especializados pode ser um "gargalo", mas boas práticas de segurança da informação, principalmente relacionadas à programação segura, podem ser inseridas ao longo da graduação, incentivando o aluno a trabalhar com esses problemas desde o início de sua formação.

Você acredita que as grandes empresas brasileiras estão imunes a esse tipo de ataque? Se não, quais medidas se pode tomar para reduzir o risco?

Vieira: De forma alguma estão imunes. Em todas as auditorias e testes de invasão que realizei, as maiores complicações foram encontradas nas aplicações web desses clientes. A melhor forma de diminuir esse risco é se preocupar com o desenvolvimento e implementar metodologias comprovadas de desenvolvimento seguro. Atualmente, um dos maiores órgãos internacionais, que possui diversos projetos sobre esse tema, é o OWASP (Open Web Application Security Project), uma fundação sem fins lucrativos, que realiza pesquisas e desenvolve materiais, projetos e metodologias na área de desenvolvimento seguro.

Miani: Ninguém está imune a um ataque desse tipo. São três principais pontos que devem ser considerados:

  • Proteção do banco de dados para que este não esteja vulnerável a ataques internos "insiders" e externos;
  • O uso de técnicas ineficientes para o armazenamento das senhas, como por exemplo o armazenamento em claro, o uso do MD-5 ou o uso de funções de hash sem salt;
  • Utilização de senhas fracas, facilitando o ataque de dicionário nos hashes divulgados. A principal medida que um usuário pode tomar é o emprego de senhas fortes e escolher senhas diferentes para contextos diferentes: uma senha de banco nunca deve ser usada em um formulário online, por exemplo.

Sobre os entrevistados

Rodrigo Sanches Miani possui graduação em Matemática pela Universidade Federal de São Carlos (2005) e mestrado em Eng. Elétrica pela Universidade Estadual de Campinas (2009), onde atualmente cursa doutorado em Engenharia Elétrica, com período "sanduíche" na Universidade de Maryland, College Park, EUA. É também professor das disciplinas relacionadas à Segurança da Informação na FACCAMP. Seus interesses de pesquisa incluem modelos de quantificação de segurança da informação, métricas de segurança, e estudos empíricos em segurança e criptografia.

Antonio Luiz de Almeida Vieira é especialista em Segurança da Informação; atua na área de TI desde 1995, com larga experiência em web, desenvolvimento, segurança e Linux. Ministrou diversos treinamentos para forças armadas, órgãos públicos, Polícia Civil e Polícia Federal. Atua com Testes de Invasão, Forense Computacional, Análise de Malware e Consultoria na área de Segurança da Informação. É Sócio-diretor do Grupo OYS.

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão
Comentários da comunidade

Bom artigo by Eduardo Souza

É bom resaltar que na utilização do salt nunca deve ser utilizados dados do próprio usuário para sua confecção como tamanho do nome do usuario, login, data de nascimento ou qualquer outro dado utilizado no momento do cadastro, vi em alguns casos em que utilizavam estes dados criptografados como salt, desta forma alguém mal intencionado pode criar um cadastro e verificar após a invasão se a senha possui algum dado seu utilizado como salt.

Acredito eu que o salt deva ser um dado gerado por um algoritmo próprio do site com criptografia própria, ou um bom algoritmo de embaralhamento de senha criptografada.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

1 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT