Descrição de Ataques XSS em servidores Web

(1)

Descrição de Ataques XSS em servidores Web

Leonardo Santos Silva São Paulo, Brasil ABSTRACT

Com a proliferação de sítios web e a incapacidade dos desenvolvedores em manter um código atualizado contra os diversos tipos de ataques, muitas empresas acabam se deparando com situações que possuem suas portas de entradas para a internet violadas. Esse artigo tem por objetivo realizar uma introdução sobre os ataques de Cross Site Script (XSS), como bloquear esses ataques e, com as ferramentas disponíveis na internet, evadir essas proteções.

INTRODUÇÃO

Por questões de custos, comodidade, segurança e outros fatores que beneficiam e proporcionam facilidades para o consumidor, observa-se um aumento do volume de compra dos brasileiros nos meios digitais, entre eles, nos sites de comércio eletrônico. Segundo dados do WebShoppers[1], um relatório disponibilizado para as empresas que viabilizam este tipo de comércio, apontou um crescimento de 20% no volume financeiro transacionado entre 2011 e 2012, enquanto que de 2012 para 2013, a expectativa de crescimento era de 25%. Os resultados ainda serão apresentados para constatação das estatísticas de 2013.

A análise desses dados sugerem um braço do comércio em contínua expansão. Inversamente à esse crescimento, o número de fraudes reportadas ao Centro de Atendimento a Incidentes de Segurança (CAIS) [2] vem sofrendo uma queda progressiva desde 2011. Observa-se, entretanto, um tipo de ataque que não está presente nas estatísticas dos órgãos de monitoramento da Segurança da Informação do Brasil, devido à complexidade e dificuldade em ser reportado. Trata-se dos ataques à camada de aplicação, onde muitas empresas não são capazes de detectá-los da maneira mais comum adotada, ou seja, por meio do uso de regras de Firewall tradicionais.

Essas regras consistem na adoção de um Firewall de perímetro na camada de rede (OSI Layer3). Todavia, a execução dessa ferramenta apresenta desempenho insatisfatório no bloqueio de ataques específicos como o Cross Site Script (XSS) e o SQL Injection.

OBJETIVO

Este artigo tem por objetivo mostrar a estrutura de um ataque XSS sobre um host vulnerável[3] criado em Java e Java Script e como o mecanismo de defesa tradicional, um Firewall de Aplicação Web pode ser evadido com uma pequena mudança no vetor de ataque.

(2)

Este trabalho será dividido em 2 etapas, a saber:

Etapa 1 - Apresentar os conceitos de ataques XSS e demonstrar em um ambiente desprotegido, como é realizado, utilizando uma aplicação desenvolvida sem nenhuma camada de proteção no código fonte [3] em uma máquina virtualizada.

Etapa 2 - Mostrar como a camada de proteção do Firewall de Aplicação Web pode ser evadida com pequenas alterações no código malicioso, usando o BurpSuite, uma ferramenta própria para manipulação de dados para sistemas web.

CONCEITO XSS

De acordo com o relatório das dez maiores vulnerabilidades existentes em programas disponíveis na internet, o Cross Site Scripting (XSS) é um dos tipos de vulnerabilidade mais difundidas nos dias de hoje, ocupando o terceiro lugar de acordo com a classificação da OWASP Top10[4] . Este ataque, permite que o atacante insira um código malicioso (JavaScript) no servidor Web que não tenha um tratamento devido, através de seu navegador das seguintes formas:

1. Dados são gravados no servidor web por meio de uma fonte não confiável, geralmente uma requisição web.

2. Os dados são incluídos em um conteúdo dinâmico que é enviado à um servidor web sem que uma validação seja feita para código malicioso.

Os ataques podem ser caracterizados em 2 grupos - XSS Refletido e XSS Armazenado [5]. XSS Refletido

Ataques de XSS Refletidos são aqueles onde o script injetado é refletido no servidor web, como uma mensagem de erro, de resultado de pesquisa, ou qualquer resposta que inclua alguma ou toda parte da entrada que é enviada ao servidor como parte da requisição.

