Framework para Detecção Automática de Vulnerabilidades em Aplicações Web usando Fuzzing

Transcrição

1 Framework para Detecção Automática de Vulnerabilidades em Aplicações Web usando Fuzzing Miguel Filipe Elias Palmeiro de Brito Beatriz Dissertação para obtenção do Grau de Mestre em Engenharia Informática e de Computadores Orientador: Prof. Miguel Nuno Dias Alves Pupo Correia Júri Presidente: Orientador: Vogal: Prof. Luís Eduardo Teixeira Rodrigues Prof. Miguel Nuno Dias Alves Pupo Correia Prof. Nuno Ferreira Neves Novembro 2014

2 ii

3 iii À minha família

4 iv

5 Agradecimentos Na elaboração desta dissertação não posso deixar de agradecer a todas as pessoas que contribuíram de alguma forma para o desenvolvimento e conclusão da mesma. Em primeiro lugar gostaria de agradecer ao orientador, professor Miguel Pupo Correia pela oportunidade que me deu em abordar este tema de dissertação e por toda a disponibilidade, apoio, ajuda e experiência dadas ao longo deste ano lectivo que foram indispensáveis ao desenvolvimento da mesma. Também gostaria de agradecer a professora Ibéria Medeiros por toda a ajuda dada ao longo do desenvolvimento da dissertação. Agradeço também aos meus amigos mais chegados pela ajuda, disponibilidade e pelas palavras de incentivo ao longo deste trabalho. Por último, mas não menos importante, gostaria de agradecer aos meus pais, irmã e avó por todo o apoio, ajuda e incentivo que me deram. v

6 vi

7 Resumo O problema de detecção de vulnerabilidades em software tem sido amplamente abordado na literatura especializada e é fulcral no desenvolvimento de aplicações que tenham requisitos de segurança. O fuzzing é uma técnica de teste de software, automatizada ou semi-automatizada, que consiste na injecção de grandes quantidades de inputs semi-aleatórios em software de modo a descobrir vulnerabilidades. Muitas das técnicas de detecção de vulnerabilidades actuais necessitam de análise manual por parte dos especialistas para confirmar a sua existência. Assim, pretendeu-se desenvolver um sistema mais expedito para permitir a detecção automática de vulnerabilidades em aplicações web através do uso de fuzzing. A detecção de vulnerabilidades em aplicações web difere da realizada em outros tipos de software por estas possuírem vários componentes back-end, que causam vulnerabilidades específicas, sendo assim conveniente existirem mecanismos que os monitorizem de forma a auxiliar a detecção. Este trabalho apresenta uma framework para fuzzing de aplicações web. Esta framework pretende detectar eficazmente vulnerabilidades através de monitorização que em grande parte está embebida nos vários componentes da aplicação distinguindo-se das abordagens existentes no state of the art. A framework considera a detecção de um conjunto representativo de vulnerabilidades web: injecção de SQL; inclusão de ficheiros local e remota; cross-site scripting reflectido e armazenado. No caso da injecção de SQL são consideradas algumas variantes descobertas recentemente. Também é apresentada uma avaliação experimental da framework desenvolvida neste trabalho tendo em conta amostras de código vulnerável e aplicações open source. Palavras-chave: Segurança, Detecção automática de vulnerabilidades, Aplicações web, Fuzzing vii

8 viii

9 Abstract Automatic detection of vulnerabilities is a problem studied in literature and a very important concern in application development with security requirements. Fuzzing is a software testing technique, automated or semi-automated, that involves injecting a massive quantity of semi-random inputs in software in order to find security vulnerabilities. Many vulnerability detection techniques need manual analysis from specialized people in order to confirm if there any vulnerabilities. To solve this problem, it was decided to develop a system that automatically detects vulnerabilities in web applications using fuzzing. Detecting vulnerabilities in web applications is different than detection in other types of software. This happens because web applications contain many back-end components, that causes specific vulnerabilities, therefore, it is convenient monitoring these components. This works presents a framework for fuzzing web applications. In this work, monitoring is made inside each web application component. The framework detects a representative set of web application vulnerabilities: SQL injection; remote and local file inclusion; reflected and stored cross-site scripting. Our SQL injection detection mechanism is able to detect even subtle attacks of this category presented recently. We present an experimental evaluation of the framework, using vulnerable code samples and open source web applications. Keywords: Security, Discovery of vulnerabilities, Web applications, Fuzzing ix

10 x

11 Conteúdo Agradecimentos v Resumo vii Abstract ix Lista de Tabelas xiii Lista de Figuras xv 1 Introdução Contribuições Estrutura do documento Trabalho Relacionado Descoberta de vulnerabilidades em aplicações Fuzzing Scanners de aplicações web Injecção de ataques Detecção de exploração de vulnerabilidades Detecção em aplicações web usando fuzzing Vulnerabilidades em aplicações web Detecção de vulnerabilidades específicas de aplicações web Injecção de SQL Inclusão de ficheiros remotos/locais Cross-site scripting Detecção de intrusões em aplicações web A Framework Arquitectura Funcionalidades Fuzzer Detecção de injecção de SQL Detecção de inclusão de ficheiros locais e remotos Detecção de cross-site scripting armazenado Detecção de cross-site scripting reflectido xi

12 3.2.6 Detecção de outras vulnerabilidades Implementação Fuzzer Mecanismo de definição do estado de execução da aplicação Detecção de injecção de SQL Detecção de inclusão de ficheiros locais e remotos Detecção de cross-site scripting armazenado Detecção de cross-site scripting reflectido Avaliação Experimental Avaliação com amostras de código Avaliação com aplicações open source Avaliação do mecanismo de detecção de ataques SQLI Conclusão Trabalho futuro Bibliografia 66 A Código vulnerável demonstrando o mecanismo de definição do estado de execução 67 xii

13 Lista de Tabelas 2.1 Definição de injecção de código segundo Ray e Ligatti através de 11 exemplos explicitando em quais destes o conteúdo injectado é código (casos com Sim) ou não (casos com Não) Resumo dos resultados obtidos pela framework com um conjunto de amostras de código vulnerável Resultados obtidos pela framework através de aplicações open source Resumo dos resultados obtidos pela framework executando aplicações open source Detecção de ataques de injecção de código definido por Ray e Ligatti realizado por seis ferramentas e pela framework desenvolvida xiii

14 xiv

15 Lista de Figuras 1.1 Detecção de intrusões usando fuzzing Fases do processo de fuzzing Abordagem de injecção de ataques Esquema de cross-site scripting reflectido Arquitectura da framework mostrando onde é efectuada a monitorização de cada um dos ataques considerados Template da query SELECT info FROM users WHERE user= $user AND pass= $pass Estrutura de uma query alvo de um ataque SQLI estrutural de primeira ordem Estrutura de uma query alvo de um ataque SQLI mímica de primeira ordem Exemplo de funcionamento do mecanismo de detecção de ataques LFI/RFI Arquitectura da framework representado os componentes de monitorização implementados 48 xv

16 xvi

17 Capítulo 1 Introdução A detecção de vulnerabilidades em software tem sido uma temática bastante estudada na literatura e é central no desenvolvimento de aplicações que tenham requisitos de segurança [1, 2, 3]. Muitas vulnerabilidades de software têm sido descobertas através da técnica de fuzzing. Por exemplo, em 2009, a Microsoft desenvolveu e utilizou uma distributed fuzzing framework tendo descoberto cerca de 1800 bugs e vulnerabilidades no Office [4]. Com o incremento e disseminação das aplicações web, estas têm-se tornado um dos mais importantes canais de comunicações entre vários tipos de fornecedores de serviços e clientes. Devido a este aumento de importância das aplicações web, o impacto negativo de falhas de segurança neste tipo de aplicações tem vindo também a crescer. As vulnerabilidades nestas aplicações podem levar a comprometer dados sensíveis dos utilizadores com danos causados cujos custos têm vindo a crescer. As razões para esse fenómeno são, por exemplo, as restrições a nível de orçamento ou de tempo que levam a descurar o aspecto da segurança no desenvolvimento das aplicações. A técnica de fuzzing, consiste na injecção de grandes quantidades de inputs semi-aleatórios em software de uma forma automatizada. Se for detectado um comportamento diferente do expectável, um input pode ter activado um bug, que pode constituir uma vulnerabilidade. Uma das dificuldades nesta temática de descoberta de novas vulnerabilidades em software centra-se no facto deste processo ser efectuado, maioritariamente, de uma forma manual por especialistas em testes de segurança de software. Os especialistas analisam os dados devolvidos pela aplicação alvo de teste e tiram conclusões acerca da existência de vulnerabilidades. Uma tarefa deste género é bastante dispendiosa dado que envolve a análise de um grande volume de dados tornando-se um método ineficiente de detecção de novas vulnerabilidades. Além disso, os casos de teste efectuados pelos especialistas podem não cobrir todo o funcionamento do software nem todas as sequências de operações que podem ser efectuadas sobre este. Como tal, é necessário o uso de ferramentas automatizadas que além de testar casos de testes simples, também efectuam testes aleatórios ou semi-aleatórios sobre o alvo de forma a poder descobrir novas vulnerabilidades. Estas ferramentas automatizadas, além de facilitarem a geração de novos casos de teste, também 1

18 facilitam a monitorização do software que é alvo de teste. Esta monitorização consiste em analisar os vários recursos existentes nesta e observar se existe algum comportamento diferente do expectável. No caso do fuzzing, os mecanismos de monitorização disponíveis têm certas lacunas ao contrário de outros sistemas de detecção de vulnerabilidades [1, 2, 3] que o fazem de uma forma mais expedita. Como tal, pretende-se integrar mecanismos de monitorização ao processo de fuzzing de forma a permitir uma detecção de vulnerabilidades mais eficiente a par de outros sistemas de detecção. Outra dificuldade existente é que muitas aplicações web têm uma arquitectura complexa, o que constitui tanto um desafio como uma oportunidade para detectar se uma injecção explorou determinada vulnerabilidade. No caso de aplicações não web, como serviços de rede ou programas executados na linha de comandos, muitos fuzzers limitam-se a injectar inputs, deixando ao utilizador a tarefa de compreender se estes causam algum comportamento anómalo [5]. Outros tentam detectar comportamentos anómalos através da observação de crashes ou variações no consumo de tempo de CPU ou memória [3], mas cabe ainda ao utilizador compreender se este tipo de anomalias correspondem à exploração de uma vulnerabilidade. Muitas vulnerabilidades existentes em aplicações web estão relacionadas com a interação com os seus componentes como o sistema de gestão de bases de dados (SGBD) ou o sistema de ficheiros, o que complica a monitorização, mas também permite fazê-la nesses pontos. Para resolver as dificuldades referidas anteriormente, este trabalho apresenta uma framework para fuzzing de aplicações web. A principal ênfase do trabalho está na monitorização dos efeitos da injecção, feita em grande parte no interior dos componentes da aplicação web, tendo por objectivo fazer uma detecção eficaz da exploração de vulnerabilidades. É importante esta monitorização ser feita no interior das componentes por diversas razões: 1) são o ponto onde termina o fluxo de entrada de dados, sendo por isso o ponto crucial da vulnerabilidade; 2) sendo esse ponto onde termina o fluxo de entrada de dados, são menores as hipóteses que se têm de fazer sobre como estes são processados pela aplicação, por exemplo, se são ou não validados ou descodificados; 3) permite utilizar funcionalidades das próprias componentes para fazer a detecção. Estas vantagens podem ser ilustradas com o caso dos ataques de injecção de SQL, que na framework são detectados no SGBD: i) estes ataques têm por objectivo ler ou escrever numa base de dados, logo o SGBD é o lugar mais adequado para os detectar; ii) os inputs chegam ao SGBD validados, sanitizados, codificados ou não, não sendo portanto necessário tecer hipóteses sobre como estes são processados pela aplicação; iii) o próprio SGBD extrai a estrutura das queries SQL, simplificando a detecção. Neste trabalho, pretende-se detectar quando é que uma vulnerabilidade foi explorada, ou seja, se aconteceu uma intrusão como está ilustrado na Figura 1.1. Para tal, é necessário numa primeira fase gerar os inputs. De seguida, na segunda fase, enviar os inputs à aplicação alvo de teste através do uso de uma ferramenta de fuzzing. Na terceira fase, é necessário observar se houve alguma intrusão. Este processo efectua-se recorrendo aos mecanismos de monitorização no interior das componentes. Estas três fases referidas anteriormente, são abrangidas pela framework. Neste trabalho é explicado como a framework detecta as seguintes vulnerabilidades: injecção de SQL de primeira e segunda ordem (SQLI); inclusão de ficheiros locais ou remotos (LFI/RFI); cross-site scripting (XSS) reflectido e armazenado. No caso da injecção de SQL são consideradas algumas 2

19 Figura 1.1: Detecção de intrusões usando fuzzing variantes descobertas recentemente [6]. A escolha recaiu sobre este conjunto de vulnerabilidades pois as de SQLI e XSS são consideradas há vários anos como as que têm um maior risco associado [7], enquanto as de LFI e RFI têm particular impacto nas aplicações web escritas em PHP. Também é explicado, neste trabalho, como é que a framework pode ser expandida de forma a detectar outras vulnerabilidades que se inserem na categoria de vulnerabilidades relativas a falta de validação do input proveniente do utilizador. A framework foi implementada de modo a permitir encontrar vulnerabilidades em aplicações PHP executadas pelo interpretador de linguagem de servidor Zend Engine e que utilizem como sistema de gestão de base de dados o MySQL. Além disso, a framework foi avaliada através de amostras de código vulnerável e aplicações open source tendo em conta o número de vulnerabilidades encontradas. 1.1 Contribuições As contribuições deste trabalho são: Framework de fuzzing em aplicações web e um conjunto de mecanismos de monitorização de ataques; Implementação de vários mecanismos de detecção de vulnerabilidades baseadas na falta de validação do input. As vulnerabilidades visadas são: injecção de SQL; inclusão de ficheiros locais e remotos; cross-site scripting reflectido e armazenado. Avaliação experimental da framework através de amostras de código vulnerável e aplicações open source. 3

20 1.2 Estrutura do documento O restante deste documento está organizado da seguinte forma: Capítulo 2 - Trabalho Relacionado: apresenta o state of the art necessário à compreensão do tema deste trabalho servindo como base para a concepção da solução proposta. São abordados vários mecanismos de teste de vulnerabilidades em aplicações através da sua execução, nomeadamente: fuzzing, scanners de aplicações web e injecção de ataques em aplicações. Também é abordado como é efectuado a detecção de exploração de vulnerabilidades, as vulnerabilidades existentes em aplicações web e como é que algumas destas são detectadas. Por fim, são abordados sistemas de detecção de intrusões; Capítulo 3 - Framework: descreve a solução proposta, uma framework para fuzzing de aplicações web e respectiva detecção de vulnerabilidades, focando-se na forma como esta é feita, diferindo de outras abordagens existentes no state of the art, através da monitorização existente no interior dos vários componentes back-end; Capítulo 4 - Implementação: descreve os detalhes de implementação da solução proposta. Descreve quais as tecnologias ou abordagens que foram utilizadas para implementar cada componente ou funcionalidade da arquitectura proposta e o seu papel; Capítulo 5 - Avaliação Experimental: apresenta a avaliação da solução proposta tendo em conta amostras de código vulnerável e aplicações open source; Capítulo 6 - Conclusão: conclui o documento, resumindo o trabalho desenvolvido neste trabalho. Também são introduzidos certos aspectos que se podem ter em conta relativamente a trabalho futuro. 4

