Pesquisadores da empresa Check Point na conferência DEF CON, detalhes da nova técnica de ataque a aplicações que usam versões vulneráveis do SQLite. O método da Check Point considera arquivos de banco de dados como uma oportunidade para integrar scripts de exploração de vulnerabilidades em várias subsistemas internos do SQLite, inacessíveis para exploração direta. Os pesquisadores também desenvolveram uma técnica de exploração que codifica o exploit na forma de uma cadeia de consultas SELECT no Banco de Dados SQLite, permitindo contornar o ASLR.
Para um ataque bem-sucedido, é necessário ter a capacidade de modificar os arquivos do banco de dados das aplicações alvo, o que limita o método a ataques em aplicações que utilizam o SQLite como formato para dados transitórios e de entrada. O método também pode ser aplicado para expandir o acesso local já obtido, por exemplo, para integrar backdoors ocultos nas aplicações utilizadas, assim como contornar mecanismos de proteção durante a análise de malware. A exploração após a substituição do arquivo ocorre no momento em que a aplicação executa a primeira consulta SELECT na tabela do banco de dados modificado.
Como exemplo, foi demonstrada a possibilidade de executar código no iOS ao abrir a lista de endereços, cujo arquivo de banco de dados "AddressBook.sqlitedb" foi alterado utilizando o método proposto. Para o ataque, foi explorada uma vulnerabilidade na função fts3_tokenizer (CVE-2019-8602, possibilidade de desreferenciamento de ponteiro), corrigida na atualização de abril do SQLite 2.28, junto com outra na implementação de funções de janela. Além disso, foi demonstrada a aplicação do método para o controle remoto de um servidor backend em PHP por parte de invasores, que acumula senhas interceptadas durante a execução do código malicioso (as senhas interceptadas eram transmitidas na forma de Banco de Dados SQLite).
O método de ataque baseia-se na utilização de duas técnicas: «Query Hijacking» e «Query Oriented Programming», que permitem explorar problemas arbitrários que levam à corrupção de memória no mecanismo SQLite. A essência do «Query Hijacking» é a substituição do conteúdo do campo «sql» na tabela de sistema sqlite_master, que define a estrutura do banco de dados. O campo mencionado contém um bloco DDL (Data Definition Language), usado para descrever a estrutura dos objetos no banco de dados. A descrição é dada utilizando a sintaxe SQL padrão, ou seja, a construção «CREATE TABLE»,
que é executada durante a inicialização do banco de dados (na primeira execução
da função sqlite3LocateTable) para criar estruturas internas relacionadas à tabela na memória.
A ideia é que, como resultado da substituição de «CREATE TABLE» por «CREATE VIEW», há a possibilidade, através da definição de sua própria visão, de controlar qualquer acesso ao banco de dados. Com «CREATE VIEW», uma operação «SELECT» é ligada à tabela, que será chamada em vez de «CREATE TABLE» e permite acessar diferentes partes do interpretador SQLite. Em seguida, a forma mais simples de ataque seria chamar a função «load_extension», que permite carregar uma biblioteca arbitrária com extensão, mas esta função está desativada por padrão.
Para realizar um ataque em condições que permitem a execução da operação «SELECT», foi proposta a técnica de «Query Oriented Programming», que possibilita explorar problemas no SQLite que levam à corrupção de memória. A técnica lembra programação orientada a retorno (, Return-Oriented Programming), mas utiliza para construir a cadeia de chamadas («gadgets») não trechos existentes de código de máquina, mas inserções em um conjunto de subconsultas dentro do SELECT.
Fonte: opennet.ru
