Mecanismo de definic¸ ˜ao do estado de execuc¸ ˜ao da aplicac¸ ˜ao

Uma aplicac¸ ˜aowebpassa por diversos estados, sendo que s ´o alguns dos quais s ˜ao vulner ´aveis. Por isso, ao usarfuzzingpara detectar vulnerabilidades numa aplicac¸ ˜ao, ´e importante faz ˆe-la percorrer os seus diversos estados e fazerfuzzingde todos os vectores em cada um deles. A implementac¸ ˜ao actual

1https://www.owasp.org/index.php/JBroFuzz

Figura 4.1: Arquitectura daframeworkrepresentado os componentes de monitorizac¸ ˜ao implementados

dofuzzer cont ´em um mecanismo que permite definir, manualmente, um conjunto de pedidos HTTP que coloquem a aplicac¸ ˜aowebnum determinado estado ou para efectuarresetao estado da aplicac¸ ˜ao ap ´os o envio de determinadoinputdofuzzer. Assim, ´e poss´ıvel definir os pedidos HTTP que v ˜ao definir o estado da aplicac¸ ˜ao atrav ´es de um ficheiro de texto contendo a estrutura apresentada na Listagem 4.1.

1 BEGIN - H T T P

2 [ GET | P O S T ]

3 [ URL ]

4 [ P A R A M S ]

5 [ C O O K I E ]

6 END - H T T P

Listagem 4.1: Estrutura de um pedido HTTP para o mecanismo de definic¸ ˜ao de estados Como se pode observar na Listagem 4.1, ´e poss´ıvel caracterizar um pedido HTTP pelo seu tipo (GET/POST),url, par ˆametros ecookiescaso sejam necess ´arios. Num ficheiro deste tipo, ´e poss´ıvel definir qualquer n ´umero de pedidos HTTP desde que estejam de acordo com a estrutura referida anteriormente.