21 Capítulo 2 Trabalho Relacionado A compreensão das implicações deste trabalho torna necessário o conhecimento de conceitos fundamentais na área da segurança e detecção de vulnerabilidades. Na subsecção 2.1 abordam-se vários mecanismos de descoberta de vulnerabilidades em aplicações: fuzzing, scanners de aplicações web e injecção de ataques. Na subsecção 2.2, são explicitadas técnicas de detecção de exploração de vulnerabilidades usando fuzzing não só em aplicações web mas também em outros tipos de software. Na subsecção 2.3 são apresentadas as vulnerabilidades em aplicações web mais reconhecidas tendo em conta a lista divulgada pelo Open Web Application Security Project OWASP das dez vulnerabilidades de maior risco [7]. Na subsecção 2.4 são abordadas várias técnicas de detecção de vulnerabilidades sendo estas: injecção de SQL (primeira e segunda ordem); inclusão de ficheiros remotos e locais; cross-site scripting reflectido e armazenado. Por fim, na subsecção 2.5, são apresentados sistemas de detecção de intrusões em aplicações web. 2.1 Descoberta de vulnerabilidades em aplicações Nesta secção, vão ser abordados alguns dos mecanismos de detecção de vulnerabilidades em aplicações através da sua execução, mais em específico, a técnica de teste de software chamada fuzzing, scanners de aplicações web e também se vai falar sobre a injecção de ataques em aplicações Fuzzing O fuzzing [8, 9, 10] é uma técnica de teste de software que envolve fornecer dados aleatórios ou semialeatórios, através da análise da aplicação alvo de teste, como input de um programa de computador para este processar. De seguida pretende-se monitorizá-lo de forma a ver se esse input causou algum comportamento diferente do esperado no software, por exemplo, uma excepção ou retorno de dados incorrecto. O fuzzing é um processo automático ou semi-automático pois pode ser necessário interação de forma a recolher informações sobre o alvo de teste. Esta técnica de teste está relacionada com a análise dos valores de fronteira (BVA) [8] onde se observam um intervalo de valores conhecidos válidos para um input e de seguida criam-se casos de 5

22 teste com valores dentro ou fora desse intervalo. Os resultados desta técnica ajudam a assegurar que as funções de tratamento de excepções conseguem tratar apropriadamente casos válidos e inválidos. O fuzzing é semelhante ao BVA, mas no caso do primeiro não se está apenas interessado nos valores fronteira mas também em qualquer input que possa despoletar algum comportamento anómalo ou desconhecido. Dentro das categorias de testes o fuzzing pode-se inserir em duas categorias: black-box e grey-box. O fuzzing pode-se inserir na categoria de teste black-box dado que se pode fornecer dados aleatórios à aplicação sem recorrer à sua estrutura interna. No caso da categoria grey-box, o fuzzing pode fornecer dados não totalmente aleatórios à aplicação pois pode recorrer a determinadas informações sobre a aplicação, como por exemplo, a sua documentação ou o seu código. Com essas informações relativas à aplicação, podem-se gerar casos de teste com maior potencial de originar um comportamento anómalo. Como se referiu anteriormente, o processo de fuzzing não consiste apenas no envio de dados aleatórios, caso isso acontecesse, seria uma operação bastante dispendiosa onde a maioria dos inputs seria rejeitado devido a uma sintaxe incorrecta. Para resolver essa situação, os dados a ser enviados também podem ser semi-aleatórios, ou seja, inputs que são gerados tendo em conta o conhecimento da aplicação alvo de teste e que conseguem contornar os seus mecanismos de validação do input e verdadeiramente testar o seu funcionamento. Para evitar tal situação, os dados a serem enviados devem ser semi-aleatórios através de técnicas ou heurísticas para que os valores escolhidos sejam mais prováveis de despoletarem vulnerabilidades tendo em conta uma análise do alvo ou de saber quais são os erros mais prováveis a existirem implementados pelos programadores, dentro destas técnicas estão incluídas [8, 11]: Análise dos valores de fronteira; Uso de repetições de string com vários caracteres diferentes; Inclusão de caracteres não alfanuméricos incluindo caracteres especiais pois costumam ser frequentemente utilizados como delimitadores de instruções; Inclusão de tokens de strings (ex: %d, %08x); Uso de codificações alternativas para os caracteres; Inclusão de fragmentos de código. Tendo em conta esta utilização das técnicas acima referidas, existe uma categorização de como é que o fuzzer cria os inputs de casos de testes que são as seguintes [8, 10, 12]: Mutation-based: aplicam-se mutações, isto quer dizer, pequenas alterações no input sem alterar a estrutura, nas amostras de dados existentes para criar casos de testes; Generation-based: criam-se casos de teste de raiz por modelação ou conhecimento acerca do protocolo ou formato de ficheiro alvo do ataque. 6

23 Figura 2.1: Fases do processo de fuzzing Além destas duas classificações que se fizeram aos fuzzers também se pode defini-los em categorias dependendo do alvo que vão testar sendo estes: Local Fuzzers: fuzzers para alvos como aplicações que recebem input através de linha de comandos, utilizam valores de variáveis globais ou para aplicações que processam ficheiros de um determinado formato. Como tal, injectam inputs em programas na mesma máquina onde o fuzzer se encontra; Remote Fuzzers: fuzzers para alvos como protocolos de rede, aplicações web ou browsers, injectando os inputs em máquinas remotas; In-Memory Fuzzers: este tipo de fuzzers contêm um mecanismo que permite guardar o estado da aplicação num determinado ponto e injectar dados nas rotinas de interpretação do input. Após a injecção de cada caso de teste, o estado guardado anteriormente é restaurado e novos dados são injectados na aplicação. Este processo repete-se até que todos os casos de teste tenham sido executados. Este tipo de fuzzers podem injectar inputs em máquinas locais ou remotas. Independentemente da abordagem ou do tipo de fuzzer que se pretende utilizar, existem fases em comum a todas estas abordagens como se pode observar pela Figura 2.1 e que vão ser enunciadas de seguida [8]. A primeira fase, consiste na identificação do alvo e no estudo do histórico de vulnerabilidades que essa aplicação já possa ter sofrido de forma a auxiliar o processo de detecção de vulnerabilidades. Na segunda fase, devem-se identificar os inputs a testar fazendo uma enumeração de vectores de 7

24 input para usar no processo de fuzzing. Pretende-se procurar fontes potenciais de input (ex: headers, nomes de ficheiros, variáveis de ambiente) que podem causar danos ao sistema. Na terceira fase, após a identificação dos inputs que podem ser passiveis de explorar vulnerabilidades na aplicação, deve-se gerar os dados a enviar através de mecanismos de mutação de dados existentes ou através da geração dinâmica de dados. A quarta fase consiste na acção de executar o processo de fuzzing, isto é, a acção de enviar os pacotes de dados ao alvo, ou de abrir um ficheiro ou lançar um processo alvo através do input selecionado e gerado nos passos anteriores. Na quinta fase, é necessário haver uma monitorização de faltas e de excepções causadas pelos dados enviados para saber qual ou quais os dados que podem ter causado a paragem do funcionamento da aplicação alvo. Este processo de descobrir as causas para a paragem do funcionamento da aplicação é um grande desafio, principalmente, para casos de vulnerabilidades com múltiplas etapas, por exemplo, envio de vários inputs. Nesta situação torna-se complicado poder monitorizar e concluir que determinada sequência de inputs causou uma falta no sistema alvo. Por fim, após a falta ter sido identificada pode ser necessário determinar se o bug pode ainda ser mais explorado. Normalmente, este processo é manual e requer um conhecimento em segurança especializado. Dado que o foco deste trabalho centra-se na descoberta de vulnerabilidades em aplicações web é necessário saber como é que funciona o fuzzing para este tipo de alvo em específico. O fuzzing de aplicações web [8] insere-se dentro da categoria de fuzzers remotos e foca-se especificamente em pacotes que estão de acordo com o protocolo HTTP (Hypertext Transfer Protocol). Este tipo de fuzzing pode descobrir vulnerabilidades na aplicação em si ou em qualquer dos seus componentes Scanners de aplicações web Scanners de aplicações web [1, 2] são ferramentas automatizadas que sondam este tipo de aplicações comunicando de forma a identificar vulnerabilidades e fraquezas na arquitectura do sistema. Por norma, os scanners de aplicações web possuem três módulos principais: módulo crawler, módulo de ataque e um módulo de análise. O módulo crawler funciona da seguinte maneira: através de um conjunto de URLs, este devolve as páginas correspondentes e identifica todas as páginas alcançáveis na aplicação alvo de teste. Este módulo também identifica todos os pontos de entrada da aplicação, tais como: parâmetros de pedidos GET, campos de entrada de formulários HTML. O módulo de ataque analisa as páginas retornadas pelo crawler e os seus pontos de entrada e de seguida efectua ataques através do envio de dados que podem vir a explorar vulnerabilidades em determinado ponto de entrada. Essa identificação de existência de vulnerabilidades é efectuada através do módulo de análise, cujo objectivo é avaliar as respostas dadas pela aplicação web. Com as respostas analisadas, pretende-se 8

25 concluir se aquele ponto de entrada é vulnerável tendo em conta os dados enviados pelo módulo de ataque. Este tipo de scanners seguem a abordagem de teste black-box dado que não têm acesso ao código e só conseguem detectar vulnerabilidades realizando ataques às cegas sobre os pontos de entrada da aplicação. Além disso, simulam ataques externos provenientes de atacantes, fornecendo métodos para a detecção de vulnerabilidades importantes, permitindo assim configurar as defesas da aplicação como por exemplo a firewall. O fuzzing distingue-se dos scanners, dado que o primeiro exercita apenas uma amostra aleatória do comportamento do sistema e na maioria das vezes os casos de testes gerados pelo fuzzer são bastante simples/específicos para serem reutilizados em diferentes sistemas alvo de teste. No caso dos scanners, estes procuram vulnerabilidades já conhecidas através de assinaturas de ataques conhecidos com que estes tipo de ferramentas são pré-configuradas, ao contrário do fuzzing que tenta descobrir novas vulnerabilidades. Além disso, os scanners estão inseridos num sistema completo onde inclui: análise dos pontos de entrada da aplicação permitindo exercitar uma maior amostra do comportamento do sistema; envio de dados à aplicação; análise das respostas dadas pela aplicação. O fuzzing pode ser usado como técnica de teste de software utilizada por um scanner de forma a identificar as vulnerabilidades na aplicação através do envio de inputs à aplicação que vai ser alvo de teste. De forma a avaliar a qualidade de um scanner de aplicações web existem vários critérios que este deve suportar, sendo estes explicitados de seguida [13]: Protocolos de transporte (ex: HTTP, SSL/TLS); Configuração de um proxy; Mecanismos de autenticação (ex: digest, Kerberos, certificados SSL de cliente); Gestão de sessões: inicializar/actualizar/readquirir token de sessão, detectar se a sessão expirou, suporte aos vários tipos de tokens existentes (ex: HTTP cookies, parâmetros HTTP); Configuração de um web crawler; Parsing de conteúdo web (ex: HTML, JavaScript, VBScript, XML, plaintext) e suporte de codificação de caracteres; Configuração e customização de testes; Comando e controlo do scanner; Geração de relatórios relativos aos resultados obtidos. Além disso, uma outra forma de avaliar a qualidade e a utilidade de um scanner é na sua habilidade de detectar vulnerabilidades. Um scanner, segundo [13], deve detectar um conjunto mínimo de vulnerabilidades ou problemas de arquitectura da aplicação sendo estes: 9

26 Figura 2.2: Abordagem de injecção de ataques Problemas de autenticação (ex: autenticação insuficiente, fraca validação na recuperação de passwords); Problemas de autorização (ex: autorização insuficiente, previsão de tokens de sessão); Ataques do lado do cliente (ex: XSS, injecção HTML, CSRF); Execução de comandos (ex: injecção de SQL, injecção de comandos SO, inclusão de ficheiros remotos/locais); Divulgação de informações sensíveis Injecção de ataques A injecção de ataques [14, 3] é um método de descoberta automática de vulnerabilidades em componentes de software. Uma ferramenta de injecção de ataques, imita o comportamento de um atacante que sistematicamente ataca o sistema alvo enquanto monitoriza o seu comportamento. Este processo é representado com as suas acções principais na Figura 2.2 e explicado mais pormenorizadamente de seguida. Em primeiro lugar, são gerados numerosos ataques de forma a avaliar completamente o sistema alvo em termos de funcionalidade. De forma a existir um maior nível de confiança acerca da ausência de faltas, os ataques devem ser exaustivos e devem abranger o máximo de classes de vulnerabilidades possível. Tendo em conta o mecanismo de geração de ataques, é esperado que uma parte destes ataques seja rejeitado pelos mecanismos de validação de dados de input enquanto alguns conseguem prosseguir até chegar à camada da aplicação onde se processa o input. Estes ataques que foram gerados no passo anterior, neste segundo passo são injectados enquanto o estado da aplicação é monitorizado, no passo 3, de forma a observar algum comportamento inesperado. Dependendo da capacidade de monitorização, a informação recolhida pode variar de um simples output do alvo, memória alocada pelos recursos do sistema ou sequência de chamadas de sistema que foram 10

27 executadas. Sempre que um erro ou uma falha é observada indica que potencialmente foi descoberta uma nova vulnerabilidade. Além destes três passos, estão incluídos mais dois que existem na framework apresentada em [14]: Especificação do protocolo: este passo insere-se antes da geração de ataques e permite fornecer a especificação da interface externa implementada pelo sistema alvo. O propósito deste passo foca-se no facto que se a ferramenta souber informações adicionais sobre o alvo pode gerar testes mais eficazes; Análise do ataque: este passo insere-se após a monitorização e tem como objectivo identificar a presença de vulnerabilidades dependendo bastante da informação recolhida durante o passo de monitorização e do conhecimento acerca da especificação do sistema alvo. Como se pode observar e relacionando com o tema desta secção é possível inserir o fuzzing no contexto desta metodologia da mesma forma como também ocorreu no caso dos scanners. O processo de geração dos ataques a efectuar contra a aplicação alvo pode ser efectuado através da técnica de teste de fuzzing. No entanto, a injecção de ataques distingue-se do fuzzing dado que o segundo só exercita uma amostra aleatória do comportamento do sistema. Além disso, a maioria das vezes os casos de testes criados pelo fuzzer são bastante simples ou específicos para serem reutilizados em diferentes sistemas alvos. Os fuzzers também têm uma lacuna em relação a mecanismos de monitorização, ao contrário das várias abordagens de monitorização existentes no sistema AJECT [3]. Por outro lado, o sistema AJECT [3] é independente da aplicação alvo ou do protocolo implementado ao contrário do fuzzing. 2.2 Detecção de exploração de vulnerabilidades Para verificar se as tentativas de input através do fuzzer tiveram resultado é necessário existirem mecanismos que consigam monitorizar o estado do sistema alvo. Como já foi referido anteriormente, normalmente usam-se ferramentas de monitorização ou recursos do sistema de forma a detectar se este foi alvo de falhas, isto é, se lançou excepções e eventualmente possa ter levado a aplicação a falhar. Nestas ferramentas de monitorização e recursos do sistema estão incluídos por exemplo [8]: Ficheiros de log: onde pode estar registado alguma falha de execução devido ao input gerado pelo fuzzer; Debuggers: que são anexados a aplicação que é alvo de teste, permitindo a identificação de excepções tratadas ou não; Códigos ou mensagens retornadas: por parte do alvo em resposta ao input fornecido podendose tentar identificar algo que difere das mensagens de resposta de pedidos benignos; 11

