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

03/09/2013

Command Execution no DVWA

Filed under: segurança,web app security — drak @ 6:00 PM

Este post é uma continuação do “Brute Force HTTP em forms com Hydra”, assume-se que você já tenha o ambiente montado e funcionando.

A segunda seção do DVWA trata da execução remota de comandos em um formulário web. Seu uso pretendido é de um simples ping, teste o uso colocando o IP da máquina atacante e note que a página retorna o texto exato de um ping não-interativo (roda durante um tempo e depois para, não precisa de nova interação como por ex. o comando passwd). Vendo a saída desse comando nos faz imaginar que todo o texto colocado no textbox é executado sem filtros no servidor web, para testar isso precisamos combinar dois comandos (o texto esperado e um comando não interativo qualquer à nossa escolha) logo basta usar a seguinte string:

192.168.71.130 | whoami

Que nos retorna o usuário “www-data”, que é o usuário que está rodando o serviço do Apache. A partir desse ponto vários outros comandos “post exploitation” podem ser usados, basta lembrar que você não tem direitos de root (todos os comandos rodam no contexto do usuário www-data) e que o comando deve ser não-interativo (não deve solicitar nada após o início de sua execução).

Veja por exemplo o que acontece quando entramos com a string abaixo.

192.168.71.130 | cat /etc/passwd

Esse tipo de falha acontece pois a string enviada pelo usuário é executada sem nenhuma análise no lado do servidor, idealmente o ping não chamaria diretamente o executável ping do SO e muito menos deixaria o caracter “|” passar para a execução final, deveria acontecer alguma sanitização na entrada para somente permitir a string esperada (nesse caso poderia ser realizado uma máscara para reconhecer um formato de IP, qualquer coisa diferente disso seria descartada).

Referências
Testing for Command Injection
Post Exploitation Command Lists

Crie um website ou blog gratuito no WordPress.com.