De forma a facilitar a compreens ˜ao deste mecanismo, vai ser explicado o funcionamento deste mecanismo atrav ´es de um exemplo de uma aplicac¸ ˜ao que cont ´em dois estados: n ˜ao autenticado e autenticado. Esta aplicac¸ ˜ao necessita de autenticac¸ ˜ao por parte do utilizador de forma a poder-se enviar uma mensagem `a aplicac¸ ˜ao sendo esta reflectida integralmente, podendo assim, ser poss´ıvel explorar uma vulnerabilidade decross-site scripting reflectido como se pode observar no Ap ˆendice A. Caso contr ´ario, n ˜ao ´e poss´ıvel aceder a esta funcionalidade. Assim, para testar-se a aplicac¸ ˜ao alvo de teste ´e necess ´ario enviar osinputsprovenientes dofuzzernos dois estados existentes de forma a conseguir-se

detectar a vulnerabilidade.

Para testar o estadon ˜ao autenticado, n ˜ao ´e necess ´ario enviar quaisquerinputsde forma a colocar a aplicac¸ ˜ao nesse estado, logo para testar, s ´o ´e necess ´ario ofuzzer enviar osinputscontidos nos seus vectores defuzzing e posteriormente verificar se foram detectadas algumas vulnerabilidades. Como referido anteriormente, neste caso, n ˜ao v ˜ao ser detectados quaisquer vulnerabilidades na aplicac¸ ˜ao.

Para testar o estadoautenticado, ´e necess ´ario colocar a aplicac¸ ˜ao num determinado estado, corres-pondendo ao processo deloginnesta. Para isso ´e necess ´ario, utilizar o mecanismo desenvolvido para definic¸ ˜ao de estados na aplicac¸ ˜ao e definir, manualmente, o pedido HTTP que corresponde aologinna aplicac¸ ˜ao como pode ser observado na Listagem 4.2. Assim, ofuzzerantes de enviar cada um dos seus inputsproveniente de vectores defuzzingencarrega-se de enviar o pedido deloginna aplicac¸ ˜ao, para que no momento de teste, osinputsenviados estejam a exercitar a aplicac¸ ˜ao no estadoautenticado.

Neste caso, vai ser detectado uma vulnerabilidade decross-site scriptingreflectido, por exemplo, atrav ´es doinput <video><source onerror="alert(’Muahahah’)">.

Posteriormente, e tamb ´em com o uso do mecanismo de definic¸ ˜ao de estados, vai-se definir, manual-mente, o pedido HTTP que corresponde aologout da aplicac¸ ˜ao de forma a efectuarresetao estado ap ´os o envio doinput proveniente dofuzzer como se pode observar na Listagem 4.3.

1 BEGIN−HTTP

Listagem 4.2: Definic¸ ˜ao do pedido de prestate HTTP no mecanismo de definic¸ ˜ao de estados implementado que representa o processo de fazerlogin

1 BEGIN−HTTP

Listagem 4.3: Definic¸ ˜ao do pedido dereset HTTP no mecanismo de definic¸ ˜ao de estados implementado que representa o processo de fazerlogout

Como referido anteriormente, o mecanismo desenvolvido necessita de uma interacc¸ ˜ao 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 infer ˆencia de estados baseado na soluc¸ ˜ao de Dup ´e et al. [42] ou no sistema LigRE [43].

4.2 Detecc¸ ˜ao de injecc¸ ˜ao de SQL

Para implementar este mecanismo, foi necess ´ario modificar o sistema de gest ˜ao de base de dados MySQL (vers ˜ao 5.7.4), mais especificamente a func¸ ˜ao deparsing(mysql parse- ficheirosql parser.cc) adicionando um total de 14 linhas de c ´odigo. Tamb ´em foi criado um ficheiroheader com 1098 linhas de c ´odigo que implementam o mecanismo de detecc¸ ˜ao e permite efectuar a an ´alise das estruturas das queriesprocessadas pelo SGBD. Atrav ´es destas alterac¸ ˜oes ´e poss´ıvel detectar variados ataques de injecc¸ ˜ao de SQL.

O mecanismo recebe uma query pr ´e-processada e alvo de parsing pelo MySQL, recolhendo a estrutura da mesma. Caso estaquery tenha sido executada pela primeira vez, a estrutura da mesma vai ser armazenada pois representa otemplateda respectivaquery. Caso contr ´ario, a estrutura recolhida vai ser comparada com o respectivotemplateprocurando diferenc¸as entre as duas. Opcionalmente, o mecanismo pode registar ou rejeitar a execuc¸ ˜ao de umaquery caso um ataque de injecc¸ ˜ao de SQL seja detectado pelo mecanismo.

Para armazenar as estruturas dasqueriese vari ´aveis de controlo e de configurac¸ ˜ao do mecanismo (ex: detecc¸ ˜ao da vulnerabilidade activada/desactivada) foi necess ´ario criar uma estrutura de dados em pilha.

Para efectuar estas tarefas referidas anteriormente, no ficheirosql parser.ccadicionou-se `a func¸ ˜ao mysql parseum n ´umero reduzido linhas de c ´odigo com o prop ´osito de obter a estrutura daquery para ser analisada pela func¸ ˜aocompareQueryStructure, existente no ficheiroheader, antes de ser executada atrav ´es da func¸ ˜aomysql execute command. Esta func¸ ˜ao, como o pr ´oprio nome indica, executa aquery na base de dados. O mecanismo de detecc¸ ˜ao ´e chamado nesse ponto de execuc¸ ˜ao porque: (1) ap ´os a fase de pr ´e-procesamento o DBMS efectua descodificac¸ ˜ao sobre a codificac¸ ˜ao dos caracteres e outros processos de uniformizac¸ ˜ao do conte ´udo recebido (ex: evas ˜ao de caracteres de espac¸o); (2) ap ´os a fase deparsing o DBMS permite recolher a estrutura daquery com os seus elementos que a comp ˜oem, permitindo aceder a essa informac¸ ˜ao, analisar e identificar ataques; (3) ´e no momento antes da execuc¸ ˜ao daquery ´e que ´e poss´ıvel efectuar acc¸ ˜oes sobre aquery caso exista um ataque, por exemplo, prevenir o seu processamento bloqueando este.

