Os Pesquisadores da Check Point revelaram recentemente na conferência DEF com os detalhes de uma nova técnica que foi descoberta, isso é usado pPara atacar aplicativos que usam versões vulneráveis do SQLite.
O método A Check Point vê os arquivos de banco de dados como uma oportunidade para integrar cenários de exploração de vulnerabilidade em vários subsistemas SQLite internos que não são acessíveis para exploração da testa. Os pesquisadores também desenvolveram uma técnica para explorar vulnerabilidades com codificação de exploração na forma de uma string de consultas SELECT em um banco de dados SQLite, o que permite que o ASLR seja evitado.
Sobre vulnerabilidade
Os pesquisadores da Check Point detalham que para um ataque bem-sucedido, um invasor deve ser capaz de modificar os arquivos de banco de dados dos aplicativos atacados, que limita o método de ataque a aplicativos que usam bancos de dados SQLite como formato para dados de trânsito e de entrada.
Apesar também divulgam que o método também pode ser utilizado para expandir o acesso local já obtido, por exemplo, para integrar portas traseiras ocultas nos aplicativos usados, bem como para evitar pesquisadores de segurança na análise de malware.
A operação após a representação do arquivo é realizada no momento em que o aplicativo executa a primeira solicitação SELECT para a tabela no banco de dados modificado.
Por exemplo, a capacidade de executar código no iOS ao abrir o catálogo de endereços foi demonstrada, o arquivo com o banco de dados «AddressBook.sqlitedb»Que foi modificado usando o método proposto.
Para o ataque, uma vulnerabilidade foi usada na função fts3_tokenizer (CVE-2019-8602, a capacidade de desreferenciar um ponteiro), corrigido na atualização 2.28 do SQLite de abril, juntamente com outra vulnerabilidade na implementação de funções de janela.
Além disso, demonstra o uso do método para captura de controle remoto de um servidor backend de atacantes escrito em PHP, que acumula senhas interceptadas durante a operação de código malicioso (as senhas interceptadas foram transferidas na forma de um banco de dados SQLite).
O método de ataque é baseado no uso de duas técnicas, Query Hijacking e Query Oriented Programming, que permitem a exploração de problemas arbitrários que levam à corrupção de memória no motor SQLite.
A essência do "sequestro de consulta" é substituir o conteúdo do campo "sql" na tabela de serviço sqlite_master que define a estrutura do banco de dados. O campo especificado contém o bloco DDL (Data Definition Language) usado para descrever a estrutura dos objetos no banco de dados.
A descrição é definida usando a sintaxe SQL normal, ou seja. A construção "CREATE TABLE", que é executada durante a inicialização do banco de dados (durante a primeira execução da função sqlite3LocateTable), é usada para criar estruturas internas associadas à tabela na memória.
A ideia é que, como resultado da substituição de "CREATE TABLE" e "CREATE VIEW, é possível controlar qualquer acesso ao banco de dados através da definição de sua visão.
Por outro lado, usando o comando "CREATE VIEW", uma operação "SELECT" é anexada à tabela, que será chamada em vez de "CREATE TABLE" e permite que o invasor acesse várias partes do interpretador SQLite.
Além disso, a maneira mais fácil de atacar seria chamar a função "load_extension", que permite ao atacante carregar uma biblioteca arbitrária com a extensão, mas esta função está desabilitada por padrão.
Para realizar um ataque nas condições de capacidade de realizar a operação SELECT, foi proposta a técnica de programação orientada a consultas, que permite explorar problemas no SQLite que levam à corrupção da memória.
A técnica é uma reminiscência da Programação Orientada a Retorno (ROP), mas usa fragmentos de código de máquina inexistentes, mas é inserida em um conjunto de subconsultas em SELECT para construir uma cadeia de chamadas ("gadgets").
fonte: https://threatpost.com/