O atacante pode roubar a sessão de um usuário legítimo do sistema, que esteja previamente autenticado e realizar operações que o mesmo poderia.

Transcrição

1 Explorando e tratando a falha de Cross-site-scripting (XSS) 1 D E D E Z E M B R O D E Muito pouco falada e com alto nível crítico dentro das vulnerabilidades relatadas, o Cross-site-scripting (XSS) ocorre na aplicação web em que os parâmetros inseridos no servidor não são tratados devidamente, permitindo que o usuário mal intencionado insira códigos (como em HTML e JavaScript) que manipulam instruções, como as estruturas de documentos HTML, roubo de sessões no sistema/credenciais, redirecionamento para sites maliciosos, entre outras coisas. Listada como Top 10 das principais vulnerabilidades da OWASP, ela está/esteve presente dentro de grandes empresas como Rede Globo, Olhar Digital, GOL, Banco do Brasil, entre outras as quais muitas vezes acabaram ignorando essa vulnerabilidade. A falha não só atinge sites comuns mas grande parte dos fóruns, devido a falta de filtro em que qualquer usuário comum pode incluir mensagens sem autorização, como instruções maliciosas para leitura de informações específicas do usuário legítimo, tais como códigos de sessão e roubo de credenciais. Observe a imagem abaixo tirado do gráfico da Owasp, trazendo as informações gerais sobre o XSS. Outro exemplo de ataque que ocorre é devido a má implementação ou inexistência de um filtro para consultas de JavaScript que podem ser utilizadas para fazer redirecionamentos maliciosos (phishing). Esse script malicioso pode simular o login de um site, capturando os valores digitados e redirecionando-os à um site falso para armazenar esses dados. Dentro da vulnerabilidade XSS podemos destacar as principais ações de um atacante dentro de um vetor de ataque: O atacante pode criar uma URL com um script malicioso podendo abusar da credibilidade do site que é autêntico, enviando para uma vítima que poderá baixar e instalar o executável. O atacante pode também, através de scripts, desconfigurar a página do site com mensagens e/ou imagens maliciosas que podem denegrir a imagem da instituição. O atacante pode roubar a sessão de um usuário legítimo do sistema, que esteja previamente autenticado e realizar operações que o mesmo poderia. Tipos de Ataques de XSS Não existe uma forma única de classificar o tipo de XSS, pois algumas são classificadas de acordo com a falha causada pelo lado do servidor (server side) ou pelo lado do cliente (client side). Sendo assim, destacamos os tipos mais conhecidos como o persistente, não persistente e baseado em DOM. Persistente (Stored) É quando o script injetado manipula alguma área no servidor podendo se alocar no banco de dados, num campo de pesquisa ou de comentários onde essa área infectada é acessada automaticamente entrando em funcionamento o script. Uma consequência grave desse ataque é a criação de um usuário e a escalação de privilégio. Não-Persistente (Reflected) Ocorre quando usuário envia uma requisição durante uma consulta feita na página de pesquisa ou na variável. Geralmente são ataques sujeitos à engenharia social, como redirecionamento de página a qual convence a vítima que está em uma conexão legítima, capturando dados sensíveis através de roubo de credenciais, sequestro de sessões, ou uso da conexão da vítima para realizar atividades arbitrárias. Baseado em DOM A falha é explorada pelo lado do cliente a partir dos objetos DOM (Document Object Model), sendo que sua manipulação é via código JavaScript. Esse caso são exemplos dos XSS que são inseridos scripts via payload numa determinada variável. Identificando e explorando o XSS Demonstraremos alguns exemplos para explorar a falha e analisá-la, executando testes manuais no site de teste da Acunetix, o qual podemos explorar e atacar sem problemas. Podemos, através de um scanner como Nessus (outro outro que queira), encontrar a vulnerabilidade, porém pode causar muito barulho no alvo. Outro meio de localizar é através de Dorks que são strings as quais utilizamos no Google para retornar buscas específicas (caso ainda não, viu leia o artigo aqui), e elas facilitam encontrar campos que possam estar vulneráveis, veja algumas Dorks abaixo: inurl:.php?query= inurl:.php?searchstring= inurl:.php?file=