A func¸ ˜aocompareQueryStructureinvoca as func¸ ˜oesprocessSelect Lex einsertElementTemplate de forma a verificar o tipo de umaquery (SELECT, DELETE, INSERT, UPDATE) e inserir os dados na sua estrutura. Esta func¸ ˜ao tamb ´em retorna o identificador daquery e verifica se existe algumtemplatepara esse identificador. Caso n ˜ao exista, a estrutura analisada ´e considerada umtemplatee ´e armazenada no mecanismo. Caso contr ´ario, otemplate ´e carregado e ´e efectuado a chamada `a func¸ ˜ao compareQueryTo-Templateque cont ´em dois passos. O primeiro passo, verifica se o n ´umero de items em ambas estruturas s ˜ao iguais. Caso n ˜ao sejam, ´e detectado uma injecc¸ ˜ao de SQL, caso contr ´ario prossegue-se para o passo seguinte. Neste segundo passo, ´e invocado a func¸ ˜aoprocessItem, cujo objectivo, ´e processar cada item da estrutura daquerye comparar com o seu respectivo item notemplate. Caso pelo menos uma destas comparac¸ ˜oes entre pares de items n ˜ao corresponda ´e identificado um ataque de injecc¸ ˜ao de SQL.

A func¸ ˜aoprocessItemanalisa os 27 tipos diferentes de items que s ˜ao definidos pelo MySQL utilizando duas func¸ ˜oes auxiliares (processField e isPrimitiveTypeBenign) para detectar diferenc¸as entrefieldse para verificar se determinado item ´e do tipo primitivo (inteiro, real,stringou decimal).

Tamb ´em foi necess ´ario concatenar `as queries executadas um identificador ´unico em forma de coment ´ario, para que seja poss´ıvel identificar qual o ponto do c ´odigo da aplicac¸ ˜ao alvo de teste onde foi efectuada determinadaquery, permitindo ao programador conseguir perceber atrav ´es de an ´alise do c ´odigo o porqu ˆe da exist ˆencia da vulnerabilidade. Caso n ˜ao exista este identificador naquery, o MySQL continua a funcionar normalmente apenas n ˜ao ´e alvo do mecanismo de detecc¸ ˜ao.

A implementac¸ ˜ao actual deste mecanismo apenas permite a an ´alise da estrutura dequeriesque contenham as seguintes cl ´ausulas: SELECT, INSERT INTO, UPDATE, FROM, WHERE, HAVING, ORDER BY, GROUP BY. Como tal, o mecanismo n ˜ao consegue, actualmente, identificar diferenc¸as estruturais nas queriesque usem cl ´ausulas que n ˜ao as referidas anteriormente, podendo essa an ´alise sobre outros tipos de cl ´ausulas ser estendida para futuras implementac¸ ˜oes daframework.

4.3 Detecc¸ ˜ao de inclus ˜ao de ficheiros locais e remotos