XSS Armazenado

Ataques de XSS Armazenados são aqueles o código injetado é armazenado de forma permanente nos servidores alvo, em banco de dados, mensagens de fóruns, logs de visitas, etc.

O Google pode ser uma ferramenta excelente para a exploração de vulnerabilidades XSS. Seus ‘dorks’ (mecanismos usados no auxílio de pesquisas) podem ajudar na descoberta desta vulnerabilidades[10]. Até o mês de março de 2014, já existem 15 falhas cadastradas de sítios web com vulnerabilidades de XSS[6]. Se exploradas, essas vulnerabilidades podem comprometer desde a apresentação de uma página web normal, até as informações de usuários, como é o caso de um sequestro de sessão. No sítio zone-h.org, há uma lista mundial de sítios que foram atacados com diversas vulnerabilidades exploradas, entre elas o XSS, conforme imagem 1.

(3)

Imagem 1 - Sítios web atacados entre os dias 23 e 26 de março de 2014

EXECUTANDO UM ATAQUE XSS

Para demonstrar como é o comportamento de um ataque, será usado o servidor Apache com o aplicativo WebGoat 5.4[3], que é uma aplicação vulnerável, criada especificamente para demonstrar as falhas de desenvolvimento. O servidor web foi instalado em uma estação virtualizada.

Ao acessar a aplicação, na parte de mensagens, podemos colocar no corpo da mensagem o seguinte valor:

(4)

Figura 2 - Inclusão de um script em um fórum web

Podemos ver que o tráfego interceptado mostra o que foi enviado para o servidor Web:

(5)

Quando outro usuário acessar a página, haverá uma nova mensagem postada e ao clicar nela, aparecerá a tela de mensagem do navegador a seguir.

Figura 4 - Execução do script malicioso

O ataque demonstrado acima apenas cria uma janela de texto. Ataques mais complexos podem ser executados, como por exemplo, capturar a identificação de uma sessão de navegação através da captura do cookie de navegação com o script:

(6)

Figura 5 - SessionID passado atravez do XSS

Isso faria com que o atacante assumisse a identificação de um usuário legítimo e realizasse ações baseadas nos direitos de acesso que este possui.

CORREÇÃO E EVASÃO

A partir de uma perspectiva técnica, a melhor forma de correção de uma vulnerabilidade XSS é o tratamento da entrada e saída dos dados no próprio código fonte da aplicação [7]. Entretanto, alguns cenários podem prejudicar ou até mesmo tornar essa tarefa de correção do código não exequível nas empresas[8]:

Disponibilidade de correções

Há situações em que a vulnerabilidade é identificada em aplicações comerciais, fazendo com que a empresa não possa corrigir a falha por si mesma e fica na dependência de que o fabricante desenvolva uma atualização da aplicação.

Tempo de instalação

Mesmo em situações em que uma correção ou um tutorial de como corrigir seja disponibilizado, um processo de aplicação consome tempo, devido aos testes em ambiente de homologação. Código legado

(7)

já não oferece suporte para a determinada versão, já tenha se retirado do mercado ou que a aplicação foi customizada pela equipe interna da empresa, fazendo com que a aplicação não possa ser corrigida ou até mesmo impossibilitando essa correção.

Código terceirizado

Em algumas situações, o desenvolvimento de aplicações terceirizadas pode entrar em conflito com clausulas contratuais, que asseguram as correções apenas a defeitos funcionais.

Geralmente, cabe à área de infra estrutura ou segurança a correção de vulnerabilidades que antes deviam ser tratadas no código fonte.

O bloqueio por filtro é o caso mais comum de proteção[9]. Configurado em Firewalls de Aplicação Web (WAF) ou em navegadores, eles comparam uma lista do que não é permitido e se esses dados forem localizados, serão bloqueados. Uma lista destes valores pode ser encontrado em navegadores como o Internet Explorer, versão 8 ou superior com o comando no prompt:

