Como o brute-forcer sabe que a senha está quebrada para o nome de usuário alvo?

2

Existem muitos ataques de força bruta (principalmente para o nome de usuário 'admin') em sites do WordPress. Todos esses ataques são feitos automaticamente por meio de solicitações de postagem.

A pergunta 1: como o brute-forcer sabe que a senha está quebrada para o nome de usuário alvo?

O brute-forcer tenta as senhas típicas como: '12345', 'qwerty' etc. E muitas vezes os administradores do site têm o nome de usuário 'admin' com a senha típica e esse nome de usuário é quebrado algumas vezes por força bruta. Limite de login-tentativas plugin resolver este problema muito bom pelo caminho.

A idéia e pergunta 2: se temos certeza de que é um ataque de força bruta (javascript-test ou cookie-test resolvem isso porque bots de força bruta não são clientes normais de navegador) do que é uma boa abordagem para dizer nada a todos, mesmo que a senha escolhida corretamente?

Discussão sobre WordPress.org fórum .

Atualização: Desenvolvi o plug-in de proteção de segurança . O plug-in adiciona o cookie na tela de login e verifica se esse cookie existe na solicitação POST. Se o cookie não existir, será uma solicitação de força bruta e a tentativa de login será bloqueada, mesmo que o nome de usuário e a senha estejam corretos. O plug-in envia cookies de login do WordPress para o bot de força bruta e o redireciona para a seção de administração para emular que a senha está quebrada e muitos forçadores brutos param seus ataques depois disso. É realmente incrível:)

    
por webvitaly 21.02.2013 / 22:54

3 respostas

7

As credenciais de login são processadas em wp_signon() e, se forem válidas, wp_set_auth_cookie() enviará um cookie no corpo da resposta HTTP.

O nome desse cookie é definido em uma constante denominada SECURE_AUTH_COOKIE ou AUTH_COOKIE . Ambos os nomes começam com wordpress_ .

Mas eles não precisam. Você pode definir essas constantes em wp-config.php e adicionar uma camada de obscuridade, para que o invasor não tenha certeza se é o cookie comum.

Você pode adicionar outra camada: conecte a ação 'wp_login_failed' e envie um cookie que realmente comece com wordpress_ . Você poderia nomear wordpress_logged_in por exemplo. Não faz nada, e não tornará seu blog mensurável mais seguro … mas não dói.

Por outro lado: o WordPress enviará um cabeçalho location e redirecionará o usuário após o login para outra página. Isso é fácil de detectar e mais difícil de contornar.

Uma verificação adicional que uso em muitos sites agora: Adicione uma nova caixa de seleção ao formulário de login por JavaScript com um nome exclusivo por site e solicite que ele seja verificado. Se não estiver marcado, a resposta será sempre uma página em branco, mesmo que a senha esteja correta . Você pode obtê-lo no GitHub: Campo de login exclusivo do T5 .

    
por fuxia 21.02.2013 / 23:57
2
  

é uma boa abordagem para dizer nada a todos, mesmo que a senha tenha sido escolhida corretamente?

Não. Não fará qualquer diferença para o hacker sofisticado, e para o dono do site é o mesmo se ele pode ser hackeado 10 vezes por script kiddies ou uma vez por um profissional.

  

como o brute-forcer sabe que a senha está quebrada para o nome de usuário alvo?

Se eu estivesse fazendo essas coisas, simplesmente tentaria acessar o examle.com/wp-admin e verificar se estou sendo redirecionado para a página de login.

De qualquer forma, sua suposição de que as pessoas fazem login apenas em navegadores é falsa. A partir de 3.5 O XML-RPC é ativado por padrão e você não precisa de nenhum JS ou cookies para tentar efetuar login com ele. Qualquer alteração que você fizer na maneira como o XML-RPC funciona provavelmente quebrará todos os aplicativos de publicação que usam o protocolo.

    
por Mark Kaplun 22.02.2013 / 06:44
2

Você está vendo esse problema do ponto de vista errado. Qualquer coisa que você faça que efetivamente impeça que um bot execute uma tentativa de fazer login na sua conta também impedirá um usuário geral. Qualquer coisa que um humano possa fazer, um programa bem escrito também pode fazer (e fazer mais rápido). Um cookie válido deve ser enviado no login bem-sucedido e é trivial para um programa testar se algum cookie enviado de volta é válido ou não, mesmo se você enviar cookies simulados em caso de falha ou alguma abordagem semelhante.

Dito isto, uma solução muito eficaz para impedir tentativas de login de força bruta é usar um plug-in que evite mais do que x número de logins em um determinado período de tempo. Limite de tentativas de login é um ótimo plugin que muitas pessoas usam e fazem isso para você (e sua pergunta sugere que você já considerou essa opção).

O motivo pelo qual a limitação das tentativas de login impedirá a força bruta é que nenhum usuário tentará fazer o login 100 vezes seguidas se ele for o usuário real, mas um bot tentará milhares e milhares de vezes. Qualquer senha decente será completamente impossível de ser decodificada se você estiver limitando as tentativas de 5 por hora (ou qualquer outro número razoável).

Eu sei que isso não responde muito bem a sua pergunta, mas espero que ele ofereça uma direção melhor.

Tudo de bom!

    
por Dan 17.04.2013 / 22:11

Tags