Onderzoekers van Check Point op de DEF CON-conferentie details over een nieuwe techniek voor het aanvallen van applicaties met behulp van kwetsbare versies van SQLite. De Check Point-methode beschouwt databasebestanden als een kans om scenario's te integreren voor het misbruiken van kwetsbaarheden in verschillende interne SQLite-subsystemen die niet direct kunnen worden misbruikt. Onderzoekers hebben ook een techniek ontwikkeld om kwetsbaarheden te misbruiken door de exploit te coderen in de vorm van een reeks SELECT-query's in de SQLite-database, waardoor je ASLR kunt omzeilen.
Voor een succesvolle aanval is het noodzakelijk om de databasebestanden van de aangevallen applicaties te kunnen wijzigen, waardoor de methode beperkt blijft tot aanvallen op applicaties die de SQLite-database gebruiken als formaat voor doorvoer- en invoergegevens. De methode kan ook worden gebruikt om bestaande lokale toegang uit te breiden, bijvoorbeeld om verborgen achterdeurtjes in gebruikte applicaties te integreren, maar ook om beveiligingsmechanismen te omzeilen bij het analyseren van malware door beveiligingsonderzoekers. De bewerking na bestandsvervanging wordt uitgevoerd op het moment dat de applicatie de eerste SELECT-query uitvoert op een tabel in de gewijzigde database.
We hebben bijvoorbeeld de mogelijkheid gedemonstreerd om code uit te voeren in iOS bij het openen van een adresboek; het bestand met de database "AddressBook.sqlitedb" werd aangepast met behulp van de voorgestelde methode. Bij de aanval werd gebruik gemaakt van een kwetsbaarheid in de functie fts3_tokenizer (CVE-2019-8602, pointer dereference-mogelijkheid), opgelost in de SQLite 2.28-update van april, samen met een andere bij de implementatie van vensterfuncties. Daarnaast werd het gebruik gedemonstreerd van een methode voor het op afstand overnemen van de controle over de backend-server van een aanvaller, geschreven in PHP, die wachtwoorden verzamelt die zijn onderschept tijdens de werking van kwaadaardige code (de onderschepte wachtwoorden werden verzonden in de vorm van een SQLite-database).
De aanvalsmethode is gebaseerd op het gebruik van twee technieken: “Query Hijacking” en “Query Oriented Programming”, waarmee willekeurige problemen kunnen worden misbruikt die leiden tot geheugenbeschadiging in de SQLite-engine. De essentie van “Query Hijacking” is het vervangen van de inhoud van het “sql”-veld in de sqlite_master servicetabel, die de structuur van de database bepaalt. Het opgegeven veld bevat een DDL-blok (Data Definition Language) dat wordt gebruikt om de structuur van objecten in de database te beschrijven. De beschrijving wordt gespecificeerd met behulp van de standaard SQL-syntaxis, d.w.z. de constructie “CREATE TABLE” wordt gebruikt,
die wordt uitgevoerd tijdens het database-initialisatieproces (tijdens de eerste lancering
sqlite3LocateTable functioneert om tabelgerelateerde interne structuren in het geheugen te creëren.
Het idee is dat, als gevolg van het vervangen van “CREATE TABLE” door “CREATE VIEW”, het mogelijk wordt om elke toegang tot de database te controleren door uw eigen weergave te definiëren. Met behulp van "CREATE VIEW" wordt een "SELECT" -bewerking aan de tabel gekoppeld, die wordt aangeroepen in plaats van "CREATE TABLE" en waarmee u toegang krijgt tot verschillende delen van de SQLite-interpreter. Vervolgens zou de eenvoudigste aanvalsmethode het aanroepen van de functie “load_extension” zijn, waarmee u een willekeurige bibliotheek met een extensie kunt laden, maar deze functie is standaard uitgeschakeld.
Om een aanval uit te voeren wanneer het mogelijk is om de “SELECT”-operatie uit te voeren, wordt de “Query Oriented Programming”-techniek voorgesteld, die het mogelijk maakt om problemen in SQLite te exploiteren die tot geheugencorruptie leiden. De techniek doet denken aan retourgeoriënteerd programmeren (, Return-Oriented Programming), maar gebruikt geen bestaande fragmenten machinecode om een reeks oproepen (“gadgets”) op te bouwen, maar voegt een reeks subquery’s in binnen SELECT.
Bron: opennet.ru