Framework para Detecção Automática de Vulnerabilidades … · Framework para Detecção...

Framework para Detecção Automática de Vulnerabilidadesem 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: Prof. Luís Eduardo Teixeira RodriguesOrientador: Prof. Miguel Nuno Dias Alves Pupo CorreiaVogal: Prof. Nuno Ferreira Neves

Novembro 2014

A minha famılia

iii

Agradecimentos

Na elaboracao desta dissertacao nao posso deixar de agradecer a todas as pessoas que contribuıram

de alguma forma para o desenvolvimento e conclusao da mesma.

Em primeiro lugar gostaria de agradecer ao orientador, professor Miguel Pupo Correia pela opor-

tunidade que me deu em abordar este tema de dissertacao e por toda a disponibilidade, apoio, ajuda

e experiencia dadas ao longo deste ano lectivo que foram indispensaveis ao desenvolvimento da

mesma. Tambem gostaria de agradecer a professora Iberia Medeiros por toda a ajuda dada ao longo do

desenvolvimento da dissertacao.

Agradeco tambem aos meus amigos mais chegados pela ajuda, disponibilidade e pelas palavras de

incentivo ao longo deste trabalho.

Por ultimo, mas nao menos importante, gostaria de agradecer aos meus pais, irma e avo por todo o

apoio, ajuda e incentivo que me deram.

v

Resumo

O problema de deteccao de vulnerabilidades em software tem sido amplamente abordado na literatura

especializada e e fulcral no desenvolvimento de aplicacoes que tenham requisitos de seguranca.

O fuzzing e uma tecnica de teste de software, automatizada ou semi-automatizada, que consiste

na injeccao de grandes quantidades de inputs semi-aleatorios em software de modo a descobrir

vulnerabilidades.

Muitas das tecnicas de deteccao de vulnerabilidades actuais necessitam de analise manual por parte

dos especialistas para confirmar a sua existencia. Assim, pretendeu-se desenvolver um sistema mais

expedito para permitir a deteccao automatica de vulnerabilidades em aplicacoes web atraves do uso de

fuzzing.

A deteccao de vulnerabilidades em aplicacoes web difere da realizada em outros tipos de software

por estas possuırem varios componentes back-end, que causam vulnerabilidades especıficas, sendo

assim conveniente existirem mecanismos que os monitorizem de forma a auxiliar a deteccao.

Este trabalho apresenta uma framework para fuzzing de aplicacoes web. Esta framework pretende

detectar eficazmente vulnerabilidades atraves de monitorizacao que em grande parte esta embebida

nos varios componentes da aplicacao distinguindo-se das abordagens existentes no state of the art.

A framework considera a deteccao de um conjunto representativo de vulnerabilidades web: injeccao

de SQL; inclusao de ficheiros local e remota; cross-site scripting reflectido e armazenado. No caso da

injeccao de SQL sao consideradas algumas variantes descobertas recentemente.

Tambem e apresentada uma avaliacao experimental da framework desenvolvida neste trabalho tendo

em conta amostras de codigo vulneravel e aplicacoes open source.

Palavras-chave: Seguranca, Deteccao automatica de vulnerabilidades, Aplicacoes web,

Fuzzing

vii

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

Conteudo

Agradecimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v

Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Lista de Tabelas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Lista de Figuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

1 Introducao 1

1.1 Contribuicoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Estrutura do documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Trabalho Relacionado 5

2.1 Descoberta de vulnerabilidades em aplicacoes . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Fuzzing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.2 Scanners de aplicacoes web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.3 Injeccao de ataques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2 Deteccao de exploracao de vulnerabilidades . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2.1 Deteccao em aplicacoes web usando fuzzing . . . . . . . . . . . . . . . . . . . . . 12

2.3 Vulnerabilidades em aplicacoes web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4 Deteccao de vulnerabilidades especıficas de aplicacoes web . . . . . . . . . . . . . . . . 16

2.4.1 Injeccao de SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.4.2 Inclusao de ficheiros remotos/locais . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.4.3 Cross-site scripting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.5 Deteccao de intrusoes em aplicacoes web . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3 A Framework 29

3.1 Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.2 Funcionalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.2.1 Fuzzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.2.2 Deteccao de injeccao de SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.2.3 Deteccao de inclusao de ficheiros locais e remotos . . . . . . . . . . . . . . . . . . 37

3.2.4 Deteccao de cross-site scripting armazenado . . . . . . . . . . . . . . . . . . . . . 40

3.2.5 Deteccao de cross-site scripting reflectido . . . . . . . . . . . . . . . . . . . . . . . 42

xi

3.2.6 Deteccao de outras vulnerabilidades . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4 Implementacao 47

4.1 Fuzzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.1.1 Mecanismo de definicao do estado de execucao da aplicacao . . . . . . . . . . . 47

4.2 Deteccao de injeccao de SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.3 Deteccao de inclusao de ficheiros locais e remotos . . . . . . . . . . . . . . . . . . . . . . 51

4.4 Deteccao de cross-site scripting armazenado . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.5 Deteccao de cross-site scripting reflectido . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5 Avaliacao Experimental 55

5.1 Avaliacao com amostras de codigo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.2 Avaliacao com aplicacoes open source . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.3 Avaliacao do mecanismo de deteccao de ataques SQLI . . . . . . . . . . . . . . . . . . . 58

6 Conclusao 61

6.1 Trabalho futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Bibliografia 66

A Codigo vulneravel demonstrando o mecanismo de definicao do estado de execucao 67

xii

Lista de Tabelas

2.1 Definicao de injeccao de codigo segundo Ray e Ligatti atraves de 11 exemplos explicitando

em quais destes o conteudo injectado e codigo (casos com Sim) ou nao (casos com Nao). 17

5.1 Resumo dos resultados obtidos pela framework com um conjunto de amostras de codigo

vulneravel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.2 Resultados obtidos pela framework atraves de aplicacoes open source . . . . . . . . . . 58

5.3 Resumo dos resultados obtidos pela framework executando aplicacoes open source . . . 58

5.4 Deteccao de ataques de injeccao de codigo definido por Ray e Ligatti realizado por seis

ferramentas e pela framework desenvolvida . . . . . . . . . . . . . . . . . . . . . . . . . . 59

xiii

Lista de Figuras

1.1 Deteccao de intrusoes usando fuzzing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Fases do processo de fuzzing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Abordagem de injeccao de ataques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 Esquema de cross-site scripting reflectido . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.1 Arquitectura da framework mostrando onde e efectuada a monitorizacao de cada um dos

ataques considerados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.2 Template da query SELECT info FROM users WHERE user=’$user’ AND pass=’$pass’ 36

3.3 Estrutura de uma query alvo de um ataque SQLI estrutural de primeira ordem . . . . . . 37

3.4 Estrutura de uma query alvo de um ataque SQLI mımica de primeira ordem . . . . . . . . 37

3.5 Exemplo de funcionamento do mecanismo de deteccao de ataques LFI/RFI . . . . . . . . 40

4.1 Arquitectura da framework representado os componentes de monitorizacao implementados 48

xv

Capıtulo 1

Introducao

A deteccao de vulnerabilidades em software tem sido uma tematica bastante estudada na literatura

e e central no desenvolvimento de aplicacoes que tenham requisitos de seguranca [1, 2, 3]. Muitas

vulnerabilidades de software tem sido descobertas atraves da tecnica 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 disseminacao das aplicacoes web, estas tem-se tornado um dos mais impor-

tantes canais de comunicacoes entre varios tipos de fornecedores de servicos e clientes. Devido a

este aumento de importancia das aplicacoes web, o impacto negativo de falhas de seguranca neste

tipo de aplicacoes tem vindo tambem a crescer. As vulnerabilidades nestas aplicacoes podem levar a

comprometer dados sensıveis dos utilizadores com danos causados cujos custos tem vindo a crescer.

As razoes para esse fenomeno sao, por exemplo, as restricoes a nıvel de orcamento ou de tempo que

levam a descurar o aspecto da seguranca no desenvolvimento das aplicacoes.

A tecnica de fuzzing, consiste na injeccao de grandes quantidades de inputs semi-aleatorios em

software de uma forma automatizada. Se for detectado um comportamento diferente do expectavel, um

input pode ter activado um bug, que pode constituir uma vulnerabilidade.

Uma das dificuldades nesta tematica 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 seguranca de software. Os especialistas analisam os dados devolvidos pela aplicacao alvo

de teste e tiram conclusoes acerca da existencia de vulnerabilidades. Uma tarefa deste genero e

bastante dispendiosa dado que envolve a analise de um grande volume de dados tornando-se um

metodo ineficiente de deteccao de novas vulnerabilidades.

Alem disso, os casos de teste efectuados pelos especialistas podem nao cobrir todo o funcionamento

do software nem todas as sequencias de operacoes que podem ser efectuadas sobre este. Como

tal, e necessario o uso de ferramentas automatizadas que alem de testar casos de testes simples,

tambem efectuam testes aleatorios ou semi-aleatorios sobre o alvo de forma a poder descobrir novas

vulnerabilidades.

Estas ferramentas automatizadas, alem de facilitarem a geracao de novos casos de teste, tambem

1

facilitam a monitorizacao do software que e alvo de teste. Esta monitorizacao consiste em analisar os

varios recursos existentes nesta e observar se existe algum comportamento diferente do expectavel. No

caso do fuzzing, os mecanismos de monitorizacao disponıveis tem certas lacunas ao contrario de outros

sistemas de deteccao de vulnerabilidades [1, 2, 3] que o fazem de uma forma mais expedita. Como tal,

pretende-se integrar mecanismos de monitorizacao ao processo de fuzzing de forma a permitir uma

deteccao de vulnerabilidades mais eficiente a par de outros sistemas de deteccao.

Outra dificuldade existente e que muitas aplicacoes web tem uma arquitectura complexa, o que

constitui tanto um desafio como uma oportunidade para detectar se uma injeccao explorou determinada

vulnerabilidade. No caso de aplicacoes nao web, como servicos de rede ou programas executados na

linha de comandos, muitos fuzzers limitam-se a injectar inputs, deixando ao utilizador a tarefa de com-

preender se estes causam algum comportamento anomalo [5]. Outros tentam detectar comportamentos

anomalos atraves da observacao de crashes ou variacoes no consumo de tempo de CPU ou memoria

[3], mas cabe ainda ao utilizador compreender se este tipo de anomalias correspondem a exploracao de

uma vulnerabilidade. Muitas vulnerabilidades existentes em aplicacoes web estao relacionadas com a

interacao com os seus componentes como o sistema de gestao de bases de dados (SGBD) ou o sistema

de ficheiros, o que complica a monitorizacao, mas tambem permite faze-la nesses pontos.

Para resolver as dificuldades referidas anteriormente, este trabalho apresenta uma framework para

fuzzing de aplicacoes web. A principal enfase do trabalho esta na monitorizacao dos efeitos da injeccao,

feita em grande parte no interior dos componentes da aplicacao web, tendo por objectivo fazer uma

deteccao eficaz da exploracao de vulnerabilidades.

E importante esta monitorizacao ser feita no interior das componentes por diversas razoes: 1) sao

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, sao menores as hipoteses que se tem

de fazer sobre como estes sao processados pela aplicacao, por exemplo, se sao ou nao validados ou

descodificados; 3) permite utilizar funcionalidades das proprias componentes para fazer a deteccao.

Estas vantagens podem ser ilustradas com o caso dos ataques de injeccao de SQL, que na framework

sao detectados no SGBD: i) estes ataques tem por objectivo ler ou escrever numa base de dados, logo o

SGBD e o lugar mais adequado para os detectar; ii) os inputs chegam ao SGBD validados, sanitizados,

codificados ou nao, nao sendo portanto necessario tecer hipoteses sobre como estes sao processados

pela aplicacao; iii) o proprio SGBD extrai a estrutura das queries SQL, simplificando a deteccao.

Neste trabalho, pretende-se detectar quando e que uma vulnerabilidade foi explorada, ou seja, se

aconteceu uma intrusao como esta ilustrado na Figura 1.1. Para tal, e necessario numa primeira fase

gerar os inputs. De seguida, na segunda fase, enviar os inputs a aplicacao alvo de teste atraves do uso

de uma ferramenta de fuzzing. Na terceira fase, e necessario observar se houve alguma intrusao. Este

processo efectua-se recorrendo aos mecanismos de monitorizacao no interior das componentes. Estas

tres fases referidas anteriormente, sao abrangidas pela framework.

Neste trabalho e explicado como a framework detecta as seguintes vulnerabilidades: injeccao de

SQL de primeira e segunda ordem (SQLI); inclusao de ficheiros locais ou remotos (LFI/RFI); cross-site

scripting (XSS) reflectido e armazenado. No caso da injeccao de SQL sao consideradas algumas

2

Figura 1.1: Deteccao de intrusoes usando fuzzing

variantes descobertas recentemente [6]. A escolha recaiu sobre este conjunto de vulnerabilidades

pois as de SQLI e XSS sao consideradas ha varios anos como as que tem um maior risco associado

[7], enquanto as de LFI e RFI tem particular impacto nas aplicacoes web escritas em PHP. Tambem

e explicado, neste trabalho, como e que a framework pode ser expandida de forma a detectar outras

vulnerabilidades que se inserem na categoria de vulnerabilidades relativas a falta de validacao do input

proveniente do utilizador.

A framework foi implementada de modo a permitir encontrar vulnerabilidades em aplicacoes PHP

executadas pelo interpretador de linguagem de servidor Zend Engine e que utilizem como sistema de

gestao de base de dados o MySQL. Alem disso, a framework foi avaliada atraves de amostras de codigo

vulneravel e aplicacoes open source tendo em conta o numero de vulnerabilidades encontradas.

1.1 Contribuicoes

As contribuicoes deste trabalho sao:

• Framework de fuzzing em aplicacoes web e um conjunto de mecanismos de monitorizacao de

ataques;

• Implementacao de varios mecanismos de deteccao de vulnerabilidades baseadas na falta de

validacao do input. As vulnerabilidades visadas sao: injeccao de SQL; inclusao de ficheiros locais

e remotos; cross-site scripting reflectido e armazenado.

• Avaliacao experimental da framework atraves de amostras de codigo vulneravel e aplicacoes open

source.

3

1.2 Estrutura do documento

O restante deste documento esta organizado da seguinte forma:

• Capıtulo 2 - Trabalho Relacionado: apresenta o state of the art necessario a compreensao do

tema deste trabalho servindo como base para a concepcao da solucao proposta. Sao abordados

varios mecanismos de teste de vulnerabilidades em aplicacoes atraves da sua execucao, nomea-

damente: fuzzing, scanners de aplicacoes web e injeccao de ataques em aplicacoes. Tambem

e abordado como e efectuado a deteccao de exploracao de vulnerabilidades, as vulnerabilida-

des existentes em aplicacoes web e como e que algumas destas sao detectadas. Por fim, sao

abordados sistemas de deteccao de intrusoes;

• Capıtulo 3 - Framework: descreve a solucao proposta, uma framework para fuzzing de aplicacoes

web e respectiva deteccao de vulnerabilidades, focando-se na forma como esta e feita, diferindo

de outras abordagens existentes no state of the art, atraves da monitorizacao existente no interior

dos varios componentes back-end ;

• Capıtulo 4 - Implementacao: descreve os detalhes de implementacao da solucao proposta. Des-

creve quais as tecnologias ou abordagens que foram utilizadas para implementar cada componente

ou funcionalidade da arquitectura proposta e o seu papel;

• Capıtulo 5 - Avaliacao Experimental: apresenta a avaliacao da solucao proposta tendo em conta

amostras de codigo vulneravel e aplicacoes open source;

• Capıtulo 6 - Conclusao: conclui o documento, resumindo o trabalho desenvolvido neste trabalho.

Tambem sao introduzidos certos aspectos que se podem ter em conta relativamente a trabalho

futuro.

4

Capıtulo 2

Trabalho Relacionado

A compreensao das implicacoes deste trabalho torna necessario o conhecimento de conceitos funda-

mentais na area da seguranca e deteccao de vulnerabilidades.

Na subseccao 2.1 abordam-se varios mecanismos de descoberta de vulnerabilidades em aplicacoes:

fuzzing, scanners de aplicacoes web e injeccao de ataques. Na subseccao 2.2, sao explicitadas tecnicas

de deteccao de exploracao de vulnerabilidades usando fuzzing nao so em aplicacoes web mas tambem

em outros tipos de software. Na subseccao 2.3 sao apresentadas as vulnerabilidades em aplicacoes

web mais reconhecidas tendo em conta a lista divulgada pelo Open Web Application Security Project –

OWASP das dez vulnerabilidades de maior risco [7]. Na subseccao 2.4 sao abordadas varias tecnicas

de deteccao de vulnerabilidades sendo estas: injeccao de SQL (primeira e segunda ordem); inclusao de

ficheiros remotos e locais; cross-site scripting reflectido e armazenado. Por fim, na subseccao 2.5, sao

apresentados sistemas de deteccao de intrusoes em aplicacoes web.

2.1 Descoberta de vulnerabilidades em aplicacoes

Nesta seccao, vao ser abordados alguns dos mecanismos de deteccao de vulnerabilidades em aplicacoes

atraves da sua execucao, mais em especıfico, a tecnica de teste de software chamada fuzzing, scanners

de aplicacoes web e tambem se vai falar sobre a injeccao de ataques em aplicacoes.

2.1.1 Fuzzing

O fuzzing [8, 9, 10] e uma tecnica de teste de software que envolve fornecer dados aleatorios ou semi-

aleatorios, atraves da analise da aplicacao alvo de teste, como input de um programa de computador

para este processar. De seguida pretende-se monitoriza-lo de forma a ver se esse input causou algum

comportamento diferente do esperado no software, por exemplo, uma excepcao ou retorno de dados

incorrecto. O fuzzing e um processo automatico ou semi-automatico pois pode ser necessario interacao

de forma a recolher informacoes sobre o alvo de teste.

Esta tecnica de teste esta relacionada com a analise dos valores de fronteira (BVA) [8] onde se

observam um intervalo de valores conhecidos validos para um input e de seguida criam-se casos de

5

teste com valores dentro ou fora desse intervalo. Os resultados desta tecnica ajudam a assegurar que

as funcoes de tratamento de excepcoes conseguem tratar apropriadamente casos validos e invalidos. O

fuzzing e semelhante ao BVA, mas no caso do primeiro nao se esta apenas interessado nos valores

fronteira mas tambem em qualquer input que possa despoletar algum comportamento anomalo 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 aleatorios

a aplicacao sem recorrer a sua estrutura interna. No caso da categoria grey-box, o fuzzing pode fornecer

dados nao totalmente aleatorios a aplicacao pois pode recorrer a determinadas informacoes sobre a

aplicacao, como por exemplo, a sua documentacao ou o seu codigo. Com essas informacoes relativas a

aplicacao, podem-se gerar casos de teste com maior potencial de originar um comportamento anomalo.

Como se referiu anteriormente, o processo de fuzzing nao consiste apenas no envio de dados

aleatorios, caso isso acontecesse, seria uma operacao bastante dispendiosa onde a maioria dos inputs

seria rejeitado devido a uma sintaxe incorrecta. Para resolver essa situacao, os dados a ser enviados

tambem podem ser semi-aleatorios, ou seja, inputs que sao gerados tendo em conta o conhecimento

da aplicacao alvo de teste e que conseguem contornar os seus mecanismos de validacao do input e

verdadeiramente testar o seu funcionamento.

Para evitar tal situacao, os dados a serem enviados devem ser semi-aleatorios atraves de tecnicas ou

heurısticas para que os valores escolhidos sejam mais provaveis de despoletarem vulnerabilidades tendo

em conta uma analise do alvo ou de saber quais sao os erros mais provaveis a existirem implementados

pelos programadores, dentro destas tecnicas estao incluıdas [8, 11]:

• Analise dos valores de fronteira;

• Uso de repeticoes de string com varios caracteres diferentes;

• Inclusao de caracteres nao alfanumericos incluindo caracteres especiais pois costumam ser

frequentemente utilizados como delimitadores de instrucoes;

• Inclusao de tokens de strings (ex: %d, %08x);

• Uso de codificacoes alternativas para os caracteres;

• Inclusao de fragmentos de codigo.

Tendo em conta esta utilizacao das tecnicas acima referidas, existe uma categorizacao de como e

que o fuzzer cria os inputs de casos de testes que sao as seguintes [8, 10, 12]:

• Mutation-based : aplicam-se mutacoes, isto quer dizer, pequenas alteracoes 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 modelacao ou conhecimento acerca do

protocolo ou formato de ficheiro alvo do ataque.

6

Figura 2.1: Fases do processo de fuzzing

Alem destas duas classificacoes que se fizeram aos fuzzers tambem se pode defini-los em categorias

dependendo do alvo que vao testar sendo estes:

• Local Fuzzers: fuzzers para alvos como aplicacoes que recebem input atraves de linha de

comandos, utilizam valores de variaveis globais ou para aplicacoes que processam ficheiros de um

