Dieser Artikel stammt von einem grep auf das falsche Verzeichnis. Zufällig erinnerte ich mich daran, diesen bestimmten Datensatz in einer SQLite-DB gelöscht zu haben, und als ich ihn in den grep-Ergebnissen fand, auch wenn er von seltsamen Zeichen umgeben war, war ich einen Moment lang überrascht. Wir denken oft nicht darüber nach, wie Systeme unsere Daten verwalten, und nehmen an, dass alles viel komplexer und präziser ist, als es ist (in diesem Fall: Löschen ist nicht gleich löschen).

SQLite wurde Anfang 2000 entwickelt, um die Abhängigkeit einer einfachen, aber wichtigen Anwendung von einem Informix-DB-Server zu beseitigen. Seitdem ist ein SQL-Server auf einem Personal Computer oder sogar auf einem PDA zu einem grundlegenden Bestandteil der Anwendungsentwicklung geworden: Motorola, AOL, Symbian, bis hin zu Android und iOS, alle speichern Daten in lokalen SQLite-Datenbanken.

Und die gespeicherten Informationen werden immer sensibler.

Warum SQLite wichtig ist

SQLite ist überall. Es ist im Webbrowser, im Telefon, im Auto und definitiv auch in Verkehrsflugzeugen. In ihr werden iMessages und WhatsApp-Nachrichten gespeichert, und wenn Sie auf Ihrem Computer nach *.db suchen, werden Sie erstaunt sein, wie viele SQLite-Datenbanken Sie finden.

SQLite ist die De-facto-Standardtechnologie zur Speicherung strukturierter Informationen in einer Datei auf einem lokalen System. Jede Anwendung, die normalisierte Daten verwalten muss, ohne auf schwerfällige Anwendungen wie SQL-Server zurückgreifen zu müssen, verwendet diese dateibasierte oder speicherinterne, leichtgewichtige, kompakte und effiziente Struktur. Dies hat die Software zu einem grundlegenden Bestandteil vieler Anwendungen gemacht, Verwalter und Hüter unserer sensibelsten Daten.

SQLite-Datenbankformat

Ich möchte hier nicht das Innenleben von SQLite erklären. Die wichtigsten Dinge, die Sie sich merken sollten:

• Wie ein Dateisystem ist die Struktur jeder Datenbank in Seiten organisiert.
• Die Daten jeder Tabelle oder jedes Index werden in einer B-Baum-Struktur gespeichert, die eine oder mehrere Seiten einnimmt. Jede Seite enthält nur die Daten, die von einer bestimmten Tabelle oder einem bestimmten Index stammen. Es gibt also keine Seiten mit Datensätzen, die zu verschiedenen Tabellen gehören.
• Jede Seite kann Verweise auf andere Seiten (interne Seiten) oder Daten (Blattseiten) enthalten. Grössere Tabellen/Indizes enthalten eine Wurzelseite, die auf interne Seiten verweist, die wiederum auf mehrere interne Seiten oder Blattseiten verweisen (verkettet).
• Wenn Tabellen hinzugefügt, Datensätze geändert oder gelöscht werden, kann sich die Anzahl der von einer Tabelle verwendeten Seiten erhöhen oder verringern, und Datensätze können zwischen Seiten verschoben werden.
• Die Freelist enthält eine Liste von Seiten, die derzeit nicht verwendet werden. Jeder Freeblock ist mit einer Seiten-Freelist verknüpft.
• Der Freeblock kann Daten enthalten, die nicht mehr zugänglich sein sollen.

Wo sind die Daten?

Da es sich um eine lokale dateibasierte Datenbank handelt, können die Daten über die vom SQLite-Daemon bereitgestellte Standardschnittstelle ohne weitere Autorisierungsschritte abgerufen werden. Aber was passiert mit den gelöschten Daten? Das kommt darauf an. Wie wir weiter unten sehen werden, beeinflussen einige Parameter, wie die Daten aus der Datenbankdatei entfernt werden. Im Allgemeinen und standardmässig bleiben jedoch die Daten in der Datei und der Platz wird einfach als frei markiert. Es ist daher möglich, die Liste der Freeblocks zu durchsuchen und den gelöschten Inhalt auf irgendeine Weise wiederherzustellen.

Die Algorithmen, mit denen die Informationen in der Datenbank verwaltet werden, sind gut bekannt, so dass es mit minimalem Aufwand möglich ist, Werkzeuge zu programmieren, die die Informationen abrufen. Das Problem liegt absurderweise in der Einfachheit der Struktur selbst. Wie bereits erwähnt, sind die Daten leicht auffindbar, und auf jeder Seite gibt es nur Datensätze, die zu einer bestimmten Tabelle gehören, aber zu welcher? Wenn wir eine Datenbank mit mehreren Tabellen haben und einige Datensätze löschen, können wir sicher sein, dass die gelöschten Daten zu der Tabelle gehören, zu der auch die verbleibenden Datensätze gehören, aber ansonsten ist es nicht möglich zu wissen, zu welcher Tabelle sie gehören. In diesem Fall ist es üblich, anhand des Inhalts und der Form des Datensatzes auf die Zugehörigkeit zu wetten. Dieses Verfahren wird jedoch mit zunehmender Grösse der gelöschten Blöcke oder mit binärem Inhalt immer ungenauer, so dass die Daten nicht immer perfekt rekonstruiert werden können.