De forma a implementar este mecanismo, foi necess ´ario modificar o interpretador do PHP (vers ˜ao 5.5.12), mais especificamente oZend Engine. Estas modificac¸ ˜oes centraram-se nas func¸ ˜oes doZend Engine que implementam as func¸ ˜oes de inclus ˜ao de ficheiros na linguagem PHP (ex: include,include once, requireerequire once) para que possa ser poss´ıvel extrair os ficheiros alvos da inclus ˜ao e recolher a informac¸ ˜ao necess ´aria `a detecc¸ ˜ao deste tipo de vulnerabilidade.

A func¸ ˜ao onde foi necess ´aria efectuar essas alterac¸ ˜oes no interpretador da linguagem PHP foi compile file(zend language scanner.c), alterando um total de 112 linhas de c ´odigo. Esta func¸ ˜ao recebe como argumento um ficheiro que vai ser compilado pelo PHP, neste caso, os ficheiros alvo de inclus ˜ao por parte da aplicac¸ ˜ao. Foi necess ´ario acrescentar um identificador a cada chamada a uma func¸ ˜ao de inclus ˜ao para se saber qual foi o ponto do c ´odigo onde foi efectuada determinada inclus ˜ao. Caso n ˜ao exista este identificador, o PHP continua a funcionar normalmente apenas n ˜ao ´e alvo do mecanismo de detecc¸ ˜ao.

Para a extracc¸ ˜ao da informac¸ ˜ao relativa ao identificador de cada chamada a uma func¸ ˜ao de inclus ˜ao, foi necess ´ario modificar o ficheirozend vm execute.halterando um total de 116 linhas de c ´odigo. Com a alterac¸ ˜ao desta func¸ ˜ao, ´e poss´ıvel tirar ilac¸ ˜oes sobre a exist ˆencia do ficheiro alvo de inclus ˜ao pois esta func¸ ˜ao pode retornar valores que indiquem a n ˜ao exist ˆencia do mesmo. Com esta nova informac¸ ˜ao ´e poss´ıvel efectuar a distinc¸ ˜ao entre o aviso de poss´ıvel exist ˆencia da vulnerabilidade caso o ficheiro exista e quando ocorre verdadeiramente a explorac¸ ˜ao da vulnerabilidade devido a inclus ˜ao de um ficheiro malicioso.

Ostemplatesnecess ´arios para comparar com futuras chamadas a func¸ ˜oes de inclus ˜oes s ˜ao armaze-nados de forma permanente atrav ´es de ficheiros contendo a informac¸ ˜ao necess ´aria relevante.

4.4 Detecc¸ ˜ao de cross-site scripting armazenado

Para implementar este mecanismo, modificou-se oZend Engine(vers ˜ao 5.5.12). A modificac¸ ˜ao centrou-se na func¸ ˜ao do interpretador que implementa a func¸ ˜aomysql query da linguagem PHP, mais especi-ficamente, a func¸ ˜aophp mysql do query general. Sobre esta func¸ ˜ao, foram alteradas um total de 72 linhas de c ´odigo para implementar o mecanismo de detecc¸ ˜ao desta vulnerabilidade atrav ´es da an ´alise do conte ´udo devolvido pelasqueries.

Para efectuar a an ´alise do conte ´udo devolvido pelasqueries ´e necess ´ario verificar se neste existe algum c ´odigo, por exemplo, HTML ou JavaScript contido. Para tal, ´e utilizado um m ´odulo deparsing programado em Java (antixss.jar) que utiliza uma biblioteca deparsingde c ´odigo deste g ´enero, nome-adamente,jsoup (vers ˜ao 1.7.3)². Como referido anteriormente, esta biblioteca tem como prop ´osito efectuarparsingde p ´aginas HTML e de outras linguagens ligadas a esta (ex: JavaScript, CSS) tendo em conta a exist ˆencia detagscom as quais consegue estruturar o c ´odigo. Para a identificac¸ ˜ao de c ´odigo, o mecanismo fornece o conte ´udo a analisar aojsoupe este insere-o numa p ´aginadummy de HTML, representada pelastags<html><head><body>no qual vai fazerparsing. Com a estrutura obtida, verifica se existe pelo menos mais umatagde c ´odigo al ´em das existentes na p ´aginadummy. Em caso afirmativo, isto quer dizer que o conte ´udo alterou a estrutura e como tal cont ´em c ´odigo. Caso contr ´ario, o conte ´udo inserido n ˜ao altera a estrutura do c ´odigo j ´a existente e n ˜ao ´e considerado como c ´odigo.

4.5 Detecc¸ ˜ao de cross-site scripting reflectido

Para implementar este mecanismo de detecc¸ ˜ao, foi utilizada novamente a bibliotecajsoup(vers ˜ao 1.7.3), mas desta vez integrada nofuzzer, como se pode ver na Figura 4.1. O uso dojsouptem como objectivo verificar a exist ˆencia de c ´odigo nosinputs enviados ou na sub-sequ ˆencia resultante pelo algoritmo Smith-Waterman.

Em relac¸ ˜ao ao algoritmoSmith-Watermaneste foi implementado em linguagem Java sendo integrado com o mecanismo de detecc¸ ˜ao. Para o correcto funcionamento deste algoritmo tendo em conta a detecc¸ ˜ao que se pretende fazer foi necess ´ario configur ´a-lo com determinados valores de pontuac¸ ˜ao de concord ˆancia e discord ˆancia entre caracteres das duas sequ ˆencias a comparar para que o tornasse mais toler ´avel a certos caracteres e menos toler ´avel a outros. Tamb ´em, foi necess ´ario definir a percentagem de similaridade entre a pontuac¸ ˜ao obtida e a pontuac¸ ˜ao perfeita para considerar determinadoinputcomo um ataque.

De seguida ´e explicada a configurac¸ ˜ao utilizada pelo mecanismo de detecc¸ ˜ao. Quando existe uma concord ˆancia (case sensitive) entre caracteres nas duas sequ ˆencias ´e adicionada uma pontuac¸ ˜ao de 5 unidades. Quando existe uma discord ˆancia esta pode ser de tr ˆes tipos:

• Quando a discord ˆancia se refere a inclus ˜ao de um espac¸o em branco para a sub-sequ ˆencia estar alinhada s ˜ao deduzidas 2 unidades. A raz ˜ao para tal deduc¸ ˜ao ´e que esta operac¸ ˜ao ´e toler ´avel

2http://www.jsoup.org

devido a poss´ıveis processos de eliminac¸ ˜ao de caracteres de espac¸o por parte da aplicac¸ ˜ao. Esta deduc¸ ˜ao ´e linear consoante o n ´umero de espac¸os em branco que sejam necess ´arios adicionar;

• Quando a discord ˆancia se refere a dois caracteres que sejam diferentes entre si mas que n ˜ao sejam os caracteres<e>s ˜ao deduzidas 5 unidades `a pontuac¸ ˜ao obtida, sendo esta deduc¸ ˜ao linear ao n ´umero de caracteres que est ˜ao em discord ˆancia;