determinado formato. Como tal, injectam inputs em programas na mesma maquina onde o fuzzer

se encontra;

• Remote Fuzzers: fuzzers para alvos como protocolos de rede, aplicacoes web ou browsers,

injectando os inputs em maquinas remotas;

• In-Memory Fuzzers: este tipo de fuzzers contem um mecanismo que permite guardar o estado

da aplicacao num determinado ponto e injectar dados nas rotinas de interpretacao do input. Apos

a injeccao de cada caso de teste, o estado guardado anteriormente e restaurado e novos dados

sao injectados na aplicacao. Este processo repete-se ate que todos os casos de teste tenham sido

executados. Este tipo de fuzzers podem injectar inputs em maquinas 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 vao ser enunciadas de

seguida [8].

A primeira fase, consiste na identificacao do alvo e no estudo do historico de vulnerabilidades que

essa aplicacao ja possa ter sofrido de forma a auxiliar o processo de deteccao de vulnerabilidades.

Na segunda fase, devem-se identificar os inputs a testar fazendo uma enumeracao de vectores de

7

input para usar no processo de fuzzing. Pretende-se procurar fontes potenciais de input (ex: headers,

nomes de ficheiros, variaveis de ambiente) que podem causar danos ao sistema.

Na terceira fase, apos a identificacao dos inputs que podem ser passiveis de explorar vulnerabilidades

na aplicacao, deve-se gerar os dados a enviar atraves de mecanismos de mutacao de dados existentes

ou atraves da geracao dinamica de dados.

A quarta fase consiste na accao de executar o processo de fuzzing, isto e, a accao de enviar

os pacotes de dados ao alvo, ou de abrir um ficheiro ou lancar um processo alvo atraves do input

selecionado e gerado nos passos anteriores.

Na quinta fase, e necessario haver uma monitorizacao de faltas e de excepcoes causadas pelos

dados enviados para saber qual ou quais os dados que podem ter causado a paragem do funcionamento

da aplicacao alvo. Este processo de descobrir as causas para a paragem do funcionamento da aplicacao

e um grande desafio, principalmente, para casos de vulnerabilidades com multiplas etapas, por exemplo,

envio de varios inputs. Nesta situacao torna-se complicado poder monitorizar e concluir que determinada

sequencia de inputs causou uma falta no sistema alvo.

Por fim, apos a falta ter sido identificada pode ser necessario determinar se o bug pode ainda ser

mais explorado. Normalmente, este processo e manual e requer um conhecimento em seguranca

especializado.

Dado que o foco deste trabalho centra-se na descoberta de vulnerabilidades em aplicacoes web e

necessario saber como e que funciona o fuzzing para este tipo de alvo em especıfico.

O fuzzing de aplicacoes web [8] insere-se dentro da categoria de fuzzers remotos e foca-se especifi-

camente em pacotes que estao de acordo com o protocolo HTTP (Hypertext Transfer Protocol).

Este tipo de fuzzing pode descobrir vulnerabilidades na aplicacao em si ou em qualquer dos seus

componentes.

2.1.2 Scanners de aplicacoes web

Scanners de aplicacoes web [1, 2] sao ferramentas automatizadas que sondam este tipo de aplicacoes

comunicando de forma a identificar vulnerabilidades e fraquezas na arquitectura do sistema.

Por norma, os scanners de aplicacoes web possuem tres modulos principais: modulo crawler, modulo

de ataque e um modulo de analise.

O modulo crawler funciona da seguinte maneira: atraves de um conjunto de URLs, este devolve as

paginas correspondentes e identifica todas as paginas alcancaveis na aplicacao alvo de teste. Este

modulo tambem identifica todos os pontos de entrada da aplicacao, tais como: parametros de pedidos

GET, campos de entrada de formularios HTML.

O modulo de ataque analisa as paginas retornadas pelo crawler e os seus pontos de entrada e

de seguida efectua ataques atraves do envio de dados que podem vir a explorar vulnerabilidades em

determinado ponto de entrada.

Essa identificacao de existencia de vulnerabilidades e efectuada atraves do modulo de analise, cujo

objectivo e avaliar as respostas dadas pela aplicacao web. Com as respostas analisadas, pretende-se

8

concluir se aquele ponto de entrada e vulneravel tendo em conta os dados enviados pelo modulo de

ataque.

Este tipo de scanners seguem a abordagem de teste black-box dado que nao tem acesso ao codigo

e so conseguem detectar vulnerabilidades realizando ataques as cegas sobre os pontos de entrada da

aplicacao. Alem disso, simulam ataques externos provenientes de atacantes, fornecendo metodos para

a deteccao de vulnerabilidades importantes, permitindo assim configurar as defesas da aplicacao como

por exemplo a firewall.

O fuzzing distingue-se dos scanners, dado que o primeiro exercita apenas uma amostra aleatoria

do comportamento do sistema e na maioria das vezes os casos de testes gerados pelo fuzzer sao

bastante simples/especıficos para serem reutilizados em diferentes sistemas alvo de teste. No caso dos

scanners, estes procuram vulnerabilidades ja conhecidas atraves de assinaturas de ataques conhecidos

com que estes tipo de ferramentas sao pre-configuradas, ao contrario do fuzzing que tenta descobrir

novas vulnerabilidades. Alem disso, os scanners estao inseridos num sistema completo onde inclui:

analise dos pontos de entrada da aplicacao permitindo exercitar uma maior amostra do comportamento

do sistema; envio de dados a aplicacao; analise das respostas dadas pela aplicacao.

O fuzzing pode ser usado como tecnica de teste de software utilizada por um scanner de forma a

identificar as vulnerabilidades na aplicacao atraves do envio de inputs a aplicacao que vai ser alvo de

teste.

De forma a avaliar a qualidade de um scanner de aplicacoes web existem varios criterios que este

deve suportar, sendo estes explicitados de seguida [13]:

• Protocolos de transporte (ex: HTTP, SSL/TLS);

• Configuracao de um proxy ;

• Mecanismos de autenticacao (ex: digest, Kerberos, certificados SSL de cliente);

• Gestao de sessoes: inicializar/actualizar/readquirir token de sessao, detectar se a sessao expirou,

suporte aos varios tipos de tokens existentes (ex: HTTP cookies, parametros HTTP);

• Configuracao de um web crawler ;

• Parsing de conteudo web (ex: HTML, JavaScript, VBScript, XML, plaintext) e suporte de codificacao

de caracteres;

• Configuracao e customizacao de testes;

• Comando e controlo do scanner ;

• Geracao de relatorios relativos aos resultados obtidos.

Alem disso, uma outra forma de avaliar a qualidade e a utilidade de um scanner e na sua habili-

dade de detectar vulnerabilidades. Um scanner, segundo [13], deve detectar um conjunto mınimo de

vulnerabilidades ou problemas de arquitectura da aplicacao sendo estes:

9

Figura 2.2: Abordagem de injeccao de ataques

• Problemas de autenticacao (ex: autenticacao insuficiente, fraca validacao na recuperacao de

passwords);

• Problemas de autorizacao (ex: autorizacao insuficiente, previsao de tokens de sessao);

• Ataques do lado do cliente (ex: XSS, injeccao HTML, CSRF);

• Execucao de comandos (ex: injeccao de SQL, injeccao de comandos SO, inclusao de ficheiros

remotos/locais);

• Divulgacao de informacoes sensıveis.

2.1.3 Injeccao de ataques

A injeccao de ataques [14, 3] e um metodo de descoberta automatica de vulnerabilidades em componen-

tes de software.

Uma ferramenta de injeccao de ataques, imita o comportamento de um atacante que sistematicamente

ataca o sistema alvo enquanto monitoriza o seu comportamento. Este processo e representado com as

suas accoes principais na Figura 2.2 e explicado mais pormenorizadamente de seguida.

Em primeiro lugar, sao gerados numerosos ataques de forma a avaliar completamente o sistema alvo

em termos de funcionalidade. De forma a existir um maior nıvel de confianca acerca da ausencia de

faltas, os ataques devem ser exaustivos e devem abranger o maximo de classes de vulnerabilidades

possıvel. Tendo em conta o mecanismo de geracao de ataques, e esperado que uma parte destes

ataques seja rejeitado pelos mecanismos de validacao de dados de input enquanto alguns conseguem

prosseguir ate chegar a camada da aplicacao onde se processa o input.

Estes ataques que foram gerados no passo anterior, neste segundo passo sao injectados enquanto o

estado da aplicacao e monitorizado, no passo 3, de forma a observar algum comportamento inesperado.

Dependendo da capacidade de monitorizacao, a informacao recolhida pode variar de um simples output

do alvo, memoria alocada pelos recursos do sistema ou sequencia de chamadas de sistema que foram

10

executadas. Sempre que um erro ou uma falha e observada indica que potencialmente foi descoberta

uma nova vulnerabilidade.

Alem destes tres passos, estao incluıdos mais dois que existem na framework apresentada em [14]:

• Especificacao do protocolo: este passo insere-se antes da geracao de ataques e permite

fornecer a especificacao da interface externa implementada pelo sistema alvo. O proposito deste

passo foca-se no facto que se a ferramenta souber informacoes adicionais sobre o alvo pode gerar

testes mais eficazes;

• Analise do ataque: este passo insere-se apos a monitorizacao e tem como objectivo identificar a

presenca de vulnerabilidades dependendo bastante da informacao recolhida durante o passo de

monitorizacao e do conhecimento acerca da especificacao do sistema alvo.

Como se pode observar e relacionando com o tema desta seccao e possıvel inserir o fuzzing no

contexto desta metodologia da mesma forma como tambem ocorreu no caso dos scanners. O processo

de geracao dos ataques a efectuar contra a aplicacao alvo pode ser efectuado atraves da tecnica de

teste de fuzzing.

No entanto, a injeccao de ataques distingue-se do fuzzing dado que o segundo so exercita uma

amostra aleatoria do comportamento do sistema. Alem disso, a maioria das vezes os casos de testes

criados pelo fuzzer sao bastante simples ou especıficos para serem reutilizados em diferentes sistemas

alvos. Os fuzzers tambem tem uma lacuna em relacao a mecanismos de monitorizacao, ao contrario

das varias abordagens de monitorizacao existentes no sistema AJECT [3].

Por outro lado, o sistema AJECT [3] e independente da aplicacao alvo ou do protocolo implementado

ao contrario do fuzzing.

2.2 Deteccao de exploracao de vulnerabilidades

Para verificar se as tentativas de input atraves do fuzzer tiveram resultado e necessario existirem

mecanismos que consigam monitorizar o estado do sistema alvo. Como ja foi referido anteriormente,

normalmente usam-se ferramentas de monitorizacao ou recursos do sistema de forma a detectar se este

foi alvo de falhas, isto e, se lancou excepcoes e eventualmente possa ter levado a aplicacao a falhar.

Nestas ferramentas de monitorizacao e recursos do sistema estao incluıdos por exemplo [8]:

• Ficheiros de log: onde pode estar registado alguma falha de execucao devido ao input gerado

pelo fuzzer ;

• Debuggers: que sao anexados a aplicacao que e alvo de teste, permitindo a identificacao de

excepcoes tratadas ou nao;

• Codigos ou mensagens retornadas: por parte do alvo em resposta ao input fornecido podendo-

se tentar identificar algo que difere das mensagens de resposta de pedidos benignos;

11

• Conexao interrompida: verificacao se a conexao com o sistema alvo persiste apos o envio do

input, pois em caso contrario pode indicar que o input ou sequencia de inputs enviado anteriormente

pelo fuzzer pode ter causado uma negacao do servico da aplicacao.

Em termos gerais, a deteccao de activacao de vulnerabilidades e efectuada atraves da analise dos

recursos existentes retornados pela aplicacao alvo de teste de forma a tirar pistas de quais foram os

inputs que despoletaram o funcionamento anomalo da aplicacao. A deteccao tambem pode ser efectuada

atraves de ferramentas de monitorizacao que sendo anexadas a aplicacao alvo de teste podem fornecer

informacoes internas relativas ao estado desta.

2.2.1 Deteccao em aplicacoes web usando fuzzing

A maioria das tecnicas definidas para deteccao de vulnerabilidades atraves do input gerado pelo fuzzer

que foram referidas na seccao anterior sao semelhantes para o caso das aplicacoes 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 deteccao de excepcoes neste tipo de aplicacoes e um grande desafio, dado que o fuzzer envia

muitos pedidos a aplicacao sendo complicado identificar qual dos pedidos fez com que a aplicacao

passasse a ter um comportamento anomalo ou que a fizesse lancar uma excepcao. Apenas e possıvel

concluir que existe uma condicao que leva o sistema a ficar vulneravel. Existe uma grande dificuldade

em identificar a causa de falta na aplicacao, pois pode ter sido causada a partir de um unico pedido

como tambem pode ter sido a partir de uma sequencia especıfica de pedidos.

De forma a poder-se observar a existencia 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

codigo 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

sequencia de erros internos do servidor (500) podem sugerir que os pedidos anteriores causaram

uma anomalia na aplicacao. Outro caso, um erro de nao autorizacao (401) pode sugerir que a

pagina requisitada existe mas nao tem permissoes para acede-la;

• Mensagem de erro do servidor web: a aplicacao pode ter sido desenhada para apresentar men-

sagens de erro directamente no conteudo da pagina web podendo ser possıvel obter informacoes

uteis acerca do estado do sistema atraves da analise das mesmas;

• Conexao interrompida: causada por um dos inputs do fuzzer que levou a um freeze/crash da

aplicacao causando uma negacao de servico dos pedidos seguintes;

• Ficheiros de log: a maioria dos servidores web sao configurados para fazer o registo dos varios

tipos de erros atraves de logs, fornecendo assim pistas de quais pedidos causaram problemas

e que levam a uma condicao de vulnerabilidade. De forma a facilitar essa observacao deve-se

sincronizar a altura do pedido e o log correspondente do lado do servidor;

12

• Debuggers: anexando-o a aplicacao alvo de teste e a melhor forma de identificar as excepcoes

lancadas pela aplicacao, pois e possıvel observar tanto as excepcoes tratadas como as que nao

foram tratadas e podem ter causado uma falha no servidor e tentar relaciona-las com os pedidos

efectuados.

No entanto, este tipo de mecanismos nao tem sido integrados em fuzzers pois nao permitem

uma deteccao precisa de ataques que explorem vulnerabilidades existentes neste tipo de aplicacoes

permitindo apenas indicar a possibilidade da existencia de vulnerabilidades.

2.3 Vulnerabilidades em aplicacoes web

Para que seja possıvel identificar automaticamente vulnerabilidades em aplicacoes web, em primeiro

lugar e necessario saber e perceber quais sao as vulnerabilidades a que este tipo de aplicacoes esta

sujeita, para tal recorreu-se ao OWASP Top 10 – 2013: The Ten Most Critical Web Application Security

Risks [7], onde referem as vulnerabilidades com um maior risco, sendo estas:

• A1 – Injection: Falhas de injeccao (ex: SQL, SO, LDAP) que ocorrem quando dados hostis sao

enviados para um interpretador como parte de um comando ou query. Os dados do atacante

podem enganar o interpretador levando a executar comandos nao intencionados ou acedendo a

dados sem a autorizacao apropriada;

• A2 – Broken Authentication and Session Management : Funcoes da aplicacao relacionadas

com autenticacao e gestao de sessao que nao foram implementadas correctamente. Permite aos

atacantes poderem comprometer passwords, chaves, tokens de sessao ou explorar quaisquer

outras falhas de implementacao de forma a assumir a identidade de outros utilizadores;

• A3 – Cross-site scripting (XSS): Falhas de cross-site scripting ocorrem sempre que uma

aplicacao utiliza dados que nao sao de confianca que vem como input e envia-as para o browser

web sem uma validacao apropriada. XSS permite aos atacantes, por exemplo, executar scripts no

browser da vıtima podendo apoderar-se das sessoes dos utilizadores ou redirecionar o utilizador

para websites maliciosos;

• A4 – Insecure Direct Object References: Uma referencia directa a um objecto ocorre quando

um programador expoe a referencia da implementacao do objecto, como por exemplo: um ficheiro,

directoria ou chave de base de dados. Sem a verificacao do controlo de acessos ou outro

mecanismo de proteccao, os atacantes podem manipular essas referencias para aceder a dados

nao autorizados;

• A5 – Security Misconfiguration: Uma ma configuracao de seguranca dos componentes de uma

aplicacao, pode permitir que utilizadores maliciosos consigam, por exemplo, alterar o website,

obter acessos nao autorizados, comprometer ficheiros ou realizar quaisquer outras accoes nao

intencionadas. Assim, de forma a haver uma boa seguranca, e preciso de se ter uma configuracao

13

segura definida e implementada para a aplicacao, framework, servidor de aplicacao, servidor

web, servidor de base de dados e plataforma. Devem ser definidas, implementadas e mantidas

configuracoes de seguranca pois as que sao definidas por omissao pelos componentes sao

normalmente inseguras. Alem disso, o software dos componentes deve estar sempre actualizado

de forma a corrigir eventuais vulnerabilidades;

• A6 – Sensitive Data Exposure: Varias aplicacoes web nao protegem de forma correcta dados

sensıveis (ex: cartoes de credito, NIF, credenciais de autenticacao). Os atacantes podem roubar

ou modificar esses dados que estao pouco protegidos para efectuar fraudes de cartoes, 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 aplicacoes web verificam as

permissoes de acesso ao nıvel das funcoes antes de torna-las visıveis ao utilizador. No entanto, a

aplicacao necessita de realizar o mesmo controlo de acesso no servidor sempre que cada funcao

e acedida, caso contrario, os atacantes sao capazes de forjar os pedidos de forma a aceder a

funcionalidades sem terem a autorizacao apropriada;

• A8 – Cross-site Request Forgery (CSRF): Este tipo de ataque necessita que a vıtima tenha o

login efectuado na pagina que contem a vulnerabilidade de forma a incluir o cookie de sessao

ou outro tipo de informacao de autenticacao. Assim, o atacante ao enviar um URL contendo um

pedido HTTP forjado e malicioso a vıtima, caso esta aceda vai efectuar operacoes maliciosas. Isto

permite que o atacante force o browser da vıtima a gerar pedidos que a aplicacao vulneravel pense

que sao pedidos legıtimos por parte da vıtima;

• A9 – Using Known Vulnerable Components: Componentes como por exemplo: bibliotecas,

frameworks e outros modulos de software na maioria da vezes executam-se com o maximo de

privilegios. 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 vulneravel e explorado, tal ataque pode levar a perdas de dados ou apoderarem-se do

servidor. Aplicacoes que usem componentes vulneraveis podem prejudicar as suas polıticas ou

configuracoes de seguranca implementadas e facilitar determinados ataques. De forma a resolver

tal situacao, estes componentes de terceiros devem ser executados com o mınimo de privilegios

necessarios para que em caso de ataque tenham o mınimo impacto possıvel. Alem disso, tambem

deve-se apenas instalar componentes que sejam fidedignos;

• A10 – Unvalidated Redirects and Fowards: As aplicacoes web frequentemente redireccionam

e encaminham utilizadores para outras paginas ou websites e utilizam dados inseguros para

determinar o destino. Caso nao haja uma validacao apropriada, os atacantes podem redireccionar

as vıtimas para paginas contendo mecanismos de malware ou phishing, ou encaminhar o acesso

para paginas nao autorizadas.

14

Tambem se recorreu ao WASC Threat Classification v2.0 do Web Application Security Consortium [15]

para obter uma lista das vulnerabilidades existentes em aplicacoes web. As vulnerabilidades mais

relevantes sao apresentadas de seguida podendo-se observar vulnerabilidades em comum entre esta

classificacao 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

Alem das classificacoes do OWASP e do WASC [7, 15] tambem 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 aplicacoes web, este

trabalho, como sera apresentado na subseccao 2.4, foca-se principalmente nas vulnerabilidades de

injeccao de SQL (primeira e segunda ordem), inclusao de ficheiros remotos/locais e tambem cross-site

scripting reflectido e armazenado. A escolha recaiu sobre este conjunto de vulnerabilidades pois as

vulnerabilidades de injeccao de SQLI e XSS sao consideradas ha varios anos como as que tem um maior

risco associado [7], enquanto as de LFI/RFI tem particular impacto nas aplicacoes web escritas em PHP,

sendo utilizada em mais de 77% das aplicacoes web [17]. Apesar de estas serem as vulnerabilidades

consideradas, a framework pode ser estendida para encontrar outras.

15

2.4 Deteccao de vulnerabilidades especıficas de aplicacoes web

Como foi referido na seccao 2.2 existem varias tecnicas de identificacao de eventos anomalos na

aplicacao alvo que podem ser consequencia do input gerado pelo fuzzer. Nesta seccao, vao ser

abordadas varias tecnicas de deteccao de vulnerabilidades a determinados ataques independentemente

da tecnica de teste de software. As vulnerabilidades que serao abordadas sao as seguintes: injeccao de

SQL, inclusao de ficheiros remotos/locais e cross-site scripting.