28 Conexão interrompida: verificação se a conexão com o sistema alvo persiste após o envio do input, pois em caso contrário pode indicar que o input ou sequência de inputs enviado anteriormente pelo fuzzer pode ter causado uma negação do serviço da aplicação. Em termos gerais, a detecção de activação de vulnerabilidades é efectuada através da análise dos recursos existentes retornados pela aplicação alvo de teste de forma a tirar pistas de quais foram os inputs que despoletaram o funcionamento anómalo da aplicação. A detecção também pode ser efectuada através de ferramentas de monitorização que sendo anexadas à aplicação alvo de teste podem fornecer informações internas relativas ao estado desta Detecção em aplicações web usando fuzzing A maioria das técnicas definidas para detecção de vulnerabilidades através do input gerado pelo fuzzer que foram referidas na secção anterior são semelhantes para o caso das aplicações web diferenciado-se apenas no tipo de dados em específico que estas podem processar, como por exemplo o tipo de formato da resposta (HTTP). A detecção de excepções neste tipo de aplicações é um grande desafio, dado que o fuzzer envia muitos pedidos à aplicação sendo complicado identificar qual dos pedidos fez com que a aplicação passasse a ter um comportamento anómalo ou que a fizesse lançar uma excepção. Apenas é possível concluir que existe uma condição que leva o sistema a ficar vulnerável. Existe uma grande dificuldade em identificar a causa de falta na aplicação, pois pode ter sido causada a partir de um único pedido como também pode ter sido a partir de uma sequência específica de pedidos. De forma a poder-se observar a existência de vulnerabilidades tem que se ter em conta os seguintes dados [8]: HTTP Status Code: quando um servidor web responde a um pedido do cliente este inclui um código para identificar o estado desse pedido podendo fornecer pistas sobre quais os pedidos provenientes do fuzzer que devem ser investigados mais aprofundadamente. Por exemplo, uma sequência de erros internos do servidor (500) podem sugerir que os pedidos anteriores causaram uma anomalia na aplicação. Outro caso, um erro de não autorização (401) pode sugerir que a página requisitada existe mas não tem permissões para acedê-la; Mensagem de erro do servidor web: a aplicação pode ter sido desenhada para apresentar mensagens de erro directamente no conteúdo da página web podendo ser possível obter informações úteis acerca do estado do sistema através da análise das mesmas; Conexão interrompida: causada por um dos inputs do fuzzer que levou a um freeze/crash da aplicação causando uma negação de serviço dos pedidos seguintes; Ficheiros de log: a maioria dos servidores web são configurados para fazer o registo dos vários tipos de erros através de logs, fornecendo assim pistas de quais pedidos causaram problemas e que levam a uma condição de vulnerabilidade. De forma a facilitar essa observação deve-se sincronizar a altura do pedido e o log correspondente do lado do servidor; 12

29 Debuggers: anexando-o a aplicação alvo de teste é a melhor forma de identificar as excepções lançadas pela aplicação, pois é possível observar tanto as excepções tratadas como as que não foram tratadas e podem ter causado uma falha no servidor e tentar relaciona-las com os pedidos efectuados. No entanto, este tipo de mecanismos não têm sido integrados em fuzzers pois não permitem uma detecção precisa de ataques que explorem vulnerabilidades existentes neste tipo de aplicações permitindo apenas indicar a possibilidade da existência de vulnerabilidades. 2.3 Vulnerabilidades em aplicações web Para que seja possível identificar automaticamente vulnerabilidades em aplicações web, em primeiro lugar é necessário saber e perceber quais são as vulnerabilidades a que este tipo de aplicações está sujeita, para tal recorreu-se ao OWASP Top : The Ten Most Critical Web Application Security Risks [7], onde referem as vulnerabilidades com um maior risco, sendo estas: A1 Injection: Falhas de injecção (ex: SQL, SO, LDAP) que ocorrem quando dados hostis são enviados para um interpretador como parte de um comando ou query. Os dados do atacante podem enganar o interpretador levando a executar comandos não intencionados ou acedendo a dados sem a autorização apropriada; A2 Broken Authentication and Session Management: Funções da aplicação relacionadas com autenticação e gestão de sessão que não foram implementadas correctamente. Permite aos atacantes poderem comprometer passwords, chaves, tokens de sessão ou explorar quaisquer outras falhas de implementação de forma a assumir a identidade de outros utilizadores; A3 Cross-site scripting (XSS): Falhas de cross-site scripting ocorrem sempre que uma aplicação utiliza dados que não são de confiança que vêm como input e envia-as para o browser web sem uma validação apropriada. XSS permite aos atacantes, por exemplo, executar scripts no browser da vítima podendo apoderar-se das sessões dos utilizadores ou redirecionar o utilizador para websites maliciosos; A4 Insecure Direct Object References: Uma referência directa a um objecto ocorre quando um programador expõe a referência da implementação do objecto, como por exemplo: um ficheiro, directoria ou chave de base de dados. Sem a verificação do controlo de acessos ou outro mecanismo de protecção, os atacantes podem manipular essas referências para aceder a dados não autorizados; A5 Security Misconfiguration: Uma má configuração de segurança dos componentes de uma aplicação, pode permitir que utilizadores maliciosos consigam, por exemplo, alterar o website, obter acessos não autorizados, comprometer ficheiros ou realizar quaisquer outras acções não intencionadas. Assim, de forma a haver uma boa segurança, é preciso de se ter uma configuração 13

30 segura definida e implementada para a aplicação, framework, servidor de aplicação, servidor web, servidor de base de dados e plataforma. Devem ser definidas, implementadas e mantidas configurações de segurança pois as que são definidas por omissão pelos componentes são normalmente inseguras. Além disso, o software dos componentes deve estar sempre actualizado de forma a corrigir eventuais vulnerabilidades; A6 Sensitive Data Exposure: Várias aplicações web não protegem de forma correcta dados sensíveis (ex: cartões de crédito, NIF, credenciais de autenticação). Os atacantes podem roubar ou modificar esses dados que estão pouco protegidos para efectuar fraudes de cartões, roubo de identidade, entre outros crimes. Estes dados importantes devem ser protegidos com um maior cuidado, por exemplo serem cifrados; A7 Missing Function Level Access Control: A maioria das aplicações web verificam as permissões de acesso ao nível das funções antes de torná-las visíveis ao utilizador. No entanto, a aplicação necessita de realizar o mesmo controlo de acesso no servidor sempre que cada função é acedida, caso contrário, os atacantes são capazes de forjar os pedidos de forma a aceder a funcionalidades sem terem a autorização apropriada; A8 Cross-site Request Forgery (CSRF): Este tipo de ataque necessita que a vítima tenha o login efectuado na página que contém a vulnerabilidade de forma a incluir o cookie de sessão ou outro tipo de informação de autenticação. Assim, o atacante ao enviar um URL contendo um pedido HTTP forjado e malicioso à vítima, caso esta aceda vai efectuar operações maliciosas. Isto permite que o atacante force o browser da vítima a gerar pedidos que a aplicação vulnerável pense que são pedidos legítimos por parte da vítima; A9 Using Known Vulnerable Components: Componentes como por exemplo: bibliotecas, frameworks e outros módulos de software na maioria da vezes executam-se com o máximo de privilégios. Dado que esses componentes foram desenvolvidos por terceiros, existe a possibilidade destes conterem vulnerabilidades que podem afectar o sistema que os inclui. Assim, se um componente vulnerável é explorado, tal ataque pode levar a perdas de dados ou apoderarem-se do servidor. Aplicações que usem componentes vulneráveis podem prejudicar as suas políticas ou configurações de segurança implementadas e facilitar determinados ataques. De forma a resolver tal situação, estes componentes de terceiros devem ser executados com o mínimo de privilégios necessários para que em caso de ataque tenham o mínimo impacto possível. Além disso, também deve-se apenas instalar componentes que sejam fidedignos; A10 Unvalidated Redirects and Fowards: As aplicações web frequentemente redireccionam e encaminham utilizadores para outras páginas ou websites e utilizam dados inseguros para determinar o destino. Caso não haja uma validação apropriada, os atacantes podem redireccionar as vítimas para páginas contendo mecanismos de malware ou phishing, ou encaminhar o acesso para páginas não autorizadas. 14

31 Também se recorreu ao WASC Threat Classification v2.0 do Web Application Security Consortium [15] para obter uma lista das vulnerabilidades existentes em aplicações web. As vulnerabilidades mais relevantes são apresentadas de seguida podendo-se observar vulnerabilidades em comum entre esta classificação e em [7]: Brute Force Cross-site Scripting Cross-site Request Forgery Denial of Service Integer Overflows OS Commanding Path Traversal Remote File Inclusion SQL/XML Injection Application/Server Misconfiguration Insufficient Authentication/Authorization Insufficient Transport Layer Protection Além das classificações do OWASP e do WASC [7, 15] também se recorreu ao Common Weakness Enumeration (CWE) v2.5 [16] que possui uma vasta listagem de vulnerabilidades das quais se podem reter as seguintes categorias de vulnerabilidades: Application/Server Misconfiguration Improper Input Validation Path Traversal/Equivalence Improper Handling of File Names Buffer Overflow Integer Overflow/Underflow Information Exposure Credentials Management Authentication Bypass Cryptographic Issues Attack Injections (SQL, XML) Remote File Inclusion Cross-site Request Forgery Temporary File Issues Tendo em conta a vastíssima variedade de vulnerabilidades existentes em aplicações web, este trabalho, como será apresentado na subsecção 2.4, foca-se principalmente nas vulnerabilidades de injecção de SQL (primeira e segunda ordem), inclusão de ficheiros remotos/locais e também cross-site scripting reflectido e armazenado. A escolha recaiu sobre este conjunto de vulnerabilidades pois as vulnerabilidades de injecção de SQLI e XSS são consideradas há vários anos como as que têm um maior risco associado [7], enquanto as de LFI/RFI têm particular impacto nas aplicações web escritas em PHP, sendo utilizada em mais de 77% das aplicações web [17]. Apesar de estas serem as vulnerabilidades consideradas, a framework pode ser estendida para encontrar outras. 15

32 2.4 Detecção de vulnerabilidades específicas de aplicações web Como foi referido na secção 2.2 existem várias técnicas de identificação de eventos anómalos na aplicação alvo que podem ser consequência do input gerado pelo fuzzer. Nesta secção, vão ser abordadas várias técnicas de detecção de vulnerabilidades a determinados ataques independentemente da técnica de teste de software. As vulnerabilidades que serão abordadas são as seguintes: injecção de SQL, inclusão de ficheiros remotos/locais e cross-site scripting. Em cada uma destas subsecções será abordado inicialmente a vulnerabilidade em questão, seguindose das várias técnicas de detecção existentes na literatura e a aplicabilidade dessas técnicas ao trabalho. Para cada tipo de vulnerabilidade que vai ser explicada de seguida existe um tipo de ataque que lhe corresponde e que habitualmente toma o mesmo nome, por exemplo, ataque/vulnerabilidade de injecção de SQL Injecção de SQL Uma injecção de SQL [18] é uma vulnerabilidade do tipo de injecção de código (A1) [7] onde o atacante usa inputs especialmente criados de forma a enganar a base de dados para consequentemente poder executar instruções não pretendidas pela aplicação. Assim, um ataque de injecção de SQL ocorre quando um atacante altera a sintaxe e/ou semântica de uma query inserindo operadores ou palavras chave SQL. Uma vulnerabilidade deste tipo tira partido da falta de validação, sanitização ou codificação do input do utilizador. Os ataques sobre este tipo de vulnerabilidade que têm efeito imediato sobre o comportamento do alvo são designados de primeira ordem. Nos ataques de segunda ordem, primeiro o atacante fornece à aplicação um input que é armazenado na base de dados e posteriormente, o atacante fornece um segundo input que cria uma query para extrair aquele que estava armazenado, criando uma segunda query modificada. Um exemplo de um ataque de injecção de SQL de primeira ordem é o seguinte: uma aplicação web faz um acesso a base de dados de forma a aceitar as credenciais (utilizador, pin) fornecidas pelo utilizador sendo o pedido à base de dados o seguinte: SELECT info FROM users WHERE login= $utilizador AND pin=$pin Um caso normal de funcionamento é o utilizador definir, por exemplo, o utilizador=miguel e pin=1234 sendo a interpretação feita pela base de dados a seguinte: SELECT info FROM users WHERE login= Miguel AND pin=1234 Pelo contrário, caso o atacante forneça o input: utilizador= OR 1=1 - - instrução que vai ser interpretada na base de dados é: e qualquer pin, a SELECT info FROM users WHERE login= OR 1=1 -- AND pin=1234 Isto vai fazer com que a base de dados interprete tudo após o token WHERE como uma condição e com a inclusão de OR 1=1 na cláusula vai tornar esta condição uma tautologia. Como a parte posterior 16

