Vulnerabilidades no Anti robo Captcha do Login

[amuller]

O Captcha do login não funciona de forma que deveria, pois utiliza o cookie como contador. O que não é adequado pois robos não utilizam o cookie ou limpam ele.

Além do captcha gerado passar com sucesso em leitores de ocr (reconhecimento de caracteres) com facilidade.

Teste realizados com gocr Chance de acerto de 80%.

Qualquer ambiente servidor e cliente

[niltonneto]

Eu usei  esse aqui no Expresssolivre Org. Será que é melhor?

[antonio-carlos.silva]

Bom.

Primeiro vamos resolver o problema do contador ficar no cookie.

Assim, estamos realocando o contador na sessão, eliminando o cookie.

[niltonneto]

Olá Antonio, como está a implementação nova do Captcha (sem uso de cookies)?

[antonio-carlos.silva]

Olá,

Estou testando a implementação do contador dentro de uma sessão.

O problema são os "headers", que provocam a perda da sessão, do jeito como esta estruturado o login.

[antonio-carlos.silva]

Alterado para ter o contador em sessão. Revisão [3437] .

[rodsouza]

Utilizar sessão e utilizar cookie são sinônimos, assim tal alteração não mudará o fato de que remover o cookie possibilitará que o dito robo continue o procedimento.

[antonio-carlos.silva]

Bem lembrado. Mas tentamos o seguinte:

Se não existir a sessão o usuario não é validado. Não é feita tentativa de autenticar e só redireciona com msg de usuario/senha invalidos.

[rodsouza]

Então o captcha não terá efetifidade, pois o cookie pode ser removido em todas as tentativas de login e assim nunca validado, e isso ocorrerá até o robo acertar a senha, caso consiga.

[niltonneto]

O Rodrigo tem razão, Antonio. A forma implementada não elimina o problema descrito.

[amuller]

Na parte de geração da imagem eu posso ajudar vocês, eu tenho uns códigos legais pra isso. Se ninguem tiver trabalhando nisso.....

[zapa]

O princípio é utilização de algum arquivo comum que seja diferente em cada instalação

e que sirva como base de criptografia para geração do cookie.

É usado o arquivo header.inc.php para geração de chave de criptografia

a ser inserido no cookie e sua existencia ou modificação são retestados na volta, desde que o captcha esteja configurado a aparecer.

Alguém poderia testar?

[rodsouza]

Replying to zapa:

O princípio é utilização de algum arquivo comum que seja diferente em cada instalação

e que sirva como base de criptografia para geração do cookie.

O que será criptografado?

É usado o arquivo header.inc.php para geração de chave de criptografia

a ser inserido no cookie e sua existencia ou modificação são retestados na volta, desde que o captcha esteja configurado a aparecer.

Não entendi. Poderia exemplificar com um caso prático?

[amuller]

r3444 faz a melhoria na imagem. Testei com GOCR foi 100% de falha no reconhecimento.

[antonio-carlos.silva]

Bom dia.

Bom, se o cookie tiver sido removido, o login não valida o usuaŕio. Não é feita a autentificação do usuário. Simplesmente retorna usuário inválido.

O que é criptografado é o id da sessão.

Mas é muito "chumbo" pra acertar um "captcha", digo, passarinho...

Reformulei tudo.

Tive que acertar o login porque os "redirecionamentos" prejudicavam o uso(permanencia) da sessão. Não vai mais usar o cookie.

[rodsouza]

Após habilitar o uso do captcha não é mais viável utilizar o Expresso, apenas a frase "Error in access. Please, alert the Administrator.*" é exibida.

Qual configuração extra é preciso?

[rodsouza]

Isso $_SERVERDOCUMENT_ROOT? não é parâmetro em todas as utilizações do Expresso, assim estou alterando para DIR, pois o erro é não encontrar o "header".

[rodsouza]

Alterando a variável que indica o diretório do ExpressoLivre?

login.php

Committed revision r3446.

[rodsouza]

A alteração da revisão r3446 deve-se a "md5_file(/var/wwwheader.inc.php)".

Outra situação é "session_start(): The session id is too long or contains illegal characters, valid characters are a-z, A-Z, 0-9 and '-,'"

Além de que não há uma verificação das funções PHP referente a imagem antes da utilização.

