Trigger in DBMS

Trigger in der forensischen DB Auswertung

Definition

Der ISO/IEC 9075 Standard - Teil 2 definiert einen Trigger als eine Aktion oder mehrere Aktionen, die als Ergebnis einer Operation stattfinden, die an einem bestimmten Objekt ausgeführt wird. Die Operationen sind als Änderungen definiert, die an Zeilen vorgenommen werden, indem sie eingefügt, aktualisiert oder gelöscht werden. Daher werden drei Trigger Typen definiert: der Insert-Trigger, der Delete-Trigger und der Update-Trigger. Die Aktion kann unmittelbar vor der Operation, anstelle der Operation oder unmittelbar nach der Operation erfolgen. Ein Trigger wird somit als BEFORE-Trigger, INSTEAD OF-Trigger oder AFTER-Trigger definiert. Die Aktion kann nur einmal oder für jede Zeile ausgeführt werden, die von der Operation bearbeitet wird. Der Trigger wird daher weiter als Trigger auf Anweisungsebene oder als Trigger auf Zeilenebene definiert.[1]

Bedeutung für die IT-Forensik

Trigger sind sowohl für Angreifer als auch für Datenbank Admins und Forensiker von großer Bedeutung. Von Angreifern können sie verwendet werden, um Daten zu manipulieren, zu löschen, Daten abzuleiten, Änderungen am Datenbanksystem und am Datenbankserver vorzunehmen und zu guter Letzt auch um Spuren zu verschleiern. Für Datenbankadministratoren sind sie ein geeignetes Mittel, um sich von auf die vorgenannten Aktionen vorzubereiten und geeignete Trigger zu installieren, die dann entsprechende Meldungen (Log Files, Emails) erzeugen. Forensiker müssen sich bei der Auswertung von Datenbankinformation der Möglichkeit von evtl. vorhandenen Triggern bewusst sein. Gerade Trigger, die bei LOGIN LOGOFF Ereignissen ausgelöst werden, können die Spurensuche und Sicherstellung der Integrität der vorliegenden Daten erschweren.

Aufbau Trigger Statement

CREATE TRIGGER Triggername

{ BEFORE | AFTER } { DELETE | INSERT | UPDATE } [ OR... ] ON Tabellenname [ REFERENCING [ OLD AS NameAlt ] [ NEW AS NameNeu] ] [ FOR EACH STATEMENT | FOR EACH ROW ] [ WHEN Bedingung ]

DECLARE

BEGIN ATOMIC Anweisungen END; DROP TRIGGER Triggername ;

Beispiel: Unter PostgreSQL

Bei PostgreSQL wird zuerst die Funktion definiert, die dann durch den Trigger ausgeführt wird. CREATE OR REPLACE FUNCTION trigger_function (p1 type, p2 type) RETURNS TRIGGER AS $$ DECLARE BEGIN -- logic

     IF ...
     THEN ...
     END IF;
     new.xyz = ...;
     old.xyz...

RETURN new END; $$ LANGUAGE plpgsql;

Und der Trigger der die o.g. Funktion ausführt:

CREATE OR REPLACE TRIGGER trigger_name { BEFORE | AFTER | INSTEAD OF } { event [OR ...] }

     ON table_name
     [ FOR [EACH] {ROW | STATEMENT} ]

Anwendungsbeispiele

Trigger in Datenbanken sind so konzipiert, dass sie automatische Aktionen basierend auf Ereignissen ausführen, die in einer Datenbank auftreten. Es gibt eine große Bandbreite von Aktionen, die von Triggern durchgeführt werden können. Sie reicht von Generierung von Daten über Veränderung von Daten bis hin zu Weglassen von Daten. [2] Diese Aktionen können potenziell Auswirkungen auf Daten innerhalb und außerhalb des DBMS haben, was auch für die forensische Auswertung wichtig sein kann, was die folgenden Beispiele verdeutlichen sollen:

Fall 1

SQL Server, Oracle and Sybase unterstützen LOGIN Trigger. Dieser Trigger wird ausgelöst, wenn ein Benutzer sich in der Datenbank anmeldet. Ein Hacker könnte diesen Trigger verwenden, um zu überprüfen, ob sich ein Benutzer mit Systemrechten (Admin), angemeldet hat. Sollte sich ein solcher Benutzer anmelden, kann er durch den Trigger ein bereits eingeschleustes Rootkit fast vollständig entfernen, sodass dem Admin auch bei genauerer Betrachtung alles normal erscheint. Der Hacker kann dann den BEFORE LOGOFF-Trigger von Oracle verwenden, um das Rootkit erneut einzufügen, oder einen Scheduled Task [3] verwenden, der das Rootkit zunächst verbirgt, um sich dann selbst wieder einzufügen, nachdem sich der Benutzer mit Systemrechten abgemeldet hat.

Fall 2