33 está comentada através dos caracteres - -, faz com que a base de dados devolva toda a informação correspondente a tabela users. Apesar dos ataques de injecção de SQL serem populares há quase uma década, recentemente Ray e Ligatti argumentaram que a definição de ataques de injecção de código como os de injecção de SQL é problemática, introduzindo o conceito de CIAO (Code-Injection Attacks on Outputs) [6]. Normalmente, uma injecção de SQL ocorre sempre que um input de um utilizador modifica a estrutura sintáctica do output de determinada aplicação. No entanto, os autores referem que esta definição tem alguns problemas, pois existem casos que este tipo de ataques não alteram a estrutura, enquanto que há casos de não-ataques que alteram essa estrutura. De forma a resolver esta situação, Ray e Ligatti definiram a noção de injecção de código através de 11 exemplos de injecções definindo quais delas são consideradas como código e quais não. De seguida são apresentados os exemplos (elementos que foram injectados na query a sublinhado) que permitiram definir a noção de injecção de código. Também se pode observar na Tabela 2.1 quais dos exemplos contêm injecções de código. 1. SELECT balance FROM acct WHERE password= OR 1= SELECT balance FROM acct WHERE pin = exit(); 3....WHERE pin = 1000>GLOBAL; 4. SELECT * FROM properties WHERE filename= f.e 5....WHERE pin = exit(); 6....WHERE pin = aaaa(); 7. SELECT * FROM t WHERE flag= TRUE; 8. SELECT * FROM t WHERE flag= aaaa; 9. SELECT * FROM t WHERE password= password; 10. CREATE TABLE t (name CHAR(40)) 11. SELECT * FROM t WHERE name= x Ray e Ligatti Sim Sim Sim Não Sim Sim Não Sim Sim Sim Não Tabela 2.1: Definição de injecção de código segundo Ray e Ligatti através de 11 exemplos explicitando em quais destes o conteúdo injectado é código (casos com Sim) ou não (casos com Não). Para a detecção deste tipo de vulnerabilidade existem duas formas genéricas de a efectuar que são as seguintes [18, 19, 20, 21, 22, 23]: 1. Verificação se são utilizados operadores ou caracteres especiais da linguagem devido a falta de validação do input [22]; 17

34 2. Verificação se existe uma alteração da estrutura lógica da instrução de SQL da estrutura pretendida pelo programador com o uso de input correcto [18, 19, 20, 21, 23]. Em relação ao primeiro ponto, em [22] utilizam-se expressões regulares de forma a detectar este tipo de vulnerabilidade através da técnica de tainting positivo. Esta técnica consiste na identificação e marcação de caracteres definidos como seguros, ao invés de outras soluções que marcam os caracteres perigosos e que devem ser rejeitados. A solução faz uma avaliação da sintaxe das queries antes de serem processadas pela base de dados e bloqueia todas as que contenham pelo menos um caracter sem estar marcado. Nesta solução utilizou-se um sistema de detecção de intrusões baseado na rede (NIDS) de forma a escutar os pacotes enviados e verificar a existência das expressões regulares no conteúdo destes. A solução proposta em [22] não é eficiente dado que esta solução utiliza um NIDS de forma a escutar os pacotes observados e detectar se estes podem causar uma injecção de SQL. A solução proposta não garante que a aplicação não possui mecanismos de validação e sanitização no momento em que processa os pedidos de forma a evitar que um ataque destes ocorra e como tal não seria vulnerável. Assim, esta solução poderia identificar que determinado pedido é passível de um ataque de injecção de SQL quando na verdade seria sanitizado pela aplicação já não sendo perigoso para esta. Em relação ao segundo ponto, existem várias alternativas de detecção. A solução apresentada por Halfond e Orso [18, 19], o sistema AMNESIA, pretende detectar estes ataques através de análise estática de código e da monitorização da aplicação em tempo de execução. Esta análise estática consiste na identificação de pontos no código onde se efectuam queries SQL de uma forma automática. De seguida para cada ponto referido anteriormente constrói-se um modelo que representa todas as queries SQL que podem ser geradas naquele ponto através de um autómato finito não-determinista cujas transições são tokens SQL: operadores ou caracteres da linguagem. Em tempo de execução, a técnica monitoriza as queries geradas dinamicamente e verifica se estão de acordo com o modelo estático. Caso sejam diferentes, indica que o modelo gerado foi violado e como tal, classifica o pedido como um ataque. Esta solução, não pode ser utilizada neste trabalho dado que efectua a detecção recorrendo a estrutura interna da aplicação, através da análise do código, inserindo-se na categoria de teste whitebox. A solução apresentada em [23], difere apenas da anterior em relação a estrutura de dados escolhida para fazer a comparação que ao invés de utilizar um autómato, efectua uma comparação entre árvores que representam a estrutura das queries. A solução proposta por Huang, Huang e Lin [20], pretende detectar vulnerabilidades sem aceder à estrutura interna da aplicação alvo de teste, utilizando apenas engenharia reversa para a identificação dos pontos de entrada de input para a base de dados. Esta solução baseia-se na análise das respostas da aplicação web tendo em conta os seguintes aspectos: Existência de erros provenientes da base de dados; Comparação da resposta proveniente da aplicação com outras duas: resposta proveniente de um pedido inválido; resposta proveniente de um pedido válido, isto é, um pedido que contorne 18

35 todos os mecanismos de validação por parte da aplicação através do Injection Knowlegde Manager (IKM). O IKM é uma estrutura que contém informação relativa aos pontos de entrada de input para a base de dados, as variáveis alvo do input do utilizador como as suas restrições, por exemplo, número de caracteres que uma determinada variável pode conter. Dado que o IKM contém essas informações, consegue gerar pedidos que contornem essas restrições. Esta solução não é eficiente, dado que existem casos que a comparação das respostas pode ser inconclusiva em termos da existência ou não de vulnerabilidades, situação que se pretende evitar como solução deste trabalho. Por fim, o mecanismo de detecção proposto em [21] também baseia-se no princípio de que uma injecção de SQL altera as estrutura das queries solicitadas, como nos sistemas propostos em [18, 19, 23]. Esta técnica implementada pelo sistema CANDID pretende comparar a estrutura das queries através de inputs candidatos. Estes inputs candidatos são benignos e pretendem deduzir de forma dinâmica qual é a estrutura pretendida das queries pelo programador da aplicação num determinado ponto que recebe input proveniente do utilizador. Esta análise da estrutura das queries é feita a partir da instrumentação da aplicação web para que intercepte o processamento destes pedidos SQL. De forma a poder-se inferir a existência de um ataque é necessário comparar a estrutura obtida através do input candidato e o input enviado que pretende testar a aplicação. Caso a estrutura seja igual, pode-se concluir que o input é válido e seguro para a base de dados. Caso contrário, pode indicar a possibilidade daquele input despoletar um ataque à aplicação. O sistema CANDID proposto em [21] parece ser uma solução apropriada para o trabalho em questão dado que efectua uma comparação das queries benignas e as que se pretendem testar e porque utiliza um mecanismo de instrumentação para analisar a estrutura queries de SQL a serem processadas na aplicação. No entanto, esta abordagem necessita que se altere a aplicação alvo e além disso, a extracção das estruturas das queries é efectuada por uma ferramenta de parsing externa ao sistema de gestão de base de dados podendo assim falhar na extracção da estrutura Inclusão de ficheiros remotos/locais A vulnerabilidade inclusão de ficheiros remotos (RFI) permite a um atacante incluir um ficheiro proveniente de um servidor web externo. Esta vulnerabilidade acontece devido à falta de validação do input fornecido pelo utilizador e além disso, resulta dos mecanismos de inclusão de ficheiros dinâmicos em aplicações web, como por exemplo na linguagem de PHP o comando include. Quando a aplicação web utiliza o input do utilizador (ex: URL, valores dos parâmetros) de forma a incluir ficheiros supostamente fidedignos, esta pode ser enganada, através da inclusão ficheiros remotos, ou seja, de outros servidores, contendo código malicioso. Esta vulnerabilidade serve por exemplo para instalar uma backdoor, obter informação técnica do sistema, execução de código no servidor web, negação de serviço ou obter o controlo do sistema vulnerável. 19

36 A linguagem PHP é particularmente vulnerável aos ataques RFI devido ao uso extensivo de inclusão de ficheiros como se pode ver na Listagem 2.1: 1 $incfile = $_REQUEST [" file "]; 2 include ( $incfile.". php "); Listagem 2.1: Exemplo de código vulnerável a LFI/RFI Como se pode ver por este excerto de código vulnerável a RFI seria possível incluir a referência a ficheiros remotos da seguinte forma: Isto resultaria na inclusão do ficheiro remoto evil.php o qual pode conter código que pode comprometer o sistema vulnerável. Existem mais comandos PHP vulneráveis a RFI: include once, fopen, file get contents, require e require once. Actualmente este tipo de vulnerabilidade deixou de ser tão usada pelos atacantes pois as versões mais recentes de PHP (versão 5.2 e seguintes) nas suas configurações por omissão deixaram de permitir a inclusão de URLs nestas funções sendo assim necessário explorar um novo tipo de vulnerabilidade que vai ser explicada de seguida que é a inclusão de ficheiros locais. A inclusão de ficheiros locais (LFI) é uma vulnerabilidade bastante semelhante a anterior mas o ficheiro que é incluído é um ficheiro presente no computador da aplicação vulnerável. Para tal ocorrer é necessário inserir o código malicioso dentro dos ficheiros locais da aplicação e posteriormente referir esse ficheiro de forma a inclui-lo e posteriormente executar o código malicioso. Existem vários mecanismos de inclusão desse código malicioso: upload do ficheiro (ficheiro PHP ou embebido num outro tipo de ficheiro) caso o website permita; inserir o código num log, por exemplo Como o ficheiro não existe, o pedido de acesso vai ser registado no log de erros e acesso, bastando agora aceder ao ficheiro de logs da seguinte forma: Assim, vai ser possível aceder ao ficheiro de log de erros e executar o código PHP pois esta linguagem interpreta código PHP independentemente se no ficheiro exista outro conteúdo escrito que não PHP. Existem vários mecanismos de prevenção, mitigação e detecção de inclusão de ficheiros remotos ou locais. Estes mecanismos focam-se principalmente na análise estática de código, verificando se o código da aplicação local contém algum dos comandos vulneráveis a RFI/LFI e se os parâmetros contêm valores provenientes do input fornecido pelo utilizador, sendo assim uma solução inviável pois necessita de acesso ao código fonte da aplicação alvo de teste para efectuar a detecção da vulnerabilidade. Também existem mecanismos que utilizam listas de valores inválidos (blacklist) [24]. Na solução apresentada em [24] pretende-se ter uma lista de todos os valores proibidos e que não podem ser inseridos em funções de inclusão de ficheiros, restringindo, assim, o conteúdo que um possível atacante 20

37 possa incluir. Este mecanismo foca-se mais na prevenção de ataques do que na detecção da exploração de determinada vulnerabilidade e como tal não é a abordagem mais adequada para este trabalho. O sistema desenvolvido por Dahse [25], baseia-se numa técnica que consiste em marcar o input do utilizador e verificar se este input chega às funções críticas que também são designadas por sensitive sinks, por exemplo, no caso de RFI/LFI a função include(). O input só é desmarcado se for alvo de validação ou de um processo de sanitização pois só nesse caso é que o input é considerado seguro para ser executado por estas funções críticas. Como nos casos anteriores, este mecanismo foca-se mais na prevenção. Outro mecanismo de prevenção é o Spectogram [26] onde se pretende fazer uma detecção de anomalias através de um modelo probabilístico chamado Markov Chain Model. Neste modelo calcula-se qual é o conteúdo mais provável a ser enviado como input à aplicação. Segundo o autor, ocorre um possível ataque quando são enviados pedidos cuja a sua probabilidade de acontecer é abaixo de um certo limiar. Isso acontece pois considera-se que é bastante improvável ocorrer o envio desse input e como tal a solução considera essa situação como um ataque. Esta solução não é eficiente pois analisa os dados que são enviados pelos utilizadores sem ter em conta os mecanismos de validação ou sanitização por parte da aplicação alvo de teste nem se a vulnerabilidade é realmente explorada. Por fim, em [27] refere-se um mecanismo simples de detecção de vulnerabilidades RFI que consiste em enviar como input para a aplicação um URL de um recurso que está num servidor web em que se possa monitorizar os acessos e determinar se esse servidor web recebeu algum pedido por parte da aplicação referente ao recurso que está inserido no URL. Caso isso tenha acontecido, quer dizer que a aplicação web estava a tentar incluir o ficheiro remoto e consequentemente possui uma vulnerabilidade RFI. Em termos de mecanismos de detecção LFI é de referir que na solução proposta em [27] o autor propõe como teste submeter o nome de um recurso executável ou estático e determinar se respectivamente existe alguma alteração no comportamento da aplicação ou se existem conteúdos copiados para a resposta da aplicação. Em caso afirmativo indica que a aplicação web é vulnerável a LFI Cross-site scripting Para o propósito do trabalho desenvolvido é necessário compreender dois tipos da vulnerabilidade de cross-site scripting: reflectido e armazenado. A vulnerabilidade de cross-site scripting reflectido [9, 28, 29] ocorre quando uma aplicação web confia nos inputs dos utilizadores e os reflecte inserindo-os numa resposta por parte do website sem validação, sanitização ou codificação adequadas. Estes dados são normalmente recolhidos na forma de link URL no qual existe conteúdo malicioso (ex: JavaScript). Os atacantes podem colocar o link num website, e assim que o utilizador acede ao link a mensagem de pedido com o script malicioso vai ser enviada para a aplicação. Quando os dados são recolhidos pela aplicação web, vai ser gerada uma página com conteúdo malicioso mas aparece como se fosse conteúdo válido no browser da vítima. Dado que os browsers não 21

38 Figura 2.3: Esquema de cross-site scripting reflectido têm considerações em termos de distinção de código proveniente da aplicação e de código proveniente do utilizador vai ser executado o script inserido pelo atacante com diversas consequências possíveis. Este tipo de vulnerabilidade permite a um atacante executar um script no browser da vítima, levando por consequência, ao atacante conseguir personificar o utilizador perante websites ou aplicações web que utiliza regularmente e que as considera fidedignas, podendo obter, alterar ou remover variados tipos de conteúdos. Um dos exemplos de acesso a conteúdos é o exemplo dos cookies, pois estes só podem ser acedidos pelo website que os criou como se pode ver pelo exemplo seguinte: 1. O atacante envia uma mensagem com o script malicioso no URL enviado à vítima: <SCRIPT> document.write(document.cookie)</script> 2. O browser envia o script malicioso no URL; 3. O script malicioso enviado por parte da vítima é reflectido através de HTML e é executado pelo browser da vítima levando a aceder ao conteúdo do cookie daquele website. A vulnerabilidade de cross-site scripting armazenado é baseada no mesmo princípio de XSS reflectido diferindo apenas num aspecto. A diferença é que nesta caso a aplicação web vulnerável, numa primeira fase, armazena os dados, por exemplo numa base de dados ou num ficheiro, no qual pode estar contido dados maliciosos (ex: script) e reflecte-os para qualquer utilizador que aceda aos mesmos [9]. Este tipo de vulnerabilidade está tipicamente presentes em fóruns, blogs ou outro tipo de aplicações que armazenem conteúdo proveniente dos utilizadores e não efectue validação do mesmo. Além dos dois tipos de cross-site scripting referidos anteriormente também existe um terceiro tipo que consiste em XSS baseado em document object model (DOM). Existem vários mecanismos de prevenção e mitigação de XSS [30, 31] que se baseiam principalmente na restrição da execução de scripts consoante a confiança nos websites e os links estáticos contidos nele necessitando de interação com o utilizador [30]. Também existem mecanismos de defesa baseados na remoção dos scripts [31] através de uma árvore de parsing para determinar a estrutura da resposta válida por parte da aplicação web com o uso de whitelist, isto é, lista de caracteres válidos para um determinado ponto de input levando a remover qualquer conteúdo que não esteja de acordo com esta lista. Esta estrutura válida é enviada para o 22

