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

28/08/2013

Brute Force HTTP em forms com Hydra

Filed under: segurança,web app security — drak @ 12:56 AM

Hoje vamos exercitar um pouco algumas habilidades de Web Application Security. Em primeiro lugar obtenha o metasploitable (VM com diversas vulnerabilidades, criada especificamente para facilitar o aprendizado de técnicas de segurança), depois a partir de um linux da sua escolha (kali/bt ou samuraiwtf são algumas boas opções) garanta que você tem conectividade com o metasploitable.

No meu lab o metasploitable está com o IP 192.168.71.129, esse é o IP utilizado nos exemplos abaixo.

Ao navegar no IP do metasploitable você terá 5 opções de aplicações Web vulneráveis, o alvo hoje é um dos módulos do DVWA (Damn Vulnerable Web Application), ao selecionar essa opção você é apresentado à um formulário, o acesso (admin/password) está logo abaixo mas vamos tornar isso mais interessante e não vamos simplesmente utilizar essas credenciais.

A primeira técnica que utilizaremos é um simples brute force no formulário, para isso iremos usar o hydra e para montarmos os parâmetros corretamente podemos analisar o código fonte para obter os nomes dos campos de usuário e senha ou interceptar o pacote num proxy local e visualizar os campos esperados diretamente com um exemplo, iremos utilizar a última opção.

Inicie um proxy local (como o burpsuite, localizado no Kali em Applications, Web Applications, Web Application Proxies, burpsuite), verifique em que porta ele está escutando (Proxy, Options), configure o browser para utilizar o mesmo (localhost:8080, na configuração padrão). Desabilite o intercept (Proxy, Intercept) caso contrário você terá que autorizar manualmente cada pacote que passa por ele.

Acesse a interface web do DVWA, note que no burp suas requisições já devem estar aparecendo em Target, Site Map ou Proxy, History. Entre com qualquer texto nos campos Username e Password do formulário de login, veja como a informação é enviada no Burp.

Note que a informação é enviada através de um POST HTTP, perceba a sintaxe da string: “username=teste&password=teste&Login=Login”, nesse caso eu utilizei a string “teste” tanto como usuário quanto senha. Analizando o resultado da falha do login na tela inicial do DVWA também obtemos uma informação importante, caso o login falhe ele amigavelmente retorna a mensagem “Login failed”, iremos usar essa informação para determinar o sucesso ou falha do nosso brute force.

Já temos a string que caracteriza o envio de usuário e senha, também identificamos um texto que indica se o login falhou (uma mudança na página em relação à situação inicial, antes de efetuarmos qualquer tentativa) agora precisamos de uma wordlist. Usando o kali vamos procurar por alguma lista de senhas e escolher a que possui o maior número de linhas:

wc -l `locate passwords` | sort -nr

Analisando rapidamente o arquivo passwords.lst que está na pasta do nmap vemos que ele está no formato adequado (uma senha por linha) e contém as senhas mais comuns, para o propósito desse exercício essa wordlist é suficiente porém o início do arquivo contém muitos comentários (que serão testados inutilmente durante o processo de brute force) vamos criar uma nova wordlist apenas com o que é interessante:

cat /usr/share/nmap/nselib/data/passwords.lst | grep -v \#\!comment > pass.tx

Agora usamos o que coletamos anteriormente na sintaxe do hydra, iremos testar as senhas da wordlist somente para o username “admin”:

hydra -l admin -P pass.txt 192.168.71.129 http-post-form "/dvwa/login.php:username=^USER^&password=^PASS^&Login=Login:Login Failed"

Rode o comando e em poucos segundos deverá aparecer a seguinte mensagem:

Hydra v7.3 (c)2012 by van Hauser/THC & David Maciejak - for legal purposes only

Hydra (http://www.thc.org/thc-hydra) starting at 2013-08-27 22:15:49
[DATA] 16 tasks, 1 server, 5084 login tries (l:1/p:5084), ~317 tries per task
[DATA] attacking service http-post-form on port 80
[80][www-form] host: 192.168.71.129   login: admin   password: password
[STATUS] attack finished for 192.168.71.129 (waiting for children to finish)
1 of 1 target successfuly completed, 1 valid password found
Hydra (http://www.thc.org/thc-hydra) finished at 2013-08-27 22:15:58
root@kali:~#

Teste a senha encontrada e veja a tela inicial do DVWA.

Navegue para a primeira seção, chamada “Brute Force” e analise o formulário existente, note a diferença no modo como a informação é enviada pelo Burp (dessa vez as credenciais são enviadas usando o método GET), veja que o texto de falha no login também é diferente. Um detalhe importante ao realizar a tentativa de ataque nesse formulário é que dessa vez o usuário deve estar autenticado para ter acesso ao segundo formulário, logo também precisamos incluir a informação da autenticação no DVWA (através da inclusão da informação do SESSION ID, que encontramos no Cookie e podemos ver facilmente no burp)

Realizando os ajustes de parâmetros necessários baseado nas novas informações obtidas com um teste no burp temos o seguinte resultado:

hydra -l admin -P pass.txt 192.168.71.129 http-get-form "/dvwa/vulnerabilities/brute/:username=^USER^&password=^PASS^&Login=Login:Username and/or password incorrect.:H=Cookie: security=low; PHPSESSID=a36c8206f365ecea8315a06bf3559792"
Hydra v7.3 (c)2012 by van Hauser/THC & David Maciejak - for legal purposes only

Hydra (http://www.thc.org/thc-hydra) starting at 2013-08-27 23:18:51
[DATA] 50 tasks, 1 server, 5000 login tries (l:1/p:5000), ~100 tries per task
[DATA] attacking service http-get-form on port 80
[80][www-form] host: 192.168.71.129   login: admin   password: password
[STATUS] attack finished for 192.168.71.129 (waiting for children to finish)
1 of 1 target successfuly completed, 1 valid password found
Hydra (http://www.thc.org/thc-hydra) finished at 2013-08-27 23:18:56
root@kali:~#

Mais uma vez conseguimos obter com sucesso, é importante lembrar que assumimos o nome de usuário “admin”, caso precisassemos testar múltiplas senhas para múltiplos usuários o tempo de brute force aumenta drasticamente, além disso outras medidas de segurança como lockar a conta após X logins sem sucesso, um delay no sistema de login que somente permita novas tentativas após Y segundos de uma tentativa mal sucedida (isso também é conhecido como tarpitting), usar um captcha ou até mesmo abandonar totalmente o uso de senhas (como no caso da autenticação SSH usando chaves públicas) são algumas medidas úteis para combater brute force.

Update 31/07/14: Caso você queira visualizar no Burp as requisições que estão sendo feitas pelo Hydra, basta acrescentar a variável de ambiente abaixo.

root@kali:~# export HYDRA_PROXY_HTTP=http://127.0.0.1:8080

Referências
Metasploitable
DVWA
Kali Linux
Samurai WTF

Crie um website ou blog gratuito no WordPress.com.