2 inurl:.php?txt= inurl:.php?tag= inurl:.php?author= inurl:.php?feedback= inurl:.php?cat= Pode-se também criar uma dork como exemplo: inurl:.php?search= && inurl: a qual irá retornar para nós o campo de busca do nosso site para que possamos explorá-lo. Pegaremos nosso alvo do site da Acunetix e iremos fazer dezenas de testes para verificar a existência de uma possível vulnerabilidade XSS, simulando algumas dificuldades que podem ser encontradas num processo de identificação. Primeiro localize no site alvo algum local para inserção do script, seja um formulário de busca ou no própria URL. Usaremos um simples script em JS para verificar a existência de um possível XSS, a qual será inserida no formulário de busca. <script>alert('falha de XSS encontrada')</script> Veja que ele irá retornar a nossa mensagem a qual foi enviada pelo nosso script. Lembrando que as linguagens usadas nos scripts são executadas em plataforma web, tais como HTML e JS que são as mais comuns. Muitas vezes existem filtros nos formulários de busca, que não serão possíveis fazer request do script com sucesso, sendo que teremos que fazer bypass neles, seja codificando o script ou injetando via GET (parâmetro enviado pela URL da página). No exemplo abaixo, temos um script que inserimos o valor em Decimal 70, 65, 76, 72, 65, 95, 68, 69, 95, 88, 83, 83 que convertendo para String tem o valor da mensagem FALHA_DE_XSS. Caso queira criar uma mensagem própria acesse a tabela ASCII aqui. Sendo uma boa forma de passar pelo filtro de busca. <script>alert(string.fromcharcode(# 70, 65, 76, 72, 65, 95, 68, 69, 95, 88, 83, 83))</script> Outro exemplo que podemos verificar o XSS é inserir uma imagem dentro da página, onde pegaremos o endereço da imagem e injetaremos dentro de um script na página.

3 <IMG SRC=" Veja que a facilidade de manipular conteúdos dentro da página, assim como também podemos fazer um redirecionamento de página (a qual são usados em muitos exemplos de Deface), só que estamos explorando no modo reflected, isso não causará dano permanente ao servidor. <script>window.location.href=" Podemos também criar um formulário falso, os quais são usados na técnica de phishing. Porém, nosso formulário é demonstrativo apenas para que você tenha a ideia de como pode ser explorada a falha, sendo assim: <form class= pure-form > <fieldset> <legend>confirmacao de Senha </legend> <input type= password placeholder= Senha id= password required> <input type= password placeholder= Confirme Senha id= confirm_password required> <button type= submit class= pure-button pure-button-primary >Confirmar</button> </fieldset> </form> Deixando ela mais incorporada agora, iremos codificar ela em base64 para fazer bypass no formulário de busca, para facilitar o processo para você, vá no site e vá na opção ENCODE e cole o script acima, sendo que pode ser feito para qualquer modelo de script desde que esteja codificando a função na base64.

4 Agora pegamos a saída e embutimos no script a seguir: <META HTTP-EQUIV="refresh"CONTENT="0;url=data:text/html;base64,# PGZvcm0gY2xhc3M9InB1cmUtZm9ybSI+DQogICAgPGZpZWxkc2V0Pg0KICAgICAgICA8bGVnZW5kPkNvbmZpcm1hY2FvIGRlIFNlbmhhIDwvbGVnZW5kPg0KICAgICAgICA8aW5wdXQ Agora insira o script na página e terá a seguinte saída. Esse foi exemplo simples, mesmo a vítima digitando a senha não será enviado para você pois necessita reformular o script para um redirecionamento de dados para você, sendo apenas didático a demonstração. Existem meios de criar payloads e scripts mais robustos para capturar sessões como na ferramenta BEEF que permite fazer hook na conexão da vítima, criando um tunelamento com ela na hora que é injetado o script ganhando acesso a máquina alvo, permitindo explorar recursos sobre o alvo desde da manutenção de acesso, injeção de exploits e shells. Como se proteger do XSS As principais medidas para evitar o ataque de XSS se baseia na validação de parâmetros no servidor como a verificação do formato dos dados introduzidos pelo usuário, codificando os dados dos utilizadores substituindo os caracteres especiais pelos seus equivalentes HTML. Para ajudar na prevenção, a OWASP criou um guia para ajudar a Prevenção de Ataque XSS, além disso outra dica deles é desativar o suporte a HTTP TRACE em todos os servidores web. Mesmo quando o document.cookie está desativado ou não é suportado no cliente, o invasor pode roubar dados de cookies via JavaScript a qual um usuário malicioso envia o script para o alvo. E ao acessar o link, uma chamada de Rastreamento HTTP Assíncrona é desencadeada recolhendo informações do cookie do usuário do servidor e em seguida é enviada para outro servidor malicioso, que recolhe as informações do cookie permitindo que o atacante sequestre a sessão. Isso é facilmente mitigado através da remoção de suporte para TRACE HTTP nos servidores web. Conclusão A falha de XSS atinge grande corporações, sendo uma falha classificada como crítica dentro das vulnerabilidades em aplicações web porém é muito descartada devido a ignorância de quem não a conhece ou pelo fato do atacante não saber a forma correta de explorá-la. Existe ferramentas que automatizam o ataque sendo mais fácil explorar do que manualmente, como Beef que já foi comentado em nossos artigos. Referência e Indicação Bibliográfica

5 S e g u r a n ç a d a I n f o r m a ç ã o C R O S S S I T E S C R I P T I N G S C R I PX TS S X S S B A S E A D X O S S D O M R E F E L M X S S E C T ES DT O R E D