#1

Introdução

A autenticação pode ser resumida como uma prova de identidade, ou seja,

consiste em verificar se alguém realmente é quem diz ser. Existem 3
métodos principais de autenticação para evitar acessos indevidos: algo que
você sabe, algo que você tem e algo que você é. Quando combinam-se
dois ou mais desses fatores, a segurança é aumentada.

Apesar disso, a autenticação também tem vulnerabilidades que, se

exploradas, podem causar dano severo. Essas falhas podem permitir - a um
atacante - o uso de contas de outro usuário, por exemplo, assim como o
acesso a sistemas, informações e dados que não deveria acessar.

No decorrer deste relatório, soluciono alguns dos laboratórios da

PortSwigger sobre o tema e discorro brevemente sobre algumas formas
de mitigação da vulnerabilidade, muito presente em aplicações web.

.
.
.
Alvo 1: PortSwigger Labs

Rodrigo Peixoto @ OffSec

 #2

Os laboratórios da PortSwigger, como deve-se imaginar, foram idealizados

para que sejam realizados com a ferramenta BurpSuite. Apesar disso, a
versão Community (gratuita) do software tem algumas limitações quanto
ao desempenho, que acabam por limitar os testes que podem ser
realizados. A fim de burlar essa limitação, utilizamos o OWASP Zed Attack
Proxy.

O OWASP Zaproxy, ou somente OWASP ZAP, é uma ferramenta open

source para análise de vulnerabilidades, que tem muitas das ferramentas
contidas no Burp, sem a necessidade de adquirir uma versão profissional.

PortSwigger Lab #1

O primeiro laboratório, Username enumeration via different responses,

requer que seja feito o acesso no sistema através da enumeração dos
usuários. Para tanto, são dadas duas listas: uma lista de usernames
possíveis e uma lista de senhas possíveis.

A fim de resolver o laboratório, primeiro testamos todos os usernames e

verificamos qual será a resposta da requisição, quando enviada por cada
um deles. O procedimento pode ser realizado capturando uma requisição
de login e usando a ferramenta Fuzzler do Zaproxy.

Rodrigo Peixoto @ OffSec

 #3

Colocamos todos os usuários no payload, que é a carga a ser enviada ao

site, e iniciamos o processo de fuzzling.

Vimos que todas as respostas da requisição têm o mesmo tamanho, de

2.884 bytes, exceto por uma que tem 2.886 bytes. A conta “acceso”, neste
caso, é a correta, pois a mensagem exibida é diferente. Percebemos que,
ao invés de receber a mensagem de username incorreto, é informado que
a senha está incorreta. Logo, esse é um usuário válido no sistema.

Para solucionar o laboratório, bastaria seguir a lógica e fazer um

brute-force, testando todas as senhas possíveis no usuário acceso,
conforme abaixo.

Rodrigo Peixoto @ OffSec

 #4

Com base nos códigos de resposta do HTTP, vimos que senhas incorretas
retornam os códigos 200 OK, enquanto a única senha correta retorna o
código 302 Found.

Utilizando a combinação do usuário com a senha correta, o acesso é

realizado e o primeiro laboratório é solucionado.

Rodrigo Peixoto @ OffSec

 #5

PortSwigger Lab #2

O segundo laboratório, 2FA simple bypass, apresenta uma vulnerabilidade

curiosa no Múltiplo Fator de Autenticação. Ao tentar logar com um usuário,
é enviado o seu código de autenticação para o email, mas sabe-se que a
tela de recebimento do código já confirma que o acesso está correto ao
perfil. Com as credenciais da vítima em mãos, vejamos o que pode ser
feito.

Método 1 - Na tela que solicita o código de autenticação, basta voltar à

página home do laboratório que o usuário da vítima, Carlos, já estará
autenticado. Dessa forma, o laboratório é solucionado sem esforço.

Método 2 - Primeiramente, logamos em nosso usuário (wiener) e

inserimos o código 2FA que é recebido no email. Feito isso, o acesso
funciona normalmente.

A URL é importante nesse caso, pois vemos que ela é alterada para o final
/my-account.

Rodrigo Peixoto @ OffSec

 #6