39 browser e serve para este quando for analisar a resposta saber como fazer a análise do mesmo levando a mitigação de XSS pois sabe a estrutura com que a aplicação web pretende ser analisada de forma a assegurar a ausência de conteúdo dinâmico (ex: script). Estes mecanismos explicitados anteriormente baseiam-se mais na prevenção e defesa de ataques XSS e não na detecção da vulnerabilidade na aplicação não sendo os ideais tendo em conta o propósito deste trabalho que tem como objectivo a detecção de vulnerabilidades. Existem vários mecanismos de detecção de XSS [32, 28, 29, 33, 34] que vão ser explicados de seguida. Existem mecanismos de detecção de XSS que se baseiam na técnica de análise estática [29, 34]. Esta técnica consiste em verificar se o input proveniente do utilizador é alvo de algum processo de validação ou sanitização antes de ser enviado como resposta. Este tipo de técnica consegue detectar potenciais vulnerabilidades cross-site scripting no código fonte mas no entanto não pode verificar a correcção das funções de sanitização. Para resolver essa situação, assume-se que as funções desse género que são desconhecidas por parte da aplicação que faz essa análise retornam dados inseguros. A análise estática consegue provar a ausência destas vulnerabilidades mas tende a gerar muitos falsos positivos, Um outro tipo de mecanismos de detecção de XSS existentes baseia-se num melhoramento da técnica anterior e consiste na análise estática de strings [29, 33, 34]. Estes mecanismos efectuam uma análise dos valores válidos como input e aceita-se ou rejeita-se este tendo em conta os valores definidos. Na solução apresentada em [33], utilizam uma gramática livre de contexto para representar os valores que determinada variável pode conter num determinado ponto do programa o que facilita a verificação dos valores de string blacklisted ao longo do programa. Esta técnica é mais precisa do que a anterior dado que gera menos falsos positivos. Estes duas abordagens de detecção referidas anteriormente requerem uma análise do código fonte da aplicação, categorizando-os como uma técnica de teste white-box. Ao contrário dos exemplos anteriores, em [32, 28] as soluções propostas pelos autores baseiam-se numa detecção do lado do cliente desta vulnerabilidade. Na solução de Matsuda, Koizumi, Sonoda [32] a detecção é feita através da posição de determinados símbolos e a sua respectiva frequência. Estes símbolos foram escolhidos através da recolha de amostras de ataques XSS na qual fez-se uma escolha dos 32 caracteres que existem neste tipo de ataque com uma maior frequência. Além da existência desta tabela de símbolos, também é necessário classificar o grau/nível de importância de cada caracter que é calculado através da sua frequência e a sua posição no input. A decisão de gerar um alarme indicando a presença da vulnerabilidade cross-site scripting baseia-se se esse grau/nível de caracter ultrapassa um certo valor limite calculado através de amostras. Caso aconteça, considera-se que aquele input como um ataque cross-site scripting. Esta solução [32] é ineficiente no aspecto que faz a análise só do input a enviar e não considera se a vulnerabilidade é activada na aplicação, causando muitos falsos positivos. A solução implementada em [28] consiste num servidor proxy de detecção e colecção e também num 23

40 servidor de base de dados. Neste servidor proxy existem dois modos para efectuar a detecção/colecção de informação relativa a ataques XSS: modo de alteração de respostas e de alteração de pedidos. Em ambos os modos, caso seja detectada informação relativa a ataques XSS o mecanismo altera a codificação do pedido/resposta de forma a este ser inofensivo para a aplicação/utilizador. O modo de alteração de respostas consiste na recolha e verificação das mensagens no servidor proxy sempre que um utilizador efectua pedidos à aplicação web. Caso existam caracteres nos pedidos que correspondam a tags especiais de HTML, estes pedidos serão armazenados no proxy antes de serem enviados. Este armazenamento tem como propósito a comparação do pedido com a respectiva resposta devolvida pela aplicação. Caso a resposta contenha as mesmas tags especiais da linguagem existentes no pedido considera-se que a aplicação é vulnerável a XSS. Este modo não funciona correctamente caso o pedido e a resposta contenham vários parâmetros com tags HTML inofensivas. Para resolver essa lacuna, é necessário um segundo modo que consiga identificar quais os parâmetros susceptíveis a vulnerabilidades XSS e os que não são. O segundo modo, o de alteração de pedidos, investiga os pedidos HTTP que contenham múltiplos parâmetros, gerando um identificador, neste caso um número aleatório, de forma a não apenas identificar se a aplicação é vulnerável a XSS mas também identificar quais são os parâmetros em específico que são vulneráveis. Esta solução comparativamente as anteriores é superior em termos de aplicabilidade ao trabalho dado que é uma detecção que não é feita do lado do servidor e que considera os processos de validação de input e também porque efectua a detecção através da comparação do conteúdo que é transmitido nos pedidos e o que é enviado como resposta por parte da aplicação. 2.5 Detecção de intrusões em aplicações web Dado que o trabalho desenvolvido consiste na detecção de vulnerabilidades em aplicações web, é necessário perceber como sistemas semelhantes funcionam, tais como sistemas de detecção de intrusões e os seus mecanismos internos para classificar determinados inputs como ataques. Um sistema de detecção de intrusões (IDS) pretende monitorizar o tráfego da rede ou eventos do sistema relacionados com actividades maliciosas de modo a detectar a existência de ataques e/ou se estes levaram a intrusões. Existem dois tipos de sistemas de detecção de intrusões [35]: baseado na rede (NIDS) e baseado no host (HIDS). No caso de NIDS pretende-se detectar as intrusões através da análise do tráfego da rede. Este mecanismo pode ter problemas caso o tráfego a ser processado seja demasiado e, assim, o sistema de detecção não consegue processar os pacotes que atravessam a rede. Além disso, os pacotes podem ser alvo de cifra deixando de ser possível fazer a análise dos mesmos. No caso de HIDS pretende-se monitorizar os componentes internos de um sistema computacional (ex: memória RAM, sistema de ficheiros, logs), como também em alguns casos os pacotes de rede que chegam às interfaces de rede do host. Caso esta monitorização detecte alguma actividade diferente do 24

41 esperado no host, o sistema avisa que pode estar a ser alvo de uma intrusão. Tendo em conta as aplicações web, um NIDS iria monitorizar a rede onde estaria inserida a aplicação alvo podendo assim proteger quaisquer servidores no interior da rede, enquanto que um HIDS iria monitorizar o funcionamento do servidor web onde está inserido a aplicação sendo assim uma estratégia mais próxima da aplicação. Independentemente do tipo de IDS que é implementado, existem várias estratégias de fazer esta detecção de intrusões que são as seguintes [35]: Baseada em regras: procura por actividades que correspondem a um conjunto pré-definido de eventos, regras ou padrões que são descritos como um ataque conhecido. Este tipo de IDS tem que ser especificamente programado para detectar cada ataque conhecido. Baseada em anomalias: procura ataques através da identificação de comportamento invulgar que ocorra na rede ou no host. Funcionam com base na observação que os atacantes comportamse de uma forma diferente dos utilizadores normais. Este tipo de IDS estabelece o que é o comportamento normal de funcionamento da aplicação e monitoriza se em algum momento da execução esta sai desse estado. Estas estratégias definidas anteriormente podem ser modeladas de duas maneiras [36]: Modelo de segurança negativo: este modelo baseia-se em negar tudo o que pode ser perigoso para aplicação. Este modelo pode deixar passar intrusões dado que não se conhece tudo o que é considerado perigoso para a aplicação; Modelo de segurança positivo: este modelo baseia-se em permitir tudo o que é seguro para aplicação e rejeitar tudo o resto. Este modelo é mais eficiente dado que consegue prevenir os casos de intrusões que não são conhecidas. De seguida, vão ser apresentadas ferramentas que funcionam como sistemas de detecção de intrusão que estão inseridas nas várias categorias que foram referidas anteriormente. Estas ferramentas que vão ser apresentadas são importantes para o trabalho dado que detectam intrusões em aplicações web. Resultam de uma combinação entre IDSs desenvolvidas num âmbito de trabalho de investigação e de detecção de intrusões num contexto real. O sistema ModSecurity [36], é uma firewall mas comporta-se como um sistema de detecção de intrusões devido as funcionalidades que implementa como se pode ver de seguida. O ModSecurity possui um mecanismo baseado em expressões regulares para aceitar ou rejeitar determinado conteúdo, permite auditoria de logs, suporta um número ilimitado de políticas diferentes (ex: virtual host, directoria, ficheiro único). O sistema suporta intercepção de upload de ficheiros e validação em runtime, possui mecanismos para evitar a evasão dos padrões ou regras definidas. A evasão referida anteriormente consiste na injecção de pacotes que contêm dados maliciosos mas que estão disfarçados no sentido que podem não ser detectados em determinadas regras definidas. Por exemplo, se existir uma regra no IDS que refere que não se pode efectuar o comando DROP TABLE xyz através de uma comparação 25

42 simples, um exemplo de evasão desta regra era existir um pedido com o comando DROP /**/ TABLE xyz, levando a ser executado o mesmo comando malicioso mas como estão inseridos os comentários no interior a regra que rejeitaria este pedido já não é activada. O sistema proposto em [37], consiste num IDS que consegue efectuar a detecção de intrusões através de um mecanismo de máquina de estados pois foca-se na detecção de intrusões que são realizadas em múltiplos passos. Este sistema também consegue correlacionar eventos ao nível da rede e ao nível do sistema operativo através de entradas contidas nos logs do servidor. A solução proposta em [38], consiste no envio de pacotes para um reverse proxy que envia os pedidos para servidores diferentes tendo em conta o nível de anomalia existente nos pacotes. Se este nível de anomalia ultrapassar um certo limiar, isto significa que este pedido pode ser um possível ataque. Logo o reverse proxy, basicamente é um proxy cuja sua funcionalidade consiste em encaminhar os pacotes para servidores diferentes consoante um conjunto de regras, envia este pedido potencialmente malicioso para um servidor que contém o mínimo de dados sensíveis e de privilégios. Isto acontece porque caso que este pedido seja malicioso, este não consegue aceder a nenhuns dados importantes da aplicação. Caso o pacote não seja considerado anómalo, pode ser enviado para o servidor que contém mais privilégios e acesso a ficheiros sensíveis pois não existe o risco daquele pedido ser malicioso e conseguir comprometer a aplicação web. O sistema DoubleGuard, consiste num IDS que modela o comportamento da rede das sessões do utilizador ao longo da aplicação web e da base de dados [39]. O sistema pretende verificar se o utilizador tem privilégios para efectuar determinados pedidos à aplicação. Por exemplo, um utilizador que não seja administrador não pode enviar pedidos que só poderiam ser enviados pelo administrador da aplicação. Nas aplicações que foram referidas anteriormente, só era possível aceitar ou rejeitar certos pedidos tendo em conta regras ou padrões no conteúdo dos mesmos e não através do utilizador que os enviou. Por fim, o sistema AppSensor do OWASP [40] pretende detectar actividade maliciosa numa aplicação antes que um atacante consiga identificar e possa explorar determinada vulnerabilidade. Isto é possível porque muitas das vulnerabilidades só são descobertas como resultado de tentativa e erro pelo atacante. Assim, se o AppSensor conseguir identificar o atacante que está a procura de vulnerabilidades é possível prevenir que este consiga identificar e explorar a vulnerabilidade. Este sistema contém um módulo de detecção de comportamento malicioso como um IDS e também contém um módulo de resposta, no qual vai integrar mecanismos de prevenção efectuando acções contra o utilizador atacante. Um factor que tem que se ter em conta é que na detecção de actividade maliciosa deve-se conseguir distinguir uma acção de erro não intencional de um ataque, pois caso tenha sido um erro não intencional o sistema não deve activar os seus mecanismos de resposta sendo essa escolha definida através de um limiar que define a partir de que ponto deixa de ser uma acção não intencional e se considera como um comportamento malicioso. Como em outros IDSs, os mecanismos de detecção baseiam-se na análise de padrões nos pedidos recebidos. Por exemplo, tendo em conta o tipo de vulnerabilidades que este trabalho foca, o AppSensor detecta injecções de SQL através de um mecanismo simples de blacklist de valores mais frequentes usados neste tipo de ataques. No caso da detecção de XSS, o AppSensor detecta através da análise de 26

43 padrões como a existência da tag <script> nos pedidos feitos pelo utilizador. Tendo em conta todas as soluções estudadas de detecção de intrusões em aplicações web e a framework desenvolvida existe uma diferença importante. No caso de um IDS, este tem como objectivo a detecção de ataques, independentemente se existe ou não uma vulnerabilidade na aplicação alvo de teste e em caso desta existir, verificar se foi activada. Este tipo de soluções efectua uma análise dos pedidos tendo em conta a existência de certas características que possam classificar o conteúdo como potencialmente benigno ou maligno independentemente da funcionalidade existente na aplicação. No caso da framework de detecção automática de vulnerabilidades desenvolvida, pretende-se verificar se determinado ataque conseguiu realmente explorar uma vulnerabilidade. Para essa situação ocorrer é preciso que o pedido chegue a aplicação e seja processado por esta. 27

44 28

45 Capítulo 3 A Framework Foi desenvolvida uma framework cujo o seu objectivo principal é efectuar fuzzing em aplicações web e monitorizar o seu efeito através de mecanismos de monitorização embebidos dentro dos componentes constituintes de uma aplicação deste género. De seguida, é apresentada a arquitectura da framework e as suas componentes. 3.1 Arquitectura A arquitectura da framework é apresentada na Figura 3.1, onde observamos as quatro componentes que a compõem, nomeadamente: Fuzzer: gera os inputs que são injectados em determinados pontos de entrada da aplicação web. Também, contém o mecanismo de monitorização de ataques cross-site scripting reflectido através da análise das respostas devolvidas tendo em conta os inputs enviados; Aplicação web: como o próprio nome indica, é a aplicação web alvo de teste que está inserida num servidor web com determinado sistema operativo e comunica com os variados componentes back-end, tais como, base de dados ou sistema de ficheiros; Interpretador da linguagem do servidor: onde estão embebidos vários mecanismos de detecção de vulnerabilidades causadas pela falta de validação do input. Estas vulnerabilidades detectadas estão divididas em três categorias consoante se interagem com o sistema de ficheiros ou se com o sistema de gestão de base de dados ou se com o sistema operativo, respectivamente. Dentro da primeira categoria inserem-se mecanismos de monitorização das seguintes vulnerabilidades: inclusão de ficheiros locais ou remotos (LFI/RFI); directory/path traversal (DT/PT); source code disclosure (SCD); Dentro da segunda categoria insere-se a monitorização de ataques de cross-site scripting armazenado e por fim, na terceira categoria, insere-se a monitorização de ataques de inclusão de comandos de sistema operativo (OSCI). Além dos mecanismos referidos anteriormente, neste componente também está contido o mecanismo de monitorização de ataques de injecção de código da linguagem do servidor. 29

