Представлена новая техника эксплуатации уязвимостей в SQLite

11 августа 2019 года

Исследователи из компании Check Point раскрыли на конференции DEF CON детали новой техники атак на приложения, использующие уязвимые версии SQLite. Метод Check Point рассматривает файлы с БД как возможность для интеграции сценариев эксплуатации уязвимостей в различных внутренних подсистемах SQLite, недоступных для эксплуатации в лоб. Исследователями также подготовлена техника эксплуатации уязвимостей с кодированием эксплоита в форме цепочки SELECT-запросов в БД SQLite, позволяющая обойти ASLR.

Для успешной атаки необходимо наличие возможности модификации файлов БД атакуемых приложений, что ограничивает метод атакой на приложения, использующие БД SQLite в качестве формата для транзитных и входных данных. Метод также может применяться для расширения уже полученного локального доступа, например, для интеграции скрытых бэкдоров в используемые приложения, а также для обхода исследователями безопасности механизмов защиты при анализе вредоносного ПО. Эксплуатация после подмены файла осуществляется в момент выполнения приложением первого SELECT-запроса к таблице в модифицированной БД.

В качестве примера продемонстрирована возможность запуска кода в iOS при открытии адресной книги, файл с БД "AddressBook.sqlitedb" которой был изменён с использованием предложенного метода. Для атаки использовалась уязвимость в функции fts3_tokenizer (CVE-2019-8602, возможность разыменования указателя), исправленная в апрельском обновлении SQLite 2.28, наряду с другой уязвимостью в реализации оконных функций. Кроме того, продемонстрировано применение метода для удалённого захвата управления за написанным на PHP бэкенд-сервером злоумышленников, осуществляющим накопление паролей, перехваченных в ходе работы вредоносного кода (перехваченные пароли передавались в форме БД SQLite).

Метод атаки основан на использовании двух техник "Query Hijacking" и "Query Oriented Programming", позволяющих эксплуатировать произвольные проблемы, приводящие к повреждению памяти в движке SQLite. Суть "Query Hijacking" в подмене содержимого поля "sql" в служебной таблице sqlite_master, определяющей структуру БД. Указанное поле содержит блок DDL (Data Definition Language), используемый для описания структуры объектов в БД. Описание задаётся с использованием штатного синтаксиса SQL, т.е. используется конструкция "CREATE TABLE", которая выполняется в процессе инициализации БД (во время первого запуска функции sqlite3LocateTable) для создания связанных с таблицей внутренних структур в памяти.

Идея в том, что, в результате замены "CREATE TABLE" на "CREATE VIEW" появляется возможность через определение своего представления контролировать любое обращение к БД. При помощи "CREATE VIEW" к таблице привязывается операция "SELECT", которая будет вызвана вместо "CREATE TABLE" и позволяет обращаться к различным частям интерпретатора SQLite. Далее самым простым способом атаки был бы вызов функции "load_extension", позволяющей загрузить произвольную библиотеку с расширением, но данная функция отключена по умолчанию.

Для совершения атаки в условиях возможности выполнения операции "SELECT" предложена техника "Query Oriented Programming", дающая возможность эксплуатировать проблемы в SQLite, приводящие к повреждению памяти. Техника напоминает возвратно-ориентированное программирование ( ROP, Return-Oriented Programming), но использует для построения цепочки вызовов ("гаджетов") не существующие отрывки машинного кода, а вставки в наборе подзапросов внутри SELECT.

Источники

править


 
 
Creative Commons
Эта статья содержит материалы из статьи «Представлена новая техника эксплуатации уязвимостей в SQLite», опубликованной OpenNET и распространяющейся на условиях лицензии Creative Commons Attribution (CC BY) — указание автора, источник и лицензию.
 
Эта статья загружена автоматически ботом NewsBots в архив и ещё не проверялась редакторами Викиновостей.
Любой участник может оформить статью: добавить иллюстрации, викифицировать, заполнить шаблоны и добавить категории.
Любой редактор может снять этот шаблон после оформления и проверки.

Комментарии

Викиновости и Wikimedia Foundation не несут ответственности за любые материалы и точки зрения, находящиеся на странице и в разделе комментариев.