Tentamos logar com a conta da vítima (user: carlos / senha: montoya), mas
não temos acesso ao seu email. Porém, o acesso não é necessário pois
podemos apenas alterar a URL, já que o usuário já está autenticado. Não é
necessária, portanto, a inserção do código e podemos pular para a página
que queremos acessar alterando a url para a desejada.

Assim, o acesso também é realizado e o laboratório é finalizado.

PortSwigger Lab #3

O terceiro laboratório, 2FA broken logic, por sua vez, mostra um caso em
que é possível manipular a requisição para burlar a verificação de usuário
do MFA. Sendo assim, pode-se capturar a requisição de POST do código e
alterar o parâmetro verify=wiener, que usa a conta do atacante, para
verify=carlos. Assim, bastaria fazer um ataque de força bruta no código
MFA e testar todas as possibilidades até obter sucesso.

O passo-a-passo usado para solução do problema inicia-se com uma

tentativa de login incorreta em nosso login (wiener).

Analisando a requisição gerada, vemos que é possível alterar o código MFA

e o parâmetro verify, colocando a conta de Carlos como valor.

Isso permite que seja realizado o ataque mencionado anteriormente.

Rodrigo Peixoto @ OffSec

 #7

Trocamos o parâmetro verify para carlos e adicionamos o código MFA no

Fuzzler, para fazer um brute-force até acertar o código correto.

Para isso, porém, é necessário configurar o fuzzling para que seja mais
efetivo.

Rodrigo Peixoto @ OffSec

 #8

Sabemos que o código possui 4 dígitos, que por consequência só podem ir

de 0000 até 9999. No payload usado no fuzzler, selecionamos o tipo
Numberzz, para que sejam testadas combinações de números de 0 até
9999. A fim de preencher os espaços vazios, usamos o Processor chamado
Expand, que irá permitir definir o comprimento do número testado como
4 caracteres, ou seja, um número de 4 dígitos - que é o que buscamos.

Com isso, o que temos é que o valor sempre terá 4 caracteres e testará de
0000 até 9999, ou seja, todas as combinações possíveis.

Rodrigo Peixoto @ OffSec

 #9

Basta deixar, agora, que o ZAP trabalhe, até retornar um código 302 Found.

Uma vez recebido o código, analisamos a request enviada e vemos que o

código postado foi 0086, então sabemos que, através desse código MFA,
seria possível logar no sistema.

Clicamos em Send, para enviar a requisição para o browser e, ao acessar a

página My Account, o laboratório é concluído.

Rodrigo Peixoto @ OffSec

 #10

PortSwigger Lab #4

O quarto laboratório, Password reset broken logic, explora um tipo de

vulnerabilidade diferente. Nesse caso, é possível resetar a senha de outro
usuário, mesmo sem estar logado em sua conta.

Primeiramente, é necessário saber como é feito o reset de senha. Em casos

normais, é enviado um link de reset para o email e, através desse link, o
usuário pode realizar a troca da sua conta.

O problema, no entanto, é que esse link, aparentemente, envia um token

de troca de senha que pode ser usado por qualquer usuário.

A partir do email do atacante, copiamos o token de troca de senha e o

incluímos em uma requisição de troca de senha bem-sucedida, como a
que fizemos anteriormente em nosso próprio usuário.

Conforme a imagem abaixo, basta trocar os parâmetros desejados e

substituir o token antigo pelo novo. Os campos new-password 1 e 2 são

Rodrigo Peixoto @ OffSec

 #11

referentes à tela de definição da nova senha, que pedem a nova senha e a

confirmação dela.

Depois de redefinir a senha de Carlos, basta fazer o acesso com a senha

escolhida (no caso, montoya) e o laboratório é concluído.

PortSwigger Lab #5

O quinto e último laboratório, Password brute-force via password

change, aborda um caso semelhante ao anterior, mas com algumas
mudanças. Essa vulnerabilidade se dá nas funcionalidades de reset de

Rodrigo Peixoto @ OffSec

 #12

senha, quando são retornadas mensagens de erro diferentes caso a senha

esteja correta ou incorreta e, além disso, é possível alterar a senha do
usuário sem estar logado no perfil dele, bastando estar logando em
qualquer perfil da aplicação.

No usuário de atacante (wiener), mais especificamente na tela de alteração

de senha, recebemos a mensagem “Current password is incorrect”, caso a
senha atual não esteja correta. Até então, tudo dentro da normalidade.