46 Figura 3.1: Arquitectura da framework mostrando onde é efectuada a monitorização de cada um dos ataques considerados Sistema de gestão de base de dados: recebe as queries provenientes da aplicação web e processa-as, enviando posteriormente, os resultados obtidos ao interpretador da linguagem do servidor. Além disso, esta componente também contém o mecanismo de monitorização de ataques de injecção de SQL. 3.2 Funcionalidades Tendo em conta a arquitectura apresentada, de seguida serão explicadas as funcionalidades de cada uma das componentes existentes na framework Fuzzer O fuzzer baseia-se na geração de inputs através de vectores de fuzzing, inserindo-se na categoria de fuzzers iterativos. Estes vectores de fuzzing consistem num conjunto de inputs previamente seleccionados, contendo várias assinaturas de ataques existentes, podendo levar à exploração de vulnerabilidades. Além disso, o fuzzer aplica mecanismos de mutação sobre cada elemento destes vectores. O mecanismo de mutação dos inputs, aleatoriamente, selecciona um conjunto de caracteres de determinado input para ser alvo de pequenas alterações (ex: substituição de caracteres), gerando assim, uma maior variedade de inputs que podem, inesperadamente, explorar vulnerabilidades. Além das funcionalidades relacionadas com a geração dos inputs, o fuzzer permite definir em que estado se pretende que a aplicação alvo de teste esteja no momento em que são enviados os inputs. Devido a esta funcionalidade, o fuzzer desenvolvido insere-se na categoria de in-memory fuzzers como 30

47 foi explicado na subsecção Para tal, é possível definir de uma forma manual, uma sequência de pedidos a serem enviados previamente de forma a colocar a aplicação em determinado estado e também uma sequência de pedidos para efectuar reset ao estado da mesma após o envio de determinado input. Esta sequência de pedidos, consiste num conjunto de pedidos HTTP dos seguintes tipos: GET e POST. O fuzzer também se encarrega de injectar os inputs gerados à aplicação alvo através do protocolo HTTP. Para tal, o fuzzer para cada elemento do vector de fuzzing envia a sua versão original proveniente do vector de fuzzing e as suas respectivas mutações. Caso o mecanismo de definição de estados esteja activo, o fuzzer encarrega-se antes do envio de cada input, enviar os pedidos HTTP que correspondem ao processo pre-state, ou seja, colocar a aplicação num estado definido pelo utilizador. Colocado nesse estado, é enviado o input como referido anteriormente. Posteriormente, caso seja necessário efectuar reset ao estado da aplicação, o fuzzer envia os pedidos HTTP definidos pelo utilizador de forma a restabelecer o estado da aplicação. Este processo é efectuado repetidamente até serem enviados todos os inputs Detecção de injecção de SQL Para a detecção de ataques de injecção de SQL em aplicações web de uma forma automática foi desenvolvido um mecanismo que não seja dependente de ferramentas externas para ser posível identificar a estrutura das queries processadas. Como tal, este tipo de vulnerabilidade é detectada no interior do sistema de gestão de base de dados (SGBD) (Figura 3.1) por várias razões: Em primeiro lugar, este mecanismo não é dependente de ferramentas externas ao SGBD para a obtenção da estrutura das queries. Além disso, estas ferramentas podem conter bugs ou podem não ser abrangentes a todos os aspectos relativos aos pedidos que analisam. Assim, com este mecanismo a análise da estrutura das queries é feita através da estrutura obtida pelo próprio parser do SGBD levando a um processo mais eficiente de detecção de vulnerabilidades SQLI com um número mínimo de erros. Em segundo lugar, este mecanismo não fica dependente de processos de sanitização caso estes existam, por exemplo nos ficheiros PHP (ex: mysql real escape string), só sendo assim necessário mesmo preocupar-se como é que a query está no momento precisamente anterior ao seu processamento no SGBD. Em último lugar, este mecanismo também tem em conta que os dados podem ser des-sanitizados quando são inseridos na base de dados evitando assim ataques de injecção SQL de segunda ordem. Assim, para evitar estes problemas, o mecanismo detecta este tipo de ataques após o SGBD processar e efectuar o parsing das queries, reduzindo, assim, qualquer pressuposto sobre as mesmas. Na explicação que se segue sobre o mecanismo considera-se o caso específico do MySQL pois foi o SGBD utilizado na implementação. Mecanismos internos de parsing Para se obter a estrutura interna de cada query é necessário, numa primeira fase, perceber como é que se efectua o processamento e parsing das queries transformando estas em algo concreto para o 31

48 sistema de gestão de base de dados. Para o caso específico do MySQL, este associa a cada query a uma thread que contém um identificador único e uma estrutura léxica da query respectiva, classe LEX, que basicamente representa a informação que se pretende analisar. A classe LEX contém todas as informações gerais sobre a query, como por exemplo, o conjunto de todos os SELECTs inseridos na query através da classe SELECT LEX ou as informações relativas às queries do tipo INSERT INTO ou UPDATE. A estrutura SELECT LEX contém toda a informação que é possível incluir dentro deste comando pelo MySQL. Esta informação inclui: informação relativa às cláusulas WHERE e HAVING, os fields que são retornados pelo SELECT, as tabelas seleccionadas na cláusula FROM, o intervalo de valores que é retornado, informação relativa às cláusulas ORDER BY e GROUP BY ou outros SELECTs encadeados. As queries do tipo INSERT INTO ou UPDATE são representadas em parte por elementos constituintes da classe SELECT LEX caso contenham alguma das palavras-chave referidas nessa estrutura e também por uma lista de elementos que representam a estrutura a mais baixo nível, nomeadamente, a classe Item. A classe Item, representa os dados relativos à estrutura da query com uma granularidade mais fina, onde estão incluídos tipos primitivos (inteiros, decimais, reais, strings), operações condicionais (ex: AND, OR), chamadas a funções, entre outros. Sucintamente, a estrutura Item está identificada através de um nome e um tipo. O MySQL considera que existem 27 tipos diferentes de Items sendo estes enunciados de seguida: Field Varbin Field STD Parameter Function Copy string Field variance Trigger field Sum Function Average field Insert value Decimal String Default value SubSelect Xpath nodeset Integer Procedure Row Xpath nodeset com- Real Conditional Cache pare Null Reference Type holder View fixer Cada um deste tipo de Items tem uma estrutura particular (parâmetros específicos) no qual pode conter sub-tipos, por exemplo, no tipo condicional existe um sub-tipo no qual especifica a operação condicional está a ser utilizada (ex: AND, OR, XOR, NOT). Assim, com a informação recolhida sobre a query é possível perceber como é que o MySQL estrutura a informação proveniente das queries de forma a poder executar instruções sobre a base de dados. Numa segunda fase, é necessário perceber, tendo em conta as informações referidas anteriormente, como é que o MySQL utiliza-as. A estrutura das queries obtidas pode ser interpretada sobre a forma de duas estruturas de dados: pilha ou através de uma árvore post-order. No entanto, o MySQL organiza 32

49 estes dados sobre a forma de uma lista. De seguida pode ser evidenciado a representação da estrutura da query SELECT * FROM user WHERE Age < 23 por parte do mecanismo de detecção de injecção de SQL. 1 SELECT_LEX_Nodes_Structure 2 WHERE_ Structure 3 FUNC_ ITEM 4 < 4 INT_ ITEM 23 5 FIELD_ ITEM Age SELECT_FIELDS_Structure 8 SELECT_ FIELD * 9 FROM_ TABLE user Listagem 3.1: Estrutura obtida pela query SELECT * FROM user WHERE Age < 23 De forma a interpretar a query a ser executada deve-se observar os items de baixo para cima. O primeiro elemento (i.e o de baixo) na estrutura refere-se ao elemento da claúsula FROM que neste caso é a tabela user. De seguida faz-se referência aos elementos que são devolvidos pelo SELECT neste caso são todas as colunas (símbolo *) da tabela referida anteriormente. De seguida, os items são referentes a estrutura da cláusula WHERE com o field Age e ao inteiro 23. Com esses dois items aplica-se a operação < como se pode verificar pelo item mais acima perfazendo, assim, a query a ser executada sobre o SGBD. Funcionamento geral O objectivo principal na detecção de ataques de injecção de SQL é identificar se em determinada query que recebe input do utilizador, se a estrutura desta ao longo de várias execuções difere tendo em conta a estrutura obtida através inputs benignos. Caso isso aconteça, indica que pode ter sido explorado uma vulnerabilidade deste tipo dado que a estrutura obtida em determinada execução é diferente da estrutura para qual a query foi desenhada. Para acontecer tal identificação, em primeiro lugar, é necessário identificar qual é o comportamento esperado de determinada query da aplicação por parte de quem desenhou a aplicação, ou seja, através de inputs benignos. O propósito de tal identificação é para ser possível comparar várias execuções de determinada query e verificar se o comportamento desta difere. Nesta solução, considera-se como modelo de funcionamento de determinado ponto de entrada, a primeira execução desse mesmo ponto, pressupondo que o input enviado nessa primeira vez é benigno, definindo-se como template de uma query. Ao executar determinada query de SQL pela primeira vez o mecanismo vai armazenar em tempo de execução o template desta de forma a ser usado como modelo de comparação com as estruturas obtidas em execuções seguintes da mesma query. Assim, este mecanismo vai conter todos os templates de todas as queries que são executadas provenientes de determinados ficheiros e linhas de código sendo identificados de uma forma única para que seja possível ao programador identificar e analisar as causas de determinado código vulnerável. 33

50 Tendo em conta o referido acima, é necessário este mecanismo ser alvo de uma fase de treino na qual são executados todos os pontos do código que executem uma query com input proveniente do utilizador, com conteúdo benigno para que seja possível gerar os respectivos templates e posteriormente iniciar a detecção de ataques na aplicação alvo de teste. Nas execuções seguintes de determinada query, compara-se a estrutura obtida com o respectivo template gerado na fase de treino. Esta comparação deve ser tolerante a certos aspectos pois em caso contrário iria gerar falsos positivos. Por exemplo, uma query que pretenda comparar um determinado atributo com um valor atribuído pelo utilizador deve tolerar os diferentes valores fornecidos. Além disso, também deve tolerar o uso de valores diferentes do expectável mas que devido a operações de typecasting o seu significado é igual. Estas operações de typecasting consistem em modificações aos tipos existentes mas cujo seu significado mantém-se, por exemplo, a alteração de uma string com o valor 10 para o inteiro correspondente. Como tal, o mecanismo considera os tipos inteiro, decimal, real e string numa só categoria denominada tipos primitivos. Assim, o mecanismo observa cada elemento da estrutura obtida e verifica se o tipo (primeiro elemento) e os seus parâmetros (restantes elementos) são exactamente iguais ao elemento correspondente no template exceptuando numa situação. Quando determinado elemento da estrutura refere-se a um tipo primitivo, não são analisados os parâmetros desse tipo, basta que no template esse elemento correspondente também seja do tipo primitivo. Caso a estrutura de determinada query não corresponda ao template respectivo significa que determinado input alterou a estrutura desta e está a explorar uma vulnerabilidade SQLI reportando a ocorrência no log de ataques. O mecanismo consegue detectar duas variantes de injecção de SQLI: estruturais e mímica. O primeiro caso ocorre, quando existe uma alteração dos elementos não-terminais, ou seja, que estruturados na forma de uma árvore, as alterações efectuadas ocorrem ao nível dos nós da árvore. O segundo caso ocorre, quando a alteração ocorre ao nível dos elementos terminais, ou em termos de uma estrutura de dados em árvore, ao nível das folhas desta denominando-se como um ataque mímica pois a estrutura da árvore de determinada query mantém-se igual. Com este mecanismo é possível detectar a existência de vulnerabilidades de injecção de SQL de primeira e segunda ordem, pois em ambos os casos, no momento em que a vulnerabilidade é explorada, existe uma alteração na estrutura da query a ser executada. Para efeitos de segurança, no template não são armazenados os parâmetros dos tipos primitivos para que não seja possível extrair informação sensível deste (ex: passwords). Este mecanismo além da detecção de vulnerabilidades de injecção de SQL também possui outras duas funcionalidades: logs das estruturas das queries executadas de forma a comparar e distinguir execuções benignas e malignas numa determinada query; mecanismo de prevenção no qual impede a execução de queries que possuam uma estrutura diferente a do respectivo template evitando assim a exploração de uma vulnerabilidade deste tipo. 34

51 Casos de detecção Este mecanismo detecta eficazmente a existência de vulnerabilidades injecção de SQL nos seguintes casos: Todas as injecções de código de SQL que alterem a estrutura sintáctica de uma query. Considerase como alteração a estrutura sintáctica uma das seguintes condições: diferença no número de parâmetros utilizados em determinada cláusula (ex: SELECT, FROM), inserção/remoção/alteração dos items utilizados numa query SQL; Dentro das injecções referidas anteriormente, o mecanismo identifica injecções de SQL de primeira e segunda ordem; O mecanismo também identifica eficazmente ataques SQLI estruturais ou mímica e ataques através de codificação de caracteres ou evasão de espaços. Limitações Este mecanismo não consegue detectar eficazmente a existência de vulnerabilidades injecção de SQL nos seguintes casos: Todas as injecções de código que não alterem a estrutura sintática do código através da não identificação da inserção/alteração/remoção de novos elementos. Log de ataques Quando um ataque SQLI é detectado, independentemente se o modo preventivo está activado, o mecanismo regista informação sobre este num log. A Listagem 3.2 apresenta o formato de um registo no log de ataques de uma ocorrência de um ataque SQLI (SQLIA). A primeira linha indica se o modo preventivo está activo ou não e o respectivo timestamp da ocorrência. A segunda linha representa o tipo de SQLIA que ocorreu: estrutural ou mímica. As linhas 3 a 5 indicam o identificador (ID) da query e a query maligna antes e posteriormente a DBMS pré-processar e efectuar parsing respectivamente. As linhas 6 e 7 indicam respectivamente, os ficheiros que representam as estruturas da query executada e respectivo template de forma a poder-se a observar as diferenças entre as duas. 1 SQL QUERY [ DROPPED NOT DROPPED ] date time 2 SQLIA [ Structural Mimmicry ] 3 Query ID 4 Query Q ss 5 Query Q dmbms 6 Query Q file 7 Query model file Listagem 3.2: Formato de um registo de um ataque SQLI no log de ataques 35