[rodsouza]

Esqueci que " DIR " não é compatível com o Expresso, estou removendo.

[rodsouza]

Utilizando 'Magic constants' para definir o path.

login.php
security/captcha.php

Committed revision r3447.

[antonio-carlos.silva]

Modificado para não usar cookie no login.

Alterado na revisão [3348].

[niltonneto]

Replying to antonio-carlos.silva:

Modificado para não usar cookie no login.

Alterado na revisão [3348].

Opa, só corrigindo: A revisão é [3448] e não [3348].

[rodsouza]

Após alguns ajustes necessários na biblioteca GD do PHP, para a utilização da função "imagettftext", assim habilitando o captcha efetivamente, o simples fato de apagar o cookie faz um robo executar inúmeras requisições sem problemas.

E nem é preciso presocupar-se com a imagem, ou seja, o captcha acaba não tendo utilidade.

Não adianta de nada criptografar cookie e criar captcha se o meio que a informação está sendo armazenada é volátil.

Quando o robo, ou mesmo uma pessoa acertar a senha então tudo passará a funcionar, com ou sem criptografia.

[rodsouza]

Outra questão, o que significa ZABX?

[eduardoalex]

Antonio,

Como ficou essa questão?

[antonio-carlos.silva]

Alterada a imagem do captcha, e o contador foi passado para uma variável dentro da sessão.

Resolvido.

[rodsouza]

Replying to rodsouza:

Outra questão, o que significa ZABX?

O que significa ZABX?

[antonio-carlos.silva]

Não significa nada em particular. Apenas o nome de uma variável, qdo foi usado nomeava uma sessão.

[niltonneto]

Antonio, por favor, registre o número da revisáo para a última implementação. Rodrigo, por favor, efetue os testes anteriores.

Obrigado.

[rodsouza]

Teste anteriores?

[niltonneto]

Robozinhos, cookies, contador, captcha, enfim, analise o que foi feito e veja há algum risco ainda, já que você participa do workgroup de segurança.

[rodsouza]

Replying to niltonneto:

Robozinhos, cookies, contador, captcha, enfim, analise o que foi feito e veja há algum risco ainda, já que você participa do workgroup de segurança.

Replying to rodsouza:

Após alguns ajustes necessários na biblioteca GD do PHP, para a utilização da função "imagettftext", assim habilitando o captcha efetivamente, o simples fato de apagar o cookie faz um robo executar inúmeras requisições sem problemas.

E nem é preciso presocupar-se com a imagem, ou seja, o captcha acaba não tendo utilidade.

Não adianta de nada criptografar cookie e criar captcha se o meio que a informação está sendo armazenada é volátil.

Quando o robo, ou mesmo uma pessoa acertar a senha então tudo passará a funcionar, com ou sem criptografia.

[rodsouza]

Como já tinha descrito e agora replicado acima...

[niltonneto]

Rodrigo, pelo que eu conversei aqui com Zapa, isso não é mais possível após a última implementação feita pelo Antonio. Se vc tiver certeza do que está dizendo, preciso de uma comprovação técnica.

[rodsouza]

Utilizando as palavras do próprio ZAPA

Replying to zapa:

Alguém poderia testar?

Não precisa de nenhum robo, muito menos conhecimentos profundos, apenas faça aparecer a imagem e remova os cookies.

E tem mais mesmo com o captcha, sem remover o cookie, não há validação.

[rodsouza]

Qual a parte de "COOKIE é sinônimo de SESSÃO" que ainda é dúbio?

[niltonneto]

Para que esse ticket não vire uma novela, sugiro conversarem (antonio e rodrigo) por telefone, messenger ou email até que seja resolvido.

[antonio-carlos.silva]

Últimi modiicação efetuada na revisão 3448.

[niltonneto]

Mesmo depois da última revisão [3448], se limpar o cookie a cada login inválido, ele nunca irá pedir o Captcha. Acho que o problema em questão só será resolvido se o bloqueio do usuário a cada N tentativas de login for habilitado no Administrador.

[antonio-carlos.silva]

O bloqueio do usuário a cada N tentativas de login pode ser habilitado.

Mas baixei a revisão 3448 do branch 2.2 da Comunidade.

Instalei aqui no Serpro para testar.

Funcionou OK.