Microsoft Windows Eventlogs in der forensischen Analyse.

Transkript

1 . Konzernsicherheit Deutsche Telekom AG

2 . Agenda. 1. Einleitung 2. Aufbau und Funktion 2.1 Konzept: EventID und Messagetable 2.2 Konfiguration in der Registry 2.3 Zusammenspiel der Komponenten 2.4 Aufbau der Logdateien 3. Vorgehensmodell für die forensische Untersuchung 4. Zusammenfassung 4.1 Ergebnis 4.2 Nächste Schritte 5. Fragen & Antworten 2. März 2005, Seite 2

3 Einleitung. Der Eventlog-Dienst. Verfügbar nur für die Microsoft Windows NT Produktlinie Eingeführt mit Microsoft Windows NT 3.5 (September 1994) Aufgaben: Entgegennahme von Meldungen Verwaltung der Protokolldateien Enumeration der Protokolleinträge Implementiert in services.exe (RPC-Server) und eventlog.dll (Behandlungsroutinen) Schnittstellen in advapi32.dll Seit Windows 2000 Plugin für die Microsoft Management Console (MMC) in els.dll 2. März 2005, Seite 3

4 Einleitung. Betrachtung eines Logs mit der Ereignisanzeige. 2. März 2005, Seite 4

5 Einleitung. Detailansicht einer Ereignis-Meldung. Datum und Uhrzeit fixieren den Eintrag auf der Zeitachse. Quelle und Ereignis-ID bestimmen (grob) die Aussage der Meldung. Typ und Kategorie lassen sich daraus ableiten. Die Beschreibung informiert in einer verständlichen Formulierung über das Ereignis. Das Feld Daten zeigt zusätzliche binäre Informationen (z. B. Registersatz, Stackdump) 2. März 2005, Seite 5

6 Einleitung. Nicht jede Logdatei lässt sich betrachten! 2. März 2005, Seite 6

7 Einleitung. Die Ausgabe ist vom System des Betrachters abhängig. 2. März 2005, Seite 7

8 Einleitung. Umgehung des Windows-API. Um diese Schwierigkeiten zu überwinden, sollte ein Parser nicht auf die Windows-API aufbauen, sondern die Logdatei direkt verarbeiten. Beispiel: Parser von Jamie French malik_eventlogs.html Vorgehen: Datei sequenziell verarbeiten Zeichenfolge "LfLe" ist Satztrenner Validierung scheitert! Ursache: Nur Teile des Datenformats sind dokumentiert. 2. März 2005, Seite 8

9 Einleitung. Grundlagen klären. Studium der Dokumentation Microsoft Knowledge Base (MSKB) Microsoft Developer Network (MSDN) Analyse gesammelter Falldaten ca. 50 Dateien von Test- und Produktivsystemen, NT 4 bis Windows 2003, unterschiedliche Patchstände Ausführung unter kontrollierten Bedingungen Dediziertes, benutzerdefiniertes Log Erzeugung von Datenpaketen mit definierten Eigenschaften Monitoring (FileMon und RegMon von sysinternals.com) 2. März 2005, Seite 9

10 Einleitung. In eigener Sache. Der Vortrag konzentriert sich auf die Darstellung der Konzepte und eine Live-Vorführung einiger Werkzeuge. Detaillierte Dokumentation der Parameter in der Registry und und dem Dateiformat im Tagungsband! Seit Drucklegung sind 2 Monate vergangen, es gibt geringfügige Änderungen: Registry: Parameter zur Warnung vor und Rotation von gefüllten Logs. Datei, Header: Bedeutung des Feldes "FileSize". 2. März 2005, Seite 10

11 Aufbau und Funktion.

12 Aufbau und Funktion. Konzept: EventID und Messagetable. Typische Ereignismeldungen sind hochgradig redundant: ,08:47: Der Benutzer aschuster hat sich angemeldet ,08:49: Der Benutzer jberger hat sich angemeldet ,08:55: Der Benutzer srasch hat sich angemeldet. Zusammenfassung der redundanten Anteile in einer Schablone: schablone[0815] = "Der Benutzer %1 hat sich angemeldet." Speicherung im Log: Datenquelle = "Benutzeranmeldung" EventID = 0815 ereignisspezifische, variable Daten: "aschuster" 2. März 2005, Seite 12

