Um ataque de dicionário é um método de cracking que consiste em tentar advinhar uma senha provando todas as palavras do dicionário ou combinações de palavras. Este tipo de ataque costuma ser mais eficiente que um ataque de força bruta, já que muitos usuários costumam utilizar uma palavra existente em sua língua ou combinação de palavras como senha. Muitos usuário fazem isso para que a senha seja fácil de lembrar, o que não é uma prática recomendável.
A figura abaixo demonstra uma das tentantivas que o atacante fez para tentar adivinhar o usuário e a senha de um site baseado em WordPress.
Os cabeçalhos e o formato desta solicitação HTTP POST são bem semelhantes a uma solicitação legítima feita por um usuário e um navegador web comum. O cabeçalho User-Agent destacado em verde na figura, descreve que a solicitação foi feita por navegador Firefox instalado num sistema operacional Linux 32 bits. Porém conforme análise dos logs que será descrita a seguir, observamos que a solicitação HTTP foi montada por um script ou programa de computador. Todos os cabeçalhos podem facilmente ser falsificados. Para o atacante, é interessante que a solicitação seja o mais parecida possível com uma solicitação legítima, desta forma, dificulta a criação de filtro para bloquear o ataque.
No segundo destaque em verde da figura acima, podemos observar que nesta tentativa, o atacante tentou o entrar no WordPress com usuário root com a senha Jessica.
Ao analisar os logs no servidor web, podemos observar que o IP 35.59.7.115 enviou várias solicitações HTTP POST para a página wp-login.php conforme figura abaixo.
Foi destacada na figura acima, a hora da solicitação. Podemos observar que foi feita uma solicitação por segundo. Com esta observação, concluímos que as solicitações foram feitas por uma processo automatizado.
Segue abaixo, uma amostra dos nomes de usuário e senhas usadas nas tentativas do atacante. Embora existam muitas palavras em inglês, este ataque foi feito com uma banco de senha em português muito provavelmente criado por brasileiros.
(...) log=root pwd=Password log=root pwd=Nicole log=root pwd=Daniel log=root pwd=Jessica log=root pwd=Lovely log=root pwd=Michael log=root pwd=Ashley log=root pwd=porsche log=root pwd=firebird log=root pwd=rosebud log=root pwd=guitar log=root pwd=butter log=root pwd=beach log=root pwd=jaguar log=root pwd=chelsea log=root pwd=united log=root pwd=amateur log=root pwd=great log=root pwd=black log=root pwd=turtle log=robsonidr pwd=mariposa log=robsonidr pwd=america log=robsonidr pwd=Password log=robsonidr pwd=Nicole log=robsonidr pwd=Daniel log=robsonidr pwd=Jessica log=robsonidr pwd=Lovely log=robsonidr pwd=Michael log=robsonidr pwd=Ashley (...)
Qual o risco deste ataque
Se você usa uma senha forte e não baseada em palavras simples, você já dificulta a vida do atacante. Porém, o grande desafio é garantir que todos os usuários, inclusive os usuários de marketing, áreas de negócios e outros tipos de usuários adotem senhas seguras.
Mesmo que você implemente um política de senha complexa, ainda existe o risco do atacante também evoluir sua base de senhas usada no ataque.
Para minimizar o risco de um atacante roubar a senha de algum usuário com este ataque, é importante que o ataque seja bloqueado.
Outro problema é o risco de ocorrer incidentes provocados pelo excesso de soliticações HTTP como, por exemplo, problemas no desempenho do ambiente, excesso de log, etc.
Como se proteger deste ataque
A forma mais prática e fácil de se proteger deste ataque é a utilização de um Web Application Firewall (WAF) que tenha um módulo de DoS no nível de aplicação.
No WebViser, um WAF desenvolvido para uso interno da Batori, a criação de uma simples regra de DoS para a página wp-login.php iria bloquear este ataque de forma muito simples.
Uma outra solução que exige mais esforço é criar um script que analise continuamente o log do servidor web e que identifique a quantidade anormal de solicitações HTTP POST para a página de login. Quando isso ocorrer, o script deverá bloquear o IP através de regras de firewall (iptables) e/ou alarmar a equipe de resposta a incidentes que deverá tomar as ações necessárias, como por exemplo, criar regra no firewall de rede para bloquear o IP, notificar o responsável pelo IP, etc.