Foi introduzida uma nova técnica para explorar vulnerabilidades no SQLite.

Pesquisadores da Check Point descoberto na conferência DEF CON, detalhes de uma nova técnica para atacar aplicativos usando versões vulneráveis ​​do SQLite. O método Check Point considera os arquivos de banco de dados como uma oportunidade para integrar cenários de exploração de vulnerabilidades em vários subsistemas SQLite internos que não são diretamente exploráveis. Os pesquisadores também prepararam uma técnica para explorar vulnerabilidades, codificando a exploração na forma de uma cadeia de consultas SELECT no banco de dados SQLite, que permite ignorar o ASLR.

Para um ataque bem-sucedido é necessário poder modificar os arquivos de banco de dados das aplicações atacadas, o que limita o método a ataques a aplicações que utilizam o banco de dados SQLite como formato para trânsito e entrada de dados. O método também pode ser usado para expandir o acesso local existente, por exemplo, para integrar backdoors ocultos em aplicativos usados, bem como para contornar mecanismos de segurança ao analisar malware por pesquisadores de segurança. A operação após a substituição do arquivo é realizada no momento em que a aplicação executa a primeira consulta SELECT em uma tabela do banco de dados modificado.

Como exemplo, demonstramos a capacidade de executar código no iOS ao abrir um catálogo de endereços, o arquivo com o banco de dados “AddressBook.sqlitedb” foi modificado utilizando o método proposto. O ataque usou uma vulnerabilidade na função fts3_tokenizer (CVE-2019-8602, capacidade de desreferência de ponteiro), corrigida na atualização SQLite 2.28 de abril, junto com outra vulnerabilidade na implementação de funções de janela. Além disso, foi demonstrado o uso do método para assumir remotamente o controle do servidor backend de um invasor escrito em PHP, que acumula senhas interceptadas durante a operação de código malicioso (as senhas interceptadas foram transmitidas na forma de um 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 motor SQLite. A essência do “Query Hijacking” é substituir o conteúdo do campo “sql” na tabela de serviço sqlite_master, que determina a estrutura do banco de dados. O campo especificado contém um bloco DDL (Data Definition Language) usado para descrever a estrutura dos objetos no banco de dados. A descrição é especificada usando a sintaxe SQL padrão, ou seja, a construção “CREATE TABLE” é usada,
que é executado durante o processo de inicialização do banco de dados (durante a primeira inicialização
funções sqlite3LocateTable para criar estruturas internas relacionadas à tabela na memória.

A ideia é que, ao substituir “CREATE TABLE” por “CREATE VIEW”, seja possível controlar qualquer acesso ao banco de dados definindo sua própria visão. Usando "CREATE VIEW" uma operação "SELECT" é vinculada à tabela, que será chamada em vez de "CREATE TABLE" e permite acessar diferentes partes do interpretador SQLite. A seguir, o método mais simples de ataque seria chamar a função “load_extension”, que permite carregar uma biblioteca arbitrária com uma extensão, mas esta função está desabilitada por padrão.

Para realizar um ataque quando é possível realizar a operação “SELECT”, é proposta a técnica “Query Oriented Programming”, que permite explorar problemas no SQLite que levam à corrupção de memória. A técnica lembra a programação orientada a retorno (ROP, Programação Orientada a Retorno), mas não usa trechos existentes de código de máquina para construir uma cadeia de chamadas (“gadgets”), mas insere em um conjunto de subconsultas dentro de SELECT.

Fonte: opennet.ru