13 Aufbau und Funktion. Konzept: EventID und Messagetable. Vorteile: Speicherplatz in Logs wird besser ausgenutzt, kompakte Meldungen. Anwender kann Meldungen in der Landessprache seines Systems lesen, unabhängig von der Sprache des erzeugenden Systems. Nachteile: Die textliche Darstellung der Meldung entsteht erst bei ihrer Betrachtung! Änderung der Textschablone bietet die Möglichkeit zur Manipulation der Meldung. Die Schablonen sind als Ressource in einer (potenziell) ausführbaren Datei (DLL) abgelegt. Vorsicht beim Zugriff März 2005, Seite 13

14 Aufbau und Funktion. Zusammenhang der Komponenten. Messages LoadLibraryEx(), FormatMessage() Registry Anwendung RegisterEventSource() ReportEvent() AuthzReportSecurityEvent() Eventlog Dienst Logdateien *.evt OpenEventLog() ReadEventLog() Event- Viewer 2. März 2005, Seite 14

15 Aufbau und Funktion. Kommunikation über RPC. Anwendung Funktionsaufruf (call) Advanced Windows 32bit Application Programming Interface advapi32.dll Client Remote Procedure Call (RPC) Server Systemdienst services.exe, eventlog.dll 2. März 2005, Seite 15

16 Konfiguration in der Registry. Eventlog-Dienst. Einträge in der Registry unter dem Schlüssel HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Services\ Eventlog Übliche Einträge für Systemdienste: Description, DisplayName, ImagePath, Start, etc. Zusätzlich ein Schlüssel je Log. Voreinstellung: Application Security System 2. März 2005, Seite 16

17 Konfiguration in der Registry. Logdateien Logrotation. File (REG_EXPAND_SZ) Pfad und Name der Datei, Umgebungsvariablen werden expandiert. MaxSize (REG_DWORD) Größe in Bytes, 64 kib- Schritte, maximal 4 GiB, Voreinstellung 512 kib. Retention (REG_DWORD) Mindest-Vorhaltedauer eines Eintrags in Sekunden. Schrittweite 1 Tag (86400 Sekunden). 2. März 2005, Seite 17

18 Konfiguration in der Registry. Logdateien Logrotation. AutoBackupLogFile (REG_DWORD) Wert 1: aktiviert die automatische Sicherung, wenn das Log voll ist. Die Datei erhält den Namen Archive-log-YYYY-MM-DD-hh-mm-ss.EVT; Zeit in UTC. Zusätzlich wird ein Event Nr. 524 mit Quelle Eventlog in das Security Log geschrieben. Siehe MSKB, Artikel LogFullPopup (REG_DWORD) Wert 1: Eine Warnmeldung erscheint, sobald das Log voll ist. WarningLevel (REG_DWORD) Werte 0..99: Schreibt einen Event Nr. 523, sobald das Security Log zu WarningLevel Prozent gefüllt ist. Ab Windows 2000, SP März 2005, Seite 18

19 Konfiguration in der Registry. Logdateien Lokalisierung. DisplayNameFile (REG_EXPAND_SZ) Pfad und Name einer Datei mit dem anzuzeigenden lokalisierten Namen in einer Messagetable. Umgebungsvariablen werden expandiert. DisplayNameID (REG_DWORD) Ordnungsnummer des lokalisierten Namens in der Messagetable. PrimaryModule (REG_SZ) Datenquelle, deren Eintragungen als Voreinstellung für andere Datenquellen dient. 2. März 2005, Seite 19

20 Konfiguration in der Registry. Datenquellen. CategoryMessageFile,EventMessageFile,ParameterMessageFile Dateien mit Textschablonen. TypesSupported Mögliche Meldungs-Typen (Info, Warnung, Fehler...) 2. März 2005, Seite 20

21 Konfiguration in der Registry. Sicherheit. Security (REG_BINARY) Security Descriptor in binärer Form. CustomSD (REG_SZ) Security Descriptor als Ausdruck der Security Descriptor Definition Language (SDDL). Ab Windows RestrictGuestAccess (REG_DWORD) Wert 1: Gastkonten und Null-Sessions haben keinen Zugriff auf das Log. Das Security-Log ist immer vor Zugriffen dieser Konten geschützt. 2. März 2005, Seite 21