52 = = user Miguel pass xpto Figura COND_ITEM 3.2: Template da query SELECT AND info FROM users WHERE user= $user OR AND pass= $pass STRING_ITEM FUNC_ITEM = FIELD_ITEM Exemplos STRING_ITEM foo = = FIELD_ITEM Para demonstrar FIELD_ITEM o funcionamento dopass mecanismo de detecção desta vulnerabilidade vai ser mostrado... um cenário user admin 1 1 FUNC_ITEM inicial de utilização benigna, = correspondendo a fase de treino e na qual vai definir o template. SELECT_FIELD Posteriormente, STRING_ITEM vão ser mostrados duasfvariantes de injecções de SQL: estrutural e mímica. Estas duas FROM_TABLE variantes são detectadas com sucesso pelo mecanismo desenvolvido. FIELD_ITEM user COND_ITEM OR Para a demonstração do mecanismo suponhamos uma FUNC_ITEM aplicação vulnerável que= contém a query FIELD_ITEM name SELECT name FROM users WHERE user= $user AND pass= $pass. STRING_ITEM Para definir 1o template, esta... (...) FIELD_ITEM 1 query vai ser processada uma primeira vez através do input $user= Miguel e $pass= xpto. A SELECT_FIELD name FUNC_ITEM = estrutura resultante correspondente ao template está apresentada na Figura 3.2 sendo representada STRING_ITEM admin a esquerda FROM_TABLE na forma de uma árvoreusers post-order e a direita através de uma pilha contendo os vários = COND_ITEM AND FUNC_ITEM = STRING_ITEM foo AND FIELD_ITEM pass FUNC_ITEM = STRING_ITEM f = = = FIELD_ITEM user FIELD_ITEM name... (...) SELECT_FIELD name user Miguel pass xpto FROM_TABLE users elementos da query. FIELD_ITEM item de função de igualdade (=) e dos items inteiros (1). Dado a esta diferença estrutural, é identificado pelo user mecanismo umaadmin vulnerabilidade SQLI estrutural. 1 É1 possível observar na estrutura sobre a forma de árvore post-order que os nós desta são diferentes relativamente ao template levando consequentemente a sua estrutura ser diferente. Para COND_ITEM demonstrar a detecção de umaor vulnerabilidade SQLI mímica vai-se considerar o envio do input FUNC_ITEM $user=admin AND 1=1 --. Neste= caso, e como se pode observar pela Figura 3.4, a árvore sintáctica da query processada comparativamente ao seu template, ambos têm o mesmo número de STRING_ITEM 1 nós e estrutura semelhante. Além disso, as duas pilhas também têm o mesmo número de items. O FIELD_ITEM 1 mecanismo identifica o ataque devido as diferenças ao nível das folhas da árvore que representa a FUNC_ITEM = STRING_ITEM admin 36 FIELD_ITEM user user FIELD_ITEM name De seguida, é enviado um input malicioso no qual tenta... explorar uma vulnerabilidade (...) SQLI estrutural OR de primeira ordem através do envio do input $user=admin SELECT_FIELD OR 1=1 -- ilustrada, name forma de uma árvore post-order e de uma pilha, a sua estrutura na Figura FROM_TABLE 3.3. users Pode-se observar que existe uma diferença nas estruturas devido a inclusão de código malicioso na query. A inclusão de código, é observada, na pilha, através da inclusão do item condicional (OR), o push COND_ITEM FUNC_ITEM STRING_ITEM FIELD_ITEM FUNC_ITEM = user COND_IT FUNC_IT STRING_ FIELD_IT FUNC_IT STRING_ FIELD_IT FIELD_IT... SELECT_ FROM_TA

53 iguel pass EM FIELD_ITEM user = FIELD_ITEM name... (...) xpto SELECT_FIELD name FROM_TABLE AND EM = ITEM foo EM pass EM = ITEM f EM user EM name (...) FIELD name user ABLE users TEM OR admin 1 = users OR = admin 1 1 Figura 3.3: Estrutura de uma query alvo de um ataque SQLI estrutural de primeira ordem COND_ITEM OR FUNC_ITEM = = STRING_ITEM 1 FIELD_ITEM 1 1 AND FUNC_ITEM = STRING_ITEM OR EM = _ITEM 1 EM 1 EM = _ITEM EM EM _FIELD ABLE FIELD_ITEM = FIELD_ITEM admin = user name... (...) = = user admin 1 1 COND_ITEM OR FUNC_ITEM = STRING_ITEM 1 FIELD_ITEM 1 FUNC_ITEM = STRING_ITEM admin FIELD_ITEM user FIELD_ITEM name... AND (...) SELECT_FIELD name FROM_TABLE = = users SELECT_FIELD user admin 1 name1 FROM_TABLE users FROM_TABLE users user COND_ITEM Figura 3.4: Estrutura de uma ANDquery alvo de um ataque SQLI mímica de primeira ordem admin name FUNC_ITEM (...) = name estrutura STRING_ITEM das queries. É verificado que 1 o field pass do template é alterado para um item do tipo inteiro. users Devido FIELD_ITEM a esta diferença entre a query 1 e o respectivo template é identificado um ataque SQLI mímica sendo reportada a sua ocorrência. FUNC_ITEM = STRING_ITEM admin FIELD_ITEM user Detecção de inclusão de ficheiros locais e remotos FIELD_ITEM name Para... a detecção de vulnerabilidades (...) de inclusão de ficheiros locais e remotos foi desenvolvido um mecanismo SELECT_FIELD de monitorização que name não seja dependente de ferramentas externas para monitorizar os recursos FROM_TABLE necessários, neste caso, users os ficheiros que são alvo de inclusão por parte da aplicação web. Como tal, este tipo de vulnerabilidade é detectada no interpretador da linguagem do servidor (Figura 3.1) extraindo informação sobre os ficheiros incluídos em cada chamada ao código relativa a uma função de inclusão de ficheiro, por exemplo, na linguagem PHP as funções include e require. user admin 1 COND_ITEM AND FUNC_ITEM = STRING_ITEM 1 FIELD_ITEM 1 FUNC_ITEM = STRING_ITEM admin FIELD_ITEM user FIELD_ITEM name... (...) SELECT_FIELD 1 name = user adm COND_ITEM FUNC_ITEM STRING_ITE FIELD_ITEM FUNC_ITEM STRING_ITE FIELD_ITEM FIELD_ITEM... SELECT_FIE FROM_TABL 37