Em cada uma destas subseccoes sera abordado inicialmente a vulnerabilidade em questao, seguindo-

se das varias tecnicas de deteccao existentes na literatura e a aplicabilidade dessas tecnicas 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 injeccao

de SQL.

2.4.1 Injeccao de SQL

Uma injeccao de SQL [18] e uma vulnerabilidade do tipo de injeccao de codigo (A1) [7] onde o atacante

usa inputs especialmente criados de forma a enganar a base de dados para consequentemente poder

executar instrucoes nao pretendidas pela aplicacao.

Assim, um ataque de injeccao de SQL ocorre quando um atacante altera a sintaxe e/ou semantica de

uma query inserindo operadores ou palavras chave SQL. Uma vulnerabilidade deste tipo tira partido

da falta de validacao, sanitizacao ou codificacao do input do utilizador. Os ataques sobre este tipo de

vulnerabilidade que tem efeito imediato sobre o comportamento do alvo sao designados de primeira

ordem. Nos ataques de segunda ordem, primeiro o atacante fornece a aplicacao um input que e

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 injeccao de SQL de primeira ordem e o seguinte: uma aplicacao

web faz um acesso a base de dados de forma a aceitar as credenciais (utilizador, pin) fornecidas pelo

utilizador sendo o pedido a base de dados o seguinte:

SELECT info FROM users WHERE login=’$utilizador’ AND pin=$pin

Um caso normal de funcionamento e o utilizador definir, por exemplo, o utilizador=Miguel e

pin=1234 sendo a interpretacao feita pela base de dados a seguinte:

SELECT info FROM users WHERE login=’Miguel’ AND pin=1234

Pelo contrario, caso o atacante forneca o input : utilizador= ’ OR 1=1 - - e qualquer pin, a

instrucao que vai ser interpretada na base de dados e:

SELECT info FROM users WHERE login=’’ OR 1=1 -- AND pin=1234

Isto vai fazer com que a base de dados interprete tudo apos o token WHERE como uma condicao e

com a inclusao de OR 1=1 na clausula vai tornar esta condicao uma tautologia. Como a parte posterior

16

esta comentada atraves dos caracteres - - , faz com que a base de dados devolva toda a informacao

correspondente a tabela users.

Apesar dos ataques de injeccao de SQL serem populares ha quase uma decada, recentemente Ray

e Ligatti argumentaram que a definicao de ataques de injeccao de codigo como os de injeccao de SQL e

problematica, introduzindo o conceito de CIAO (Code-Injection Attacks on Outputs) [6].

Normalmente, uma injeccao de SQL ocorre sempre que um input de um utilizador modifica a estrutura

sintactica do output de determinada aplicacao. No entanto, os autores referem que esta definicao tem

alguns problemas, pois existem casos que este tipo de ataques nao alteram a estrutura, enquanto que

ha casos de nao-ataques que alteram essa estrutura.

De forma a resolver esta situacao, Ray e Ligatti definiram a nocao de injeccao de codigo atraves de

11 exemplos de injeccoes definindo quais delas sao consideradas como codigo e quais nao. De seguida

sao apresentados os exemplos (elementos que foram injectados na query a sublinhado) que permitiram

definir a nocao de injeccao de codigo. Tambem se pode observar na Tabela 2.1 quais dos exemplos

contem injeccoes de codigo.

1. SELECT balance FROM acct WHERE password=’’ OR 1=1 --

2. 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’

1 2 3 4 5 6 7 8 9 10 11Ray e Ligatti Sim Sim Sim Nao Sim Sim Nao Sim Sim Sim Nao

Tabela 2.1: Definicao de injeccao de codigo segundo Ray e Ligatti atraves de 11 exemplos explicitandoem quais destes o conteudo injectado e codigo (casos com Sim) ou nao (casos com Nao).

Para a deteccao deste tipo de vulnerabilidade existem duas formas genericas de a efectuar que sao

as seguintes [18, 19, 20, 21, 22, 23]:

1. Verificacao se sao utilizados operadores ou caracteres especiais da linguagem devido a falta de

validacao do input [22];

17

2. Verificacao se existe uma alteracao da estrutura logica da instrucao de SQL da estrutura pretendida

pelo programador com o uso de input correcto [18, 19, 20, 21, 23].

Em relacao ao primeiro ponto, em [22] utilizam-se expressoes regulares de forma a detectar este

tipo de vulnerabilidade atraves da tecnica de tainting positivo. Esta tecnica consiste na identificacao e

marcacao de caracteres definidos como seguros, ao inves de outras solucoes que marcam os caracteres

perigosos e que devem ser rejeitados. A solucao faz uma avaliacao 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 solucao utilizou-se um sistema de deteccao de intrusoes baseado na rede

(NIDS) de forma a escutar os pacotes enviados e verificar a existencia das expressoes regulares no

conteudo destes.

A solucao proposta em [22] nao e eficiente dado que esta solucao utiliza um NIDS de forma a escutar

os pacotes observados e detectar se estes podem causar uma injeccao de SQL. A solucao proposta

nao garante que a aplicacao nao possui mecanismos de validacao e sanitizacao no momento em que

processa os pedidos de forma a evitar que um ataque destes ocorra e como tal nao seria vulneravel.

Assim, esta solucao poderia identificar que determinado pedido e passıvel de um ataque de injeccao de

SQL quando na verdade seria sanitizado pela aplicacao ja nao sendo perigoso para esta.

Em relacao ao segundo ponto, existem varias alternativas de deteccao. A solucao apresentada por

Halfond e Orso [18, 19], o sistema AMNESIA, pretende detectar estes ataques atraves de analise estatica

de codigo e da monitorizacao da aplicacao em tempo de execucao. Esta analise estatica consiste na

identificacao de pontos no codigo onde se efectuam queries SQL de uma forma automatica. De seguida

para cada ponto referido anteriormente constroi-se um modelo que representa todas as queries SQL

que podem ser geradas naquele ponto atraves de um automato finito nao-determinista cujas transicoes

sao tokens SQL: operadores ou caracteres da linguagem. Em tempo de execucao, a tecnica monitoriza

as queries geradas dinamicamente e verifica se estao de acordo com o modelo estatico. Caso sejam

diferentes, indica que o modelo gerado foi violado e como tal, classifica o pedido como um ataque.

Esta solucao, nao pode ser utilizada neste trabalho dado que efectua a deteccao recorrendo a

estrutura interna da aplicacao, atraves da analise do codigo, inserindo-se na categoria de teste white-

box.

A solucao apresentada em [23], difere apenas da anterior em relacao a estrutura de dados escolhida

para fazer a comparacao que ao inves de utilizar um automato, efectua uma comparacao entre arvores

que representam a estrutura das queries.

A solucao proposta por Huang, Huang e Lin [20], pretende detectar vulnerabilidades sem aceder a

estrutura interna da aplicacao alvo de teste, utilizando apenas engenharia reversa para a identificacao

dos pontos de entrada de input para a base de dados. Esta solucao baseia-se na analise das respostas

da aplicacao web tendo em conta os seguintes aspectos:

• Existencia de erros provenientes da base de dados;

• Comparacao da resposta proveniente da aplicacao com outras duas: resposta proveniente de

um pedido invalido; resposta proveniente de um pedido ”valido”, isto e, um pedido que contorne

18

todos os mecanismos de validacao por parte da aplicacao atraves do Injection Knowlegde Manager

(IKM).

O IKM e uma estrutura que contem informacao relativa aos pontos de entrada de input para a base

de dados, as variaveis alvo do input do utilizador como as suas restricoes, por exemplo, numero de

caracteres que uma determinada variavel pode conter. Dado que o IKM contem essas informacoes,

consegue gerar pedidos que contornem essas restricoes.

Esta solucao nao e eficiente, dado que existem casos que a comparacao das respostas pode ser

inconclusiva em termos da existencia ou nao de vulnerabilidades, situacao que se pretende evitar como

solucao deste trabalho.

Por fim, o mecanismo de deteccao proposto em [21] tambem baseia-se no princıpio de que uma

injeccao de SQL altera as estrutura das queries solicitadas, como nos sistemas propostos em [18, 19, 23].

Esta tecnica implementada pelo sistema CANDID pretende comparar a estrutura das queries atraves de

inputs candidatos. Estes inputs candidatos sao benignos e pretendem deduzir de forma dinamica qual e

a estrutura pretendida das queries pelo programador da aplicacao num determinado ponto que recebe

input proveniente do utilizador. Esta analise da estrutura das queries e feita a partir da instrumentacao

da aplicacao web para que intercepte o processamento destes pedidos SQL.

De forma a poder-se inferir a existencia de um ataque e necessario comparar a estrutura obtida

atraves do input candidato e o input enviado que pretende testar a aplicacao. Caso a estrutura seja

igual, pode-se concluir que o input e valido e seguro para a base de dados. Caso contrario, pode indicar

a possibilidade daquele input despoletar um ataque a aplicacao.

O sistema CANDID proposto em [21] parece ser uma solucao apropriada para o trabalho em questao

dado que efectua uma comparacao das queries benignas e as que se pretendem testar e porque utiliza

um mecanismo de instrumentacao para analisar a estrutura queries de SQL a serem processadas

na aplicacao. No entanto, esta abordagem necessita que se altere a aplicacao alvo e alem disso, a

extraccao das estruturas das queries e efectuada por uma ferramenta de parsing externa ao sistema de

gestao de base de dados podendo assim falhar na extraccao da estrutura.

2.4.2 Inclusao de ficheiros remotos/locais

A vulnerabilidade inclusao de ficheiros remotos (RFI) permite a um atacante incluir um ficheiro proveniente

de um servidor web externo. Esta vulnerabilidade acontece devido a falta de validacao do input fornecido

pelo utilizador e alem disso, resulta dos mecanismos de inclusao de ficheiros dinamicos em aplicacoes

web, como por exemplo na linguagem de PHP o comando include.

Quando a aplicacao web utiliza o input do utilizador (ex: URL, valores dos parametros) de forma a

incluir ficheiros supostamente fidedignos, esta pode ser enganada, atraves da inclusao ficheiros remotos,

ou seja, de outros servidores, contendo codigo malicioso.

Esta vulnerabilidade serve por exemplo para instalar uma backdoor, obter informacao tecnica do

sistema, execucao de codigo no servidor web, negacao de servico ou obter o controlo do sistema

vulneravel.

19

A linguagem PHP e particularmente vulneravel aos ataques RFI devido ao uso extensivo de inclusao

de ficheiros como se pode ver na Listagem 2.1:

1 $incfile = $_REQUEST["file"];

2 include($incfile.".php");

Listagem 2.1: Exemplo de codigo vulneravel a LFI/RFI

Como se pode ver por este excerto de codigo vulneravel a RFI seria possıvel incluir a referencia a

ficheiros remotos da seguinte forma:

http://www.alvo.pt/vuln_pag.php?file=http://www.evil.pt/evil

Isto resultaria na inclusao do ficheiro remoto evil.php o qual pode conter codigo que pode com-

prometer o sistema vulneravel. Existem mais comandos PHP vulneraveis a RFI: include once, fopen,

file get contents, require e require once.

Actualmente este tipo de vulnerabilidade deixou de ser tao usada pelos atacantes pois as versoes

mais recentes de PHP (versao 5.2 e seguintes) nas suas configuracoes por omissao deixaram de permitir

a inclusao de URLs nestas funcoes sendo assim necessario explorar um novo tipo de vulnerabilidade

que vai ser explicada de seguida que e a inclusao de ficheiros locais.

A inclusao de ficheiros locais (LFI) e uma vulnerabilidade bastante semelhante a anterior mas o

ficheiro que e incluıdo e um ficheiro presente no computador da aplicacao vulneravel. Para tal ocorrer e

necessario inserir o codigo malicioso dentro dos ficheiros locais da aplicacao e posteriormente referir

esse ficheiro de forma a inclui-lo e posteriormente executar o codigo malicioso.

Existem varios mecanismos de inclusao desse codigo malicioso: upload do ficheiro (ficheiro PHP

ou embebido num outro tipo de ficheiro) caso o website permita; inserir o codigo num log, por exemplo

http://alvo.pt/<?php+phpinfo();+?>. Como o ficheiro nao existe, o pedido de acesso vai ser registado no

log de erros e acesso, bastando agora aceder ao ficheiro de logs da seguinte forma:

http://www.alvo.pt/vuln_pag.php?file=/var/log/error_log%00

Assim, vai ser possıvel aceder ao ficheiro de log de erros e executar o codigo PHP pois esta linguagem

interpreta codigo PHP independentemente se no ficheiro exista outro conteudo escrito que nao PHP.

Existem varios mecanismos de prevencao, mitigacao e deteccao de inclusao de ficheiros remotos

ou locais. Estes mecanismos focam-se principalmente na analise estatica de codigo, verificando se o

codigo da aplicacao local contem algum dos comandos vulneraveis a RFI/LFI e se os parametros contem

valores provenientes do input fornecido pelo utilizador, sendo assim uma solucao inviavel pois necessita

de acesso ao codigo fonte da aplicacao alvo de teste para efectuar a deteccao da vulnerabilidade.

Tambem existem mecanismos que utilizam listas de valores invalidos (blacklist) [24]. Na solucao

apresentada em [24] pretende-se ter uma lista de todos os valores proibidos e que nao podem ser

inseridos em funcoes de inclusao de ficheiros, restringindo, assim, o conteudo que um possıvel atacante

20

possa incluir. Este mecanismo foca-se mais na prevencao de ataques do que na deteccao da exploracao

de determinada vulnerabilidade e como tal nao e a abordagem mais adequada para este trabalho.

O sistema desenvolvido por Dahse [25], baseia-se numa tecnica que consiste em marcar o input do

utilizador e verificar se este input chega as funcoes crıticas que tambem sao designadas por sensitive

sinks, por exemplo, no caso de RFI/LFI a funcao include(). O input so e desmarcado se for alvo de

validacao ou de um processo de sanitizacao pois so nesse caso e que o input e considerado seguro

para ser executado por estas funcoes crıticas. Como nos casos anteriores, este mecanismo foca-se

mais na prevencao.

Outro mecanismo de prevencao e o Spectogram [26] onde se pretende fazer uma deteccao de

anomalias atraves de um modelo probabilıstico chamado Markov Chain Model. Neste modelo calcula-se

qual e o conteudo mais provavel a ser enviado como input a aplicacao. Segundo o autor, ocorre um

possıvel ataque quando sao enviados pedidos cuja a sua probabilidade de acontecer e abaixo de um

certo limiar. Isso acontece pois considera-se que e bastante improvavel ocorrer o envio desse input

e como tal a solucao considera essa situacao como um ataque. Esta solucao nao e eficiente pois

analisa os dados que sao enviados pelos utilizadores sem ter em conta os mecanismos de validacao ou

sanitizacao por parte da aplicacao alvo de teste nem se a vulnerabilidade e realmente explorada.

Por fim, em [27] refere-se um mecanismo simples de deteccao de vulnerabilidades RFI que consiste

em enviar como input para a aplicacao um URL de um recurso que esta num servidor web em que se

possa monitorizar os acessos e determinar se esse servidor web recebeu algum pedido por parte da

aplicacao referente ao recurso que esta inserido no URL. Caso isso tenha acontecido, quer dizer que a

aplicacao web estava a tentar incluir o ficheiro remoto e consequentemente possui uma vulnerabilidade

RFI.

Em termos de mecanismos de deteccao LFI e de referir que na solucao proposta em [27] o autor

propoe como teste submeter o nome de um recurso executavel ou estatico e determinar se respectiva-

mente existe alguma alteracao no comportamento da aplicacao ou se existem conteudos copiados para

a resposta da aplicacao. Em caso afirmativo indica que a aplicacao web e vulneravel a LFI.

2.4.3 Cross-site scripting

Para o proposito do trabalho desenvolvido e necessario 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 aplicacao web

confia nos inputs dos utilizadores e os reflecte inserindo-os numa resposta por parte do website sem

validacao, sanitizacao ou codificacao adequadas. Estes dados sao normalmente recolhidos na forma de

link URL no qual existe conteudo malicioso (ex: JavaScript). Os atacantes podem colocar o link num

website, e-mail e assim que o utilizador acede ao link a mensagem de pedido com o script malicioso vai

ser enviada para a aplicacao.

Quando os dados sao recolhidos pela aplicacao web, vai ser gerada uma pagina com conteudo

malicioso mas aparece como se fosse conteudo valido no browser da vıtima. Dado que os browsers nao

21

Figura 2.3: Esquema de cross-site scripting reflectido

tem consideracoes em termos de distincao de codigo proveniente da aplicacao e de codigo proveniente

do utilizador vai ser executado o script inserido pelo atacante com diversas consequencias possıveis.

Este tipo de vulnerabilidade permite a um atacante executar um script no browser da vıtima, levando

por consequencia, ao atacante conseguir personificar o utilizador perante websites ou aplicacoes web

que utiliza regularmente e que as considera fidedignas, podendo obter, alterar ou remover variados tipos

de conteudos.

Um dos exemplos de acesso a conteudos e o exemplo dos cookies, pois estes so 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 a 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 e reflectido atraves de HTML e e executado pelo

browser da vıtima levando a aceder ao conteudo do cookie daquele website.

A vulnerabilidade de cross-site scripting armazenado e baseada no mesmo princıpio de XSS reflectido

diferindo apenas num aspecto. A diferenca e que nesta caso a aplicacao web vulneravel, 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 esta tipicamente presentes em foruns, blogs ou outro tipo de aplicacoes que

armazenem conteudo proveniente dos utilizadores e nao efectue validacao do mesmo.

Alem dos dois tipos de cross-site scripting referidos anteriormente tambem existe um terceiro tipo

que consiste em XSS baseado em document object model (DOM).

Existem varios mecanismos de prevencao e mitigacao de XSS [30, 31] que se baseiam principalmente

na restricao da execucao de scripts consoante a confianca nos websites e os links estaticos contidos

nele necessitando de interacao com o utilizador [30].

Tambem existem mecanismos de defesa baseados na remocao dos scripts [31] atraves de uma

arvore de parsing para determinar a estrutura da resposta valida por parte da aplicacao web com o uso

de whitelist, isto e, lista de caracteres validos para um determinado ponto de input levando a remover

qualquer conteudo que nao esteja de acordo com esta lista. Esta estrutura valida e enviada para o

22

browser e serve para este quando for analisar a resposta saber como fazer a analise do mesmo levando

a mitigacao de XSS pois sabe a estrutura com que a aplicacao web pretende ser analisada de forma a

assegurar a ausencia de conteudo dinamico (ex: script).

Estes mecanismos explicitados anteriormente baseiam-se mais na prevencao e defesa de ataques

XSS e nao na deteccao da vulnerabilidade na aplicacao nao sendo os ideais tendo em conta o proposito

deste trabalho que tem como objectivo a deteccao de vulnerabilidades.

Existem varios mecanismos de deteccao de XSS [32, 28, 29, 33, 34] que vao ser explicados de

seguida.

Existem mecanismos de deteccao de XSS que se baseiam na tecnica de analise estatica [29, 34].

Esta tecnica consiste em verificar se o input proveniente do utilizador e alvo de algum processo de

validacao ou sanitizacao antes de ser enviado como resposta. Este tipo de tecnica consegue detectar

potenciais vulnerabilidades cross-site scripting no codigo fonte mas no entanto nao pode verificar a

correccao das funcoes de sanitizacao. Para resolver essa situacao, assume-se que as funcoes desse

genero que sao desconhecidas por parte da aplicacao que faz essa analise retornam dados inseguros.

A analise estatica consegue provar a ausencia destas vulnerabilidades mas tende a gerar muitos falsos

positivos,

Um outro tipo de mecanismos de deteccao de XSS existentes baseia-se num melhoramento da

tecnica anterior e consiste na analise estatica de strings [29, 33, 34]. Estes mecanismos efectuam uma

analise dos valores validos como input e aceita-se ou rejeita-se este tendo em conta os valores definidos.

Na solucao apresentada em [33], utilizam uma gramatica livre de contexto para representar os valores

que determinada variavel pode conter num determinado ponto do programa o que facilita a verificacao

dos valores de string blacklisted ao longo do programa. Esta tecnica e mais precisa do que a anterior

dado que gera menos falsos positivos.

Estes duas abordagens de deteccao referidas anteriormente requerem uma analise do codigo fonte

da aplicacao, categorizando-os como uma tecnica de teste white-box.

Ao contrario dos exemplos anteriores, em [32, 28] as solucoes propostas pelos autores baseiam-se

numa deteccao do lado do cliente desta vulnerabilidade.

Na solucao de Matsuda, Koizumi, Sonoda [32] a deteccao e feita atraves da posicao de determinados

sımbolos e a sua respectiva frequencia. Estes sımbolos foram escolhidos atraves 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 frequencia. Alem da existencia desta tabela de sımbolos, tambem e necessario classificar o

grau/nıvel de importancia de cada caracter que e calculado atraves da sua frequencia e a sua posicao

no input.