Der Zugriff auf die Informationen ist sehr einfach. Mit wenigen Zeilen Code ist es möglich, die für die Rekonstruktion der gelöschten Datensätze erforderlichen Schlüsselparameter auszulesen:

rcc@vic:~/scip_Labs/labs.20210819_sqlite3_forensic/databases$ python3 info.py --database contacts-v1.db
Passed databasename is contacts-v1.db
Database contacts-v1.db exists and is a regular file.
Open database contacts-v1.db
Database version:         SQLite format 3
Page size (bytes):        4096
Database size (pages):    1929
Freelist first page nr:   25
------------
Address of the first freelist page:  b'\x00\x00\x00\x19'  ->  25
Number of freelist pages:            b'\x00\x00\x01\xe7'  ->  487
*** Read page nr:  25
   - Page header:   b'\x00\x00\x00\x00\x00\x00\x01\xe6'
    Address of the next freelist trunk page :  b'\x00\x00\x00\x00'  ->  0
    Address of the next freelist leaf page  :  b'\x00\x00\x01\xe6'  ->  486
*** Read page nr:  486
   - Page header:   b'\r\x00\x00\x00Z\x00\xe2\x00'
    Address of the next freelist trunk page :  b'\r\x00\x00\x00'  ->  218103808
    Address of the next freelist leaf page  :  b'Z\x00\xe2\x00'  ->  1510007296
    Address of the next freelist page :  b'\r\x00\x00\x00'  ->  218103808
*** Read page nr:  218103808
   - Page header:   b''
    Address of the next freelist trunk page :  b''  ->  0
    Address of the next freelist leaf page  :  b''  ->  0
    This is the last freelist page.

Tools und Wiederherstellungsraten

Es gibt Standardtests zur Überprüfung der Qualität eines Tools bei der Wiederherstellung gelöschter Datensätze. Beachten Sie auf jeden Fall, dass selbst die besten Tools unter den besten Bedingungen nicht über die Wiederherstellung von 50 % der gelöschten Datensätze hinausgehen, abhängig von der Art der gespeicherten Daten (Text oder Binärdaten).

SQLite-Pragmas

Wie bereits erwähnt, hängt die Erfolgsquote bei der Datenwiederherstellung von den verwendeten Optionen ab. SQLite verfügt über einige Mechanismen zum Schrumpfen oder Überschreiben von Speicherplatz, der nicht mehr verwendet wird. Wenn sie in Gebrauch sind, ist die Wiederherstellung der gelöschten Daten praktisch unmöglich.

Die folgenden Optionen beeinflussen das Verhalten der gelöschten Datensätze.

Vacuum

Wenn auto-vacuum deaktiviert ist und Daten aus einer Datenbank gelöscht werden, bleibt die Datenbankdatei in ihrer Grösse unverändert. Ungenutzte Seiten der Datenbankdatei werden einer freelist hinzugefügt und für nachfolgende Einfügungen wiederverwendet. Wenn der Auto-Vacuum-Modus 1 oder full ist, werden die Freelist-Seiten an das Ende der Datenbankdatei verschoben und die Datenbankdatei wird abgeschnitten, um die Freelist-Seiten bei jedem Transaktions-Commit zu entfernen. Beachten Sie, dass Auto-Vakuuming eingeschaltet sein muss, bevor eine Tabelle erstellt wird.

Sicheres Löschen ein

Wenn secure_delete eingeschaltet ist, überschreibt SQLite den gelöschten Inhalt mit Nullen. Dies ist die sicherste Option, um sicherzustellen, dass gelöschte Datensätze nicht wiederherstellbar sind. Wir empfehlen, dieses Pragma zu verwenden, wann immer dies möglich ist, auch wenn es sich leicht auf die Leistung auswirkt.

Journal-Modus

Der Journalmodus, Rollback oder Write-Ahead, wird für atomare Transaktionen verwendet. Beide Arten von Protokollen speichern eine Historie der letzten in der Datenbank durchgeführten Aktionen und sind daher eine wertvolle Datenquelle im Falle einer forensischen Analyse. Viele Parameter können die Logs beeinflussen (Länge, Persistenz, etc.), aber im Allgemeinen, wenn sie vorhanden sind, schneiden die wenigen Tools, die auf Log Recovery basieren, viel besser ab als Tools, die nur die Datenbank analysieren; in einigen besonderen Fällen war die Wiederherstellung der gelöschten Informationen 100%.

Zusammenfassung

SQLite ermöglicht es uns, strukturierte Informationen zu speichern, ohne ein schweres System wie eine Datenbank zu benötigen. Auch wenn es nicht möglich ist, die Sicherheitsoptionen zwischen einem Datenbankserver und SQLite zu vergleichen, ist es in jedem Fall ratsam, einige Vorkehrungen zu treffen, um die Nutzung der Anwendung sicherer zu machen, indem man beispielsweise sicherstellt, dass gelöschte Datensätze nicht wiederherstellbar sind.

Über den Autor

Rocco Gagliardi ist seit den 1980er Jahren im Bereich der Informationstechnologie tätig. In den 1990er Jahren hat er sich ganz der Informationssicherheit verschrieben. Die Schwerpunkte seiner Arbeit liegen im Bereich Security Frameworks, Routing, Firewalling und Log Management.

Links

• https://sqlite.org/fileformat.html
• https://www.sciencedirect.com/science/article/pii/S1742287618300471
• https://www.sciencedirect.com/science/article/pii/S1742287619301677