• Quando a discord ˆancia se refere a dois caracteres que sejam diferentes entre si, no qual num deles est ˜ao incluidos os caracteres<e >s ˜ao deduzidas 25 vezes as unidades deduzidas no ponto anterior `a pontuac¸ ˜ao obtida. Esta deduc¸ ˜ao ´e linear ao n ´umero de caracteres que est ˜ao em discord ˆancia. A raz ˜ao do valor elevado de penalizac¸ ˜ao deve-se `a import ˆancia destes caracteres neste tipo de vulnerabilidade pois estes podem ser utilizados como c ´odigo. Quando existe uma discord ˆancia deste tipo, geralmente significa que a aplicac¸ ˜ao filtrou oinputatrav ´es de processos de validac¸ ˜ao, sanitizac¸ ˜ao ou codificac¸ ˜ao.

Por fim, definiu-se que s ´o ´e considerado que certoinput explorou uma vulnerabilidade decross-site scriptingreflectido quando a pontuac¸ ˜ao obtida atrav ´es do algoritmoSmith-Waterman ´e superior a 95%

da pontuac¸ ˜ao perfeita, ou seja, pontuac¸ ˜ao obtida caso haja concord ˆancia em todos os caracteres entre as duas sequ ˆencias comparadas pelo algoritmo.

Cap´ıtulo 5

Avaliac¸ ˜ao Experimental

O sistema desenvolvido foi avaliado perante amostras de c ´odigo vulner ´avel (Subsecc¸ ˜ao 5.1) e aplicac¸ ˜oes open source(Subsecc¸ ˜ao 5.2). Em ambas as avaliac¸ ˜oes efectuadas, foi necess ´ario uma fase de treino de forma a exercitar o c ´odigo alvo de teste cominputsbenignos para que fosse poss´ıvel gerar ostemplates necess ´arios para a detecc¸ ˜ao das vulnerabilidades existentes.

Para avaliar aframework contabilizaram-se o n ´umero de vulnerabilidades que foram detectadas com sucesso por esta. No caso das amostras de c ´odigo vulner ´avel, procedeu-se a uma comparac¸ ˜ao entre o n ´umero de vulnerabilidades detectadas e as existentes nas mesmas. No caso das aplicac¸ ˜oesopen source, procedeu-se a uma contabilizac¸ ˜ao das vulnerabilidades detectadas pelaframework.

Al ´em disso, tamb ´em se avaliou o mecanismo de detecc¸ ˜ao de ataques de injecc¸ ˜ao de SQL tendo em conta o conceito definido por Ray e Ligatti sobre ataques de injecc¸ ˜ao de c ´odigo. No trabalho de Ray e Ligatti [6], definiram 11 casos de teste que suportam a sua definic¸ ˜ao. Sendo assim, o mecanismo desenvolvido foi avaliado atrav ´es destes casos de teste. Al ´em disso, o mecanismo foi comparado com outras ferramentas de detecc¸ ˜ao deste tipo de ataque que tamb ´em compararam os seus resultados com esta definic¸ ˜ao.

