PT106777B - Sistema e método para produção automática de software vulnerável através da injeção de código vulnerável durante o processo de compilação ou interpretação - Google Patents

Sistema e método para produção automática de software vulnerável através da injeção de código vulnerável durante o processo de compilação ou interpretação Download PDF

Info

Publication number
PT106777B
PT106777B PT106777A PT10677713A PT106777B PT 106777 B PT106777 B PT 106777B PT 106777 A PT106777 A PT 106777A PT 10677713 A PT10677713 A PT 10677713A PT 106777 B PT106777 B PT 106777B
Authority
PT
Portugal
Prior art keywords
vulnerability
vulnerabilities
injection
vulnerable
compilation
Prior art date
Application number
PT106777A
Other languages
English (en)
Other versions
PT106777A (pt
Inventor
Nelson Nobre Escravana
João Pedro Paulino Aires Ferreira De Lima
Original Assignee
Inov Inesc Inovação Inst De Novas Tecnologias
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Inov Inesc Inovação Inst De Novas Tecnologias filed Critical Inov Inesc Inovação Inst De Novas Tecnologias
Priority to PT106777A priority Critical patent/PT106777B/pt
Publication of PT106777A publication Critical patent/PT106777A/pt
Publication of PT106777B publication Critical patent/PT106777B/pt

Links

Landscapes

  • Debugging And Monitoring (AREA)

Abstract

A INJEÇÃO DE VULNERABILIDADES EM SOFTWARE TEM SIDO ATÉ AO PRESENTE REALIZADA DE FORMA NÃO AUTOMATIZADA E DEPENDENTE DE CADA PROGRAMA-ALVO E VULNERABILIDADE A INJETAR. O PRESENTE INVENTO ENQUADRA-SE NO CAMPO DE SEGURANÇA EM REDES E SISTEMAS E REFERE-SE A UM MÉTODO E SISTEMA PARA PRODUÇÃO AUTOMÁTICA DE SOFTWARE VULNERÁVEL, ATRAVÉS DO CONDICIONAMENTO DO PROCESSO DE COMPILAÇÃO OU INTERPRETAÇÃO DO CÓDIGO-FONTE. RECORRENDO A UMA BASE DE DADOS DE VULNERABILIDADES OBTIDAS DE DIVERSAS FONTES, O PRESENTE INVENTO ANALISA QUAIS DESTAS PODEM SER INJETADAS NUM DETERMINADO PROGRAMA-ALVO, UTILIZANDO PARA TAL UMA REPRESENTAÇÃO INTERMÉDIA NORMALIZADA DESSE PROGRAMA, PROCEDENDO POSTERIORMENTE À INJEÇÃO E VERIFICAÇÃO DA EXPLORABILIDADE DESSAS VULNERABILIDADES. O PRESENTE INVENTO PERMITE A AUTOMATIZAÇÃO DO PROCESSO DE INJEÇÃO DE VULNERABILIDADES, SENDO PARTICULARMENTE APLICÁVEL PARA A CRIAÇÃO DE PROGRAMAS DE TESTE VULNERÁVEIS PARA TESTAR APLICAÇÕES DE ANÁLISE DE VULNERABILIDADES, BEM COMO GERAR PROGRAMAS APARENTEMENTE VULNERÁVEIS COM O INTUITO DE ATRAIR ATACANTES.

Description

DESCRIÇÃO
Método e sistema para produção automática de software vulnerável através da injeção de código vulnerável durante o processo de compilação ou interpretação
Domínio técnico da invenção presente invento enquadra-se no campo da segurança em redes e sistemas informáticos, e refere-se a um método e a um sistema para produção automática de software vulnerável, com base na injeção de código vulnerável aquando do processo de compilação e/ou interpretação.
Estado da técnica anterior
A injeção de código-fonte vulnerável em programas de computador (Software em inglês), também conhecida como injeção de vulnerabilidades tem sido, até à data, maioritariamente utilizada por pessoas cuja intenção é violar a segurança dos sistemas computacionais com intuitos maliciosos e/ou criminosos, pese embora a sua aplicação possa ser feita, para fins benignos, em diversos domínios.
As técnicas de injeção de vulnerabilidades podem ser vistas como uma generalização das técnicas de injeção de faltas [1], sendo estas geralmente focadas na inserção de comportamento num programa de computador de forma a gerar uma falta quando sob determinadas circunstâncias e assim testar se o sistema é capaz de sobreviver a estas. No caso da injeção de vulnerabilidades, esta é focada não apenas no teste da capacidade de sobrevivência do sistema, mas também em testar as capacidades que um atacante possa ser capaz de adquirir como resultado da exploração de uma vulnerabilidade, enquanto o sistema se mantém em funcionamento pleno.
Apesar da diferença significativa entre as duas abordagens em termos de resultado final, as técnicas usadas na injeção de faltas podem também ser usadas na injeção de vulnerabilidades:
• Injeção em tempo de execução (run-time)- Esta classe de injeção baseia-se na inserção de instruções que não existiam inicialmente no programa enquanto este está em execução. Isto pode ser conseguido através da utilização de um temporizador de modo a inserir falhas em determinados pontos no tempo, usando exceções de forma a transferir o controlo para o injetor de falhas quando uma determinada condição for atingida, ou ainda através da substituição de um conjunto de instruções por outro quando estas forem encontradas;
• Injeção em tempo de compilação (compile-time)- Diversas linguagens de programação fazem uso de um processo denominado compilação, de forma a converter uma representação textual de um programa de computador, chamado código-fonte, num formato executável antes deste estar pronto a executar. Neste caso, a injeção das faltas é feita condicionando a forma como este processo de conversão é executado;
• Injeção em código-fonte - Neste caso, a injeção das faltas é feita diretamente no código-fonte antes deste passar pelo processo de compilação.
No caso das injeções efectuadas em tempo de compilação, estas baseiam-se na modificação do processo de transformação do código-fonte realizado pelo compilador. De forma a converter o código-fonte num formato executável, o compilador comporta diversas etapas de forma a validar que este está conforme a sintaxe da linguagem de programação correspondente, e a optimizar o executável gerado para o sistema a que se destina. As várias fases deste processo são descritas em [2,3].
Algumas abordagens foram já propostas para endereçar o problema da injeção de vulnerabilidades em programas de computador, pese embora se destinem a linguagens de programação em especifico e a conjuntos de vulnerabilidades limitados. Em [4] é apresentada uma ferramenta de injeção de vulnerabilidades cujo foco são as aplicações Web programadas na linguagem PHP, com o intuito de injetar vulnerabilidades de injeção de SQL e de cross site scripting (XSS). Em [5] é apresentada outra ferramenta de injeção de vulnerabilidades também focada na linguagem de programação PHP, e também com o intuito de injetar vulnerabilidades de injeção de SQL e cross site scripting (XSS). No entanto, esta ferramenta contém uma arquitetura de interfaces que permite suportar tanto linguagens de programação adicionais bem como outros tipos de vulnerabilidades.
Descrição geral presente invento refere-se a um método e sistema para injetar automaticamente vulnerabilidades em programas de computador, adiante designados de programa-alvo, usando técnicas de injeção em tempo de compilação/interpretação com o objectivo de produzir amostras de programas de computador vulneráveis.
presente invento é composto por um método e de receber um programa-alvo codificado em sistema capaz qualquer das linguagens de programação suportadas e convertê-lo para uma representação intermédia, de forma a ser possível avaliar quais as vulnerabilidades passíveis de ser injetadas, injetar as vulnerabilidades selecionadas na representação intermédia obtida e, por fim, converter a representação intermédia modificada de volta para a linguagem de programação original.
presente invento é composto por um método e sistema para detectar sistematicamente pontos num programa-alvo nos quais uma vulnerabilidade pode ser injetada. Adicionalmente, o presente invento compreende um método e sistema para validar se é possível explorar as vulnerabilidades injetadas, permitindo que um atacante potencialmente explore uma fraqueza específica inserida no programa modificado.
presente invento pode ser considerado uma extensão às técnicas de manipulação/optimização utilizadas pelos compiladores e interpretadores de programas de computador, com o objetivo de injetar vulnerabilidades em pontos específicos do programa-alvo de forma a fazê-lo expor uma determinada vulnerabilidade.
presente invento compreende um método e sistema para efetuar procuras em bases de dados de vulnerabilidades, de forma a aprender novos vectores e métodos de ataque, e incorporar esta informação no sistema numa forma que possa ser posteriormente utilizada para injetar as novas vulnerabilidades.
presente invento compreende um método e sistema que pode ser usado para, baseado numa análise das vulnerabilidades que podem ser injetadas em cada ponto de um determinado programa-alvo, gerar um conjunto alargado de programas de computador de teste vulneráveis, com diferentes tipos e distribuições de vulnerabilidades injetadas nestes.
presente invento é também composto por um método e sistema para garantir o controlo das ações tomadas no sistema, bem como para manter a confidencialidade e integridade da informação acerca das amostras de testes geradas.
presente invento pode ser aplicado em particular para gerar conjuntos de programas de teste vulneráveis, que podem ser utilizados para validar a quantidade de vulnerabilidades que uma ferramenta de análise de vulnerabilidades é capaz de detectar ou, por outro lado, para gerar sistemas que podem ser usados para iludir e atrair potenciais atacantes (também conhecidos como Honeypot) [2] sem que seja facilmente reconhecido como tal, dado ser possível gerar amostras únicas baseadas em diferentes programas de computador.
Descrição das figuras
Para uma mais fácil compreensão da técnica juntam-se em anexo as figuras, as quais, representam realizações preferenciais que, contudo, não pretendem limitar o objeto da presente técnica.
A Figura 1 ilustra a arquitetura interna do sistema, sendo esta composta pelo Módulo de Seleção de Vulnerabilidades (5), Módulo de Análise de Pontos de Injeção (6), Módulo de Injeção de Vulnerabilidades (7), Gestor de Configuração de Vulnerabilidades (8), Gestor de Informação de Injeção (9), Base de Dados (10) e Adaptadores de Linguagem de Programação (3,4) que interagem com os programas de computador especificados nessa linguagem através dos Interfaces para a Linguagem (1,2).
A Figura 2 sistema de sendo este Tradução do Programa de Vulnerabilidades a Avaliar das Vulnerabilidades (13) Inj etar (14), Inversa do Programa de intermédio de decisão, mediante interação do das etapas (13) e ilustra forma a processo > Programa a sequência de passos utilizados pelo efetuar a injeção de vulnerabilidades composto pelas seguintes etapas:
Computador (11), Seleção de (12), Avaliação da Injetabilidade Definição das Vulnerabilidades a Vulnerabilidades (18) e Tradução um passo (15) que, repetição seja não r
Injeção das
Computador (19)
Avaliação operador, (14) caso (18) , existindo Satisfatória? pode conduzir à a avaliação satisfatória (16) ou continuar caso seja satisfatória (17) para a etapa Injeção das Vulnerabilidades (18).
Descrição de formas de realização presente invento consiste num método e sistema para modificar programas-alvo de forma a criar programas de teste vulneráveis, baseado na injeção de vulnerabilidades que faça estes providenciarem uma funcionalidade para o qual não foram inicialmente desenhados.
De acordo com as classes de métodos usados para injetar faltas em programas de computador descritos no estado da técnica anterior, a injeção de vulnerabilidades é efectuada em tempo de compilação/interpretação, seja esta efectuada através da manipulação compilado/interpretado, do código-fonte durante o antes deste processo compilação/interpretação, modificações no resultado através da introdução da compilação/interpretação, ser de de ou ainda aplicando modificações imediatamente antes deste ser executado.
Comparativamente com as abordagens anteriormente apresentadas para a injeção de vulnerabilidades em programas de computador, o presente invento compreende os seguintes aspectos inovadores:
• É focado na fase de compilação/interpretação - As abordagens anteriormente seguidas focam-se na injeção de vulnerabilidades no código-fonte dos programas de computador, interpretando para este efeito os ficheiros de código-fonte originais sobre os quais são injetadas as vulnerabilidades, convertendo-os de volta para ficheiros de código-fonte após a injeção.
Comparativamente com estas abordagens, o presente invento é capaz de injetar um conjunto mais abrangente de vulnerabilidades, uma vez que este intervém no processo de compilação/interpretação, sendo que pode anular algumas das verificações de segurança efectuadas pela maioria dos compiladores. Esta capacidade faz com que seja possível injetar vulnerabilidades que seriam removidas pelo compilador caso fossem usadas abordagens tal como proposto em [4] e [5];
• Recorre a relações de necessidade/oferta para definir as vulnerabilidades e padrões de injeção - Nas abordagens anteriormente usadas, a definição de vulnerabilidades é baseada na descrição do conjunto de instruções que devem ser encontradas de forma a ser possível injetar uma determinada vulnerabilidade. No entanto, caso exista alguma variância na forma como as instruções estejam codificadas no programa, a ferramenta de injeção pode não ser capaz de detectar um passível ponto de injeção. Comparativamente invento permite a padrões de injeção que um dado caminho e em termos das adicionadas de vulnerabilidade.
Com isto, o padrões de vulnerabilidade, exaustiva das formas ser adquirida, bem capacidade quando é vulnerabilidades, reduzindo requeridos e, baseado de injeção com essas descrição em termos num programa de computador deve ter, capacidades que necessitam ser forma a expor uma determinada abordagens, o presente das vulnerabilidades e de capacidades modulares presente invento permite a definição de forma modular e independente de cada oferecendo uma definição mais precisa e nas quais cada vulnerabilidade pode como reusar a definição de vulnerabilidades.
definição de cada Adicionalmente, um conjunto de ser simplificada a procura ao conjunto comum de capacidades pelo conjunto de vulnerabilidades selecionado nos resultados da procura, compor os pontos possíveis.
r entre feita uma procura por a procura pode ao conjunto presente invento pode ser também definido como um método e sistema com capacidade para codificado em qualquer das suportadas, convertê-lo para uma após ter efectuado modificações para a linguagem de programação intermédia é tal que permite definidos em qualquer das suportadas de forma a realizar vulnerabilidades uniformemente, expressividade e a semântica da possível para de forma receber um programa-alvo linguagens de programação representação intermédia e, nesta, convertê-lo de volta original. Esta representação representar programas-alvo linguagens de a
preservando linguagem de tal feito, cada uma das forma a ser bidirecional suportadas, da programação descoberta e injeção no entanto programação é definido linguagens origem. De mapeamento programação entre a gramática da linguagem original representação intermédia.
de a de um de a representar a tradução e a gramática da
Numa forma de realização, o método ou caracterizado por ser capaz de injetar provenientes de diversas fontes:
sistema é ainda vulnerabilidades • Vulnerabilidades vulnerabilidades derivadas de bases existentes, ou de dados provenientes de de linguagens normalizadas de descrição de vulnerabilidades;
• Vulnerabilidades especificadas pelo administrador do sistema.
As vulnerabilidades provenientes destas fontes passam por um processo automático ou semiautomático de transformação de forma a facilitar o processo de análise de viabilidade e a injeção destas, convertendo-as para o formato de especificação usado no sistema.
A especificação das vulnerabilidades, e a forma como estas podem ser injetadas num programa de computador, é efectuada usando uma combinação das seguintes técnicas:
• A definição da instrução especifica, e a forma como esta deve ser modificada, de forma a expor uma determinada vulnerabilidade. Como exemplo, é apresentado o seguinte trecho de código, que representa a conversão de um endereço IP introduzido pelo utilizador para um nome de computador (Hostname):
void host_lookup(char *user_supplied_addr){ struct hostent *hp; in_addr_t *addr; in_addr_t inet_addr(const char *cp); validate_addr_form(user_supplied_addr); addr = inet_addr(user_supplied_addr); hp = gethostbyaddr( addr, sizeof(struct in_addr), AF_INET);
char hostname[64];
strcpy(hostname, hp->h_name, strlen(hostname));
Neste caso, a vulnerabilidade a explorar é a validação imprópria do tamanho de uma estrutura de dados, aquando da cópia de uma linha de texto introduzido pelo utilizador (strcpy). 0 trecho de código apresentado acima seria vulnerável caso a instrução na qual é efectuada a cópia do texto fosse substituída pela linha abaixo:
strcpy(hostname, hpNeste caso, a definição do padrão de código a ser encontrado seria uma chamada à função de sistema strcpy usando uma estrutura de dados de destino de tamanho estaticamente definido, sendo este tamanho validado na chamada à função de sistema. Caso este padrão fosse encontrado, a vulnerabilidade seria introduzida através da remoção da validação do tamanho da estrutura de dados de destino na chamada argumento).
• A definição do conjunto substituir uma instrução, encontrada no código-fonte técnica, pode ser código, parâmetro introduzido:
à função de sistema (3o que devem instruções,
Como exemplo desta seguinte de instruções ou conjunto de original.
, pode ser considerado o seguinte trecho de que explora uma vulnerabilidade de validação do
PreparedStatement stmt = connection.prepareStatement(SELECT * FROM users WHERE userid=? AND password=?);
stmt.setString(1, userid);
stmt.setString(2, password);
trecho de código corresponde a uma consulta a uma base de de dados (SQL query) , na qual é introduzida o nome utilizador e password como argumentos. Substituindo trecho de código acima com o apresentado abaixo, programa ficaria vulnerável a injeção de SQL:
String query = SELECT * FROM users WHERE userid ='+ userid + + AND password=' + password +
Statement stmt = connection.createStatement();
ResultSet rs = stmt.executeQuery(query);
padrão a ser procurado seria um objecto PreparedStatement, que de uma consulta SQL. Quando instruções no qual o objecto seria substituído pelo definida a injeção o
de execução conjunto de é usado instruções no qual a consulta é portanto vulnerável de texto, conj unto de ter de já ser um dado capacidades que adquirido num determinado possível injetar o que precisa de exposta.
uma ser validar o
Neste caso, instanciação indiciaria a encontrado, o
PreparedStatement conjunto de usando uma linha de código SQL;
• A definição do programa precisa ponto de forma a vulnerabilidade, bem como modificado para que esta seja
Usando o exemplo da injeção de SQL apresentado acima, e de forma a ser possível injetar uma vulnerabilidade de injeção de SQL, o programa de computador tem de, num determinado ponto, construir uma consulta SQL, esta consulta tem de requerer introdução de informação pelo utilizador, e é usada alguma condição para conteúdo introduzido pelo utilizador. Neste injetar esta vulnerabilidade, é necessária a de três capacidades: Cônsulta_SQL, Interação e Validação_dados. Cada uma destas capacidades seria independentemente definida em termos do conjunto de instruções que permitiria adquiri-la.
caso, para existência utilizador
Finalmente, e caso fosse possível descobrir um caminho no programa no qual existissem as três capacidades necessárias, o caminho de injeção seria definido como a remoção de uma das capacidades, podendo neste caso ser definido como a substituição da capacidade Validação_dados por uma condição que é sempre verdadeira seja qual for o conteúdo introduzido.
A capacidade do presente invento de obter vulnerabilidades de diversas fontes e injetá-las em qualquer programa-alvo no qual estas encaixem é um dos seus aspectos inovadores.
Adicionalmente, a capacidade do presente invento de injetar vulnerabilidades em qualquer linguagem de programação para a qual este tenha um adaptador, de forma única e normalizada é outro dos seus aspectos inovadores.
A Figura 2 ilustra a arquitetura interna do sistema, sendo esta composta pelos seguintes componentes que serão de seguida descritos:
• Adaptador de Linguagem de Programação (3,4);
• Gestor de Configuração de Vulnerabilidades (8);
• Módulo de Seleção de Vulnerabilidades (5);
• Módulo de Análise de Pontos de Injeção (6);
• Módulo de Injeção de Vulnerabilidades (7);
• Gestor de Informação de Injeção (9);
• Base de Dados (10).
Os Adaptadores de Linguagem de Programação (3,4) são os componentes usados para mediar a interação com os Interfaces para as Linguagens de Programação (1,2) para cada uma das linguagens suportadas, mediando a interação com o compilador/interpretador destas linguagens. De forma a simplificar a interação com os diversos Adaptadores de Linguagem de Programação (3,4), o sistema disponibiliza uma arquitetura de interfaces, na qual cada Adaptador de Linguagem de Programação (3,4) tem de implementar duas operações chave, que correspondem à primeira e última etapas do processo de injeção de vulnerabilidades, Tradução do Programa-alvo (11) e Tradução Inversa do Programa de Teste Vulnerável (19) respectivamente, ilustrado na Figura 2:
• Obter uma representação em árvore de sintaxe abstrata do programa-alvo, sendo esta árvore de sintaxe abstrata conforme o formato de representação intermédia usada no sistema. De forma a ser possível obter uma árvore de 9 um determinado programa-alvo que a representação
Adaptador de defina uma ambígua usando mas sintaxe abstrata para esteja alinhada necessário Programação bidirecional, transformação como, mas não limitado operação caracteriza-se por, aquando programa-alvo na representação em abstrata da linguagem de programação a transformação definida, convertê-la para o formato de representação intermédia do sistema;
• Converter a representação intermédia em árvore de sintaxe abstrata na qual foram efectuadas modificações de forma a inserir um determinado conjunto de vulnerabilidades de volta para a representação original na sua linguagem de programação, de forma a continuar o processo de compilação/interpretação. A conversão da árvore de sintaxe abstrata é efectuada usando a transformação bidirecional definida. É de notar que a implementação desta operação pode envolver mais do que fase de compilação/interpretação, de forma a não é removida processo de com que cada (3,4) não > como, intermédia é Linguagem de transformação linguagem de XSLT [6]. Esta recepção de um de sintaxe e usando uma a, da árvore original, uma fase de compilação/interpretação, garantir que a vulnerabilidade inserida como resultado da conclusão do compilação/interpretação.
Em formas alternativas ou complementares vários Adaptadores de Linguagem de Programação ser desenvolvidos de forma a suportar as linguagens de programação cujo uso é mais comum. Algumas das linguagens de programação para as quais um adaptador pode ser desenvolvido são, embora não limitado a estas, C, C+ + , C#, Java, Python, Ruby, Common Lisp.
de realização, (3,4) podem linguagens
Gestor de Configuração de Vulnerabilidades (8) é o componente responsável pela gestão e atualização da configuração das vulnerabilidades que o sistema é capaz de injetar nos programas-alvo.
As vulnerabilidades a ser injetadas podem ser descritas em qualquer das, mas não limitado a, linguagens e taxonomias de vulnerabilidades ou podem ser obtidas de qualquer das, mas não limitado a, bases de dados de vulnerabilidades: CVE, CWE, AVDL, OSVDB, Bugtraq, exploit-db.
Para cada uma das vulnerabilidades importadas, é criada uma nova entrada no sistema descrevendo-a, definindo a estratégia usada para a procurar e injetar, bem como o que deve ser procurado e o que deve ser injetado quando essa procura tiver resultado positivo. A especificação do padrão a ser procurado e a ser injetado deve ser efectuada na representação abstrata intermédia, de forma a que seja possível procurá-la em qualquer das linguagens de programação suportadas.
Como exemplo pode tomar-se a injeção de SQL descrita acima. Neste caso, seria definido como estratégia de procura e injeção a captura de um determinado conjunto de instruções a ser substituído por outro de forma a expor aquela vulnerabilidade. 0 padrão a ser encontrado seria compreendido por uma instanciação de um objeto PreparedStatement e o conjunto de instruções que fazem uso deste. 0 padrão, após encontrado, é usado para, baseado no texto usado para definir a procura SQL e os parâmetros que posteriormente são definidos, criar uma procura SQL numa linha de texto sem estas validações, na qual é possível fazer uma injeção de SQL.
Numa forma de realização, adicionalmente às vulnerabilidades importadas de fontes externas, o administrador do sistema pode definir vulnerabilidades adicionais, adicionar condições de injeção ou adicionar condições complementares ou ainda definir formas adicionais de injetar uma determinada vulnerabilidade.
Módulo interagir inj eção.
etapas
Vulnerabilidades Vulnerabilidades vulnerabilidades potenciais pontos Vulnerabilidades
Vulnerabilidades o sistema responsável segunda (12) , suporta as quais
Na quarta etapa (14), o apresenta os baseados na segunda vulnerabilidades de teste vulnerável.
é usado para processo de e quarta Seleção____de de Seleção de e controlar Este módulo é (12,14) . Na a Avaliar (5) para de injeção.
a Injetar
Vulnerabilidades (5) injeção encontrados vulnerabilidades obtida permitir a seleção de injetadas em cada programa (5) durante o pela segunda etapa,
Módulo de Seleção de a definição das devem ser procurados , Definição de
Módulo de Seleção passíveis pontos na definição etapa, de forma que devem de de de ser
Na etapa de Seleção das Vulnerabilidades a Avaliar (12), são definidos os parâmetros que guiarão a análise dos pontos de injeção de vulnerabilidades. Esta definição pode ser efectuada de duas formas:
• 0 operador do sistema especifica as classes de vulnerabilidades a ser procuradas - Esta definição de procura pode produzir resultados mais rapidamente, para além de ser útil em programas nos guais determinadas classes de vulnerabilidades não façam sentido. Quando uma dada vulnerabilidade é selecionada para análise o operador do sistema pode definir o número exato, o número máximo e/ou minimo de pontos de injeção a ser encontrados para aguela vulnerabilidade em especifico. Da mesma forma, o operador do sistema pode definir o número global de potenciais pontos de injeção a encontrar. Em gualguer um dos parâmetros, e caso nada seja especificado, será definido gue a procura deve ser feita extensivamente para o programa completo, até gue este tenha sido extensivamente testado contra aguelas vulnerabilidades;
• 0 operador de sistema especifica uma procura por todos os passíveis pontos de injeção para todas as vulnerabilidades conhecidas no sistema - Neste caso, a definição da procura é mais abrangente do que quando quando apenas algumas vulnerabilidades são selecionadas. No entanto, em alguns contextos este modo pode ser impraticável, dado gue alguns programas podem ser muito grandes e algumas vulnerabilidades podem não fazer sentido nesse contexto, tornando a análise excessivamente lenta. Neste modo de definição apenas o número máximo de potenciais pontos de injeção a encontrar é definido.
Uma vez definido o tipo de procura a fazer para um determinado programa-alvo, bem como a sua cardinalidade, esta informação é passada para a próxima etapa do processo de injeção, Avaliação de Injetabilidade das Vulnerabilidades (13), que é realizada pelo Módulo de Análise dos Pontos de Inj eção (6) .
Na etapa de Definição de Vulnerabilidades a Injetar (14), e após o Módulo de Análise dos Pontos de Injeção (6) ter efectuado a procura dos pontos de injeção potenciais de acordo com a definição de procura criada na segunda etapa (12) do processo de injeção, o operador recebe uma listagem dos pontos de injeção encontrados para cada uma das vulnerabilidades selecionadas, bem como a sua caracterização em termos da sua localização no programa-alvo e ainda na árvore de sintaxe abstrata.
No caso de uma definição de procura na qual o operador do sistema especificou as vulnerabilidades para as quais pontos de injeção deviam ser procurados, e no caso dos resultados desta procura não serem satisfatórios, o operador pode definir vulnerabilidades adicionais para as quais pontos de injeção devem ser procurados, e assim reiniciar a etapa de Avaliação de Injetabilidade das Vulnerabilidades (13).
Caso não seja necessário reiniciar a etapa de Avaliação de Injetabilidade das Vulnerabilidades (13), o operador do sistema pode definir, para os pontos de injeção encontrados, aqueles nos quais deve ser injetada a vulnerabilidade no programa de teste vulnerável. Da mesma forma, o operador pode selecionar o número exato, máximo e/ou mínimo de vulnerabilidades a injetar sem que seja selecionado nenhum tipo de vulnerabilidade em específico. Neste caso, o sistema selecionará aleatoriamente as vulnerabilidades a injetar de entre os pontos de injeção detetados.
Para além disto, o operador do sistema pode definir que seja gerada mais do que um programa de teste vulnerável para o programa-alvo. Neste caso, o operador pode fazer uma definição manual das vulnerabilidades a inserir em cada um programas de teste vulneráveis a criar. Da mesma forma, o operador do sistema teste vulneráveis a e/ou máximo de pode definir o número de programas de criar, e ainda o número exato, mínimo vulnerabilidades a inserir, sendo posteriormente o Módulo de Seleção de Vulnerabilidades (5) responsável por escolher, de forma aleatória, o conjunto de pontos de injeção a ser usados em cada programa de teste vulnerável.
operador do vulnerabilidades avaliar se uma sistema pode ainda definir que as injetadas sejam validadas, de forma a determinada vulnerabilidade injetada é explorável ou não. Quando esta validação é feita, o operador pode ainda definir que apenas as vulnerabilidades cuja exploração é possível devem ser
Finalmente, e quando a Vulnerabilidades a Injetar especificação dos programas de passada ao Módulo de Injeção injetadas, ou vice-versa.
etapa de Definição de (14) é completada, a teste vulneráveis a criar é de Vulnerabilidades (7), de forma a criar os programas de teste vulneráveis especificados.
Módulo de Análise de Pontos de Injeção (6) é responsável por, uma vez recebida uma lista das vulnerabilidades para as quais devem ser procurados pontos de injeção nos quais estas possam ser inseridas, fazer uma procura extensiva pela representação intermédia em árvore de sintaxe abstrata do programa-alvo obtida do Adaptador de Linguagem de Programação (3,4) correspondente. Esta procura corresponde à etapa Avaliação da Injetabilidade das Vulnerabilidades (13).
Este componente pode fazer uso de diversos algoritmos de procura tal como, mas não limitado a, profunidade-primeiro (do Inglês, depth-first) [7], largura-primeiro (em Inglês, breadth-f irst) [8], profundidade-primeiro com aumento iterativo da profundidade (em Inglês, iterative deepening depth-first) [9], etc.
Dependendo da especificação da estratégia de procura a usar para cada vulnerabilidade selecionada, o sistema pode ser capaz de procurar mais do que uma vulnerabilidade em cada ciclo de procura.
Uma vez concluída a Avaliação da Injetabilidade das Vulnerabilidades (13) passíveis de ser utilizados os resultados da procura são devolvidos ao Módulo de Seleção de Vulnerabilidades (5) , de forma a estes serem escolhidos e validados e posteriormente as vulnerabilidades selecionadas serem injetadas.
Módulo de Injeção de Vulnerabilidades (7), com base na especificação dos programas de teste vulneráveis a criar, é responsável por operar as modificações necessárias à representação intermédia em árvore abstrata, de forma a que o programa gerado exponha as vulnerabilidades desejadas nos pontos especificados. A esta etapa do processo dá-se o nome de Injeção das Vulnerabilidades (18).
Caso na definição dos programas de teste vulneráveis a criar seja determinada a validação da explorabilidade das vulnerabilidades a injetar, este módulo simula todos os caminhos de execução possíveis de forma a validar se existe pelo menos um caminho que possa ser usado para explorar essa vulnerabilidade. De forma a fazer esta validação recorre-se a várias técnicas como por exemplo, mas não limitado a, execução simbólica [10], teste concreto e simbólico (em Inglês, Concolic Testing) [11], teste fuzzy [12], etc. Nos casos em que, baseado na especificação, seja determinado que em resultado da validação da explorabilidade de uma determinada vulnerabilidade, esta não deve ser inserida, o Módulo de Injeção de Vulnerabilidades (7) é responsável por restaurar o estado da representação intermédia em árvore abstrata ao estado anterior à injeção dessa vulnerabilidade.
Por cada vulnerabilidade injetada é gerado um evento que é posteriormente enviado para o Gestor de Informação de Injeção (9) de forma a manter um registo das vulnerabilidades inseridas em cada programa de teste vulnerável. Este evento descreve o fluxo de eventos/ações que conduzem à vulnerabilidade inserida, bem como o resultado dos testes de validação de explorabilidade, caso estes tenham sido efetuados.
Uma vez concluída a Injeção das Vulnerabilidades (18), a execução é devolvida ao Adaptador de Linguagem de Programação (3,4) de forma a concluir o processo de compilação/interpretação, fazendo a Tradução Inversa do Programa de Computador (19) . Uma vez este processo concluído, o resultado final do processo de injeção de vulnerabilidades, bem como os programas de teste vulneráveis, são enviados ao Gestor de Informação de Injeção (9) como um evento final.
O Gestor de informação de injeção (9) é responsável por processar os eventos gerados pelo Módulo de Injeção de Vulnerabilidades (7) e, utilizando um conjunto de mecanismos de proteção, persistir a informação de injeção de uma forma que assegure a confidencialidade, integridade e não-repúdio das ações tomadas no sistema. Da mesma forma, este módulo é responsável por disponibilizar esta informação aos operadores e administradores do sistema de acordo com as suas permissões.
Este componente pode ser definido em torno de duas funcionalidades principais:
• Persistência dos eventos de injeção gerados pelos outros módulos:
o Eventos de injeção de vulnerabilidades - Estes eventos são gerados cada vez que uma determinada vulnerabilidade é injetada no programa-alvo. Este evento é persistido na base de dados, bem como a referência do programa de teste vulnerável a que este pertence, para além da informação acerca da vulnerabilidade injetada, isto é, validações de explorabilidade efectuadas, fluxo de execução que pode conduzir à sua exploração, ponto da representação intermédia esta foi inserida, etc.;
em árvore abstrata onde
Eventos de finalização de programa de teste vulnerável - Estes eventos relativa ao programa-alvo injetadas vulnerabilidades, agregam a informação sobre o qual foram bem como informação acerca do resultado final da injeção. Mais do que um destes eventos pode ser criado para cada programa-alvo, dependendo do número de programas de teste vulneráveis criados.
• Consulta de informação - Este componente é utilizado também para aceder à informação relativa a cada programa de teste vulnerável gerado pelo sistema. 0 acesso a esta informação está condicionado a controlo de acessos, de forma a garantir que um determinado operador apenas acede a informação relativa a programas de teste vulneráveis criados para os quais tenha autorização.
A Base de Dados (10) é utilizada para persistir a informação relativa ao funcionamento do sistema. Três tipos de informação são guardados:
• Informação de vulnerabilidades, nomeadamente relativa às vulnerabilidades obtidas de fontes externas e especificadas no sistema, de forma ao sistema ser capaz de as usar como vulnerabilidades injetáveis;
• Informação de controlo de acessos, de forma a restringir o acesso e a informação que pode ser acedida por cada administrador e operador do sistema;
• Informação dos programas de teste vulneráveis criados, com o objectivo de manter registo de cada amostra gerada, e das vulnerabilidades que esta contém.
Mecanismos de Proteção
De forma a restringir o uso indevido do sistema ou, por outro lado, de forma a evitar que este possa ser usado por um atacante, ou a informação guardada neste, é usado um conjunto de mecanismos de proteção:
• Controlo de acessos - 0 acesso ao sistema é condicionado por nome de utilizador e palavra-passe de forma a, por um lado, manter um registo da atividade de um determinado utilizador no sistema, e por outro lado a restringir a informação relativa a vulnerabilidades e programas de teste vulneráveis que este pode aceder;
• Segurança da Base de Dados (10) - Dada a natureza sensível da informação armazenada na Base de Dados (10), são necessárias medidas de proteção adicionais, de forma a garantir que um atacante não pode aceder a esta informação. No caso da informação relativa a programas de teste vulneráveis, e de forma a evitar que um atacante que seja capaz de aceder à Base de Dados (10) consiga aceder à especificação das vulnerabilidades inseridas num determinado programa de teste vulnerável, esta informação é protegida usando técnicas criptográficas, sejam estas de criptografia simétrica ou assimétrica.
Referências [1] Arlat, J., Costes, a., Crouzet, Y., Laprie, J.C., Powell, D.: Fault injection and dependability evaluation of fault-tolerant systems. IEEE Transactions on Computers. 42, 913-923 (1993).
[2] Muchnick, S.: Advanced Compiler Design and
Implementation. Morgan Kaufmann (1997).
[3] Aho, A., Lam, M., Sethi, R., Ullman, J. : Compilers: principies, techniques, and tools. (2007) .
[4] Fonseca, J., Vieira, M., Madeira, H.: Vulnerability &
attack injection for web applications. 2009 IEEE/IFIP
International Conference on Dependable Systems & Networks. pp. 93-102. IEEE (2009).
[5] Vieira, F.: Realistic Vulnerability Injections in PHP Web Applications, (2011).
[6] http://www,w3.org/TR/xslt-30/ [7] Even, S.: Graph Algorithms. Cambridge University Press (2011).
[8] Breadth-first search, http://en,wikipedia,org/wiki/Breadth~first search.
[9] Russell, S., Norvig, P.: Artificial Intelligence: A Modern Approach (3rd Edition). Prentice Hall (2009).
[10] King, J.C.: Symbolic execution and program testing.
Communications of the ACM. 19, 385-394 (1976).
[11] Williams, N., Marre, B., Mouy, P., Roger, M. : PathCrawler: Automatic Generation of Path Tests by Combining Static and Dynamic Analysis. Dependable Computing EDCC 2005. pp. 281-292. Springer Berlin (2005).
[12] Sutton, M., Greene, A., Amini, P.: Fuzzing: Brute Force Vulnerability Discovery. Addison-Wesley Professional (2007).
A presente realização não é, naturalmente, de modo algum restrita às realizações descritas neste documento e uma pessoa com conhecimentos médios da área poderá prever muitas possibilidades de modificação da mesma sem se afastar da ideia geral, tal como definido nas reivindicações.
As realizações preferenciais acima descritas são obviamente combináveis entre si. As seguintes reivindicações definem adicionalmente realizações preferenciais.

Claims (8)

1. Método de produção de software vulnerável, caracterizado por injetar vulnerabilidades em programas ou aplicações durante a fase de compilação, recorrendo a um compilador modificado para introduzir alterações especificas durante o processo de compilação, das quais resultará uma ou várias vulnerabilidades no software produzido.
2. Método de acordo com a reivindicação 1, caracterizado por durante o processo de compilação:
traduzir o código-fonte do programa original (11), para uma representação intermédia, a qual é mapeada bidireccionalmente com as linguagens de programação suportadas e permite representar os programas-alvo definidos em qualquer das linguagens de programação suportadas;
localizar através de um algoritmo de procura em árvore na representação intermédia, os pontos de injeção de vulnerabilidades (13), que correspondam aos critérios previamente selecionados por um operador (12);
injetar nos pontos de injeção de vulnerabilidade (18) encontrados as vulnerabilidades selecionadas;
após ter efetuado modificações de introdução de vulnerabilidades na representação intermédia, traduzir a representação intermédia para a linguagem de programação original (19) de forma a continuar o processo de compilação.
3. Método de acordo com qualquer uma das reivindicações 1 ou 2, caracterizado por o mesmo processo de injeção de vulnerabilidades ser aplicado repetidamente nas várias fases da compilação.
4. Método de acordo com qualquer uma das reivindicações 1 ou 2, caracterizado por o processo de verificar a explorabilidade das vulnerabilidades injetadas ser compreendido por simular todos os caminhos de execução possíveis de forma a validar se existe pelo menos um caminho de execução que possa ser utilizado para explorar as vulnerabilidades injetadas.
5. Método de acordo com qualquer uma das reivindicações 1 ou 2, caracterizado por a especificação das vulnerabilidades e dos padrões de injeção ser realizada definindo as relações de necessidade/oferta de capacidades modulares que um dado caminho computador deve ter, vulnerabilidade seja de execução num programa de de forma a que uma dada aplicável, e em termos das capacidades que necessitem de ser adicionadas de forma a expor uma determinada vulnerabilidade.
6. Método de acordo com qualquer uma das reivindicações 1 ou
2, caracterizado por a verificação da explorabilidade das vulnerabilidades injetadas ser realizada recorrendo a um ou vários dos seguintes algoritmos: execução simbólica, teste concreto e simbólico, teste fuzzy.
Ί. Método de acordo com qualquer uma das reivindicações 1 ou
2, caracterizado por recorrer a adaptadores de linguagem de programação e compreender as seguintes operações: tradução do programa para uma representação intermédia (11) e tradução da representação intermédia para a linguagem original do programa (19) .
8. Método de acordo com qualquer uma das reivindicações 1, 2 ou 4, caracterizado por a seleção de vulnerabilidades a fornecer ao processo de verificação de explorabilidade incluir informação de especificação selecionada pelo Gestor de Configuração de Vulnerabilidades (8) e por a seleção de vulnerabilidades a fornecer ao processo de injeção de vulnerabilidades incluir informação de especificação selecionada pelo Módulo de Seleção de Vulnerabilidades (5);
Sistema de injeção de vulnerabilidades em aplicações, caracterizado por implementar produção de software vulnerável de acordo uma das reivindicações 1 a 8, e incluir programas ou o método de com qualquer os seguintes adaptadores de linguagens de programação (3,4): C, C++, C#, Java, Python, Ruby, Common Lisp.
10. Sistema de injeção de vulnerabilidades de acordo com a reivindicação 9, caracterizado por implementar o método de produção de software vulnerável de acordo com qualquer uma das reivindicações 1 a 8, e compreender um gestor de configuração de vulnerabilidades (8) que especifica e importa vulnerabilidades das seguintes linguagens e bases de dados de vulnerabilidades:
PT106777A 2013-02-11 2013-02-11 Sistema e método para produção automática de software vulnerável através da injeção de código vulnerável durante o processo de compilação ou interpretação PT106777B (pt)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PT106777A PT106777B (pt) 2013-02-11 2013-02-11 Sistema e método para produção automática de software vulnerável através da injeção de código vulnerável durante o processo de compilação ou interpretação

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PT106777A PT106777B (pt) 2013-02-11 2013-02-11 Sistema e método para produção automática de software vulnerável através da injeção de código vulnerável durante o processo de compilação ou interpretação

Publications (2)

Publication Number Publication Date
PT106777A PT106777A (pt) 2014-08-11
PT106777B true PT106777B (pt) 2015-08-20

Family

ID=51831945

Family Applications (1)

Application Number Title Priority Date Filing Date
PT106777A PT106777B (pt) 2013-02-11 2013-02-11 Sistema e método para produção automática de software vulnerável através da injeção de código vulnerável durante o processo de compilação ou interpretação

Country Status (1)

Country Link
PT (1) PT106777B (pt)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1094391A1 (en) * 1999-10-21 2001-04-25 Sun Microsystems, Inc. Method and apparatus for testing a computer system through software fault injection
US20100138817A1 (en) * 2008-12-01 2010-06-03 Microsoft Corporation In-place function modification
WO2011073982A1 (en) * 2009-12-15 2011-06-23 Seeker Security Ltd. Method and system of runtime analysis

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1094391A1 (en) * 1999-10-21 2001-04-25 Sun Microsystems, Inc. Method and apparatus for testing a computer system through software fault injection
US20100138817A1 (en) * 2008-12-01 2010-06-03 Microsoft Corporation In-place function modification
WO2011073982A1 (en) * 2009-12-15 2011-06-23 Seeker Security Ltd. Method and system of runtime analysis

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
Fonseca, J. et al., Vulnerability & attack injection for web applications, in Proc. IEEE/IFIP International conference on dependable systems & networks (DSN’09), Jun., 20090101 *
Vieira, F., Realistic Vulnerability Injections in PHP Web Applications", 5 Maio 2011, Dissertação de Mestrado – Universidade de Lisboa, 20110505 *

Also Published As

Publication number Publication date
PT106777A (pt) 2014-08-11

Similar Documents

Publication Publication Date Title
Martin et al. Finding application errors and security flaws using PQL: a program query language
Dahse et al. Simulation of Built-in PHP Features for Precise Static Code Analysis.
Saxena et al. A symbolic execution framework for javascript
Liang et al. Deepfuzzer: Accelerated deep greybox fuzzing
Schoepe et al. Explicit secrecy: A policy for taint tracking
US20130339930A1 (en) Model-based test code generation for software testing
Alhuzali et al. Chainsaw: Chained automated workflow-based exploit generation
Zhang et al. Automatic detection of Java cryptographic API misuses: Are we there yet?
Kim et al. Software vulnerability detection methodology combined with static and dynamic analysis
Shcherbakov et al. Serialdetector: Principled and practical exploration of object injection vulnerabilities for the web
Jensen et al. Thaps: automated vulnerability scanning of php applications
Luo et al. Tchecker: Precise static inter-procedural analysis for detecting taint-style vulnerabilities in php applications
Shi et al. Backporting security patches of web applications: A prototype design and implementation on injection vulnerability patches
Hamlen et al. Aspect-oriented runtime monitor certification
Edalat et al. ConsiDroid: A concolic-based tool for detecting SQL injection vulnerability in android apps
Bathia et al. Assisting programmers resolving vulnerabilities in java web applications
Arts et al. Extracting QuickCheck specifications from EUnit test cases
PT106777B (pt) Sistema e método para produção automática de software vulnerável através da injeção de código vulnerável durante o processo de compilação ou interpretação
Hauzar et al. On security analysis of PHP web applications
Alkhalaf Automatic Detection and Repair of Input Validation and Sanitization Bugs
Alhanahnah et al. Towards best secure coding practice for implementing SSL/TLS
Lashkaripour et al. A security analysis tool for web application reinforcement against SQL injection attacks (SQLIAs)
Monshizadeh et al. Patching logic vulnerabilities for web applications using logicpatcher
Gauthier et al. Semantic smells and errors in access control models: A case study in PHP
Eassa et al. IMATT: An Integrated Multi-Agent Testing Tool for the Security of Agent-Based Web Applications

Legal Events

Date Code Title Description
BB1A Laying open of patent application

Effective date: 20140619

FG3A Patent granted, date of granting

Effective date: 20150817