findstr /c:"sc{r}" \windows\system32\mshtml.dll|find "{"

(8)

Apesar de muito usado e ser efetivo contra ataques padronizados, esta proteção pode ser burlada por codificações. Tomando por exemplo o código utilizado anteriormente e utilizando o aplicativo BurpSuite 1.5, é possível esconder o código para evadir o bloqueio por filtro e acessar a página de alvo.

Figura 7 - Codificação de dados no BurpSuite

Script

(9)

Um ataque reflexivo poderia ser expresso com qualquer parâmetro codificado acima que não dispararia nenhuma regra do WAF ou do navegador

http://sitio_alvo/?param=data:text/html;base64,PHNjcmlwdCBsYW5ndWFnZT0 iamF2YXNjcmlwdCIgdHlwZT0idGV4dC9qYXZhc2NyaXB0Ij5hbGVydCgiTuNvIOkgbyA1N iIpOzwvc2NyaXB0Pg==

CONCLUSÃO E ESTUDOS FUTUROS

A aplicação de uma camada de proteção para a aplicação Web acaba bloqueando os ataques mais comuns de XSS, onde o código de script é passado para a aplicação sem nenhuma modificação. Entretanto, os ataques mais elaborados não utilizam expressões padronizadas e passam por essa camada sem levantar suspeitas, seja ela uma camada de WAF ou uma lista de bloqueio do navegador web. O responsável pela segurança em ambientes corporativos deve sempre procurar maneiras de analisar o conteúdo normalizado do não normalizado, à procura de alguma carga maliciosa escondida no pacote.

Entretanto, há uma série de verificações extras que podem ser realizadas, que não cabem neste artigo. O uso de outros sistemas operacionais, tanto fechados (Apple IOS, Solaris, Blackberry OS, etc) como abertos (Android, Linux, Chrome OS, etc), versões antigas de navegadores web (que não possuem uma lista de bloqueio para XSS), a verificação de regras em outros aplicativos de WAF, a inserção de códigos maliciosos em outros atributos (href, Object, image, form, etc) e a utilização de CharSet diferentes, como o UTF-32, por exemplo. REFERÊNCIA BIBLIOGRÁFICA

[1] E-commerce Brasileiro, a velocidade do crescimento -

http://www.ecommercebrasil.com.br/artigos/e-commerce-brasileiro-a-velocidade-do-crescimento/

[2] Incidentes reportados ao CAIS: por ano - http://www.rnp.br/cais/estatisticas/index.php

[3] Category:OWASPWebGoat Project-

(10)

[4] OWASP Top Ten Project-

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

[5] R. Pelizzi and R. Sekar, “Protection, usability and improvements in reflected XSS filters,” Proc. 7th ACM Symp.Information, Comput.Commun.Secur. - ASIACCS ’12, p. 5, 2012. [6] Exploit Database - Google Hacking Tools - (

http://www.exploit-db.com/search/?action=search&filter_page=1&filter_description=xss&filter_exploit_text=&filter_ author=&filter_platform=0&filter_type=0&filter_lang_id=0&filter_port=&filter_osvdb=&filter_cve=

)

[7] Top 10 2013-A3-Cross-Site Scripting (XSS), -

(https://www.owasp.org/index.php/Top_10_2013-A3-Cross-Site_Scripting_(XSS))

[8] J. Garcia-Alfaro and G. Navarro-Arribas, “Prevention of cross-site scripting attacks on current web applications,” Move to Meaningful Internet …, 2007.

[9] P. Wurzinger, C. Platzer, C. Ludl, E. Kirda, and C. Kruegel, “SWAP: Mitigating XSS attacks using a reverse proxy,” 2009 ICSE Work. Softw.Eng. Secur. Syst., pp. 33–39, May 2009. [10] R. Pelizzi, T. Tran, and A. Saberi, “Large-Scale, Automatic XSS Detection using Google Dorks,” 2011.