A decisao de gerar um alarme indicando a presenca da vulnerabilidade cross-site scripting baseia-se

se esse grau/nıvel de caracter ultrapassa um certo valor limite calculado atraves de amostras. Caso

aconteca, considera-se que aquele input como um ataque cross-site scripting.

Esta solucao [32] e ineficiente no aspecto que faz a analise so do input a enviar e nao considera se a

vulnerabilidade e activada na aplicacao, causando muitos falsos positivos.

A solucao implementada em [28] consiste num servidor proxy de deteccao e coleccao e tambem num

23

servidor de base de dados. Neste servidor proxy existem dois modos para efectuar a deteccao/coleccao

de informacao relativa a ataques XSS: modo de alteracao de respostas e de alteracao de pedidos.

Em ambos os modos, caso seja detectada informacao relativa a ataques XSS o mecanismo altera a

codificacao do pedido/resposta de forma a este ser inofensivo para a aplicacao/utilizador.

O modo de alteracao de respostas consiste na recolha e verificacao das mensagens no servidor proxy

sempre que um utilizador efectua pedidos a aplicacao web. Caso existam caracteres nos pedidos que

correspondam a tags especiais de HTML, estes pedidos serao armazenados no proxy antes de serem

enviados. Este armazenamento tem como proposito a comparacao do pedido com a respectiva resposta

devolvida pela aplicacao. Caso a resposta contenha as mesmas tags especiais da linguagem existentes

no pedido considera-se que a aplicacao e vulneravel a XSS. Este modo nao funciona correctamente

caso o pedido e a resposta contenham varios parametros com tags HTML inofensivas. Para resolver

essa lacuna, e necessario um segundo modo que consiga identificar quais os parametros susceptıveis a

vulnerabilidades XSS e os que nao sao.

O segundo modo, o de alteracao de pedidos, investiga os pedidos HTTP que contenham multiplos

parametros, gerando um identificador, neste caso um numero aleatorio, de forma a nao apenas identificar

se a aplicacao e vulneravel a XSS mas tambem identificar quais sao os parametros em especıfico que

sao vulneraveis.

Esta solucao comparativamente as anteriores e superior em termos de aplicabilidade ao trabalho

dado que e uma deteccao que nao e feita do lado do servidor e que considera os processos de validacao

de input e tambem porque efectua a deteccao atraves da comparacao do conteudo que e transmitido

nos pedidos e o que e enviado como resposta por parte da aplicacao.

2.5 Deteccao de intrusoes em aplicacoes web

Dado que o trabalho desenvolvido consiste na deteccao de vulnerabilidades em aplicacoes web, e

necessario perceber como sistemas semelhantes funcionam, tais como sistemas de deteccao de

intrusoes e os seus mecanismos internos para classificar determinados inputs como ataques.

Um sistema de deteccao de intrusoes (IDS) pretende monitorizar o trafego da rede ou eventos do

sistema relacionados com actividades maliciosas de modo a detectar a existencia de ataques e/ou se

estes levaram a intrusoes.

Existem dois tipos de sistemas de deteccao de intrusoes [35]: baseado na rede (NIDS) e baseado no

host (HIDS).

No caso de NIDS pretende-se detectar as intrusoes atraves da analise do trafego da rede. Este

mecanismo pode ter problemas caso o trafego a ser processado seja demasiado e, assim, o sistema de

deteccao nao consegue processar os pacotes que atravessam a rede. Alem disso, os pacotes podem

ser alvo de cifra deixando de ser possıvel fazer a analise dos mesmos.

No caso de HIDS pretende-se monitorizar os componentes internos de um sistema computacional

(ex: memoria RAM, sistema de ficheiros, logs), como tambem em alguns casos os pacotes de rede que

chegam as interfaces de rede do host. Caso esta monitorizacao detecte alguma actividade diferente do

24

esperado no host, o sistema avisa que pode estar a ser alvo de uma intrusao.

Tendo em conta as aplicacoes web, um NIDS iria monitorizar a rede onde estaria inserida a aplicacao

alvo podendo assim proteger quaisquer servidores no interior da rede, enquanto que um HIDS iria

monitorizar o funcionamento do servidor web onde esta inserido a aplicacao sendo assim uma estrategia

mais proxima da aplicacao.

Independentemente do tipo de IDS que e implementado, existem varias estrategias de fazer esta

deteccao de intrusoes que sao as seguintes [35]:

• Baseada em regras: procura por actividades que correspondem a um conjunto pre-definido de

eventos, regras ou padroes que sao descritos como um ataque conhecido. Este tipo de IDS tem

que ser especificamente programado para detectar cada ataque conhecido.

• Baseada em anomalias: procura ataques atraves da identificacao de comportamento invulgar

que ocorra na rede ou no host. Funcionam com base na observacao que os atacantes comportam-

se de uma forma diferente dos utilizadores normais. Este tipo de IDS estabelece o que e o

comportamento normal de funcionamento da aplicacao e monitoriza se em algum momento da

execucao esta sai desse estado.

Estas estrategias definidas anteriormente podem ser modeladas de duas maneiras [36]:

• Modelo de seguranca negativo: este modelo baseia-se em negar tudo o que pode ser perigoso

para aplicacao. Este modelo pode deixar passar intrusoes dado que nao se conhece tudo o que e

considerado perigoso para a aplicacao;

• Modelo de seguranca positivo: este modelo baseia-se em permitir tudo o que e seguro para

aplicacao e rejeitar tudo o resto. Este modelo e mais eficiente dado que consegue prevenir os

casos de intrusoes que nao sao conhecidas.

De seguida, vao ser apresentadas ferramentas que funcionam como sistemas de deteccao de

intrusao que estao inseridas nas varias categorias que foram referidas anteriormente. Estas ferramentas

que vao ser apresentadas sao importantes para o trabalho dado que detectam intrusoes em aplicacoes

web. Resultam de uma combinacao entre IDSs desenvolvidas num ambito de trabalho de investigacao e

de deteccao de intrusoes num contexto real.

O sistema ModSecurity [36], e uma firewall mas comporta-se como um sistema de deteccao de

intrusoes devido as funcionalidades que implementa como se pode ver de seguida. O ModSecurity

possui um mecanismo baseado em expressoes regulares para aceitar ou rejeitar determinado conteudo,

permite auditoria de logs, suporta um numero ilimitado de polıticas diferentes (ex: virtual host, directoria,

ficheiro unico). O sistema suporta intercepcao de upload de ficheiros e validacao em runtime, possui

mecanismos para evitar a evasao dos padroes ou regras definidas. A evasao referida anteriormente

consiste na injeccao de pacotes que contem dados maliciosos mas que estao disfarcados no sentido

que podem nao ser detectados em determinadas regras definidas. Por exemplo, se existir uma regra

no IDS que refere que nao se pode efectuar o comando DROP TABLE xyz atraves de uma comparacao

25

simples, um exemplo de evasao desta regra era existir um pedido com o comando DROP /**/ TABLE

xyz, levando a ser executado o mesmo comando malicioso mas como estao inseridos os comentarios no

interior a regra que rejeitaria este pedido ja nao e activada.

O sistema proposto em [37], consiste num IDS que consegue efectuar a deteccao de intrusoes

atraves de um mecanismo de maquina de estados pois foca-se na deteccao de intrusoes que sao

realizadas em multiplos passos. Este sistema tambem consegue correlacionar eventos ao nıvel da rede

e ao nıvel do sistema operativo atraves de entradas contidas nos logs do servidor.

A solucao 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 e 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 contem o mınimo de dados sensıveis e de privilegios. Isto acontece

porque caso que este pedido seja malicioso, este nao consegue aceder a nenhuns dados importantes da

aplicacao. Caso o pacote nao seja considerado anomalo, pode ser enviado para o servidor que contem

mais privilegios e acesso a ficheiros sensıveis pois nao existe o risco daquele pedido ser malicioso e

conseguir comprometer a aplicacao web.

O sistema DoubleGuard, consiste num IDS que modela o comportamento da rede das sessoes do

utilizador ao longo da aplicacao web e da base de dados [39]. O sistema pretende verificar se o utilizador

tem privilegios para efectuar determinados pedidos a aplicacao. Por exemplo, um utilizador que nao seja

administrador nao pode enviar pedidos que so poderiam ser enviados pelo administrador da aplicacao.

Nas aplicacoes que foram referidas anteriormente, so era possıvel aceitar ou rejeitar certos pedidos

tendo em conta regras ou padroes no conteudo dos mesmos e nao atraves do utilizador que os enviou.

Por fim, o sistema AppSensor do OWASP [40] pretende detectar actividade maliciosa numa aplicacao

antes que um atacante consiga identificar e possa explorar determinada vulnerabilidade. Isto e possıvel

porque muitas das vulnerabilidades so sao descobertas como resultado de tentativa e erro pelo atacante.

Assim, se o AppSensor conseguir identificar o atacante que esta a procura de vulnerabilidades e possıvel

prevenir que este consiga identificar e explorar a vulnerabilidade.

Este sistema contem um modulo de deteccao de comportamento malicioso como um IDS e tambem

contem um modulo de resposta, no qual vai integrar mecanismos de prevencao efectuando accoes

contra o utilizador atacante. Um factor que tem que se ter em conta e que na deteccao de actividade

maliciosa deve-se conseguir distinguir uma accao de erro nao intencional de um ataque, pois caso tenha

sido um erro nao intencional o sistema nao deve activar os seus mecanismos de resposta sendo essa

escolha definida atraves de um limiar que define a partir de que ponto deixa de ser uma accao nao

intencional e se considera como um comportamento malicioso.

Como em outros IDSs, os mecanismos de deteccao baseiam-se na analise de padroes nos pedidos

recebidos. Por exemplo, tendo em conta o tipo de vulnerabilidades que este trabalho foca, o AppSensor

detecta injeccoes de SQL atraves de um mecanismo simples de blacklist de valores mais frequentes

usados neste tipo de ataques. No caso da deteccao de XSS, o AppSensor detecta atraves da analise de

26

padroes como a existencia da tag <script> nos pedidos feitos pelo utilizador.

Tendo em conta todas as solucoes estudadas de deteccao de intrusoes em aplicacoes web e a

framework desenvolvida existe uma diferenca importante.

No caso de um IDS, este tem como objectivo a deteccao de ataques, independentemente se existe ou

nao uma vulnerabilidade na aplicacao alvo de teste e em caso desta existir, verificar se foi activada. Este

tipo de solucoes efectua uma analise dos pedidos tendo em conta a existencia de certas caracterısticas

que possam classificar o conteudo como potencialmente benigno ou maligno independentemente da

funcionalidade existente na aplicacao.

No caso da framework de deteccao automatica de vulnerabilidades desenvolvida, pretende-se

verificar se determinado ataque conseguiu realmente explorar uma vulnerabilidade. Para essa situacao

ocorrer e preciso que o pedido chegue a aplicacao e seja processado por esta.

27

Capıtulo 3

A Framework

Foi desenvolvida uma framework cujo o seu objectivo principal e efectuar fuzzing em aplicacoes web e

monitorizar o seu efeito atraves de mecanismos de monitorizacao embebidos dentro dos componentes

constituintes de uma aplicacao deste genero. De seguida, e apresentada a arquitectura da framework e

as suas componentes.

3.1 Arquitectura

A arquitectura da framework e apresentada na Figura 3.1, onde observamos as quatro componentes

que a compoem, nomeadamente:

• Fuzzer: gera os inputs que sao injectados em determinados pontos de entrada da aplicacao web.

Tambem, contem o mecanismo de monitorizacao de ataques cross-site scripting reflectido atraves

da analise das respostas devolvidas tendo em conta os inputs enviados;

• Aplicacao web: como o proprio nome indica, e a aplicacao web alvo de teste que esta 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 estao embebidos varios mecanismos de deteccao

de vulnerabilidades causadas pela falta de validacao do input. Estas vulnerabilidades detectadas

estao divididas em tres categorias consoante se interagem com o sistema de ficheiros ou se com

o sistema de gestao de base de dados ou se com o sistema operativo, respectivamente. Dentro

da primeira categoria inserem-se mecanismos de monitorizacao das seguintes vulnerabilidades:

inclusao de ficheiros locais ou remotos (LFI/RFI); directory/path traversal (DT/PT); source code

disclosure (SCD); Dentro da segunda categoria insere-se a monitorizacao de ataques de cross-site

scripting armazenado e por fim, na terceira categoria, insere-se a monitorizacao de ataques de

inclusao de comandos de sistema operativo (OSCI). Alem dos mecanismos referidos anteriormente,

neste componente tambem esta contido o mecanismo de monitorizacao de ataques de injeccao de

codigo da linguagem do servidor.

29

Figura 3.1: Arquitectura da framework mostrando onde e efectuada a monitorizacao de cada um dosataques considerados

• Sistema de gestao de base de dados: recebe as queries provenientes da aplicacao web e

processa-as, enviando posteriormente, os resultados obtidos ao interpretador da linguagem do

servidor. Alem disso, esta componente tambem contem o mecanismo de monitorizacao de ataques

de injeccao de SQL.

3.2 Funcionalidades

Tendo em conta a arquitectura apresentada, de seguida serao explicadas as funcionalidades de cada

uma das componentes existentes na framework.

3.2.1 Fuzzer

O fuzzer baseia-se na geracao de inputs atraves de vectores de fuzzing, inserindo-se na categoria de

fuzzers iterativos. Estes vectores de fuzzing consistem num conjunto de inputs previamente selecciona-

dos, contendo varias assinaturas de ataques existentes, podendo levar a exploracao de vulnerabilidades.

Alem disso, o fuzzer aplica mecanismos de mutacao sobre cada elemento destes vectores. O mecanismo

de mutacao dos inputs, aleatoriamente, selecciona um conjunto de caracteres de determinado input para

ser alvo de pequenas alteracoes (ex: substituicao de caracteres), gerando assim, uma maior variedade

de inputs que podem, inesperadamente, explorar vulnerabilidades.

Alem das funcionalidades relacionadas com a geracao dos inputs, o fuzzer permite definir em que

estado se pretende que a aplicacao alvo de teste esteja no momento em que sao enviados os inputs.

Devido a esta funcionalidade, o fuzzer desenvolvido insere-se na categoria de in-memory fuzzers como

30

foi explicado na subseccao 2.1.1. Para tal, e possıvel definir de uma forma manual, uma sequencia de

pedidos a serem enviados previamente de forma a colocar a aplicacao em determinado estado e tambem

uma sequencia de pedidos para efectuar reset ao estado da mesma apos o envio de determinado input.

Esta sequencia de pedidos, consiste num conjunto de pedidos HTTP dos seguintes tipos: GET e POST.

O fuzzer tambem se encarrega de injectar os inputs gerados a aplicacao alvo atraves do protocolo

HTTP. Para tal, o fuzzer para cada elemento do vector de fuzzing envia a sua versao original proveniente

do vector de fuzzing e as suas respectivas mutacoes. Caso o mecanismo de definicao 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 aplicacao num estado definido pelo utilizador. Colocado nesse

estado, e enviado o input como referido anteriormente. Posteriormente, caso seja necessario efectuar

reset ao estado da aplicacao, o fuzzer envia os pedidos HTTP definidos pelo utilizador de forma a

restabelecer o estado da aplicacao. Este processo e efectuado repetidamente ate serem enviados todos

os inputs.

3.2.2 Deteccao de injeccao de SQL

Para a deteccao de ataques de injeccao de SQL em aplicacoes web de uma forma automatica foi

desenvolvido um mecanismo que nao seja dependente de ferramentas externas para ser posıvel

identificar a estrutura das queries processadas. Como tal, este tipo de vulnerabilidade e detectada no

interior do sistema de gestao de base de dados (SGBD) (Figura 3.1) por varias razoes:

Em primeiro lugar, este mecanismo nao e dependente de ferramentas externas ao SGBD para a

obtencao da estrutura das queries. Alem disso, estas ferramentas podem conter bugs ou podem nao ser

abrangentes a todos os aspectos relativos aos pedidos que analisam. Assim, com este mecanismo a

analise da estrutura das queries e feita atraves da estrutura obtida pelo proprio parser do SGBD levando

a um processo mais eficiente de deteccao de vulnerabilidades SQLI com um numero mınimo de erros.

Em segundo lugar, este mecanismo nao fica dependente de processos de sanitizacao caso estes

existam, por exemplo nos ficheiros PHP (ex: mysql real escape string), so sendo assim necessario

mesmo preocupar-se como e que a query esta no momento precisamente anterior ao seu processamento

no SGBD.

Em ultimo lugar, este mecanismo tambem tem em conta que os dados podem ser des-sanitizados

quando sao inseridos na base de dados evitando assim ataques de injeccao SQL de segunda ordem.

Assim, para evitar estes problemas, o mecanismo detecta este tipo de ataques apos o SGBD

processar e efectuar o parsing das queries, reduzindo, assim, qualquer pressuposto sobre as mesmas.

Na explicacao que se segue sobre o mecanismo considera-se o caso especıfico do MySQL pois foi o

SGBD utilizado na implementacao.

Mecanismos internos de parsing

Para se obter a estrutura interna de cada query e necessario, numa primeira fase, perceber como e

que se efectua o processamento e parsing das queries transformando estas em algo concreto para o

31

sistema de gestao de base de dados.

Para o caso especıfico do MySQL, este associa a cada query a uma thread que contem um

identificador unico e uma estrutura lexica da query respectiva, classe LEX, que basicamente representa

a informacao que se pretende analisar.

A classe LEX contem todas as informacoes gerais sobre a query, como por exemplo, o conjunto

de todos os SELECTs inseridos na query atraves da classe SELECT LEX ou as informacoes relativas as

queries do tipo INSERT INTO ou UPDATE.

A estrutura SELECT LEX contem toda a informacao que e possıvel incluir dentro deste comando

pelo MySQL. Esta informacao inclui: informacao relativa as clausulas WHERE e HAVING, os fields que

sao retornados pelo SELECT, as tabelas seleccionadas na clausula FROM, o intervalo de valores que e

retornado, informacao relativa as clausulas ORDER BY e GROUP BY ou outros SELECTs encadeados.

As queries do tipo INSERT INTO ou UPDATE sao representadas em parte por elementos constituintes

da classe SELECT LEX caso contenham alguma das palavras-chave referidas nessa estrutura e tambem

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 a estrutura da query com uma granularidade mais fina,

onde estao incluıdos tipos primitivos (inteiros, decimais, reais, strings), operacoes condicionais (ex: AND,

OR), chamadas a funcoes, entre outros. Sucintamente, a estrutura Item esta identificada atraves de um

nome e um tipo. O MySQL considera que existem 27 tipos diferentes de Items sendo estes enunciados

de seguida:

• Field

• Function

• Sum Function

• String

• Integer

• Real

• Null

• Varbin

• Copy string

• Average field

• Default value

• Procedure

• Conditional

• Reference

• Field STD

• Field variance

• Insert value

• SubSelect

• Row

• Cache

• Type holder

• Parameter

• Trigger field

• Decimal

• Xpath nodeset

• Xpath nodeset com-

pare

• View fixer

Cada um deste tipo de Items tem uma estrutura particular (parametros especıficos) no qual pode

conter sub-tipos, por exemplo, no tipo condicional existe um sub-tipo no qual especifica a operacao

condicional esta a ser utilizada (ex: AND, OR, XOR, NOT).

Assim, com a informacao recolhida sobre a query e possıvel perceber como e que o MySQL estrutura

a informacao proveniente das queries de forma a poder executar instrucoes sobre a base de dados.

Numa segunda fase, e necessario perceber, tendo em conta as informacoes referidas anteriormente,

como e que o MySQL utiliza-as. A estrutura das queries obtidas pode ser interpretada sobre a forma de

duas estruturas de dados: pilha ou atraves de uma arvore post-order. No entanto, o MySQL organiza

32

estes dados sobre a forma de uma lista. De seguida pode ser evidenciado a representacao da estrutura

da query SELECT * FROM user WHERE Age < 23 por parte do mecanismo de deteccao de injeccao de

SQL.

1 SELECT_LEX_Nodes_Structure

2 WHERE_Structure

3 FUNC_ITEM 4 <

4 INT_ITEM 23

5 FIELD_ITEM Age

6 ...

7 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 clausula FROM que neste caso e

a tabela user. De seguida faz-se referencia aos elementos que sao devolvidos pelo SELECT neste caso

sao todas as colunas (sımbolo *) da tabela referida anteriormente. De seguida, os items sao referentes a

estrutura da clausula WHERE com o field Age e ao inteiro 23. Com esses dois items aplica-se a operacao <

como se pode verificar pelo item mais acima perfazendo, assim, a query a ser executada sobre o SGBD.

Funcionamento geral

O objectivo principal na deteccao de ataques de injeccao de SQL e identificar se em determinada query

que recebe input do utilizador, se a estrutura desta ao longo de varias execucoes difere tendo em conta

a estrutura obtida atraves inputs benignos. Caso isso aconteca, indica que pode ter sido explorado uma