5.1 Avaliac¸ ˜ao com amostras de c ´ odigo

A subsecc¸ ˜ao apresenta os resultados da avaliac¸ ˜ao do sistema desenvolvido perante um conjunto de amostras de c ´odigo cujas vulnerabilidades est ˜ao bem identificadas e documentadas. Uma parte deste conjunto de amostras de c ´odigo foi sendo desenvolvida em paralelo com aframework de modo a permitir test ´a-la. Este conjunto de amostras de c ´odigo cont ´em 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 explorac¸ ˜ao para poderem ser contabilizadas como tal, antes de serem alvo de teste por parte daframework.

A outra parte foi constitu´ıda por amostras de c ´odigo provenientes doNIST Software Assurance Reference Dataset Project ¹. As vulnerabilidades existentes s ˜ao justificadas atrav ´es de uminput de

1http://samate.nist.gov/SARD/

Vulnerabilidades Testes Framework (11 ficheiros) Samate (7 ficheiros)

Tabela 5.1: Resumo dos resultados obtidos pelaframework com um conjunto de amostras de c ´odigo vulner ´avel

exemplo que explora a vulnerabilidade e tamb ´em atrav ´es da descric¸ ˜ao da vulnerabilidade em causa tendo em conta a especificac¸ ˜ao definida no CWE².

Constatou-se que uma parte destas amostras continha informac¸ ˜ao bastante reduzida ou incorrecta, pois indicavam que eram vulner ´aveis quando na verdade, ap ´os an ´alise das mesmas, n ˜ao eram, sendo assim, exclu´ıdas da avaliac¸ ˜ao. Al ´em disso, haviam amostras v ´alidas que continham mais vulnerabilidades do que as indicadas, tendo estas sido testadas manualmente, de forma a verificar a exist ˆencia destas e a consider ´a-las como tal. No total, este conjunto de amostras de c ´odigo cont ´em no total 7 ficheiros com 11 vulnerabilidades identificadas como existentes.

Al ´em disso, em ambos conjuntos de amostras de c ´odigo usadas para testar aframework, n ˜ao s ˜ao considerados a exist ˆencia de estados. Como tal, nesta avaliac¸ ˜ao n ˜ao foi necess ´ario recorrer-se ao mecanismo de definic¸ ˜ao do estado de execuc¸ ˜ao da aplicac¸ ˜ao existente nofuzzer.

A Tabela 5.1 apresenta os resultados obtidos pelaframework perante estas amostras de c ´odigo, dividindo-os pela fonte e em termos de cada tipo de vulnerabilidade detectada. Observa-se que todas as vulnerabilidades existentes nestas amostras de c ´odigo vulner ´avel foram detectadas com sucesso.

De seguida ´e apresentado um exemplo de uma amostra de c ´odigo proveniente da amostra de dados do Samate(Listagem 5.1) cujo c ´odigo ´e vulner ´avel a LFI e RFI. A framework detectou com sucesso ambas as vulnerabilidades. A vulnerabilidade ocorre devido a falta de processos de validac¸ ˜ao, sanitizac¸ ˜ao ou codificac¸ ˜ao doinput recebido fazendo com que seja poss´ıvel incluir qualquer ficheiro, inclusiv ´e maliciosos, no c ´odigo da aplicac¸ ˜ao. As vulnerabilidades foram detectadas atrav ´es do envio de vectores defuzzing, por exemplo,/var/log/apache2/error logehttp://localhost/evil.txtque detectaram respectivamente as vulnerabilidades de LFI e RFI.

1 <html>

2 <head></head>

3 <body>

4 <a h r e f = ’ ?page= i n d e x . i n c ’>Index</a> : : <a h r e f = ’ ?page= l i n k s . i n c ’>L i n k s</a><b r />

5 <h1>My Web Page</h1>

6 T h i s i s my main t e m p l a t e .<b r />

11 i n c l u d e ( $page ) ; 12 ?>

13 </body>

14 </ html>

Listagem 5.1: Excerto de c ´odigo vulner ´avel na amostra de dados do Samate