54 Funcionamento geral O mecanismo desenvolvido define um template de cada inclusão de ficheiros existente no código da aplicação alvo de teste. Este template pressupõe-se que é definido a partir de uma utilização benigna da aplicação em cada ponto de inclusão. O template é registado durante a primeira execução de determinada chamada a uma função de inclusão de ficheiros. Assim, o template define o comportamento expectável da aplicação por parte de quem desenhou a mesma. O objectivo deste mecanismo é verificar se as inclusões seguintes estão de acordo com o respectivo template. Este template é genérico de forma a abranger todos os inputs benignos, mas também restrito de forma a excluir inputs maliciosos. Como tal, o template é constituído pelo path e extensão do ficheiro que é incluído. No caso do ficheiro ser de proveniência remota, o path inclui o protocolo do endereço externo (ex: A razão para a escolha desses dois elementos como parte constituinte de um template de uma função de inclusão de código assenta em dois princípios: Quando um atacante pretende incluir um ficheiro local ou remoto este tem que alterar o path do ficheiro respectivamente, através de path/directory traversal ou inclusão do protocolo do endereço externo, enquanto numa utilização normal o path mantém-se ao longo das várias chamadas a uma função de inclusão de ficheiros; Normalmente quando existe uma inclusão de ficheiros a extensão deste é constante ao longo de várias execuções, como tal de forma a prevenir que um atacante inclua ficheiros com outras extensões podendo incluir código malicioso, considera-se que a alteração da extensão de ficheiro a ser incluído é uma operação perigosa tendo em conta a categoria de vulnerabilidades de inclusão de ficheiros. Para este mecanismo, também é necessário a existência de uma fase de treino. Nesta fase, pretendese exercitar todas as chamadas a funções de inclusões na aplicação de forma a criar os respectivos templates. Pretende-se comparar os templates com futuras execuções a estas respectivas chamadas e consequentemente identificar a existência de vulnerabilidades caso estas existam. Para detectar a exploração de uma vulnerabilidade RFI/LFI, nas seguintes execuções de determinada chamada a uma função de inclusão de ficheiro compara-se o ficheiro incluído e o seu respectivo template. Caso uma destas seguintes condições se verifique indica a existência de uma vulnerabilidade: O path da inclusão em determinado ponto de código for diferente do path existente no template respectivo; A extensão do ficheiro a ser incluído ser diferente do que está referido no template respectivo. Como referido anteriormente, caso uma destas condições se verifique, de seguida, o mecanismo verifica se o ficheiro alvo de inclusão existe ou não. Em caso afirmativo, notifica a exploração da vulnerabilidade. Caso contrário, avisa que a vulnerabilidade seria explorada caso existisse o ficheiro. 38

55 Esta notificação é efectuada através de um log de ataques no qual regista a ocorrência do ataque com informação relevante. Este mecanismo além da detecção, caso seja activado, também permite a utilização deste em modo preventivo no qual nega qualquer tentativa de inclusão de ficheiros que não estejam de acordo com o respectivo template. Casos de detecção Esta solução detecta eficazmente a existência de vulnerabilidades LFI/RFI nos seguintes casos: Todas as tentativas de inclusões de ficheiros locais ou remotos que tenham um path ou uma extensão diferente do que o definido no template respectivo; Limitações Esta solução não consegue detectar eficazmente a existência de vulnerabilidades LFI/RFI nos seguintes casos: Inclusões de ficheiros locais ou remotos maliciosos cujo path e extensão são iguais aos que estão definidos no template respectivo. Log de ataques Quando um ataque de inclusão de ficheiros locais ou remotos é detectado, independentemente se o modo preventivo está activado, o mecanismo regista informação sobre o ataque num log. Em cada nova ocorrência de um ataque, no log é registado se este explorou a vulnerabilidade ou se existe a possibilidade, através de um aviso, da vulnerabilidade ser explorada caso o ficheiro alvo de inclusão existisse no servidor local ou remoto. Além disso, também é registado informação acerca do local na aplicação onde ocorreu a exploração da vulnerabilidade para se proceder a correcção da mesma. Exemplos De forma a demonstrar o mecanismo em funcionamento, vai-se considerar o seguinte excerto de código (Listagem 3.3) no qual efectua uma inclusão de um ficheiro tendo em conta o input fornecido. Para a definição do template e respectivo comportamento benigno do código considera-se o input xpto.txt levando à inclusão do ficheiro correspondente. Nesta situação, o template vai registar o path que corresponde à directoria actual (.) e a extensão do ficheiro alvo de inclusão (txt). Agora suponhamos uma situação em que um atacante tenta explorar uma vulnerabilidade de inclusão de ficheiros remotos, inserindo como input no qual contém um script malicioso. Nesta situação, o mecanismo ao recolher a informação relativa a inclusão, tem como path e como extensão php. Dado que tanto o path e a extensão diferem do que foi definido pelo template respectivo, o mecanismo vai notificar a existência de uma vulnerabilidade neste ponto do código como se pode observar na Figura 3.5. A mesma situação ocorreria com a tentativa de inclusão 39

56 Figura 3.5: Exemplo de funcionamento do mecanismo de detecção de ataques LFI/RFI de um ficheiro local malicioso, desde que este alterasse o path ou a extensão do ficheiro alvo de inclusão comparativamente ao que foi definido no template respectivo. 1 include ( $_GET [ nome ]); Listagem 3.3: Exemplo de código vulnerável a LFI/RFI Detecção de cross-site scripting armazenado Para detectar este tipo de ataque, sempre que é executada uma query, o mecanismo verifica se o conteúdo devolvido por esta contém código que possa ser interpretado por browsers. Esta detecção é efectuada no interior do interpretador da linguagem do servidor (Figura 3.1) e a análise de existência de código é feita através de um módulo de parsing que analisa a existência de tags de código (ex: HTML, JavaScript) no conteúdo retornado. Funcionamento geral Como referido anteriormente, pretende-se verificar se o conteúdo devolvido pelo processamento de uma query de SQL contém código ou partes deste que possa ser interpretado por browsers web. Para ser possível a identificação desse código é necessário a utilização de um módulo para fazer parsing de páginas HTML e linguagens similares. Este módulo tem como objectivo analisar o conteúdo devolvido e indicar se este contém código ou não através da existência de tags de HTML ou JavaScript. Antes do conteúdo ser analisado pelo módulo de parsing, devido ao facto que a maioria do conteúdo a analisar é inofensivo causando, assim, um overhead no desempenho, o mecanismo efectua uma préverificação. Esta pré-verificação consiste na análise do conteúdo em termos da existência de caracteres perigosos (ex: <, >) ou strings potencialmente perigosas (ex: href, javascript). Em caso afirmativo, procede-se à análise com o módulo de parsing, caso contrário, dado que não existem caracteres ou strings perigosas como resultado da query não é necessário analisar mais e como tal o mecanismo de detecção termina. 40

57 Após esta pré-verificação, como referido anteriormente, o módulo de parsing analisa o conteúdo que é devolvido pela query e verifica se existe alguma tag de código que pode ser interpretado por browsers web. Em caso afirmativo, o mecanismo notifica a existência de um ataque de cross-site scripting armazenado e regista a respectiva ocorrência no log de ataques. Além disso, e para não afectar o desempenho do interpretador, o mecanismo quando identifica pela primeira vez a existência de código no conteúdo alvo de análise notifica imediatamente a existência da vulnerabilidade e não analisa o restante. Casos de detecção Esta solução detecta eficazmente a existência de uma vulnerabilidade cross-site scripting armazenado nos seguintes casos: Conteúdo retornado por uma query SQL no qual é identificado caracteres ou strings especiais e que é considerado como código HTML ou JavaScript pelo módulo de parsing. Limitações Esta solução não consegue detectar eficazmente a existência de uma vulnerabilidade cross-site scripting armazenado nos seguintes casos: Conteúdo retornado por uma query SQL no qual não são identificados caracteres ou strings especiais mas que é considerado como código; Conteúdo retornado por uma query SQL no qual são identificados caracteres ou strings especiais e que não é considerado como código HTML ou JavaScript pelo módulo de parsing mas na verdade contém código. Log de ataques Quando um ataque deste tipo é detectado o mecanismo regista informação sobre este num log. Em cada ocorrência é registado no log a data e hora em que o ataque ocorreu e o respectivo identificador da query que retornou dados que continham código e que explora esta vulnerabilidade. Além disso, retorna o conteúdo alvo de análise que fez despoletar a identificação deste ataque por parte do mecanismo de forma a facilitar a compreensão das razões pela qual a vulnerabilidade foi explorada. Exemplos Para demonstrar o funcionamento deste mecanismo, de seguida, vai ser apresentado um excerto de código (Listagem 3.4) no qual recebe um input proveniente do utilizador, insere-o na base de dados e de seguida retorna-o através de queries MySQL: 41

58 1 $q = " INSERT INTO posts ( Title, Content ) VALUES ( $_POST [ title ], $_POST [ content ])"; 2 $r = mysql_query ($q); 3 $q = " SELECT * FROM posts "; 4 $r = mysql_query ($q); Listagem 3.4: Exemplo de código vulnerável a XSS armazenado Numa situação normal de funcionamento inseriam-se os seguintes dados na aplicação web vulnerável: Title="Hello!", Content="Hello World". Nesta situação, o mecanismo não detecta nenhum dos caracteres perigosos da pré-verificação e como tal, termina a verificação. Um exemplo malicioso seria a inserção dos seguintes dados: Title="Hello!", Content=<script>alert("XSS")</script>; Nesta situação, quando os dados são retornados, o mecanismo na fase de pré-verificação encontra os caracteres perigosos, prosseguindo para a análise com o módulo de parsing. Ao analisar-se através do módulo de parsing, é identificado código JavaScript devido às tags de script existentes no conteúdo retornado, sendo assim, identificado uma vulnerabilidade de cross-site scripting armazenado Detecção de cross-site scripting reflectido Este mecanismo detecta a existência de um ataque se ao enviar um script como input à aplicação web se este é reflectido como resposta por parte da mesma. Esta detecção é efectuada no interior do fuzzer (Figura 3.1) dado que é o componente que interage com a aplicação web alvo de teste e como tal consegue aceder ao conteúdo dos pedidos efectuados e das respectivas respostas. Antes de serem enviados os inputs à aplicação, estes precisam de ser analisados em termos de existência de código (ex: HTML, JavaScript). Em caso afirmativo, o mecanismo procede ao envio do pedido HTTP à aplicação alvo com o respectivo input. Caso contrário, como o input a ser enviado não contém código também não vai afectar a resposta devolvida. De seguida, é analisada a resposta devolvida pela aplicação. Esta análise verifica se a resposta contém uma parte significativa do input enviado, através do algoritmo Smith-Waterman [41]. Este algoritmo, usualmente utilizado na área da biologia computacional, efectua um alinhamento local entre duas sequências de caracteres. Este algoritmo funciona através de um sistema de pontuações: são adicionados pontos entre emparelhamentos entre dois caracteres iguais e são deduzidos em caso contrário. As pontuações podem ser diferentes consoante os caracteres, por exemplo, os caracteres < e > têm uma pontuação superior comparativamente aos outros, devido à sua importância. Além disso, também podem ser deduzidos pontos caso seja necessário adicionar um intervalo entre duas partes da sequência de forma ao restante destas ficar alinhado. Deste algoritmo são obtidas as sub-sequências de caracteres com maior similaridade, ou seja, cuja pontuação é mais elevada. Para a detecção da vulnerabilidade de cross-site scripting reflectido, o algoritmo efectua um alinhamento local entre o input e a respectiva resposta, por forma a obter a sub-sequência da resposta que 42

59 tem uma maior similaridade com o input enviado. Caso a pontuação obtida pelo algoritmo seja perfeita, ou seja, a sub-sequência corresponde integralmente ao input enviado, significa que este foi totalmente reflectido sendo notificado a existência de uma vulnerabilidade cross-site scripting reflectido. Caso a pontuação obtida não seja perfeita, mas seja superior a um limiar parametrizado analisa-se a subsequência da resposta obtida. Esta análise, consiste em verificar se existe código nessa sub-sequência da mesma forma que se efectuou com input antes de ser enviado. Em caso afirmativo, é notificada a existência da vulnerabilidade. Caso contrário, considera-se que a aplicação alterou significativamente o input de forma a este não explorar uma vulnerabilidade. Casos de detecção Esta solução detecta eficazmente a existência de uma vulnerabilidade cross-site scripting reflectido nos seguintes casos: Todos os inputs contendo código e cuja a respectiva resposta contém uma sub-sequência resultante do algoritmo Smith-Waterman que corresponde ao input enviado. Esta sub-sequência deve ter um número de alterações inferior a um limiar parametrizado definido pelo mecanismo e deve conter código. Limitações Esta solução não consegue detectar eficazmente a existência de uma vulnerabilidade cross-site scripting reflectido nos seguintes casos: Pode haver falhas na identificação de código no input ou na sub-sequência resultante da resposta por parte do mecanismo de análise do conteúdo; Existência de alterações significativas da resposta tendo em conta o input enviado e não ser identificado pelo mecanismo a vulnerabilidade mas mesmo assim, este ter desencadeado um ataque com sucesso sobre a aplicação; Log de ataques Quando um ataque de cross-site scripting reflectido é detectado o mecanismo regista informação sobre o ataque num log. Em cada nova ocorrência, no log é registado se houve uma exploração da vulnerabilidade, caso o input seja integralmente reflectido, ou se existe a possibilidade da exploração da vulnerabilidade, caso a resposta contenha uma parte significativa do input, através do algoritmo Smith-Waterman e que esta contenha código. Além disso, também são registados os parâmetros e os respectivos inputs que foram enviados à aplicação alvo de teste para facilitar a análise das causas da exploração da vulnerabilidade. 43

60 Exemplos Para demonstrar o funcionamento deste mecanismo de detecção consideremos o seguinte excerto de código PHP vulnerável (Listagem 3.5). Neste excerto de código, é enviado como resposta uma string que contém conteúdo proveniente do input do utilizador. 1 $nome = $_GET [ nome ]; 2 echo " Bem vindo ". $nome ; Listagem 3.5: Exemplo de código vulnerável a XSS reflectido Uma situação normal de funcionamento deste excerto de código seria inserir como input a string Miguel. Nesta situação não seria detectado a existência de código no input e como tal este não é enviado a aplicação. Suponhamos que é enviado o conteúdo malicioso <script>alert("xss")</script>. Nesta situação, é identificado no input a existência de código devido a existência das tags de script enviando, assim, o input à aplicação. Ao receber a respectiva resposta, esta é analisada e é identificado, através do algoritmo de Smith-Waterman, que o input foi integralmente reflectido na resposta notificando, assim, a existência de uma vulnerabilidade na aplicação. De seguida, vai-se considerar um exemplo mais complexo (Listagem 3.6), o qual recebe input do utilizador e de seguida reflecte-o removendo todos os espaços em branco deste: 1 $nome = preg_replace ( /\s+/,, $_GET [ nome ]); 2 echo " Bem vindo ". $nome ; Listagem 3.6: Exemplo de código vulnerável a XSS reflectido Um exemplo de tentativa de exploração de uma vulnerabilidade deste género seria através do conteúdo <script> alert("xss") </script> como input. Nesta situação, seria inicialmente identificado como código o input a ser enviado e como tal procederia-se ao envio do mesmo à aplicação. Ao receber a resposta, está é analisada, através do algoritmo Smith-Waterman e constata-se que a sub-sequência da resposta mais semelhante ao input seria a string <script>alert("xss")</script> devido a remoção dos espaços em branco. Dado que esta sub-sequência resultante, contém código e está acima do limiar de similaridade para ser considerada como um ataque, o mecanismo notifica a possibilidade da existência de uma vulnerabilidade de cross-site scripting reflectido Detecção de outras vulnerabilidades Como referido na Figura 3.1, a framework pode ser estendida para detectar outras vulnerabilidades usualmente existentes em aplicações web. Essas vulnerabilidades podem-se categorizar consoante o componente back-end que interage com a aplicação web. Os componentes visados são o sistema operativo no qual se detecta a vulnerabilidade de injecção de comandos de SO (OSCI), o interpretador da linguagem do servidor onde se detecta a vulnerabilidade de injecção de código e o sistema de ficheiros onde se inserem as seguintes vulnerabilidades: directory/path traversal, source code disclosure. 44

61 A framework pretende analisar e monitorizar os sensitive sinks relacionados com cada umas vulnerabilidades que se pretende detectar e com a informação recolhida através da monitorização, tirar ilações sobre a exploração de determinada vulnerabilidade. De seguida, vai ser explicado mais pormenorizadamente a forma como a framework pode ser estendida para a detecção de cada uma destas vulnerabilidades visadas referindo uma possível abordagem para a sua implementação. Detecção de injecção de comandos de SO Para a detecção de uma vulnerabilidade de injecção de comandos de sistema operativo, seria necessário efectuar a monitorização sobre as funções encarregues de executar comandos de sistema operativo no interpretador da linguagem do servidor (Figura 3.1). Também, como alternativa, a monitorização pode ser efectuada nas funções relativas ao parsing dos comandos na shell no servidor. Esta monitorização tem como objectivo recolher informação relativa à estrutura dos comandos de sistema operativo executados pela aplicação alvo de teste em determinada chamada a um sensitive sink relativo a esta vulnerabilidade. Com a obtenção desta estrutura, efectua-se a comparação entre a estrutura obtida e o respectivo template, ou seja, o modelo benigno daquela chamada a uma função de execução de comandos de SO e verificar se existem diferenças entre as duas. Em caso afirmativo, indica a existência da exploração de uma vulnerabilidade de injecção de comandos de SO. Detecção de injecção de código Dado que a linguagem do servidor utilizada na implementação é o PHP, vai-se considerar respectivamente, a detecção de ataques de injecção de código PHP através do comando eval. Para detectar uma vulnerabilidade deste tipo seria necessário monitorizar ao nível do interpretador da linguagem servidor (Figura 3.1), nas funções que estão encarregues de implementar esse comando. Como na maioria dos mecanismos de detecção explicitados, pretende-se obter a estrutura esperada em determinada chamada à função eval na aplicação proveniente de inputs benignos, definindo-se como template. De seguida, pretende-se comparar este template gerado anteriormente com futuras chamadas a esta função, verificando-se, assim, se existem diferenças entre o template gerado e a estrutura obtida nas execuções seguintes. Em caso afirmativo, indica a exploração de uma vulnerabilidade de injecção de código PHP na aplicação. Detecção de directory/path traversal Para efectuar a detecção de vulnerabilidades do tipo directory/path traversal (DT/PT) seria necessário modificar ao nível das funções de leitura de ficheiro, como se efectuou também para o caso da detecção da vulnerabilidade de inclusão de ficheiros locais ou remotos, efectuando a monitorização no interpretador da linguagem do servidor (Figura 3.1). Como tal, pretende-se recolher informação proveniente de inputs benignos, mais especificamente, o path e extensão do ficheiro alvo de determinada chamada a uma função na qual pode ser explorada 45

62 este tipo de vulnerabilidade, em semelhança à detecção de vulnerabilidades RFI/LFI, definindo-se como template. Assim, é possível verificar se os ficheiros que são passados como parâmetros a essas funções em causa se estão de acordo com o respectivo template, isto quer dizer, se possuem o mesmo path e extensão. Em caso afirmativo, indica que o ficheiro passado como parâmetro está de acordo com o modelo gerado através inputs benignos e como tal não tenta explorar este tipo de vulnerabilidade. Em caso contrário, indica que determinado ficheiro alvo a ser passado como parâmetro pretende explorar este tipo de vulnerabilidade pois tem um path ou extensão diferentes ao que foi definido através inputs benignos no template. Detecção de source code disclosure Para detectar a vulnerabilidade de source code disclosure seria necessário monitorizar ao nível das funções de leitura de ficheiros no interpretador da linguagem do servidor (Figura 3.1). Baseando-se no mesmo princípio de detecção das vulnerabilidades LFI/RFI e DT/PT, pretende-se efectuar um template através de uma primeira execução, armazenando o path e extensão do ficheiro alvo da chamada a determinada função relativa a esta vulnerabilidade. Este template tem como objectivo, representar o funcionamento esperado pela aplicação em determinado ponto tendo em conta inputs benignos. Com esse template, pretende-se verificar se os ficheiros incluídos nessa mesma chamada se estão de acordo com o template, ou seja, se têm um path e uma extensão iguais. Caso haja alguma diferença, indica a existência de uma vulnerabilidade de source code disclosure na aplicação alvo de teste. 46

63 Capítulo 4 Implementação Este capítulo explica como é que os vários componentes da framework foram implementados, nomeadamente, o fuzzer e os mecanismos de detecção das vulnerabilidades de injecção de SQL, inclusão de ficheiros locais/remotos e cross-site scripting reflectido/armazenado. Na Figura 4.1 está apresentado a arquitectura da framework tendo em conta os componentes implementados e as respectivas tecnologias utilizadas. 4.1 Fuzzer Para implementar o fuzzer recorreu-se a uma ferramenta desenvolvida pelo OWASP de nome JBroFuzz (versão 2.4) 1. Esta ferramenta é constituída por um fuzzer e também por uma biblioteca que contém várias classes que permitem a implementação de um fuzzer contendo várias funcionalidades, por exemplo: vectores de fuzzing ou fuzzing de vários parâmetros em simultâneo. Dado que o fuzzer não contém mecanismos de monitorização de ataques foi necessário recorrer-se à biblioteca deste para criar um fuzzer de forma a incluir o mecanismo de detecção de ataques de cross-site scripting reflectido. Dado que a biblioteca apenas permite a criação de inputs de fuzzing e descura o aspecto do envio destes para aplicação alvo de teste também foi necessário implementar outras funcionalidades: mecanismo de mutação dos inputs; envio de pedidos HTTP com os inputs gerados; mecanismo para colocar a aplicação em determinado estado de execução. Em relação aos vectores de fuzzing foram compiladas listas para as vulnerabilidades que se pretende explorar provenientes de várias fontes de forma a ser o mais abrangente possível nas tentativas de ataque contemplado casos de ataques simples como também casos mais complexos Mecanismo de definição do estado de execução da aplicação Uma aplicação web passa por diversos estados, sendo que só alguns dos quais são vulneráveis. Por isso, ao usar fuzzing para detectar vulnerabilidades numa aplicação, é importante fazê-la percorrer os seus diversos estados e fazer fuzzing de todos os vectores em cada um deles. A implementação actual

64 Figura 4.1: Arquitectura da framework representado os componentes de monitorização implementados do fuzzer contém um mecanismo que permite definir, manualmente, um conjunto de pedidos HTTP que coloquem a aplicação web num determinado estado ou para efectuar reset ao estado da aplicação após o envio de determinado input do fuzzer. Assim, é possível definir os pedidos HTTP que vão definir o estado da aplicação através de um ficheiro de texto contendo a estrutura apresentada na Listagem BEGIN - HTTP 2 [ GET POST ] 3 [ URL ] 4 [ PARAMS ] 5 [ COOKIE ] 6 END - HTTP Listagem 4.1: Estrutura de um pedido HTTP para o mecanismo de definição de estados Como se pode observar na Listagem 4.1, é possível caracterizar um pedido HTTP pelo seu tipo (GET/POST), url, parâmetros e cookies caso sejam necessários. Num ficheiro deste tipo, é possível definir qualquer número de pedidos HTTP desde que estejam de acordo com a estrutura referida anteriormente. De forma a facilitar a compreensão deste mecanismo, vai ser explicado o funcionamento deste mecanismo através de um exemplo de uma aplicação que contém dois estados: não autenticado e autenticado. Esta aplicação necessita de autenticação por parte do utilizador de forma a poder-se enviar uma mensagem à aplicação sendo esta reflectida integralmente, podendo assim, ser possível explorar uma vulnerabilidade de cross-site scripting reflectido como se pode observar no Apêndice A. Caso contrário, não é possível aceder a esta funcionalidade. Assim, para testar-se a aplicação alvo de teste é necessário enviar os inputs provenientes do fuzzer nos dois estados existentes de forma a conseguir-se 48