Naukowcy z Check Point na konferencji DEF CON szczegóły nowej techniki atakowania aplikacji przy użyciu podatnych na ataki wersji SQLite. Metoda Check Point traktuje pliki baz danych jako okazję do integracji scenariuszy wykorzystania luk w zabezpieczeniach w różnych wewnętrznych podsystemach SQLite, których nie można bezpośrednio wykorzystać. Badacze przygotowali także technikę wykorzystania podatności poprzez zakodowanie exploita w postaci łańcucha zapytań SELECT w bazie danych SQLite, co pozwala ominąć ASLR.
Aby atak był skuteczny, konieczna jest możliwość modyfikacji plików baz danych zaatakowanych aplikacji, co ogranicza metodę do ataków na aplikacje korzystające z bazy danych SQLite jako formatu przesyłania i wprowadzania danych. Metodę można również wykorzystać do rozszerzenia istniejącego dostępu lokalnego, na przykład do zintegrowania ukrytych backdoorów z używanymi aplikacjami, a także do ominięcia mechanizmów bezpieczeństwa podczas analizy szkodliwego oprogramowania przez badaczy bezpieczeństwa. Operacja po podstawieniu pliku wykonywana jest w momencie wykonania przez aplikację pierwszego zapytania SELECT względem tabeli w zmodyfikowanej bazie danych.
Jako przykład zademonstrowaliśmy możliwość uruchomienia kodu w systemie iOS podczas otwierania książki adresowej, zaproponowanym sposobem zmodyfikowano plik z bazą danych „AddressBook.sqlitedb”. W ataku wykorzystano lukę w funkcji fts3_tokenizer (CVE-2019-8602, możliwość dereferencji wskaźników), naprawioną w kwietniowej aktualizacji SQLite 2.28, a także inną w implementacji funkcji okna. Dodatkowo zademonstrowano wykorzystanie napisanej w języku PHP metody zdalnego przejmowania kontroli nad serwerem backendowym atakującego, która gromadzi hasła przechwycone podczas działania złośliwego kodu (przechwycone hasła zostały przesłane w postaci bazy danych SQLite).
Metoda ataku opiera się na wykorzystaniu dwóch technik „Query Hijacking” i „Query Oriented Programming”, które pozwalają na wykorzystanie dowolnych problemów prowadzących do uszkodzenia pamięci w silniku SQLite. Istotą „Query Hijacking” jest zastąpienie zawartości pola „sql” w tabeli usługi sqlite_master, która określa strukturę bazy danych. Podane pole zawiera blok DDL (Data Definition Language) służący do opisu struktury obiektów w bazie danych. Opis jest podawany przy użyciu standardowej składni SQL, tj. stosowana jest konstrukcja „CREATE TABLE”,
który jest wykonywany podczas procesu inicjalizacji bazy danych (podczas pierwszego uruchomienia
Funkcje sqlite3LocateTable do tworzenia wewnętrznych struktur związanych z tabelami w pamięci.
Pomysł jest taki, że w wyniku zastąpienia opcji „UTWÓRZ TABELĘ” opcją „UTWÓRZ WIDOK” możliwa staje się kontrola dowolnego dostępu do bazy danych poprzez zdefiniowanie własnego widoku. Używając „UTWÓRZ WIDOK”, operacja „WYBIERZ” jest powiązana z tabelą, która zostanie wywołana zamiast „UTWÓRZ TABELĘ” i umożliwi dostęp do różnych części interpretera SQLite. Następnie najprostszą metodą ataku byłoby wywołanie funkcji „load_extension”, która pozwala załadować dowolną bibliotekę z rozszerzeniem, ale funkcja ta jest domyślnie wyłączona.
Aby przeprowadzić atak, gdy możliwe jest wykonanie operacji „SELECT”, proponowana jest technika „programowania zorientowanego na zapytania”, która umożliwia wykorzystanie problemów w SQLite prowadzących do uszkodzenia pamięci. Technika ta przypomina programowanie zorientowane na zwrot (, Programowanie zorientowane na powrót), ale wykorzystuje nieistniejące fragmenty kodu maszynowego do zbudowania łańcucha wywołań („gadżetów”), ale wstawia zestaw podzapytań wewnątrz SELECT.
Źródło: opennet.ru