Porém, se a senha atual estiver correta, mas as senhas novas não estão
iguais, a mensagem recebida é “New passwords do not match”. Essa
mensagem indica que, caso seja feito um fuzzling, o tamanho da resposta
será diferente para os dois casos.

Além disso, pela lógica, se o erro está nas senhas novas e não na senha
atual, isso significa que a senha usada funciona para login.

Rodrigo Peixoto @ OffSec

 #13

Abrindo a request de troca de senha no editor de requisições do OWASP

ZAP, o que temos são os seguintes parâmetros: usuário, senha atual, nova
senha 1 e 2 (senha nova e confirmação).

Podemos, no entanto, alterar o username para carlos (vítima) e inserir duas

senhas que não combinam nos campos new-password 1 e 2.

Usando, mais uma vez, o recurso Fuzzler, podemos inserir a lista de senhas
pré-existentes e fazer um brute-force no usuário de Carlos.

Rodrigo Peixoto @ OffSec

 #14

Vale lembrar que as senhas devem ser diferentes, conforme abaixo, para
que a mensagem de retorno seja diferente no site e, com isso, saibamos
qual é a senha atual (current-password) que funciona.

Após conclusão do fuzzling, vemos que apenas uma das requisições é

diferente, pois possui um tamanho de resposta diferente.

Abrindo a referida requisição, verificamos que a senha de carlos é joshua.

Com isso, é possível tentar o acesso ao site com as credenciais atuais de

Carlos e ter sucesso no laboratório.

Rodrigo Peixoto @ OffSec

 #15

.
.
.
Desafios

Username enumeration via response timing

O desafio proposto consiste na realização do laboratório Username

enumeration via response timing. Assim como o outro desafio de
enumeração, deve-se verificar qual é o usuário correto através do tempo de
resposta e combinar este ataque com um brute force para descobrimento
da senha.

Uma vez criado o payload, realizamos o fuzzling para encontrar um tempo

de resposta que esteja fora dos padrões.

Descobrimos que as contas admin, root e carlos se destacam na multidão.

Rodrigo Peixoto @ OffSec

 #16

O que pode ser feito é a criação de dois payloads: um com as três contas
de usuário, que tiveram tempo de resposta menor, e outro com as senhas,
para serem testadas nos três. O brute force é muito mais viável em um
número limitado de contas.

Apesar disso, não foi possível identificar nenhuma anomalia. Todas as

contas, aparentemente, retornam o mesmo código, com tempos de
resposta similares, e não há nenhuma indicação, via mensagem de erro, do
motivo pelo qual o ataque não foi bem sucedido.
Requer um maior aprofundamento.

.
.
.
Mitigação da Vulnerabilidade

Como vimos, o impacto de ataques contra a autenticação pode ser muito

pesado. Felizmente, existem diversas formas de prevenção e contenção do
problema através da melhoria dos mecanismos de autenticação.

Uma das táticas que pode ser usada neste objetivo é implementar o
HTTPS. Por vezes, a conexão é não-criptografa e somente via HTTP, o que
permite que credenciais fiquem expostas. É importante direcionar o
tráfego HTTP para HTTPS, quando possível.

Da mesma forma, é preciso revisar se os métodos de login ou recuperação

de senha são seguros e não permitem engenharia reversa para acesso às
contas de outros usuários. Até mesmo o Duplo Fator de Autenticação deve
ser implementado com cuidado e com limitações, especialmente de
tempo.

Rodrigo Peixoto @ OffSec

 #17

Por fim, recomenda-se também garantir que, no momento da troca de

senha, o usuário correto esteja autenticado, que seja exigida a senha atual -
quando for viável - e, acima de tudo, as mensagens de erro não sejam
muito descritivas.

.
.
.
Conclusão

O processo de autenticação é importante para, basicamente, qualquer

sistema da atualidade, portanto é imprescindível olhar para ele com
atenção e carinho, visto que não são somente os ativos que devem ser
protegidos, mas também os métodos de acesso a esses ativos e
funcionalidades.

Nota-se, mais uma vez, a importância do profissional de Segurança

Ofensiva, que pode realizar testes em sistemas, a fim de encontrar
problemas, falhas e vulnerabilidades similares às que foram apresentadas
no decorrer deste documento.

.
.
.

Obrigado pela leitura!

Rodrigo Peixoto @ OffSec