22 Logdateien. Logdateien bestehen aus Frames. Länge Magic Daten Länge Allgemeine Eigenschaften: Frames beginnen und enden mit einer Längenangabe (DWORD). Maximale Länge (theoretisch) 4 GiB. Minimale Länge 40 (0x28) Bytes. 2. März 2005, Seite 22

23 Logdateien. Verknüpfung der Frames. Doppelt verkettete Liste Aneinanderreihung Vorgänger Nachfolger Daten Vorgänger Nachfolger Daten Vorgänger Nachfolger Hoher Aufwand bei der Suche des Satzanfangs und des Vorgängers. Daten Länge Länge Daten Länge Länge Daten Die Liste lässt sich in jede Richtung mit gleichem (geringen) Aufwand traversieren. 2. März 2005, Seite 23

24 Logdateien. Die initialisierte Logdatei : c66 4c LfLe : : a : : (..."""" : a d89f 0300 b DDDDp...Ø...& : 001f ( : Die leere Datei enthält zwei unterschiedliche Frames, Header und Cursor. 2. März 2005, Seite 24

25 Logdateien. Das erste Ereignis : c66 4c LfLe : : : c66 4c b `...LfLe...b.!B : 62b b.!b...` : a a Z...Z : a Z...T.e.s.t : e b c i.n.g...k.s.l.a : f B.O.R.2...` : (..."""" a0: DDDD b0: (... Der Event-Frame wird an der ursprünglichen Position des Cursors geschrieben, dahinter dann der neue Cursor. 2. März 2005, Seite 25

26 Logdateien. Header. Nicht von Microsoft dokumentiert! Steht immer und nur am Dateianfang (Offset 0) Länge = 48 (0x30) Bytes Magic LfLe Position und lfd. Nummer des ältesten Event-Frames in der Datei Position und lfd. Nummer des nächsten zu erstellenden Event-Frames Dateigröße Mindest-Vorhaltedauer in Sekunden (vgl. Registry) 2 unbekannte Werte, konstant "1". Flags 2. März 2005, Seite 26

27 Logdateien. Header Flags. Bitfeld, von 32 möglichen werden offenbar nur 4 Bits genutzt: 0001 (1): DIRTY 0 = Header ist gültig 1 = Header ist ungültig (bis auf dieses Flag!) 0010 (2): WRAPPED 0 = Die Datensätze sind chronologisch geordnet. 1 = Der jüngste Datensatz steht vor dem ältesten! 0100 (4): FULL 1 = Das Log ist voll, Daten konnten nicht geschrieben werden! 1000 (8): PRIMARY / BACKUP 0 = Datei wurde per BackupEventLog() erzeugt. 1 = Datei wird durch Eventlog-Dienst genutzt bzw. wurde kopiert. 2. März 2005, Seite 27

28 Logdateien. Cursor. Ebenfalls nicht dokumentiert. Länge = 40 (0x28) Bytes, kleinster zulässiger Frame. Magic: 0x1111 0x1111 0x2222 0x2222 0x3333 0x3333 0x4444 0x4444 Position und lfd. Nummer des ältesten Event-Frames in der Datei. Position und lfd. Nummer des nächsten zu erstellenden Event-Frames. Im Gegensatz zum Header (fast) immer aktuell. 2. März 2005, Seite 28

29 Logdateien. Log voll, und dann? Wenn die Länge noch nicht "MaxSize" erreicht hat: Datei um 64kiB verlängern, weiter wie bisher... Wenn die maximale Dateigröße erreicht ist: Ist "AutoBackupLogFile" gesetzt? Dann Backup erstellen, Log löschen und weiter wie bisher. Erlaubt "Retention" das Überschreiben des ältesten Datensatzes? Dann Flag WRAPPED setzen und den ältesten Datensatz überschreiben. Wenn auch das nicht möglich ist: Flag FULL setzen, zusätzlich bei "LogFullPopUp" eine Warnung anzeigen. Aufgeben! 2. März 2005, Seite 29

30 Logdateien. Sonderfall: Padding. 000ffb0: ffc0: ffd0: a '...'...' ffe0: '...'...'...' fff0: '...'...'...'... Bleiben hinter dem Event-Frame bis zum Dateiende weniger als 56 (0x38) Bytes frei, dann wird dieser Bereich mit DWORDs 0x27 aufgefüllt. Das Padding ist leicht als solches zu erkennen, da als Länge illegal: nicht an DWORD-Grenze ausgerichtet 1 Byte kürzer als der kleinste zulässige Frame 2. März 2005, Seite 30

31 Logdateien. Die Logdatei ist als Ringpuffer organisiert. Header 24 b 25 Cursor a Cursor Header März 2005, Seite 31

32 Logdateien. Event. Der wichtigste Datensatz, als Ergebnis der Funktion ReadEventLog() von Microsoft dokumentiert: en-us/debug/base/eventlogrecord_str.asp Länge >= 56 (0x38) Bytes Magic LfLe Besteht aus einem fest und einem variabel strukturierten Teil. 2. März 2005, Seite 32

33 Logdateien. Event fester Teil. Lfd. Nummer (Eindeutig für die Lebensdauer des Logs) Zeitstempel Meldung erzeugt und Meldung geschrieben Sekunden ab , 00:00 UTC Beide Werte sind in der Regel gleich. Abweichungen begründen eine eingehende Untersuchung! Vollständige EventID (Der Event-Viewer zeigt nur die niederwertigen 16 Bit) Anwendungsspezifische Kategorie Typ der Meldung (Info,Warnung, Fehler,...) Diverse Offsets und Längenangaben für den variablen Teil. 2. März 2005, Seite 33

34 Logdateien. Event variabler Teil. Beginnt bei Byte 0x38 des Datensatzes. Der feste Teil nennt für jedes Feld einen Offset (bezüglich Satzanfang) und eine Länge. Länge = 0 zeigt ein leeres Feld an. Felder: Datenquelle SID (im Binärformat) des betreffenden Kontos meldungsspezifische Strings ergänzende Binärdaten Padding auf DWORD-Grenze 2. März 2005, Seite 34

35 Vorgehensmodell für die forensische Untersuchung.

36 Vorgehensmodell für die forensische Untersuchung. Übersicht. 1. Datensicherung 2. Ermittlung der Konfiguration des Dienstes und der Logs 3. Suche nach Logdaten/-dateien 4. Auslesen der Rohdaten 5. Ergänzen der Meldungstexte 2. März 2005, Seite 36

37 Vorgehensmodell für die forensische Untersuchung. Datensicherung. Jeder Fall ist anders, daher ohne Anspruch auf universelle Gültigkeit! Ausgangslage: Großunternehmen Lange Anfahrts- und Informationswege Volatile Daten sind längst zerstört... Vorgehen: System herunterfahren (Aktualisierung des Headers mit Flags!). Forensische Kopie der Datenträger erstellen. Verzicht auf Sicherung des Arbeitsspeichers. 2. März 2005, Seite 37

38 Vorgehensmodell für die forensische Untersuchung. Konfiguration des Dienstes und der Logs. Sichtung der Registry stets offline! Dokumentation der Konfiguration. Besonderheiten? Wo sind die Logs abgelegt? Verfahren zur Logrotation? Tipp: Der "Windows Registry File Viewer" von liest eine exportierte Registrydatei unter Umgehung des Windows-API. 2. März 2005, Seite 38

39 Vorgehensmodell für die forensische Untersuchung. Suche nach Logdaten und -dateien. Suche über die Datei-Extension *.evt. Suche über den Datei-Inhalt, z.b. mit file(1): # magic(5) entry for Microsoft Windows Eventlog files 4 string LfLe Microsoft Windows Eventlog Suche nach "LfLe" in unbenutzten Bereichen der Datenträger (unallocated clusters, file slack). Achtung vor false positives! Fragmente lassen sich nach Zeitstempeln und lfd. Nummern der Event-Frames ordnen und kombinieren. Für weitere Hinweise siehe z.b. HKEY_USERS\*\Software\Microsoft\Windows\CurrentVersion\ Explorer\ComDlg3\OpenSaveMRU\Evt 2. März 2005, Seite 39

40 Vorgehensmodell für die forensische Untersuchung. Auslesen der Rohdaten. Alles sichern und dokumentieren: Header Cursor Events... Hilfreich sind Hex-Editoren mit frei programmierbaren Ansichten: SweetScape 010 Editor (leider kein Unicode) X-Ways WinHex 2. März 2005, Seite 40

41 Vorgehensmodell für die forensische Untersuchung. Auslesen der Rohdaten Events. Allgemeines Vorgehen: 1. Cursor suchen. 2. Zu niedrigeren Offsets vorarbeiten, dabei jeden Event-Frame lesen. 3. Bei Erreichen des Headers (Offset 0x30) am Dateiende fortfahren. 4. Ende bei Erreichen des Cursors. Sonderfall, wenn die Flags DIRTY und WRAPPED nicht gesetzt sind: 1. Hinter dem Header starten. 2. Zu höheren Offsets vorarbeiten, dabei jeden Event-Frame lesen. 3. Ende bei Erreichen des Cursors. 2. März 2005, Seite 41

42 Vorgehensmodell für die forensische Untersuchung. Ergänzen der Meldungstexte. Der einfache Weg: Nachschlagen der Texte in einer Datenbank: Microsoft Events and Errors Message Center EventID.Net Alternativ: Auslesen mit einem Resource-Editor aus der betreffenden DLL. Tipp: XN Resource Editor von C. Wilson 2. März 2005, Seite 42

43 Vorgehensmodell für die forensische Untersuchung. Vervollständigung der Meldungstexte. Vorgehen: 1. In der Registry über Log und Datenquelle die entsprechende DLL finden (Wert "EventMessageFile"). 2. DLL im Resource-Editor öffnen und Messagetable betrachten. 3. Event-ID als Index führt zur gesuchten Meldung. 2. März 2005, Seite 43

44 Zusammenfassung.

45 Vorgehensmodell für die forensische Untersuchung. Ergebnis. Auf der Basis von Windows 2000 ist die Erkenntnislage mittlerweile stabil. Eine stetige Weiterentwicklung des Dienstes ist zu erkennen, u.a.: erweiterte Lokalisierung (ab W2k). AutoBackupLogFiles (ab Version und Kernfunktionen und Dateiformate bleiben bislang unverändert. Endgültige Sicherheit bietet nur die Dekompilierung. Rechtliche Situation? 2. März 2005, Seite 45

46 Vorgehensmodell für die forensische Untersuchung. Nächste Schritte Fertigstellung der Testsuite. Ausdehnung der Tests auf Windows XP und Beispiel-Implementierungen: Parser für Logdateien Parser für Messagetables Aufbau einer Datenbank von Textschablonen aus vertrauenswürdigen Quellen. 2. März 2005, Seite 46

47 Fragen & Antworten.

48 Vielen Dank für Ihre Aufmerksamkeit! Konzernsicherheit Deutsche Telekom AG

49 Ergänzende Materialien.

50 Ergänzende Materialien. Urheberrechtsgesetz 69e Dekompilierung. (1) Die Zustimmung des Rechtsinhabers ist nicht erforderlich, wenn die Vervielfältigung des Codes oder die Übersetzung der Codeform im Sinne des 69c Nr. 1 und 2 unerläßlich ist, um die erforderlichen Informationen zur Herstellung der Interoperabilität eines unabhängig geschaffenen Computerprogramms mit anderen Programmen zu erhalten, sofern folgende Bedingungen erfüllt sind: 1. Die Handlungen werden von dem Lizenznehmer oder von einer anderen zur Verwendung eines Vervielfältigungsstücks des Programms berechtigten Person oder in deren Namen von einer hierzu ermächtigten Person vorgenommen; 2. die für die Herstellung der Interoperabilität notwendigen Informationen sind für die in Nummer 1 genannten Personen noch nicht ohne weiteres zugänglich gemacht; 3. die Handlungen beschränken sich auf die Teile des ursprünglichen Programms, die zur Herstellung der Interoperabilität notwendig sind. 2. März 2005, Seite 50

51 Ergänzende Materialien. Urheberrechtsgesetz 69e Dekompilierung. (2) Bei Handlungen nach Absatz 1 gewonnene Informationen dürfen nicht 1. zu anderen Zwecken als zur Herstellung der Interoperabilität des unabhängig geschaffenen Programms verwendet werden, 2. an Dritte weitergegeben werden, es sei denn, daß dies für die Interoperabilität des unabhängig geschaffenen Programms notwendig ist, 3. für die Entwicklung, Herstellung oder Vermarktung eines Programms mit im wesentlichen ähnlicher Ausdrucksform oder für irgendwelche anderen das Urheberrecht verletzenden Handlungen verwendet werden. (3) Die Absätze 1 und 2 sind so auszulegen, daß ihre Anwendung weder die normale Auswertung des Werkes beeinträchtigt noch die berechtigten Interessen des Rechtsinhabers unzumutbar verletzt. 2. März 2005, Seite 51