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.