Dead Packets

05/09/2013

Explicando Cross Site Request Forgery

Filed under: segurança,web app security — drak @ 11:21 PM

Este post é uma continuação da série que trata de vulnerabilidades em aplicações Web, iniciada com o “Brute Force HTTP em forms com Hydra”, assume-se que você já tenha o ambiente montado e funcionando.

Ao navegar na seção CSRF é apresentado somente um formulário com a opção de troca de senha para o usuário admin, ao testarmos o formulário vemos que os parâmetros são enviados num GET (tanto pela URL que mudou quanto pelo Burp, podemos ver a URL após o envio do formulário abaixo). Mas e daí?

http://192.168.71.129/dvwa/vulnerabilities/csrf/?password_new=password&password_conf=password&Change=Change#

Para entender a vulnerabilidade temos que imaginar a seguinte situação: Você, usuário administrador de um site qualquer está logado nele (situação normal do teste), em uma determinada seção desse site você tem a possibilidade de trocar sua senha. O que aconteceria se você copiasse a linha acima, alterasse o parâmetro “password” para uma nova senha qualquer e colasse em uma nova aba ? O processo de alteração de senha ocorreria sem problema nenhum, pois você está logado e o comando é a única coisa necessária para trocar a senha.

É nesse ponto que começa o problema, suponha que você está logado no site e em outra aba do seu browser você está navegando em outros sites, você recebe um email ou clica em uma URL que tenha como argumento o seguinte:

http://192.168.71.129/dvwa/vulnerabilities/csrf/?password_new=EVIL_pass&password_conf=EVIL_pass&Change=Change#

Pronto! Uma vez que você estava logado no site, ao clicar nesse link recebido por email ou em alguma outra página qualquer você enviou um comando ao site para trocar sua senha para “EVIL_pass”.

Tudo isso parece muito improvável de acontecer, mas esse foi apenas o exemplo simplificado. No mundo real teríamos algo mais complexo como o seguinte caso:

Você está num site de e-commerce/banco/forum de discussão, em outra aba você está verificando seus emails ou navegando em outros sites quaisquer, em um desses sites existe uma figura que não abre, você nem percebe isso mas no momento que carregou a página você deu um comando direcionada para o site do e-commerce efetuar uma compra que você não esperava, ou uma transferência de dinheiro de uma conta para outra ou ainda trocou sua senha/postou alguma mensagem no forum. Tudo isso pode acontecer se o site de e-comm/banco/forum estiver vulnerável à CSRF, pois a única identificação que ele está usando é o cookie (e como você mandou o comando o pacote formado já inclui o cookie para o site alvo).

Para testar esse conceito no DVWA iremos criar uma página com o link que devemos fazer com que o usuário legítimo clique (ou carregue de alguma outra maneira mais discreta). Crie um arquivo html com o seguinte conteúdo:

<html>
	<body>
	<a href="http://192.168.71.129/dvwa/vulnerabilities/csrf/?password_new=EVIL_pass&password_conf=EVIL_pass&Change=Change#">troca</a>
	</body>
</html>

Logue no DVWA em uma aba, na outra abra o arquivo criado localmente e clique no link, faça logoff e teste a nova senha.

Mas ninguém seria tão idiota para clicar num link desses, certo ? Então vamos tornar nosso PoC mais furtivo.

<html>
	<body>
	<img style="display:none;" src="http://192.168.71.129/dvwa/vulnerabilities/csrf/?password_new=EVIL_pass&password_conf=EVIL_pass&Change=Change#">
	</body>
</html>

Dessa vez estamos abusando do comportamento dos browsers em enviar solicitações para imagens sem que seja necessário a intervenção do usuário, poderíamos usar também um iframe, javascript invocando a imagem ou auto envio do request. Teste da seguinte maneira: Troque a senha do admin para “password”, faça logoff e teste a senha. Abra o novo arquivo html, nada irá aparecer mas o comando já terá sido executado (confira no Burp), faça o logoff no DVWA e teste o acesso com a senha nova (que foi trocada sem a sua intervenção, bastando apenas abrir uma página “em branco”).

Esse tipo de ataque pode ser evitado através do uso de tokens randômicos no próprio formulário, que devem ser enviados no POST junto com os outros parâmetros. Como não temos como descobrir qual é esse parâmetro e ele não vai junto por padrão (diferente do cookie que está associado ao site) não temos como gerar uma requisição que pareça legítima.

Referências
HOW TO EXPLOIT CSFR VULNERABILITY(CSRF TUTORIAL)?
Preventing CSRF and XSRF Attacks
Testing for CSRF (OWASP-SM-005)
CSRF Form Generator

Anúncios

1 Comentário »

  1. Muito legal, boa explicação do conceito!

    Comentário por marcelo — 21/11/2013 @ 9:39 PM | Responder


RSS feed for comments on this post. TrackBack URI

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

Crie um website ou blog gratuito no WordPress.com.

%d blogueiros gostam disto: