Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03180.jsonl.gz/583

Microsoft365DSC
Rocco Gagliardi
So funktioniert SQLite-Forensik
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.
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.
Ich möchte hier nicht das Innenleben von SQLite erklären. Die wichtigsten Dinge, die Sie sich merken sollten:
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.
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).
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.
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.
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.
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%.
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.
Unsere Spezialisten kontaktieren Sie gern!
Rocco Gagliardi
Rocco Gagliardi
Unsere Spezialisten kontaktieren Sie gern!
Weitere Artikel im Archiv