vulnerabilidade deste tipo dado que a estrutura obtida em determinada execucao e diferente da estrutura

para qual a query foi desenhada.

Para acontecer tal identificacao, em primeiro lugar, e necessario identificar qual e o comportamento

esperado de determinada query da aplicacao por parte de quem desenhou a aplicacao, ou seja, atraves

de inputs benignos. O proposito de tal identificacao e para ser possıvel comparar varias execucoes de

determinada query e verificar se o comportamento desta difere.

Nesta solucao, considera-se como modelo de funcionamento de determinado ponto de entrada, a

primeira execucao desse mesmo ponto, pressupondo que o input enviado nessa primeira vez e benigno,

definindo-se como template de uma query. Ao executar determinada query de SQL pela primeira vez o

mecanismo vai armazenar em tempo de execucao o template desta de forma a ser usado como modelo

de comparacao com as estruturas obtidas em execucoes seguintes da mesma query.

Assim, este mecanismo vai conter todos os templates de todas as queries que sao executadas

provenientes de determinados ficheiros e linhas de codigo sendo identificados de uma forma unica para

que seja possıvel ao programador identificar e analisar as causas de determinado codigo vulneravel.

33

Tendo em conta o referido acima, e necessario este mecanismo ser alvo de uma fase de treino na qual

sao executados todos os pontos do codigo que executem uma query com input proveniente do utilizador,

com conteudo benigno para que seja possıvel gerar os respectivos templates e posteriormente iniciar a

deteccao de ataques na aplicacao alvo de teste.

Nas execucoes seguintes de determinada query, compara-se a estrutura obtida com o respectivo

template gerado na fase de treino. Esta comparacao deve ser tolerante a certos aspectos pois em caso

contrario 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. Alem

disso, tambem deve tolerar o uso de valores diferentes do expectavel mas que devido a operacoes de

typecasting o seu significado e igual. Estas operacoes de typecasting consistem em modificacoes aos

tipos existentes mas cujo seu significado mantem-se, por exemplo, a alteracao de uma string com o

valor 10 para o inteiro correspondente. Como tal, o mecanismo considera os tipos inteiro, decimal, real

e string numa so categoria denominada tipos primitivos. Assim, o mecanismo observa cada elemento

da estrutura obtida e verifica se o tipo (primeiro elemento) e os seus parametros (restantes elementos)

sao exactamente iguais ao elemento correspondente no template exceptuando numa situacao. Quando

determinado elemento da estrutura refere-se a um tipo primitivo, nao sao analisados os parametros

desse tipo, basta que no template esse elemento correspondente tambem seja do tipo primitivo.

Caso a estrutura de determinada query nao corresponda ao template respectivo significa que

determinado input alterou a estrutura desta e esta a explorar uma vulnerabilidade SQLI reportando a

ocorrencia no log de ataques.

O mecanismo consegue detectar duas variantes de injeccao de SQLI: estruturais e mımica. O primeiro

caso ocorre, quando existe uma alteracao dos elementos nao-terminais, ou seja, que estruturados na

forma de uma arvore, as alteracoes efectuadas ocorrem ao nıvel dos nos da arvore. O segundo caso

ocorre, quando a alteracao ocorre ao nıvel dos elementos terminais, ou em termos de uma estrutura de

dados em arvore, ao nıvel das folhas desta denominando-se como um ataque mımica pois a estrutura

da arvore de determinada query mantem-se igual.

Com este mecanismo e possıvel detectar a existencia de vulnerabilidades de injeccao de SQL de

primeira e segunda ordem, pois em ambos os casos, no momento em que a vulnerabilidade e explorada,

existe uma alteracao na estrutura da query a ser executada.

Para efeitos de seguranca, no template nao sao armazenados os parametros dos tipos primitivos

para que nao seja possıvel extrair informacao sensıvel deste (ex: passwords).

Este mecanismo alem da deteccao de vulnerabilidades de injeccao de SQL tambem possui outras

duas funcionalidades: logs das estruturas das queries executadas de forma a comparar e distinguir

execucoes benignas e malignas numa determinada query ; mecanismo de prevencao no qual impede a

execucao de queries que possuam uma estrutura diferente a do respectivo template evitando assim a

exploracao de uma vulnerabilidade deste tipo.

34

Casos de deteccao

Este mecanismo detecta eficazmente a existencia de vulnerabilidades injeccao de SQL nos seguintes

casos:

• Todas as injeccoes de codigo de SQL que alterem a estrutura sintactica de uma query. Considera-

se como alteracao a estrutura sintactica uma das seguintes condicoes: diferenca no numero de

parametros utilizados em determinada clausula (ex: SELECT, FROM), insercao/remocao/alteracao

dos items utilizados numa query SQL;

• Dentro das injeccoes referidas anteriormente, o mecanismo identifica injeccoes de SQL de primeira

e segunda ordem;

• O mecanismo tambem identifica eficazmente ataques SQLI estruturais ou mımica e ataques atraves

de codificacao de caracteres ou evasao de espacos.

Limitacoes

Este mecanismo nao consegue detectar eficazmente a existencia de vulnerabilidades injeccao de SQL

nos seguintes casos:

• Todas as injeccoes de codigo que nao alterem a estrutura sintatica do codigo atraves da nao

identificacao da insercao/alteracao/remocao de novos elementos.

Log de ataques

Quando um ataque SQLI e detectado, independentemente se o modo preventivo esta activado, o

mecanismo regista informacao sobre este num log.

A Listagem 3.2 apresenta o formato de um registo no log de ataques de uma ocorrencia de um

ataque SQLI (SQLIA). A primeira linha indica se o modo preventivo esta activo ou nao e o respectivo

timestamp da ocorrencia. 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

pre-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 diferencas 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

COND_ITEM AND

FUNC_ITEM =

STRING_ITEM foo

FIELD_ITEM pass

FUNC_ITEM =

STRING_ITEM f

FIELD_ITEM user

FIELD_ITEM name

... (...)

SELECT_FIELD name

FROM_TABLE users

user

=

admin

FUNC_ITEM =

STRING_ITEM admin

FIELD_ITEM user

FIELD_ITEM name

... (...)

SELECT_FIELD name

FROM_TABLE users

user

=

admin 1

=

1

AND

COND_ITEM AND

FUNC_ITEM =

STRING_ITEM 1

FIELD_ITEM 1

FUNC_ITEM =

STRING_ITEM admin

FIELD_ITEM user

FIELD_ITEM name

... (...)

SELECT_FIELD name

FROM_TABLE users

user

=

admin 1

=

1

OR

COND_ITEM OR

FUNC_ITEM =

STRING_ITEM 1

FIELD_ITEM 1

FUNC_ITEM =

STRING_ITEM admin

FIELD_ITEM user

FIELD_ITEM name

... (...)

SELECT_FIELD name

FROM_TABLE users

user

=

Miguel pass

=

xpto

AND

COND_ITEM AND

FUNC_ITEM =

STRING_ITEM foo

FIELD_ITEM pass

FUNC_ITEM =

STRING_ITEM alice

FIELD_ITEM user

FIELD_ITEM name

... (...)

SELECT_FIELD name

FROM_TABLE users bottom of the stack

push top, pop

COND_ITEM AND

FUNC_ITEM =

STRING_ITEM foo

FIELD_ITEM pass

FUNC_ITEM =

STRING_ITEM f

FIELD_ITEM user

FIELD_ITEM name

... (...)

SELECT_FIELD name

FROM_TABLE users

user

=

admin

FUNC_ITEM =

STRING_ITEM admin

FIELD_ITEM user

FIELD_ITEM name

... (...)

SELECT_FIELD name

FROM_TABLE users

user

=

admin 1

=

1

AND

COND_ITEM AND

FUNC_ITEM =

STRING_ITEM 1

FIELD_ITEM 1

FUNC_ITEM =

STRING_ITEM admin

FIELD_ITEM user

FIELD_ITEM name

... (...)

SELECT_FIELD name

FROM_TABLE users

user

=

admin 1

=

1

OR

COND_ITEM OR

FUNC_ITEM =

STRING_ITEM 1

FIELD_ITEM 1

FUNC_ITEM =

STRING_ITEM admin

FIELD_ITEM user

FIELD_ITEM name

... (...)

SELECT_FIELD name

FROM_TABLE users

user

=

Miguel pass

=

xpto

AND

COND_ITEM AND

FUNC_ITEM =

STRING_ITEM foo

FIELD_ITEM pass

FUNC_ITEM =

STRING_ITEM alice

FIELD_ITEM user

FIELD_ITEM name

... (...)

SELECT_FIELD name

FROM_TABLE users bottom of the stack

push top, pop

Figura 3.2: Template da query SELECT info FROM users WHERE user=’$user’ AND pass=’$pass’

Exemplos

Para demonstrar o funcionamento do mecanismo de deteccao desta vulnerabilidade vai ser mostrado

um cenario inicial de utilizacao benigna, correspondendo a fase de treino e na qual vai definir o template.

Posteriormente, vao ser mostrados duas variantes de injeccoes de SQL: estrutural e mımica. Estas duas

variantes sao detectadas com sucesso pelo mecanismo desenvolvido.

Para a demonstracao do mecanismo suponhamos uma aplicacao vulneravel que contem a query

SELECT name FROM users WHERE user=’$user’ AND pass=’$pass’. Para definir o template, esta

query vai ser processada uma primeira vez atraves do input $user=’Miguel’ e $pass=’xpto’. A

estrutura resultante correspondente ao template esta apresentada na Figura 3.2 sendo representada

a esquerda na forma de uma arvore post-order e a direita atraves de uma pilha contendo os varios

elementos da query.

De seguida, e enviado um input malicioso no qual tenta explorar uma vulnerabilidade SQLI estrutural

de primeira ordem atraves do envio do input $user=admin’ OR 1=1 -- ilustrada, na forma de uma

arvore post-order e de uma pilha, a sua estrutura na Figura 3.3.

Pode-se observar que existe uma diferenca nas estruturas devido a inclusao de codigo malicioso

na query. A inclusao de codigo, e observada, na pilha, atraves da inclusao do item condicional (OR), o

item de funcao de igualdade (=) e dos items inteiros (1). Dado a esta diferenca estrutural, e identificado

pelo mecanismo uma vulnerabilidade SQLI estrutural. E possıvel observar na estrutura sobre a forma de

arvore post-order que os nos desta sao diferentes relativamente ao template levando consequentemente

a sua estrutura ser diferente.

Para demonstrar a deteccao de uma vulnerabilidade SQLI mımica vai-se considerar o envio do

input $user=admin’ AND 1=1 -- . Neste caso, e como se pode observar pela Figura 3.4, a arvore

sintactica da query processada comparativamente ao seu template, ambos tem o mesmo numero de

nos e estrutura semelhante. Alem disso, as duas pilhas tambem tem o mesmo numero de items. O

mecanismo identifica o ataque devido as diferencas ao nıvel das folhas da arvore que representa a

36

COND_ITEM AND

FUNC_ITEM =

STRING_ITEM foo

FIELD_ITEM pass

FUNC_ITEM =

STRING_ITEM f

FIELD_ITEM user

FIELD_ITEM name

... (...)

SELECT_FIELD name

FROM_TABLE users

user

=

admin 1

=

1

AND

COND_ITEM AND

FUNC_ITEM =

STRING_ITEM 1

FIELD_ITEM 1

FUNC_ITEM =

STRING_ITEM admin

FIELD_ITEM user

FIELD_ITEM name

... (...)

SELECT_FIELD name

FROM_TABLE users

user

=

admin 1

=

1

OR

COND_ITEM OR

FUNC_ITEM =

STRING_ITEM 1

FIELD_ITEM 1

FUNC_ITEM =

STRING_ITEM admin

FIELD_ITEM user

FIELD_ITEM name

... (...)

SELECT_FIELD name

FROM_TABLE users

user

=

Miguel pass

=

xpto

AND

COND_ITEM AND

FUNC_ITEM =

STRING_ITEM foo

FIELD_ITEM pass

FUNC_ITEM =

STRING_ITEM f

FIELD_ITEM user

FIELD_ITEM name

... (...)

SELECT_FIELD name

FROM_TABLE users

user

=

admin 1

=

1

AND

COND_ITEM AND

FUNC_ITEM =

STRING_ITEM 1

FIELD_ITEM 1

FUNC_ITEM =

STRING_ITEM admin

FIELD_ITEM user

FIELD_ITEM name

... (...)

SELECT_FIELD name

FROM_TABLE users

user

=

admin 1

=

1

OR

COND_ITEM OR

FUNC_ITEM =

STRING_ITEM 1

FIELD_ITEM 1

FUNC_ITEM =

STRING_ITEM admin

FIELD_ITEM user

FIELD_ITEM name

... (...)

SELECT_FIELD name

FROM_TABLE users

user

=

Miguel pass

=

xpto

AND

Figura 3.3: Estrutura de uma query alvo de um ataque SQLI estrutural de primeira ordem

COND_ITEM AND

FUNC_ITEM =

STRING_ITEM foo

FIELD_ITEM pass

FUNC_ITEM =

STRING_ITEM f

FIELD_ITEM user

FIELD_ITEM name

... (...)

SELECT_FIELD name

FROM_TABLE users

user

=

admin 1

=

1

AND

COND_ITEM AND

FUNC_ITEM =

STRING_ITEM 1

FIELD_ITEM 1

FUNC_ITEM =

STRING_ITEM admin

FIELD_ITEM user

FIELD_ITEM name

... (...)

SELECT_FIELD name

FROM_TABLE users

user

=

admin 1

=

1

OR

COND_ITEM OR

FUNC_ITEM =

STRING_ITEM 1

FIELD_ITEM 1

FUNC_ITEM =

STRING_ITEM admin

FIELD_ITEM user

FIELD_ITEM name

... (...)

SELECT_FIELD name

FROM_TABLE users

user

=

Miguel pass

=

xpto

AND

COND_ITEM AND

FUNC_ITEM =

STRING_ITEM foo

FIELD_ITEM pass

FUNC_ITEM =

STRING_ITEM f

FIELD_ITEM user

FIELD_ITEM name

... (...)

SELECT_FIELD name

FROM_TABLE users

user

=

admin 1

=

1

AND

COND_ITEM AND

FUNC_ITEM =

STRING_ITEM 1

FIELD_ITEM 1

FUNC_ITEM =

STRING_ITEM admin

FIELD_ITEM user

FIELD_ITEM name

... (...)

SELECT_FIELD name

FROM_TABLE users

user

=

admin 1

=

1

OR

COND_ITEM OR

FUNC_ITEM =

STRING_ITEM 1

FIELD_ITEM 1

FUNC_ITEM =

STRING_ITEM admin

FIELD_ITEM user

FIELD_ITEM name

... (...)

SELECT_FIELD name

FROM_TABLE users

user

=

Miguel pass

=

xpto

AND

Figura 3.4: Estrutura de uma query alvo de um ataque SQLI mımica de primeira ordem

estrutura das queries. E verificado que o field pass do template e alterado para um item do tipo inteiro.

Devido a esta diferenca entre a query e o respectivo template e identificado um ataque SQLI mımica

sendo reportada a sua ocorrencia.

3.2.3 Deteccao de inclusao de ficheiros locais e remotos

Para a deteccao de vulnerabilidades de inclusao de ficheiros locais e remotos foi desenvolvido um

mecanismo de monitorizacao que nao seja dependente de ferramentas externas para monitorizar os

recursos necessarios, neste caso, os ficheiros que sao alvo de inclusao por parte da aplicacao web.

Como tal, este tipo de vulnerabilidade e detectada no interpretador da linguagem do servidor (Figura 3.1)

extraindo informacao sobre os ficheiros incluıdos em cada chamada ao codigo relativa a uma funcao de

inclusao de ficheiro, por exemplo, na linguagem PHP as funcoes include e require.

37

Funcionamento geral

O mecanismo desenvolvido define um template de cada inclusao de ficheiros existente no codigo da

aplicacao alvo de teste. Este template pressupoe-se que e definido a partir de uma utilizacao benigna

da aplicacao em cada ponto de inclusao. O template e registado durante a primeira execucao de

determinada chamada a uma funcao de inclusao de ficheiros. Assim, o template define o comportamento

expectavel da aplicacao por parte de quem desenhou a mesma.

O objectivo deste mecanismo e verificar se as inclusoes seguintes estao de acordo com o respectivo

template.

Este template e generico de forma a abranger todos os inputs benignos, mas tambem restrito de

forma a excluir inputs maliciosos. Como tal, o template e constituıdo pelo path e extensao do ficheiro

que e incluıdo. No caso do ficheiro ser de proveniencia remota, o path inclui o protocolo do endereco