Eine Datenbank in einem medizinischen System, die medizinische Patienteninformationen enthält. Eine Zusatzinformationstabelle wird verwendet, um optionale Informationen wie die Einwilligung für Organspende, evtl. vorhandene Allergien usw. in nullbaren Spalten zu speichern. Dieses System wird unter anderem verwendet, um die Informationen von neuen Patienten zu erfassen, die in ein Krankenhaus eingeliefert werden. Der Aufnahmesachbearbeiter trägt sorgfältig alle Informationen aus einem Formular ein, das vom Patienten oder seinem aufnehmenden Partner ausgefüllt wird. Das Formular eines bestimmten Patienten weist eindeutig darauf hin, dass er gegen Penicillin allergisch ist. Diese Informationen werden vom Zulassungssachbearbeiter pflichtgemäß in das System eingegeben. Ein Angreifer hat jedoch einen INSTEAD OF-Trigger in die Zusatzinformationstabelle eingefügt, der den Wert auf eine evtl. vorhandene Allergie auf Null ändert, bevor die ursprüngliche Einfügung ausgeführt wird. Nach der Aufnahme wird das medizinische System dann verwendet, um die Patientenakte auszudrucken. Ein Arzt ordnet anschließend die Verabreichung von Penicillin als Teil eines Behandlungsplans an, nachdem er die Tabelle mit den Angaben über die Allergien des Patienten konsultiert hat. Diese Aktion führt letztendlich zum Tod des Patienten aufgrund einer allergischen Reaktion. Nach Feststellung der Todesursache wird eine Untersuchung durchgeführt, um die Haftung des Krankenhauses festzustellen. Die Untersuchung ergab, dass die Allergie auf dem Aufnahmeformular angegeben, aber nicht in das medizinische System aufgenommen wurde. Der Aufnahmesachbearbeiter, der die Daten des verstorbenen Patienten eingegeben hat, wird ermittelt und befragt. Der Sachbearbeiter besteht jedoch darauf, dass er die Allergie-Informationen in das Formular eingetragen hat und das System die erfolgreiche Eingabe angezeigt hat. Ohne diesbezüglichen Nachweis wird dem Zulassungssachbearbeiter jedoch Fahrlässigkeit vorgeworfen. Abhängig von der jeweiligen Datenbank durchgeführten Protokollierung gibt es möglicherweise keinen Eintrag in der Datenbank, der beweisen kann, dass der Sachbearbeiter nicht fahrlässig gehandelt hat. Die zum Erfassen der Informationen verwendete Anwendung kann jedoch ein Protokoll enthalten, das eine Diskrepanz zwischen den erfassten und den gespeicherten Daten anzeigt. Ohne ein solches Protokoll bleibt allenfalls ein Gegenbeweis, der auf grobe Fahrlässigkeit des Zulassungssachbearbeiters hindeutet. Dies könnte letztlich dazu führen, dass dem Zulassungssachbearbeiter eine Unterlassungshandlung vorgeworfen wird. Sollten Trigger jedoch im Rahmen einer forensischen Untersuchung untersucht werden, könnten sie eine andere Perspektive bieten.[1] In diesem Beispiel kann das Vorhandensein des Triggers zumindest Zweifel an den Beweisen aufkommen lassen und möglicherweise tatsächliche Beweise liefern, um die Version der Ereignisse zu bestätigen, wie sie vom Sachbearbeiter berichtet wurden.

Fall 3

Eine weiterer, von Angreifern oft genutzter Einsatz von Triggern, ist die Manipulation von Finanzanwendungen. Zum Beispiel kann ein Angreifer einen Trigger auf eine Tabelle von Kaufpreiserstattungen setzen. Jedes Mal, wenn eine Zahlungsrückerstattung in die Tabelle geschrieben wird, fängt der BEFORE Trigger die Schreiboperation ab, und ändert die zu erstattende Kontonummer in eine vom Angreifer gewählte und schreibt erst dann die Daten in die Tabelle. Bei der anschließenden Überweisung (zB. im Bulk über Nacht, wird dann die eingeschleuste Ktonummer des Angreifers verwendet, statt die ursprüngliche der Kunden*innen. In den Logfiles wären auch hier keine Hinweise auf die Manipulation der Daten zu finden, sondern nur durch die Analyse von Triggern selbst können Beweise erlangt werden, dass durch den Trigger die Manipulation der Daten zu dem bestimmten Zeitpunkt vorgenommen worden ist.

Quellen

[1] THE IMPACT OF TRIGGERS ON FORENSIC ACQUISITION AND ANALYSIS OF DATABASES W. K. Hauger and M. S. Olivier SOUTH AFRICAN INSTITUTE OF ELECTRICAL ENGINEERS Vol.106 (2) Juni 2015

[2] H.K. Khanuja and D.S. Adane: “A framework for database forensic analysis”, Computer Science & Engineering, Vol. 2 No. 3, Juni 2012.

[3] A. Kornbrust: “Database rootkits”, Black Hat Europe, April 2005. Internet: http://www.red-database-security.com/wp/db_rootkits_us.pdf, [12. Februar 2022].