externo (ex: http://).

A razao para a escolha desses dois elementos como parte constituinte de um template de uma

funcao de inclusao de codigo assenta em dois princıpios:

• Quando um atacante pretende incluir um ficheiro local ou remoto este tem que alterar o path do

ficheiro respectivamente, atraves de path/directory traversal ou inclusao do protocolo do endereco

externo, enquanto numa utilizacao normal o path mantem-se ao longo das varias chamadas a uma

funcao de inclusao de ficheiros;

• Normalmente quando existe uma inclusao de ficheiros a extensao deste e constante ao longo

de varias execucoes, como tal de forma a prevenir que um atacante inclua ficheiros com outras

extensoes podendo incluir codigo malicioso, considera-se que a alteracao da extensao de ficheiro a

ser incluıdo e uma operacao perigosa tendo em conta a categoria de vulnerabilidades de inclusao

de ficheiros.

Para este mecanismo, tambem e necessario a existencia de uma fase de treino. Nesta fase, pretende-

se exercitar todas as chamadas a funcoes de inclusoes na aplicacao de forma a criar os respectivos

templates. Pretende-se comparar os templates com futuras execucoes a estas respectivas chamadas e

consequentemente identificar a existencia de vulnerabilidades caso estas existam.

Para detectar a exploracao de uma vulnerabilidade RFI/LFI, nas seguintes execucoes de determinada

chamada a uma funcao de inclusao de ficheiro compara-se o ficheiro incluıdo e o seu respectivo template.

Caso uma destas seguintes condicoes se verifique indica a existencia de uma vulnerabilidade:

• O path da inclusao em determinado ponto de codigo for diferente do path existente no template

respectivo;

• A extensao do ficheiro a ser incluıdo ser diferente do que esta referido no template respectivo.

Como referido anteriormente, caso uma destas condicoes se verifique, de seguida, o mecanismo

verifica se o ficheiro alvo de inclusao existe ou nao. Em caso afirmativo, notifica a exploracao da

vulnerabilidade. Caso contrario, avisa que a vulnerabilidade seria explorada caso existisse o ficheiro.

38

Esta notificacao e efectuada atraves de um log de ataques no qual regista a ocorrencia do ataque com

informacao relevante.

Este mecanismo alem da deteccao, caso seja activado, tambem permite a utilizacao deste em modo

preventivo no qual nega qualquer tentativa de inclusao de ficheiros que nao estejam de acordo com o

respectivo template.

Casos de deteccao

Esta solucao detecta eficazmente a existencia de vulnerabilidades LFI/RFI nos seguintes casos:

• Todas as tentativas de inclusoes de ficheiros locais ou remotos que tenham um path ou uma

extensao diferente do que o definido no template respectivo;

Limitacoes

Esta solucao nao consegue detectar eficazmente a existencia de vulnerabilidades LFI/RFI nos seguintes

casos:

• Inclusoes de ficheiros locais ou remotos maliciosos cujo path e extensao sao iguais aos que estao

definidos no template respectivo.

Log de ataques

Quando um ataque de inclusao de ficheiros locais ou remotos e detectado, independentemente se o

modo preventivo esta activado, o mecanismo regista informacao sobre o ataque num log. Em cada

nova ocorrencia de um ataque, no log e registado se este explorou a vulnerabilidade ou se existe a

possibilidade, atraves de um aviso, da vulnerabilidade ser explorada caso o ficheiro alvo de inclusao

existisse no servidor local ou remoto. Alem disso, tambem e registado informacao acerca do local na

aplicacao onde ocorreu a exploracao da vulnerabilidade para se proceder a correccao da mesma.

Exemplos

De forma a demonstrar o mecanismo em funcionamento, vai-se considerar o seguinte excerto de codigo

(Listagem 3.3) no qual efectua uma inclusao de um ficheiro tendo em conta o input fornecido. Para a

definicao do template e respectivo comportamento benigno do codigo considera-se o input xpto.txt

levando a inclusao do ficheiro correspondente. Nesta situacao, o template vai registar o path que

corresponde a directoria actual (.) e a extensao do ficheiro alvo de inclusao (txt).

Agora suponhamos uma situacao em que um atacante tenta explorar uma vulnerabilidade de inclusao

de ficheiros remotos, inserindo como input http://evil.com/evil.php no qual contem um script

malicioso. Nesta situacao, o mecanismo ao recolher a informacao relativa a inclusao, tem como path

http://evil.com e como extensao php. Dado que tanto o path e a extensao diferem do que foi definido

pelo template respectivo, o mecanismo vai notificar a existencia de uma vulnerabilidade neste ponto do

codigo como se pode observar na Figura 3.5. A mesma situacao ocorreria com a tentativa de inclusao

39

Figura 3.5: Exemplo de funcionamento do mecanismo de deteccao de ataques LFI/RFI

de um ficheiro local malicioso, desde que este alterasse o path ou a extensao do ficheiro alvo de inclusao

comparativamente ao que foi definido no template respectivo.

1 include($_GET[’nome’]);

Listagem 3.3: Exemplo de codigo vulneravel a LFI/RFI

3.2.4 Deteccao de cross-site scripting armazenado

Para detectar este tipo de ataque, sempre que e executada uma query, o mecanismo verifica se o

conteudo devolvido por esta contem codigo que possa ser interpretado por browsers. Esta deteccao e

efectuada no interior do interpretador da linguagem do servidor (Figura 3.1) e a analise de existencia de

codigo e feita atraves de um modulo de parsing que analisa a existencia de tags de codigo (ex: HTML,

JavaScript) no conteudo retornado.

Funcionamento geral

Como referido anteriormente, pretende-se verificar se o conteudo devolvido pelo processamento de uma

query de SQL contem codigo ou partes deste que possa ser interpretado por browsers web. Para ser

possıvel a identificacao desse codigo e necessario a utilizacao de um modulo para fazer parsing de

paginas HTML e linguagens similares. Este modulo tem como objectivo analisar o conteudo devolvido e

indicar se este contem codigo ou nao atraves da existencia de tags de HTML ou JavaScript.

Antes do conteudo ser analisado pelo modulo de parsing, devido ao facto que a maioria do conteudo

a analisar e inofensivo causando, assim, um overhead no desempenho, o mecanismo efectua uma pre-

verificacao. Esta pre-verificacao consiste na analise do conteudo em termos da existencia de caracteres

perigosos (ex: <, >) ou strings potencialmente perigosas (ex: href, javascript). Em caso afirmativo,

procede-se a analise com o modulo de parsing, caso contrario, dado que nao existem caracteres ou

strings perigosas como resultado da query nao e necessario analisar mais e como tal o mecanismo de

deteccao termina.

40

Apos esta pre-verificacao, como referido anteriormente, o modulo de parsing analisa o conteudo

que e devolvido pela query e verifica se existe alguma tag de codigo que pode ser interpretado por

browsers web. Em caso afirmativo, o mecanismo notifica a existencia de um ataque de cross-site

scripting armazenado e regista a respectiva ocorrencia no log de ataques.

Alem disso, e para nao afectar o desempenho do interpretador, o mecanismo quando identifica pela

primeira vez a existencia de codigo no conteudo alvo de analise notifica imediatamente a existencia da

vulnerabilidade e nao analisa o restante.

Casos de deteccao

Esta solucao detecta eficazmente a existencia de uma vulnerabilidade cross-site scripting armazenado

nos seguintes casos:

• Conteudo retornado por uma query SQL no qual e identificado caracteres ou strings especiais e

que e considerado como codigo HTML ou JavaScript pelo modulo de parsing.

Limitacoes

Esta solucao nao consegue detectar eficazmente a existencia de uma vulnerabilidade cross-site scripting

armazenado nos seguintes casos:

• Conteudo retornado por uma query SQL no qual nao sao identificados caracteres ou strings

especiais mas que e considerado como codigo;

• Conteudo retornado por uma query SQL no qual sao identificados caracteres ou strings especiais e

que nao e considerado como codigo HTML ou JavaScript pelo modulo de parsing mas na verdade

contem codigo.

Log de ataques

Quando um ataque deste tipo e detectado o mecanismo regista informacao sobre este num log. Em

cada ocorrencia e registado no log a data e hora em que o ataque ocorreu e o respectivo identificador da

query que retornou dados que continham codigo e que explora esta vulnerabilidade. Alem disso, retorna

o conteudo alvo de analise que fez despoletar a identificacao deste ataque por parte do mecanismo de

forma a facilitar a compreensao das razoes pela qual a vulnerabilidade foi explorada.

Exemplos

Para demonstrar o funcionamento deste mecanismo, de seguida, vai ser apresentado um excerto de

codigo (Listagem 3.4) no qual recebe um input proveniente do utilizador, insere-o na base de dados e de

seguida retorna-o atraves de queries MySQL:

41

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 codigo vulneravel a XSS armazenado

Numa situacao normal de funcionamento inseriam-se os seguintes dados na aplicacao web vulneravel:

Title="Hello!", Content="Hello World". Nesta situacao, o mecanismo nao detecta nenhum dos

caracteres perigosos da pre-verificacao e como tal, termina a verificacao. Um exemplo malicioso seria a

insercao dos seguintes dados: Title="Hello!", Content=<script>alert("XSS")</script>; Nesta

situacao, quando os dados sao retornados, o mecanismo na fase de pre-verificacao encontra os

caracteres perigosos, prosseguindo para a analise com o modulo de parsing. Ao analisar-se atraves

do modulo de parsing, e identificado codigo JavaScript devido as tags de script existentes no conteudo

retornado, sendo assim, identificado uma vulnerabilidade de cross-site scripting armazenado.

3.2.5 Deteccao de cross-site scripting reflectido

Este mecanismo detecta a existencia de um ataque se ao enviar um script como input a aplicacao

web se este e reflectido como resposta por parte da mesma. Esta deteccao e efectuada no interior do

fuzzer (Figura 3.1) dado que e o componente que interage com a aplicacao web alvo de teste e como tal

consegue aceder ao conteudo dos pedidos efectuados e das respectivas respostas.

Antes de serem enviados os inputs a aplicacao, estes precisam de ser analisados em termos de

existencia de codigo (ex: HTML, JavaScript). Em caso afirmativo, o mecanismo procede ao envio do

pedido HTTP a aplicacao alvo com o respectivo input. Caso contrario, como o input a ser enviado

nao contem codigo tambem nao vai afectar a resposta devolvida. De seguida, e analisada a resposta

devolvida pela aplicacao.

Esta analise verifica se a resposta contem uma parte significativa do input enviado, atraves do

algoritmo Smith-Waterman [41]. Este algoritmo, usualmente utilizado na area da biologia computacional,

efectua um alinhamento local entre duas sequencias de caracteres. Este algoritmo funciona atraves

de um sistema de pontuacoes: sao adicionados pontos entre emparelhamentos entre dois caracteres

iguais e sao deduzidos em caso contrario. As pontuacoes podem ser diferentes consoante os caracteres,

por exemplo, os caracteres < e > tem uma pontuacao superior comparativamente aos outros, devido a

sua importancia. Alem disso, tambem podem ser deduzidos pontos caso seja necessario adicionar um

intervalo entre duas partes da sequencia de forma ao restante destas ficar alinhado. Deste algoritmo

sao obtidas as sub-sequencias de caracteres com maior similaridade, ou seja, cuja pontuacao e mais

elevada.

Para a deteccao da vulnerabilidade de cross-site scripting reflectido, o algoritmo efectua um alinha-

mento local entre o input e a respectiva resposta, por forma a obter a sub-sequencia da resposta que

42

tem uma maior similaridade com o input enviado. Caso a pontuacao obtida pelo algoritmo seja perfeita,

ou seja, a sub-sequencia corresponde integralmente ao input enviado, significa que este foi totalmente

reflectido sendo notificado a existencia de uma vulnerabilidade cross-site scripting reflectido. Caso

a pontuacao obtida nao seja perfeita, mas seja superior a um limiar parametrizado analisa-se a sub-

sequencia da resposta obtida. Esta analise, consiste em verificar se existe codigo nessa sub-sequencia

da mesma forma que se efectuou com input antes de ser enviado. Em caso afirmativo, e notificada a

existencia da vulnerabilidade. Caso contrario, considera-se que a aplicacao alterou significativamente o

input de forma a este nao explorar uma vulnerabilidade.

Casos de deteccao

Esta solucao detecta eficazmente a existencia de uma vulnerabilidade cross-site scripting reflectido nos

seguintes casos:

• Todos os inputs contendo codigo e cuja a respectiva resposta contem uma sub-sequencia resultante

do algoritmo Smith-Waterman que corresponde ao input enviado. Esta sub-sequencia deve ter um

numero de alteracoes inferior a um limiar parametrizado definido pelo mecanismo e deve conter

codigo.

Limitacoes

Esta solucao nao consegue detectar eficazmente a existencia de uma vulnerabilidade cross-site scripting

reflectido nos seguintes casos:

• Pode haver falhas na identificacao de codigo no input ou na sub-sequencia resultante da resposta

por parte do mecanismo de analise do conteudo;

• Existencia de alteracoes significativas da resposta tendo em conta o input enviado e nao ser

identificado pelo mecanismo a vulnerabilidade mas mesmo assim, este ter desencadeado um

ataque com sucesso sobre a aplicacao;

Log de ataques

Quando um ataque de cross-site scripting reflectido e detectado o mecanismo regista informacao

sobre o ataque num log. Em cada nova ocorrencia, no log e registado se houve uma exploracao da

vulnerabilidade, caso o input seja integralmente reflectido, ou se existe a possibilidade da exploracao

da vulnerabilidade, caso a resposta contenha uma parte significativa do input, atraves do algoritmo

Smith-Waterman e que esta contenha codigo. Alem disso, tambem sao registados os parametros e os

respectivos inputs que foram enviados a aplicacao alvo de teste para facilitar a analise das causas da

exploracao da vulnerabilidade.

43

Exemplos

Para demonstrar o funcionamento deste mecanismo de deteccao consideremos o seguinte excerto de

codigo PHP vulneravel (Listagem 3.5). Neste excerto de codigo, e enviado como resposta uma string

que contem conteudo proveniente do input do utilizador.

1 $nome = $_GET[’nome’];

2 echo "Bem vindo".$nome;

Listagem 3.5: Exemplo de codigo vulneravel a XSS reflectido

Uma situacao normal de funcionamento deste excerto de codigo seria inserir como input a string

Miguel. Nesta situacao nao seria detectado a existencia de codigo no input e como tal este nao e

enviado a aplicacao.

Suponhamos que e enviado o conteudo malicioso <script>alert("XSS")</script>. Nesta

situacao, e identificado no input a existencia de codigo devido a existencia das tags de script en-

viando, assim, o input a aplicacao. Ao receber a respectiva resposta, esta e analisada e e identificado,

atraves do algoritmo de Smith-Waterman, que o input foi integralmente reflectido na resposta notificando,

assim, a existencia de uma vulnerabilidade na aplicacao.

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 espacos em branco deste:

1 $nome = preg_replace(’/\s+/’, ’’, $_GET[’nome’]);

2 echo "Bem vindo".$nome;

Listagem 3.6: Exemplo de codigo vulneravel a XSS reflectido

Um exemplo de tentativa de exploracao de uma vulnerabilidade deste genero seria atraves do

conteudo <script> alert("XSS") </script> como input. Nesta situacao, seria inicialmente iden-

tificado como codigo o input a ser enviado e como tal procederia-se ao envio do mesmo a aplicacao.

Ao receber a resposta, esta e analisada, atraves do algoritmo Smith-Waterman e constata-se que a

sub-sequencia da resposta mais semelhante ao input seria a string <script>alert("XSS")</script>

devido a remocao dos espacos em branco. Dado que esta sub-sequencia resultante, contem codigo

e esta acima do limiar de similaridade para ser considerada como um ataque, o mecanismo notifica a

possibilidade da existencia de uma vulnerabilidade de cross-site scripting reflectido.

3.2.6 Deteccao de outras vulnerabilidades

Como referido na Figura 3.1, a framework pode ser estendida para detectar outras vulnerabilidades

usualmente existentes em aplicacoes web. Essas vulnerabilidades podem-se categorizar consoante

o componente back-end que interage com a aplicacao web. Os componentes visados sao o sistema

operativo no qual se detecta a vulnerabilidade de injeccao de comandos de SO (OSCI), o interpretador da

linguagem do servidor onde se detecta a vulnerabilidade de injeccao de codigo e o sistema de ficheiros

onde se inserem as seguintes vulnerabilidades: directory/path traversal, source code disclosure.

44

A framework pretende analisar e monitorizar os sensitive sinks relacionados com cada umas vul-

nerabilidades que se pretende detectar e com a informacao recolhida atraves da monitorizacao, tirar

ilacoes sobre a exploracao de determinada vulnerabilidade. De seguida, vai ser explicado mais porme-

norizadamente a forma como a framework pode ser estendida para a deteccao de cada uma destas

vulnerabilidades visadas referindo uma possıvel abordagem para a sua implementacao.

Deteccao de injeccao de comandos de SO

Para a deteccao de uma vulnerabilidade de injeccao de comandos de sistema operativo, seria necessario

efectuar a monitorizacao sobre as funcoes encarregues de executar comandos de sistema operativo no

interpretador da linguagem do servidor (Figura 3.1). Tambem, como alternativa, a monitorizacao pode

ser efectuada nas funcoes relativas ao parsing dos comandos na shell no servidor.

Esta monitorizacao tem como objectivo recolher informacao relativa a estrutura dos comandos de

sistema operativo executados pela aplicacao alvo de teste em determinada chamada a um sensitive sink

relativo a esta vulnerabilidade.

Com a obtencao desta estrutura, efectua-se a comparacao entre a estrutura obtida e o respectivo

template, ou seja, o modelo benigno daquela chamada a uma funcao de execucao de comandos de SO

e verificar se existem diferencas entre as duas. Em caso afirmativo, indica a existencia da exploracao de

uma vulnerabilidade de injeccao de comandos de SO.

Deteccao de injeccao de codigo

Dado que a linguagem do servidor utilizada na implementacao e o PHP, vai-se considerar respectiva-

mente, a deteccao de ataques de injeccao de codigo PHP atraves do comando eval. Para detectar uma

vulnerabilidade deste tipo seria necessario monitorizar ao nıvel do interpretador da linguagem servidor

(Figura 3.1), nas funcoes que estao encarregues de implementar esse comando. Como na maioria dos

mecanismos de deteccao explicitados, pretende-se obter a estrutura esperada em determinada chamada

a funcao eval na aplicacao proveniente de inputs benignos, definindo-se como template.

De seguida, pretende-se comparar este template gerado anteriormente com futuras chamadas a esta

funcao, verificando-se, assim, se existem diferencas entre o template gerado e a estrutura obtida nas

execucoes seguintes. Em caso afirmativo, indica a exploracao de uma vulnerabilidade de injeccao de

codigo PHP na aplicacao.

Deteccao de directory/path traversal

Para efectuar a deteccao de vulnerabilidades do tipo directory/path traversal (DT/PT) seria necessario

modificar ao nıvel das funcoes de leitura de ficheiro, como se efectuou tambem para o caso da deteccao

da vulnerabilidade de inclusao de ficheiros locais ou remotos, efectuando a monitorizacao no interpretador

da linguagem do servidor (Figura 3.1).

Como tal, pretende-se recolher informacao proveniente de inputs benignos, mais especificamente, o

path e extensao do ficheiro alvo de determinada chamada a uma funcao na qual pode ser explorada

45

este tipo de vulnerabilidade, em semelhanca a deteccao de vulnerabilidades RFI/LFI, definindo-se como

template. Assim, e possıvel verificar se os ficheiros que sao passados como parametros a essas funcoes

em causa se estao de acordo com o respectivo template, isto quer dizer, se possuem o mesmo path

e extensao. Em caso afirmativo, indica que o ficheiro passado como parametro esta de acordo com o

modelo gerado atraves inputs benignos e como tal nao tenta explorar este tipo de vulnerabilidade. Em

caso contrario, indica que determinado ficheiro alvo a ser passado como parametro pretende explorar

este tipo de vulnerabilidade pois tem um path ou extensao diferentes ao que foi definido atraves inputs

benignos no template.

Deteccao de source code disclosure

Para detectar a vulnerabilidade de source code disclosure seria necessario monitorizar ao nıvel das

funcoes de leitura de ficheiros no interpretador da linguagem do servidor (Figura 3.1). Baseando-se no

mesmo princıpio de deteccao das vulnerabilidades LFI/RFI e DT/PT, pretende-se efectuar um template

atraves de uma primeira execucao, armazenando o path e extensao do ficheiro alvo da chamada a

determinada funcao relativa a esta vulnerabilidade. Este template tem como objectivo, representar o

funcionamento esperado pela aplicacao em determinado ponto tendo em conta inputs benignos.

Com esse template, pretende-se verificar se os ficheiros incluıdos nessa mesma chamada se estao

de acordo com o template, ou seja, se tem um path e uma extensao iguais. Caso haja alguma diferenca,

indica a existencia de uma vulnerabilidade de source code disclosure na aplicacao alvo de teste.

46

Capıtulo 4

Implementacao

Este capıtulo explica como e que os varios componentes da framework foram implementados, nomeada-

mente, o fuzzer e os mecanismos de deteccao das vulnerabilidades de injeccao de SQL, inclusao de

ficheiros locais/remotos e cross-site scripting reflectido/armazenado. Na Figura 4.1 esta 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

(versao 2.4) 1. Esta ferramenta e constituıda por um fuzzer e tambem por uma biblioteca que contem

varias classes que permitem a implementacao de um fuzzer contendo varias funcionalidades, por

exemplo: vectores de fuzzing ou fuzzing de varios parametros em simultaneo. Dado que o fuzzer nao

contem mecanismos de monitorizacao de ataques foi necessario recorrer-se a biblioteca deste para criar

um fuzzer de forma a incluir o mecanismo de deteccao de ataques de cross-site scripting reflectido.

Dado que a biblioteca apenas permite a criacao de inputs de fuzzing e descura o aspecto do

envio destes para aplicacao alvo de teste tambem foi necessario implementar outras funcionalidades:

mecanismo de mutacao dos inputs; envio de pedidos HTTP com os inputs gerados; mecanismo para

colocar a aplicacao em determinado estado de execucao. Em relacao aos vectores de fuzzing foram

compiladas listas para as vulnerabilidades que se pretende explorar provenientes de varias fontes de

forma a ser o mais abrangente possıvel nas tentativas de ataque contemplado casos de ataques simples

como tambem casos mais complexos.

4.1.1 Mecanismo de definicao do estado de execucao da aplicacao

Uma aplicacao web passa por diversos estados, sendo que so alguns dos quais sao vulneraveis. Por

isso, ao usar fuzzing para detectar vulnerabilidades numa aplicacao, e importante faze-la percorrer os

seus diversos estados e fazer fuzzing de todos os vectores em cada um deles. A implementacao actual

1https://www.owasp.org/index.php/JBroFuzz

47

Figura 4.1: Arquitectura da framework representado os componentes de monitorizacao implementados

do fuzzer contem um mecanismo que permite definir, manualmente, um conjunto de pedidos HTTP que

coloquem a aplicacao web num determinado estado ou para efectuar reset ao estado da aplicacao apos

o envio de determinado input do fuzzer. Assim, e possıvel definir os pedidos HTTP que vao definir o

estado da aplicacao atraves de um ficheiro de texto contendo a estrutura apresentada na Listagem 4.1.

1 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 definicao de estados

Como se pode observar na Listagem 4.1, e possıvel caracterizar um pedido HTTP pelo seu tipo

(GET/POST), url, parametros e cookies caso sejam necessarios. Num ficheiro deste tipo, e possıvel

definir qualquer numero de pedidos HTTP desde que estejam de acordo com a estrutura referida

anteriormente.

De forma a facilitar a compreensao deste mecanismo, vai ser explicado o funcionamento deste

mecanismo atraves de um exemplo de uma aplicacao que contem dois estados: nao autenticado e

autenticado. Esta aplicacao necessita de autenticacao por parte do utilizador de forma a poder-se enviar

uma mensagem a aplicacao sendo esta reflectida integralmente, podendo assim, ser possıvel explorar

uma vulnerabilidade de cross-site scripting reflectido como se pode observar no Apendice A. Caso

contrario, nao e possıvel aceder a esta funcionalidade. Assim, para testar-se a aplicacao alvo de teste e

necessario enviar os inputs provenientes do fuzzer nos dois estados existentes de forma a conseguir-se

48

detectar a vulnerabilidade.

Para testar o estado nao autenticado, nao e necessario enviar quaisquer inputs de forma a colocar a

aplicacao nesse estado, logo para testar, so e necessario o fuzzer enviar os inputs contidos nos seus

vectores de fuzzing e posteriormente verificar se foram detectadas algumas vulnerabilidades. Como

referido anteriormente, neste caso, nao vao ser detectados quaisquer vulnerabilidades na aplicacao.

Para testar o estado autenticado, e necessario colocar a aplicacao num determinado estado, corres-

pondendo ao processo de login nesta. Para isso e necessario, utilizar o mecanismo desenvolvido para

definicao de estados na aplicacao e definir, manualmente, o pedido HTTP que corresponde ao login na

aplicacao como pode ser observado na Listagem 4.2. Assim, o fuzzer antes de enviar cada um dos seus

inputs proveniente de vectores de fuzzing encarrega-se de enviar o pedido de login na aplicacao, para

que no momento de teste, os inputs enviados estejam a exercitar a aplicacao no estado autenticado.

Neste caso, vai ser detectado uma vulnerabilidade de cross-site scripting reflectido, por exemplo, atraves

do input <video><source onerror="alert(’Muahahah’)">.

Posteriormente, e tambem com o uso do mecanismo de definicao de estados, vai-se definir, manual-

mente, o pedido HTTP que corresponde ao logout da aplicacao de forma a efectuar reset ao estado

apos o envio do input proveniente do fuzzer como se pode observar na Listagem 4.3.

1 BEGIN−HTTP

2 POST

3 URL h t t p : / / l o c a l h o s t / l o g i n . php

4 PARAMS name=Miguel

5 COOKIE PHPSESSID=77a3cca8f19e1ff36efbe34f278d1914

6 END−HTTP

Listagem 4.2: Definicao do pedido de prestate HTTP no mecanismo de definicao de estados

implementado que representa o processo de fazer login

1 BEGIN−HTTP

2 POST

3 URL h t t p : / / l o c a l h o s t / logou t . php

4 PARAMS logou t =1

5 COOKIE PHPSESSID=77a3cca8f19e1ff36efbe34f278d1914

6 END−HTTP

Listagem 4.3: Definicao do pedido de reset HTTP no mecanismo de definicao de estados implementado

que representa o processo de fazer logout

Como referido anteriormente, o mecanismo desenvolvido necessita de uma interaccao com o utilizador

de forma a definir o estado. Caso se pretenda que este mecanismo de estados seja mais expedito, o

fuzzer pode ser estendido com um mecanismo de inferencia de estados baseado na solucao de Dupe et

al. [42] ou no sistema LigRE [43].

49

4.2 Deteccao de injeccao de SQL

Para implementar este mecanismo, foi necessario modificar o sistema de gestao de base de dados

MySQL (versao 5.7.4), mais especificamente a funcao de parsing (mysql parse - ficheiro sql parser.cc)

adicionando um total de 14 linhas de codigo. Tambem foi criado um ficheiro header com 1098 linhas

de codigo que implementam o mecanismo de deteccao e permite efectuar a analise das estruturas das

queries processadas pelo SGBD. Atraves destas alteracoes e possıvel detectar variados ataques de

injeccao de SQL.

O mecanismo recebe uma query pre-processada e alvo de parsing pelo MySQL, recolhendo a

estrutura da mesma. Caso esta query tenha sido executada pela primeira vez, a estrutura da mesma vai

ser armazenada pois representa o template da respectiva query. Caso contrario, a estrutura recolhida

vai ser comparada com o respectivo template procurando diferencas entre as duas. Opcionalmente, o

mecanismo pode registar ou rejeitar a execucao de uma query caso um ataque de injeccao de SQL seja

detectado pelo mecanismo.

Para armazenar as estruturas das queries e variaveis de controlo e de configuracao do mecanismo

(ex: deteccao da vulnerabilidade activada/desactivada) foi necessario criar uma estrutura de dados em

pilha.

Para efectuar estas tarefas referidas anteriormente, no ficheiro sql parser.cc adicionou-se a funcao

mysql parse um numero reduzido linhas de codigo com o proposito de obter a estrutura da query para

ser analisada pela funcao compareQueryStructure, existente no ficheiro header, antes de ser executada

atraves da funcao mysql execute command. Esta funcao, como o proprio nome indica, executa a query

na base de dados. O mecanismo de deteccao e chamado nesse ponto de execucao porque: (1) apos a

fase de pre-procesamento o DBMS efectua descodificacao sobre a codificacao dos caracteres e outros

processos de uniformizacao do conteudo recebido (ex: evasao de caracteres de espaco); (2) apos a

fase de parsing o DBMS permite recolher a estrutura da query com os seus elementos que a compoem,

permitindo aceder a essa informacao, analisar e identificar ataques; (3) e no momento antes da execucao

da query e que e possıvel efectuar accoes sobre a query caso exista um ataque, por exemplo, prevenir o

seu processamento bloqueando este.

A funcao compareQueryStructure invoca as funcoes processSelect Lex e insertElementTemplate

de forma a verificar o tipo de uma query (SELECT, DELETE, INSERT, UPDATE) e inserir os dados na sua

estrutura. Esta funcao tambem retorna o identificador da query e verifica se existe algum template para

esse identificador. Caso nao exista, a estrutura analisada e considerada um template e e armazenada no

mecanismo. Caso contrario, o template e carregado e e efectuado a chamada a funcao compareQueryTo-

Template que contem dois passos. O primeiro passo, verifica se o numero de items em ambas estruturas

sao iguais. Caso nao sejam, e detectado uma injeccao de SQL, caso contrario prossegue-se para o

passo seguinte. Neste segundo passo, e invocado a funcao processItem, cujo objectivo, e processar

cada item da estrutura da query e comparar com o seu respectivo item no template. Caso pelo menos

uma destas comparacoes entre pares de items nao corresponda e identificado um ataque de injeccao de

SQL.

50

A funcao processItem analisa os 27 tipos diferentes de items que sao definidos pelo MySQL utilizando

duas funcoes auxiliares (processField e isPrimitiveTypeBenign) para detectar diferencas entre fields e

para verificar se determinado item e do tipo primitivo (inteiro, real, string ou decimal).

Tambem foi necessario concatenar as queries executadas um identificador unico em forma de

comentario, para que seja possıvel identificar qual o ponto do codigo da aplicacao alvo de teste onde

foi efectuada determinada query, permitindo ao programador conseguir perceber atraves de analise do

codigo o porque da existencia da vulnerabilidade. Caso nao exista este identificador na query, o MySQL

continua a funcionar normalmente apenas nao e alvo do mecanismo de deteccao.

A implementacao actual deste mecanismo apenas permite a analise da estrutura de queries que

contenham as seguintes clausulas: SELECT, INSERT INTO, UPDATE, FROM, WHERE, HAVING, ORDER BY,

GROUP BY. Como tal, o mecanismo nao consegue, actualmente, identificar diferencas estruturais nas

queries que usem clausulas que nao as referidas anteriormente, podendo essa analise sobre outros

tipos de clausulas ser estendida para futuras implementacoes da framework.

4.3 Deteccao de inclusao de ficheiros locais e remotos

De forma a implementar este mecanismo, foi necessario modificar o interpretador do PHP (versao 5.5.12),

mais especificamente o Zend Engine. Estas modificacoes centraram-se nas funcoes do Zend Engine

que implementam as funcoes de inclusao de ficheiros na linguagem PHP (ex: include, include once,

require e require once) para que possa ser possıvel extrair os ficheiros alvos da inclusao e recolher a

informacao necessaria a deteccao deste tipo de vulnerabilidade.

A funcao onde foi necessaria efectuar essas alteracoes no interpretador da linguagem PHP foi

compile file (zend language scanner.c), alterando um total de 112 linhas de codigo. Esta funcao recebe

como argumento um ficheiro que vai ser compilado pelo PHP, neste caso, os ficheiros alvo de inclusao

por parte da aplicacao. Foi necessario acrescentar um identificador a cada chamada a uma funcao de

inclusao para se saber qual foi o ponto do codigo onde foi efectuada determinada inclusao. Caso nao

exista este identificador, o PHP continua a funcionar normalmente apenas nao e alvo do mecanismo de

deteccao.

Para a extraccao da informacao relativa ao identificador de cada chamada a uma funcao de inclusao,

foi necessario modificar o ficheiro zend vm execute.h alterando um total de 116 linhas de codigo. Com a

alteracao desta funcao, e possıvel tirar ilacoes sobre a existencia do ficheiro alvo de inclusao pois esta

funcao pode retornar valores que indiquem a nao existencia do mesmo. Com esta nova informacao e

possıvel efectuar a distincao entre o aviso de possıvel existencia da vulnerabilidade caso o ficheiro exista

e quando ocorre verdadeiramente a exploracao da vulnerabilidade devido a inclusao de um ficheiro

malicioso.

Os templates necessarios para comparar com futuras chamadas a funcoes de inclusoes sao armaze-

nados de forma permanente atraves de ficheiros contendo a informacao necessaria relevante.

51

4.4 Deteccao de cross-site scripting armazenado

Para implementar este mecanismo, modificou-se o Zend Engine (versao 5.5.12). A modificacao centrou-

se na funcao do interpretador que implementa a funcao mysql query da linguagem PHP, mais especi-

ficamente, a funcao php mysql do query general. Sobre esta funcao, foram alteradas um total de 72

linhas de codigo para implementar o mecanismo de deteccao desta vulnerabilidade atraves da analise

do conteudo devolvido pelas queries.

Para efectuar a analise do conteudo devolvido pelas queries e necessario verificar se neste existe

algum codigo, por exemplo, HTML ou JavaScript contido. Para tal, e utilizado um modulo de parsing

programado em Java (antixss.jar ) que utiliza uma biblioteca de parsing de codigo deste genero, nome-

adamente, jsoup (versao 1.7.3) 2. Como referido anteriormente, esta biblioteca tem como proposito

efectuar parsing de paginas HTML e de outras linguagens ligadas a esta (ex: JavaScript, CSS) tendo em

conta a existencia de tags com as quais consegue estruturar o codigo. Para a identificacao de codigo,

o mecanismo fornece o conteudo a analisar ao jsoup e este insere-o numa pagina dummy de HTML,

representada pelas tags <html><head><body> no qual vai fazer parsing. Com a estrutura obtida, verifica

se existe pelo menos mais uma tag de codigo alem das existentes na pagina dummy. Em caso afirmativo,

isto quer dizer que o conteudo alterou a estrutura e como tal contem codigo. Caso contrario, o conteudo

inserido nao altera a estrutura do codigo ja existente e nao e considerado como codigo.

4.5 Deteccao de cross-site scripting reflectido

Para implementar este mecanismo de deteccao, foi utilizada novamente a biblioteca jsoup (versao 1.7.3),

mas desta vez integrada no fuzzer, como se pode ver na Figura 4.1. O uso do jsoup tem como objectivo

verificar a existencia de codigo nos inputs enviados ou na sub-sequencia resultante pelo algoritmo

Smith-Waterman.

Em relacao ao algoritmo Smith-Waterman este foi implementado em linguagem Java sendo integrado

com o mecanismo de deteccao. Para o correcto funcionamento deste algoritmo tendo em conta a

deteccao que se pretende fazer foi necessario configura-lo com determinados valores de pontuacao de

concordancia e discordancia entre caracteres das duas sequencias a comparar para que o tornasse mais

toleravel a certos caracteres e menos toleravel a outros. Tambem, foi necessario definir a percentagem

de similaridade entre a pontuacao obtida e a pontuacao perfeita para considerar determinado input como

um ataque.

De seguida e explicada a configuracao utilizada pelo mecanismo de deteccao. Quando existe uma

concordancia (case sensitive) entre caracteres nas duas sequencias e adicionada uma pontuacao de 5

unidades. Quando existe uma discordancia esta pode ser de tres tipos:

• Quando a discordancia se refere a inclusao de um espaco em branco para a sub-sequencia estar

alinhada sao deduzidas 2 unidades. A razao para tal deducao e que esta operacao e toleravel

2http://www.jsoup.org

52

devido a possıveis processos de eliminacao de caracteres de espaco por parte da aplicacao. Esta

deducao e linear consoante o numero de espacos em branco que sejam necessarios adicionar;

• Quando a discordancia se refere a dois caracteres que sejam diferentes entre si mas que nao

sejam os caracteres < e > sao deduzidas 5 unidades a pontuacao obtida, sendo esta deducao

linear ao numero de caracteres que estao em discordancia;

• Quando a discordancia se refere a dois caracteres que sejam diferentes entre si, no qual num

deles estao incluidos os caracteres < e > sao deduzidas 25 vezes as unidades deduzidas no

ponto anterior a pontuacao obtida. Esta deducao e linear ao numero de caracteres que estao em

discordancia. A razao do valor elevado de penalizacao deve-se a importancia destes caracteres

neste tipo de vulnerabilidade pois estes podem ser utilizados como codigo. Quando existe uma

discordancia deste tipo, geralmente significa que a aplicacao filtrou o input atraves de processos

de validacao, sanitizacao ou codificacao.

Por fim, definiu-se que so e considerado que certo input explorou uma vulnerabilidade de cross-site

scripting reflectido quando a pontuacao obtida atraves do algoritmo Smith-Waterman e superior a 95%

da pontuacao perfeita, ou seja, pontuacao obtida caso haja concordancia em todos os caracteres entre

as duas sequencias comparadas pelo algoritmo.

53

Capıtulo 5

Avaliacao Experimental

O sistema desenvolvido foi avaliado perante amostras de codigo vulneravel (Subseccao 5.1) e aplicacoes

open source (Subseccao 5.2). Em ambas as avaliacoes efectuadas, foi necessario uma fase de treino de

forma a exercitar o codigo alvo de teste com inputs benignos para que fosse possıvel gerar os templates

necessarios para a deteccao das vulnerabilidades existentes.

Para avaliar a framework contabilizaram-se o numero de vulnerabilidades que foram detectadas com

sucesso por esta. No caso das amostras de codigo vulneravel, procedeu-se a uma comparacao entre

o numero de vulnerabilidades detectadas e as existentes nas mesmas. No caso das aplicacoes open

source, procedeu-se a uma contabilizacao das vulnerabilidades detectadas pela framework.

Alem disso, tambem se avaliou o mecanismo de deteccao de ataques de injeccao de SQL tendo em

conta o conceito definido por Ray e Ligatti sobre ataques de injeccao de codigo. No trabalho de Ray

e Ligatti [6], definiram 11 casos de teste que suportam a sua definicao. Sendo assim, o mecanismo

desenvolvido foi avaliado atraves destes casos de teste. Alem disso, o mecanismo foi comparado com

outras ferramentas de deteccao deste tipo de ataque que tambem compararam os seus resultados com

esta definicao.

5.1 Avaliacao com amostras de codigo

A subseccao apresenta os resultados da avaliacao do sistema desenvolvido perante um conjunto

de amostras de codigo cujas vulnerabilidades estao bem identificadas e documentadas. Uma parte

deste conjunto de amostras de codigo foi sendo desenvolvida em paralelo com a framework de modo

a permitir testa-la. Este conjunto de amostras de codigo contem um total de 11 ficheiros com 14

vulnerabilidades identificadas como existentes. As vulnerabilidades existentes neste conjunto, foram

colocadas intencionalmente e foram testadas de forma manual a sua exploracao para poderem ser

contabilizadas como tal, antes de serem alvo de teste por parte da framework.

A outra parte foi constituıda por amostras de codigo provenientes do NIST Software Assurance

Reference Dataset Project 1. As vulnerabilidades existentes sao justificadas atraves de um input de

1http://samate.nist.gov/SARD/

55

Vulnerabilidades Testes Framework (11 ficheiros) Samate (7 ficheiros)Encontradas Existentes Encontradas Existentes

SQLI 4 4 2 2LFI 3 3 2 2RFI 2 2 2 2XSS reflectido 4 4 5 5XSS armazenado 1 1 0 0Total 14 14 11 11

Tabela 5.1: Resumo dos resultados obtidos pela framework com um conjunto de amostras de codigovulneravel

exemplo que explora a vulnerabilidade e tambem atraves da descricao da vulnerabilidade em causa

tendo em conta a especificacao definida no CWE 2.

Constatou-se que uma parte destas amostras continha informacao bastante reduzida ou incorrecta,

pois indicavam que eram vulneraveis quando na verdade, apos analise das mesmas, nao eram, sendo

assim, excluıdas da avaliacao. Alem disso, haviam amostras validas que continham mais vulnerabilidades

do que as indicadas, tendo estas sido testadas manualmente, de forma a verificar a existencia destas e

a considera-las como tal. No total, este conjunto de amostras de codigo contem no total 7 ficheiros com

11 vulnerabilidades identificadas como existentes.

Alem disso, em ambos conjuntos de amostras de codigo usadas para testar a framework, nao sao

considerados a existencia de estados. Como tal, nesta avaliacao nao foi necessario recorrer-se ao

mecanismo de definicao do estado de execucao da aplicacao existente no fuzzer.

A Tabela 5.1 apresenta os resultados obtidos pela framework perante estas amostras de codigo,

dividindo-os pela fonte e em termos de cada tipo de vulnerabilidade detectada. Observa-se que todas as

vulnerabilidades existentes nestas amostras de codigo vulneravel foram detectadas com sucesso.

De seguida e apresentado um exemplo de uma amostra de codigo proveniente da amostra de

dados do Samate (Listagem 5.1) cujo codigo e vulneravel a LFI e RFI. A framework detectou com

sucesso ambas as vulnerabilidades. A vulnerabilidade ocorre devido a falta de processos de validacao,

sanitizacao ou codificacao do input recebido fazendo com que seja possıvel incluir qualquer ficheiro,

inclusive maliciosos, no codigo da aplicacao. As vulnerabilidades foram detectadas atraves do envio de

vectores de fuzzing, por exemplo, /var/log/apache2/error log e http://localhost/evil.txt que

detectaram respectivamente as vulnerabilidades de LFI e RFI.

1 <html>

2 <head></head>

3 <body>

4 <a h re f = ’ ?page=index . i nc ’>Index</a> : : <a h re f = ’ ?page= l i n k s . i nc ’>Links </a><br />

5 <h1>My Web Page</h1>

6 This i s my main template .<br />

7 <?php

8 $page = ” index . i nc ” ;

9 i f ( i s s e t ( $ GET [ ’ page ’ ] ) && s t r l e n ($ GET [ ’ page ’ ] ) > 0)

10 $page = $ GET [ ’ page ’ ] ;

2http://cwe.mitre.org/

56

11 i nc lude ( $page ) ;

12 ?>

13 </body>

14 </html>

Listagem 5.1: Excerto de codigo vulneravel na amostra de dados do Samate

5.2 Avaliacao com aplicacoes open source

Nesta subseccao apresentam-se os resultados obtidos pelo sistema desenvolvido perante um conjunto

de aplicacoes open source em termos do numero de vulnerabilidades detectadas. As aplicacoes

escolhidas para avaliar a framework contem vulnerabilidades que foram criadas intencionalmente.

Para identificar as vulnerabilidades existentes nas aplicacoes foi necessario seleccionar os seus

parametros de entrada existentes ao fuzzer, prosseguindo-se o processo de fuzzing com o envio de

inputs. Alem disso, foi necessario uma fase de treino de forma a criar os templates correspondentes

aos varios pontos de entrada da aplicacao alvo de teste. Terminado este processo e de forma a

determinar a existencia de vulnerabilidades foi necessario observar os varios relatorios automaticos de

cada mecanismo de deteccao.

A Tabela 5.2 apresenta as vulnerabilidades detectadas pela framework perante as varias aplicacoes

testadas. Observa-se que foram detectados um numero significativo de vulnerabilidades em todas as

aplicacoes alvo de teste. A Tabela 5.3 apresenta um resumo relativamente as deteccoes efectuadas

tendo em conta a aplicacao web testada. Durante a avaliacao, observou-se no caso especıfico da

aplicacao XSSeducation a existencia de falsos positivos (FP nas tabelas), pois os inputs que contem

scripts foram inseridos numa seccao de codigo da resposta onde estava ser executado um script

afectando assim a execucao dos dois scripts existentes. Assim, o input que foi enviado a aplicacao foi

reflectido mas nao foi executado pelo browser.

De seguida e apresentado um exemplo de um excerto de codigo na aplicacao DVWA 1.0.8 (Listagem

5.2) vulneravel a um ataque de injeccao de SQL tendo este sido detectado com sucesso pela framework.

A vulnerabilidade ocorre devido a falta de processos de validacao, sanitizacao ou codificacao do input

recebido. Como tal, o input consegue alterar a estrutura para qual a query foi inicialmente desenhada.

Esta vulnerabilidade foi detectada pela framework atraves do envio de vectores de fuzzing, por

exemplo, ’-’ ou ’ UNION SELECT VERSION()-- . No entanto, tambem houveram varios vectores de fuz-

zing que foram rejeitados pela aplicacao ou que nao exploram a vulnerabilidade em questao, por exemplo,

a’=’b’=’c’ ou CONCAT(CHAR(39),CHAR(97),CHAR(100),CHAR(109),CHAR(105),CHAR(110),CHAR( 39))--

respectivamente.

1 $id = $ GET [ ’ i d ’ ] ;

2 $get id = ” /∗ ” . F ILE . ” : ” . L INE . ” ∗ /SELECT f i r s t name , last name FROM users WHERE u se r i d

= ’ $ id ’ ” ;

3 $ r e s u l t = mysql query ( $ge t id ) or d ie ( ’<pre> ’ . mysq l e r ro r ( ) . ’</pre> ’ ) ;

Listagem 5.2: Excerto de codigo vulneravel na aplicacao DVWA 1.0.8

57

Aplicacao web Vulnerabilidades detectadasSQLI RFI LFI XSS reflectido XSS armazenado

DVWA 1.0.8 5 1 2 7 2Mutilidae 1.3 5 1 1 6 5OWASP Bricks Normada 2 0 0 2 0OWASP Bricks Tuivai 9 0 0 8 0Peruggia 1.2 8 1 2 2 2Wackopicko 3 1 1 2 2XSSeducation 0 0 0 4 (2 FP) 0Total 32 4 6 31 11

Tabela 5.2: Resultados obtidos pela framework atraves de aplicacoes open source

Aplicacao web Ficheiros Linhas de codigo FicheirosVulneraveis

VulnerabilidadesEncontradas

DVWA 1.0.8 316 32880 11 17Mutilidae 1.3 15 838 7 18OWASP Bricks Normada 10 654 2 4OWASP Bricks Tuivai 23 1831 10 17Peruggia 1.2 10 1015 6 15Wackopicko 49 3014 6 9XSSeducation 9 114 4 (2 FP) 4 (2 FP)Total 432 40346 46 84

Tabela 5.3: Resumo dos resultados obtidos pela framework executando aplicacoes open source

Alem disso, constatou-se que certas aplicacoes open source que foram testadas tem diversos estados

e como tal, isso teve de ser considerado no processo de fuzzing. Sendo assim, foi necessario utilizar o

mecanismo de definicao de estados referido na subseccao 4.1.1 para ser possıvel exercitar a aplicacao

nos diferentes estados e detectar as vulnerabilidades existentes nestas. As aplicacoes visadas foram:

DVWA, Peruggia e Wackopicko. Em todas elas, a existencia de estados focava-se na autenticacao dos

utilizadores havendo, assim, dois estados nestas aplicacoes: nao autenticado e autenticado. Observou-

se a existencia de vulnerabilidades quando a aplicacao se encontrava no estado autenticado que nao

eram acessıveis quando a aplicacao se encontrava no estado nao autenticado.

5.3 Avaliacao do mecanismo de deteccao de ataques SQLI

Como referido na subseccao 2.4.1, Ray e Ligatti introduziram o conceito de ataques de injeccao de

codigo (CIAO - Code-Injection Attacks on Output) [6] tendo definido 11 casos de teste que suportam a

sua definicao.

De forma a avaliar a eficiencia e qualidade do mecanismo de monitorizacao da vulnerabilidade SQLI

desenvolvido neste trabalho, este foi alvo destes casos de testes. Foi necessario haver uma fase de

treino no qual definiram-se os templates para cada caso atraves de inputs benignos. Nestes 11 casos de

testes nao e considerado a existencia de varios estados, como tal, nao foi necessario recorrer-se ao

mecanismo de definicao de estados existente na framework.

Na Tabela 5.4 estao apresentados os resultados apresentados pela framework desenvolvida comparando-

os com a definicao de Ray e Ligatti. Alem disso, comparou-se os resultados obtidos com varias ferra-

58

mentas que foram apresentadas no trabalho desenvolvido em [6] e tambem com uma outra ferramenta -

DIGLOSSIA [44] - que tambem comparam os seus resultados tambem com esta definicao. Os casos no

qual foi identificado como codigo, estao representados com Sim e em caso contrario, estao representados

com Nao.

1 2 3 4 5 6 7 8 9 10 11Definicao de Ray e Ligatti [6] Sim Sim Sim Nao Sim Sim Nao Sim Sim Sim NaoDIGLOSSIA [44] Sim Sim Sim Nao Sim Sim Nao Sim Sim Nao NaoCANDID [21] Sim Sim Sim Nao Nao Nao Sim Nao Nao Nao SimSQLCHECK [45] Sim Nao Nao Sim Nao Nao Nao Nao Nao Nao NaoXu et al. [46] Sim Sim Sim Nao Nao Nao Nao Nao Nao Nao SimAMNESIA [19], Nyugen-tuong et al. [47] Sim Sim Sim Nao Nao Nao Nao Nao Nao Nao SimFramework Sim Sim Sim Nao Sim Sim Nao Sim Sim Nao Nao

Tabela 5.4: Deteccao de ataques de injeccao de codigo definido por Ray e Ligatti realizado por seisferramentas e pela framework desenvolvida

Pode-se observar que a framework desenvolvida classifica correctamente 10 dos 11 casos de ataque

definidos por Ray e Ligatti [6]. O unico caso que difere, caso 10, ocorre pois o parametro expectavel

ao VARCHAR/CHAR na definicao de uma string e um inteiro. O valor injectado (40) e um inteiro, como tal

o mecanismo nao reporta o ataque pois nao considera que houve uma violacao dos tipos de dados a

serem inseridos. No entanto, se o valor inserido nao fosse um inteiro ou se fosse um inteiro representado

numa outra notacao, o mecanismo detectaria a tentativa de ataque.

Em relacao as outras ferramentas, apenas a ferramenta DIGLOSSIA [44] esta em igualdade em

termos de desempenho com o mecanismo de monitorizacao SQLI existente na framework dado que

tambem classificou correctamente 10 dos 11 casos. As restantes ferramentas tiveram um desempenho

inferior. Obstante a essa igualdade, o mecanismo de deteccao de ataques SQLI desenvolvido neste

trabalho consegue detectar injeccoes de SQL estruturais ou mımica (primeira e de segunda ordem) e

injeccoes de SQL recorrendo a codificacao ou a evasao de espacos. A ferramenta DIGLOSSIA apenas

consegue detectar ataques SQLI estruturais e mımica de primeira ordem sendo assim uma solucao

inferior comparativamente a solucao desenvolvida neste trabalho.

59

Capıtulo 6

Conclusao

Esta dissertacao apresenta uma framework para fuzzing de aplicacoes web, detectando eficazmente

vulnerabilidades atraves de mecanismos de monitorizacao inovadores. A solucao desenvolvida difere do

apresentado no state of the art, dado que a maioria da deteccao esta embebida nos varios componentes

que constituem uma aplicacao web, enquanto o restante da monitorizacao esta inserido no fuzzer.

Uma abordagem de deteccao deste genero tem varias vantagens: como a monitorizacao esta inserida

como ultimo elemento do fluxo de execucao, nao e necessario efectuar suposicoes sobre as entidades

previas; a monitorizacao nao esta dependente de processos de sanitizacao, validacao ou codificacao;

utiliza recursos dos componentes da aplicacao web para auxiliar a deteccao.

Alem disso, a solucao desenvolvida tem um menor numero de falhas na deteccao pois nao e

dependente de parsers ou outras ferramentas externas. Este tipo de ferramentas podem conter bugs ou

podem nao ser abrangentes a todos os aspectos das linguagens existentes nos varios componentes de

uma aplicacao web.

A maioria das abordagens implementadas para a deteccao das varias vulnerabilidades neste trabalho,

centram-se na deteccao de diferencas estruturais nos pedidos que sao efectuados por parte dos

utilizadores a aplicacao alvo de teste tendo em conta varios inputs. Estas abordagens, verificam se a

estrutura de determinado pedido e diferente da estrutura gerada atraves de inputs benignos, denominada

como template. Em caso afirmativo, indica que o input do utilizador e malicioso pois altera o proposito

inicial para o qual foi desenhado determinado pedido.

A actual implementacao da framework permite detectar um conjunto significativo de vulnerabilidades

inseridas na categoria de vulnerabilidades de validacao de input : injeccao de SQL, inclusao de ficheiros

locais ou remotos e tambem cross-site scripting reflectido e armazenado. Tambem de ressalvar, a

possibilidade do fuzzer existente na framework permitir colocar a aplicacao alvo de teste num determi-

nado estado antes de serem enviados os pedidos com os inputs provenientes do fuzzer, tornando esta

deteccao mais eficiente.

A framework desenvolvida foi testada perante amostras de codigo intencionalmente vulneraveis e

aplicacoes open source em termos do numero de vulnerabilidades detectadas. Dentro das amostras de

codigo intencionalmente vulneraveis, foram utilizadas amostras que foram desenvolvidas paralelamente

61

com o desenvolvimento da framework e tambem atraves de amostras de codigo provenientes do

NIST Software Assurance Reference Dataset Project. Em ambas as amostras foram detectadas com

sucesso todas as vulnerabilidades existentes. Relativamente as aplicacoes open-source, a framework

desenvolvida testou sete aplicacoes, tendo detectado um numero significativo de vulnerabilidades nestas.

Alem disso, e para o caso especıfico do mecanismo de deteccao da vulnerabilidade de injeccao de

SQL, pode-se observar que a solucao desenvolvida e superior em termos de desempenho na deteccao

relativamente a maioria das solucoes existentes no state of the art.

6.1 Trabalho futuro

Em relacao a trabalho futuro, pode-se considerar o desenvolvimento dos restantes mecanismos de

deteccoes de vulnerabilidades referidos em 3.1 nos quais estao incluıdos as seguintes vulnerabilidades:

injeccao de comandos de SO; injeccao de codigo da linguagem de servidor; directory/path traversal ;

source code disclosure.

Alem disso e para automatizar mais o funcionamento da framework, adicionar funcionalidades de

state-awareness de forma a ser possıvel, automaticamente, efectuar uma analise a aplicacao alvo

de teste e conseguir inferir a existencia de estados, sendo assim possıvel exercitar com os inputs

provenientes do fuzzer, todos os pontos de entrada de uma aplicacao em cada estado. Por exemplo, o

fuzzer poderia ser estendido com o mecanismo de inferencia de estados de Dupe et al. [42] ou com os

mecanismos do sistema LigRE [43].

62

Bibliografia

[1] Jason Bau, Elie Bursztein, Divij Gupta, and John Mitchell. State of the art: Automated black-box

web application vulnerability testing. In Proceedings of the 2010 IEEE Symposium on Security and

Privacy, 2010.

[2] Adam Doupe, Marco Cova, and Giovanni Vigna. Why johnny can’t pentest: An analysis of black-box

web vulnerability scanners. In Proceedings of the 7th International Conference on Detection of

Intrusions and Malware, and Vulnerability Assessment, 2010.

[3] Joao Antunes, Nuno Neves, Miguel Pupo Correia, Paulo Verissimo, and Rui Neves. Vulnerability

discovery with attack injection. IEEE Transactions on Software Engineering, 36(3):357–370, 2010.

[4] Gregg Keizer. Microsoft runs fuzzing botnet, finds 1,800 office bugs. Computer World, March 2010.

[5] LaShanda Dukes, Xiaohong Yuan, and Francis Akowuah. A case study on web application security

testing with tools and manual testing. In Southeastcon, 2013 Proceedings of IEEE, pages 1–6, 2013.

[6] Donald Ray and Jay Ligatti. Defining code-injection attacks. In Proceedings of the 39th Annual ACM

SIGPLAN-SIGACT Symposium on Principles of Programming Languages, 2012.

[7] OWASP. OWASP Top 10 - 2013 - the ten most critical web application security risks. Technical

report, OWASP Foundation, 2013.

[8] Michael Sutton, Adam Greene, and Pedram Amini. Fuzzing: Brute Force Vulnerability Discovery.

Addison-Wesley Professional, 2007.

[9] Miguel Pupo Correia and Paulo Jorge Sousa. Seguranca no Software. FCA, 2010.

[10] Peter Oehlert. Violating assumptions with fuzzing. IEEE Security & Privacy, 3(2):58–62, 2005.

[11] Christian Holler, Kim Herzig, and Andrea Zeller. Fuzzing with code fragments. In Proceedings of the

21st USENIX Conference on Security Symposium, 2012.

[12] Jared DeMott. The evolving art of fuzzing. DEF CON, 14, 2006.

[13] WASC. Web application security scanner evaluation criteria v1.0. Technical report, Web Application

Security Consortium, 2009.

[14] Joao Antunes. Network Attack Injection. PhD thesis, University of Lisboa, 2012.

63

[15] WASC. Threat Classification. Technical report, Web Application Security Consortium, 2010.

[16] Robert Martin, Steven Cristey, Ryan Glenn, Janis Kenderdine, John Mazella, and Lesley Piper.

Common weakness enumeration v2.5. Technical report, MITRE, 2013.

[17] Imperva. Hacker intelligence initiative, monthly trend report #8. April 2012.

[18] William Halfond and Alessandro Orso. Malware Detection - Detection and Prevention of SQL Attacks.

Springer, 2006.

[19] William Halfond and Alessandro Orso. Preventing SQL injection attacks using AMNESIA. In

Proceedings of the 28th International Conference on Software Engineering, 2006.

[20] Yao-Wen Huang, Shih-Kun Huang, Tsung-Po Lin, and Chung-Hung Tsai. Web application security

assessment by fault injection and behavior monitoring. In Proceedings of the 12th International

Conference on World Wide Web, pages 148–159, 2003.

[21] Sruthi Bandhakavi, Prithvi Bisht, P. Madhusudan, and V. N. Venkatakrishnan. CANDID: preventing

SQL injection attacks using dynamic candidate evaluations. In Proceedings of the 14th ACM

Conference on Computer and Communications Security, pages 12–24, 2007.

[22] K Sunitha and M Sridevi. Automated detection system for SQL injection attack. International Journal

of Computer Science and Security, 4(4):426–435, 2009.

[23] Gregory T Buehrer, Bruce W Weide, and Paolo A G Sivilotti. Using parse tree validation to prevent

SQL injection attacks. In Proceedings of the 5th International Workshop on Software Engineering

and Middleware, pages 106–113, 2005.

[24] Imperva. Hacker intelligence initiative, monthly trend report #8. Remote and Local File Inclusion

Vulnerabilities 101, 2012.

[25] Johannes Dahse and Jorg Schwenk. Rips-a static source code analyser for vulnerabilities in PHP

scripts, 2010. http://www.nds.rub.de/media/nds/attachments/files/2010/09/rips-paper.pdf.

[26] Yingbo Song, Angelos D Keromytis, and Salvatore Stolfo. Spectrogram: A mixture-of-Markov-chains

model for anomaly detection in web traffic. In Proceedings of the Network and Distributed System

Security Symposium 2009: February, 2009, pages 121–135, 2009.

[27] Arpit Bajpai. Securing Apache, Part 9: Attacks that Target PHP-based Instances, 2011.

http://www.linuxforu.com/ 2011/05/securing-apache-part-9-attacks-that-target-php-instances/.

[28] Omar Ismail, Masashi Etoh, Youki Kadobayashi, and Suguru Yamaguchi. A proposal and implemen-

tation of automatic detection/collection system for cross-site scripting vulnerability. In Proceedings of

the 18th International Conference on Advanced Information Networking and Applications, volume 2,

2004.

[29] Suman Saha. Consideration points detecting cross-site scripting. CoRR, 4, 2009.

64

[30] Engin Kirda, Cristopher Kruegel, Giovanni Vigna, and Nenad Jovanovic. Noxes: A client-side

solution for mitigating cross-site scripting attacks. In Proceedings of the 2006 ACM Symposium on

Applied Computing, pages 330–337, 2006.

[31] Mike Ter Louw and V. N. Venkatakrishnan. Blueprint: Robust prevention of cross-site scripting

attacks for existing browsers. In Proceedings of the 30th IEEE Symposium on Security and Privacy,

pages 331–346, 2009.

[32] Takeshi Matsuda, Daiki Koizumi, , and Michio Sonnoda. Cross site scripting attacks detection

algorithm based on the appearance position of characters. In Proceedings of the 2012 Mosharaka

International Conference on Communications, Computers and Applications, pages 65–70, 2012.

[33] Gary Wassermann and Zhendong Su. Static detection of cross-site scripting vulnerabilities. In

Proceedings of the 30th International Conference on Software Engineering, pages 171–180, 2008.

[34] Lwin Khin Shar and Hee Beng Kuan Tan. Defending against cross-site scripting attacks. IEEE

Computer, 45(3):55–62, 2012.

[35] RBAP Mell. Intrusion detection systems. National Institute of Standards and Technology (NIST),

Special Publication, 51, 2001.

[36] Ivan Ristic. Web intrusion detection with mod security. OWASP AppSec Europe, 2005.

[37] Giovanni Vigna, William Robertson, Vishal Kher, and Richard A Kemmerer. A stateful intrusion

detection system for world-wide web servers. In Proceedings of the Computer Security Applications

Conference, pages 34–43, 2003.

[38] Fredrik Valeur, Giovanni Vigna, Christopher Kruegel, and Engin Kirda. An anomaly-driven reverse

proxy for web applications. In Proceedings of the 2006 ACM Symposium on Applied Computing,

pages 361–368, 2006.

[39] Meixing Le, Angelos Stavrou, and BB Kang. Doubleguard: Detecting intrusions in multitier web

applications. Dependable and Secure Computing, IEEE Transactions on, 9(4):512–525, 2012.

[40] Michael Coates. Owasp appsensor guide v1.1 - detect and respond to attacks from within the

application. Technical report, Aspect Security, Inc, 2009.

[41] Temple F Smith and Michael S Waterman. Identification of common molecular subsequences.

Journal of molecular biology, 147(1):195–197, 1981.

[42] Adam Doupe, Ludovico Cavedon, Christopher Kruegel, and Giovanni Vigna. Enemy of the state: A

state-aware black-box web vulnerability scanner. In Proceedings of the 21st USENIX Conference on

Security Symposium, Security, pages 26–26, 2012.

[43] F. Duchene, S. Rawat, J.-L. Richier, and R. Groz. Ligre: Reverse-engineering of control and data

flow models for black-box xss detection. In Proceedings of the 20th Working Conference on Reverse

Engineering (WCRE), pages 252–261, Oct 2013.

65

[44] Sooel Son, Kathryn S McKinley, and Vitaly Shmatikov. Diglossia: detecting code injection attacks

with precision and efficiency. In Proceedings of the 2013 ACM SIGSAC conference on Computer &

communications security, pages 1181–1192, 2013.

[45] Zhendong Su and Gary Wassermann. The essence of command injection attacks in web applications.

In Proceedings of the 33rd ACM SIGPLAN-SIGACT Symposium on Principles Of Programming

Languages, pages 372–382, 2006.

[46] Wei Xu, Sandeep Bhatkar, and R Sekar. Taint-enhanced policy enforcement: A practical approach

to defeat a wide range of attacks. In Proceedings of the IEEE Symposium on Security and Privacy,

volume 15, 2006.

[47] Anh Nguyen-Tuong, Salvatore Guarnieri, Doug Greene, Jeff Shirley, and David Evans. Automatically

hardening web applications using precise tainting. 2005.

66

Apendice A

Codigo vulneravel demonstrando o

mecanismo de definicao do estado de

execucao

1 <?php

2 s e s s i o n s t a r t ( ) ;

3 i f ( ! i s s e t ( $ SESSION [ ’ user ’ ] ) ) {

4 echo ”<form ac t i on =\” l o g i n . php\ ” method=\” post\”>

5 Name: <i npu t type =\” t e x t \ ” name=\”name\”><br>

6 <i npu t type =\” submit\”>

7 </ form> ” ;

8 $ SESSION [ ’ user ’ ] = $ POST [ ’name ’ ] ;

9 }else{

10 echo ”<form ac t i on =\” r e s u l t . php\ ” method=\” post\”>

11 Content : <i npu t type =\” t e x t \ ” name=\” content\”><br>

12 <i npu t type =\” submit\”>

13 </ form> ” ;

14 i f ( i s s e t ($ POST [ ’ content ’ ] ) ) {

15 $ SESSION [ ’ content ’ ] = $ POST [ ’ content ’ ] ;

16 }

17 echo ”<form ac t i on =\” logou t . php\ ” method=\” post\”>

18 <i npu t type =\” submit \ ” value =\” Logout\”/>

19 </ form>

20 </body></html> ” ;

21 }

22 ?>

Listagem A.1: Ficheiro de login da aplicacao alvo do mecanismo de definicao do estado de execucao

(login.php)

1 <?php

2 s e s s i o n s t a r t ( ) ;

67

3 i f ( i s s e t ($ SESSION [ ’ user ’ ] ) ) {

4 echo $ POST [ ’ content ’ ] ;

5 echo ” Resul ts :<br><form ac t i on =\” l o g i n . php\ ” method=\” post\”>

6 <i npu t type =\” submit \ ” value =\”Back\”/>

7 </ form>

8 </body></html> ” ;

9 }

Listagem A.2: Ficheiro da aplicacao alvo do mecanismo de definicao do estado de execucao que contem

a vulnerabilidade XSS reflectido (result.php - linha 4)

1 <?php

2 s e s s i o n s t a r t ( ) ;

3 i f ( i s s e t ($ POST [ ’ logou t ’ ] ) )

4 sess ion des t roy ( ) ;

5 header ( ” l o c a t i o n : / miguelb / XSSref lected / l o g i n . php ” ) ;

6 e x i t ( ) ;

7 ?>

Listagem A.3: Ficheiro de logout da aplicacao alvo do mecanismo de definicao do estado de execucao

(logout.php)

68

Framework para Detecção Automática de Vulnerabilidades … · Framework para Detecção...

Documents

Transcript of Framework para Detecção Automática de Vulnerabilidades … · Framework para Detecção...