Digitale Forensik. unter Microsoft Windows.

Transcrição

Digitale Forensik.
unter Microsoft Windows.
Andreas Schuster
Deutsche Telekom AG
Konzernsicherheit
[email protected]
Digitale Forensik unter Microsoft Windows.
Agenda.
1.
1.1
1.2
1.3
Probleme in einer Closed-Source-Umgebung
Registry
NTFS
Ereignisprotokoll
2.
2.1
2.2
2.3
2.4
Analyse des Arbeitsspeichers
Keylogger
TCP/IP
Kompromittierung
Persistenz
3.
Fazit
Digitale Forensik unter Microsoft Windows
Andreas Schuster
09.05.2007, Seite 2
Probleme in einer Closed-Source-Umgebung.
Kapselung der Systemfunktionalität durch eine definierte Schnittstelle (API)
Vorteile:

umfassende, überwiegend frei zugängliche Dokumentation der
Schnittstelle
(MSDN, Technet, Knowledge Base)

Konstanz der Schnittstelle über viele Jahre

erleichtert Entwicklern beiderseits der API die Softwarepflege
Andreas Schuster
09.05.2007, Seite 3
Nachteile bei Verwendung der API:

Scheitern bei unvollständigen Daten
(z. B. nach Rekonstruktion gelöschter Daten)

Anfälligkeit gegenüber gezielten Manipulationen
(anti-forensic techniques)

Inkaufnahme eines möglichen Informationsverlusts
Andreas Schuster
09.05.2007, Seite 4
Nachteile bei Umgehung der API:

Reverse-Engineering

Zulässigkeit

Aufwand

Zuverlässigkeit
Gefahr grundlegender Veränderungen durch jedes einzelne
Service-Pack oder Hotfix.
Andreas Schuster
09.05.2007, Seite 5
Beispiel: Registry.
Binärformat von Microsoft undokumentiert, aber gut verstanden.

Offline Registry Editor von Peter Nordahl (1997)

Parse::Win32Registry von James Macfarlane (2006)
Nützliche Meta-Daten:

Access Control Lists

Zeitpunkt des letzten Schreibzugriffs
Erschlagende Fülle von Informationen, teilweise in Ressource Kits und der
Knowledge Base dokumentiert.
Andreas Schuster
09.05.2007, Seite 6
Beispiel: NTFS.
von Microsoft nicht dokumentiert,
Hauptarbeit durch Linux-NTFS Projekt
Brian Carriers „File System Forensic Analysis“ gehört an den Arbeitsplatz.
Alternate Data Streams alias multiple $DATA-Attribute sollten mittlerweile
kein Problem mehr darstellen.
Andreas Schuster
09.05.2007, Seite 7
Beispiel: NTFS.
Zeitmarken für

Creation Time

Modified Time

MFT Modified Time

Accessed Time
Zeitmarken existieren in den Attributen

$STANDARD_INFORMATION

$FILE_NAME
Welcher Satz wird angezeigt, welchen Satz verändern Anti-forensic Tools (z.
B. Timestomper).
Andreas Schuster
09.05.2007, Seite 8
Beispiel: Ereignisprotokoll.
Ereignisprotokoll (Event Log Service):

zentraler Protokollierungsdienst

ähnlich syslog(8)

jedoch unerwartetes Verhalten: Die Ereignismeldung wird im Moment
des Betrachtens konstruiert.

Dateiformat wird nach mehr als 10 Jahren meistens verstanden.
Andreas Schuster
09.05.2007, Seite 9
Unter Verwendung der API:
Andreas Schuster
09.05.2007, Seite 10
Unter Verwendung der API:
Andreas Schuster
09.05.2007, Seite 11
Unter Umgehung der API:
4 Flags:

DIRTY – Daten geschrieben, Dateikopf und –rumpf sind bis zum
Schließen der Datei inkonsistent.

WRAPPED – der älteste Datensatz steht hinter dem jüngsten.

FULL – maximale Größe erreicht, Datenverlust ist aufgetreten.

PRIMARY – gesetzt nur bei Dateien, die der Dienst aktuell beschreibt

Unterschiedliche Behandlung bei BackupEventLog und
ClearEventLog.

von der Version des Dienstes abhängig.
Andreas Schuster
09.05.2007, Seite 12
Unter Umgehung der API:
Andreas Schuster
09.05.2007, Seite 13
Der Standardfließtext.
Die zu vermittelnden Informationen.
Fließtext: TeleGrotesk halbfett, 22 Punkt, Zeilenabstand 0,9 Zeilen,
nach einem Absatz 0,5 Zeilen, Farbe Schwarz.
Andreas Schuster
09.05.2007, Seite 14
Analyse des Arbeitsspeichers.
Aus dem Vortrag von Steve Wood
Andreas Schuster
09.05.2007, Seite 15

Operation in der Regel unterhalb der API

bestenfalls „graue Dokumentation“:

Codebeispiele

Symboldateien für Debugger

Kernel-Binary
Möglichkeiten zur Auswertung eines Speicherabbildes:
1. Suche nach Folgen druckbarer Zeichen
2. Rekonstruktion interner Datenstrukturen
3. Suche nach Objekten
Andreas Schuster
09.05.2007, Seite 16
Suche nach druckbaren Zeichen.

strings(1)
gibt Folgen von mindestens 4 druckbaren Zeichen aus

Achtung bei Multi-Byte-Zeichensätzen (UTF-16, UCS-2, …)
Null-Byte führt sonst zu vorzeitiger Terminierung bzw. Unterdrückung des
Strings.
Andreas Schuster
09.05.2007, Seite 17
Auswertung.
Demo - BinText.
Andreas Schuster
09.05.2007, Seite 18
Rekonstruktion interner Datenstrukturen.
Einfache Strukturen dominieren:

Baum

doppelt verkettete Liste:
kd> dt _LIST_ENTRY
nt!_LIST_ENTRY
+0x000 Flink
+0x004 Blink
: Ptr32 _LIST_ENTRY
: Ptr32 _LIST_ENTRY
Andreas Schuster
09.05.2007, Seite 19
Andreas Schuster
09.05.2007, Seite 20
PsActive
ProcessHead
smrss
rk
explorer
flink
blink
flink
blink
flink
blink
Andreas Schuster
09.05.2007, Seite 21
PsActive
ProcessHead
smrss
rk
explorer
flink
blink
flink
blink
flink
blink
rk
flink
blink
Andreas Schuster
09.05.2007, Seite 22
Vorteile:

relativ einfache Technik

umfangreiche Informationen
Nachteil:

enfache Umgehung durch Direct Kernel Object Manipulation (DKOM)
Leistungsfähigstes Programm seiner Art ist KnTList von George M. Garner.
Andreas Schuster
09.05.2007, Seite 23
Suche nach Datenstrukturen.
Einfaches, lineares Durchsuchen des Speicherabbildes.
Schwierigkeit: Formulierung einer geeigneten „Signatur“

hinreichende Trennschärfe

Robustheit gegenüber Manipulation (DKOM im weiteren Sinn)
Welche Daten sind essentiell?
Andreas Schuster
09.05.2007, Seite 24
1. Speicherverwaltung – POOL_HEADER
2. Kernel-Objekte – OBJECT_HEADER
3. spezifische Struktur – hier: EPROCESS
Andreas Schuster
09.05.2007, Seite 25
_POOL_HEADER beschreibt eine einzelne Allokation.
Die Struktur ist u.a. in den Debug-Symbolen des Kernels dokumentiert.
>dt nt!_POOL_HEADER
+0x000 PreviousSize
+0x000 PoolIndex
+0x002 BlockSize
+0x002 PoolType
+0x004 PoolTag
+0x004 AllocatorBackTraceIndex
+0x006 PoolTagHash
:
:
:
:
:
:
:
Pos 0,
Pos 9,
Pos 0,
Pos 9,
Uint4B
Uint2B
Uint2B
9
7
9
7
Bits
Bits
Bits
Bits
Andreas Schuster
09.05.2007, Seite 26
Suche nach Datenstrukturen..
BlockSize:
Größe dieses Blocks.
Zeiger “vorwärts” zum nächsten Block.
PreviousSize:
Größe des vorhergehenden Blocks.
Zeiger “zurück” zum vorherigen Block.
0 für den ersten Block einer Speicherseite.
Für beide Werte gilt:
Angabe in Einheiten zu 8 Bytes (Windows 2000: 32 Bytes).
Angabe beinhaltet den _POOL_HEADER (8 Bytes),
muss also mindestens 1 sein.
Andreas Schuster
09.05.2007, Seite 27
Deklaration im Windows Development Kit, Datei wdm.h:
typedef enum _POOL_TYPE {
NonPagedPool,
PagedPool,
NonPagedPoolMustSucceed,
DontUseThisType,
NonPagedPoolCacheAligned,
PagedPoolCacheAligned,
NonPagedPoolCacheAlignedMustS,
MaxPoolType
} POOL_TYPE;
0000
0001
0010
0011
0100
0101
0110
0111
Werte größer als 31 zeigen einen Session Pool an.
Andreas Schuster
09.05.2007, Seite 28
PoolType (Wert im Speicher) ist um 1 erhöht.
In der Praxis werden unterschieden:
0 = Block ist freigegeben
ungerade = non-paged pool
gerade = paged pool
Andreas Schuster
09.05.2007, Seite 29
Gemäß Dokumentation der Funktion ExAllocatePoolWithTag im MSDN:
bis zu 4 Zeichen
ASCII Werte zwischen 0 und 127
in little-endian (umgekehrter) Reihenfolge gespeichert
‘1234’ wird als ‘4321’ gespeichert
Jeder Ausführungspfad soll ein eigenes PoolTag verwenden.
Es gibt kein Verzeichnis fürPoolTags.
Jede Anwendung kann jedes beliebige (Einschränkungen s.o.) PoolTag
verwenden!
Versehentliche oder absichtliche “Mitbenutzung” von PoolTags anderer
Anwendungen (siehe skape & Skywing 2005 über Microsoft PatchGuard x64)
Andreas Schuster
09.05.2007, Seite 30
Beispiel 1 – Keylogger.
Zurück zum Beispiel…
Andreas Schuster
09.05.2007, Seite 31
Annahme: es handelt sich tatsächlich um einen Auszug aus einem Pool.
Andreas Schuster
09.05.2007, Seite 32
Wie ist der Block zu interpretieren?

Präfix „CM“ deutet bereits auf den Configuration Manager des Kernels
hin (Registry).

„CMVa“ steht laut Liste von PoolTags des Debuggers für „value cache
value tag“.

Suche nach Verwendung des PoolTags führt auf den Kernel, dort auf
die Funktion CmpGetValueKeyFromCache.
Andreas Schuster
09.05.2007, Seite 33
Ein kurzer Codeauszug der Fundstelle:
0049764B
00497650
00497652
00497657
0049765A
0049765B
0049765D
00497662
00497664
00497666
0049766A
0049766E
00497670
00497672
00497675
00497678
; CmpGetValueKeyFromCache(x,x,x,x,x,x,x)
call
_HvGetCellSize@8 ; HvGetCellSize(x,x)
mov
edi, eax
push
'aVMC'
; Tag
lea
eax, [edi+4]
push
eax
; NumberOfBytes
push
PagedPool
; PoolType
call
_ExAllocatePoolWithTag@12 ; ExAllocatePoolWithTag(x,x,x)
test
eax, eax
jz
short Alloc_CMVa_failed
and
word ptr [eax], 0 ; set first dword in alloc to 0
mov
[eax+2], di
; set second dword in alloc to data size
mov
ecx, edi
mov
edx, ecx
shr
ecx, 2
lea
edi, [eax+4]
; destination buffer starts at 4th byte
rep movsd
; copy cell
Andreas Schuster
09.05.2007, Seite 34
Aufruf u. a.durch:
ZwSetValueKey und NtSetValueKey
erzeugt bzw. ersetzt den Wert eines Schlüssels.

ZwQueryValueKey und NtQueryValueKey
gibt die Werte eines geöffneten Schlüssels zurück.
Abschließende Deutung: der Wert „E:\aradamax keylogger.exe“ wurde als
Wert in die Registry geschrieben oder von dort gelesen.
Andreas Schuster
09.05.2007, Seite 35
Beispiel 2 – TCP/IP.
Netzaktivität:

Microsoft Windows XP SP 2 als Guest OS in VMware 5.5.x

Netcat (nc.exe) wird gestartet und erwartet Verbindungen
Port 666/tcp.

Einige Minuten später wird Netcat wieder beendet.

Es gab keinen Verbindungsbau.

Die VMware-Sitzung wird angehalten; VMware speichert den
“physischen Speicher” der virtuellen Maschine in einer Datei.
Ziel: Finde Hinweise auf die Ausführung von Netcat.
Andreas Schuster
09.05.2007, Seite 36
1.
2.
3.
4.
5.
6.
7.
192.168.186.128:138/UDP,
0.0.0.0:135/TCP,
0.0.0.0:0/IGMP,
0.0.0.0:0/GRE,
0.0.0.0:1029/UDP,
127.0.0.1:1025/TCP,
0.0.0.0:666/TCP,
8. 192.168.186.128:139/TCP,
…
PID=4,
PID=800,
PID=884,
PID=4,
PID=948,
PID=1508,
PID=1448,
PID=4,
2006-07-17 22:08:47
2006-07-17 22:08:40
2006-07-17 22:08:49
2006-07-17 22:08:51
2006-07-17 22:09:46
2006-07-17 22:08:51
2006-07-17 22:11:15
(defunct)
2006-07-17 22:08:47
Andreas Schuster
09.05.2007, Seite 37
Suche nach TCP Connection Objects in ähnlicher Weise:
192.168.186.128:1037 -> 213.253.9.70:80, PID=884
192.168.186.128:1038 -> 213.253.9.70:80, PID=884
192.168.186.128:1039 -> 64.4.21.93:80, PID=884
PID 884 verweist auf eine Instanz von svchost.exe.
Es gibt keine Hinweise auf eine TCP-Verbindung zu nc.exe.
Andreas Schuster
09.05.2007, Seite 38
Beispiel 3 – Kompromittierung.
Prozessaktivität:

DFRWS 2005 Memory Analysis Challenge
http://www.dfrws.org/2005/challenge/index.html

Frische Installation von Microsoft Windows 2000.

„Der Besitzer hatte wenig Zeit, das System abzusichern.“

Der Computer fällt durch ungewöhnlichen Datenverkehr auf. (NIDS?)

Gegeben sind 2 mittels dd erstellte Speicherabbilder (vor/nach
Neustart).
Andreas Schuster
09.05.2007, Seite 39
Beispiel 3 – Kompromittierung..
Andreas Schuster
09.05.2007, Seite 40
Andreas Schuster
09.05.2007, Seite 41
LSASS.EXE (Local Security Authority Subsystem)
startet gewöhnlich keine Kindsprozesse.
Metasploit.exe deutet auf die Verwendung des
gleichnamigen Exploit-Baukastens hin.
Die weitere Untersuchung zeigt, dass UMGR32.EXE
das Trojanische Pferd „BackOrifice“ ist.
Andreas Schuster
09.05.2007, Seite 42
Das Trojanische Pferd startet einen Prozess „dfrws2005.exe“.
Der Prozess terminiert unmittelbar ohne Hinweis auf einen
Fehler.
Andreas Schuster
09.05.2007, Seite 43
Andreas Schuster
09.05.2007, Seite 44
Andreas Schuster
09.05.2007, Seite 45
Beispiel 4 – Persistenz von Speicherinhalten.
Prozesse, die augenscheinlich vor dem Systemstart (2005-06-05 00:32:27)
ausgeführt wurden:
Date
2005-06-03
2005-06-03
2005-06-04
Time
01:25:53Z
01:25:54Z
23:36:31Z
Image Name
csrss.exe
winlogon.exe
winlogon.exe
PID
168
164
176
Nach einem weiteren Warmstart (2005-06-05 15:00:56):
Date
2005-06-03
2005-06-05
2005-06-05
Time
01:25:53Z
00:32:40Z
00:32:43Z
Image Name
csrss.exe
smss.exe
csrss.exe
PID
168
156
180
Andreas Schuster
09.05.2007, Seite 46
Fazit.
Autoritative Dokumentation reicht nicht „bis auf‘s letzte Bit hinab“.
Notwendiges Reverse-Engineering erfordert hohen Aufwand.
(Rest-) Unsicherheit über die wahren Zusammenhänge zwingt zu
vorsichtigem Vorgehen und zurückhaltenden Interpretationen der
beobachteten Daten.
Nützliche, bisweilen verblüffende Ergebnisse rechtfertigen den Aufwand.
Andreas Schuster
09.05.2007, Seite 47
Weitere Informationen.
Harlan Carvey:
Windows Forensics and Incident Recovery
Addison Wesley, 2005
Harlan Carvey:
Windows Forensic Analysis DVD Toolkit
Syngress Media, 2007
http://computer.forensikblog.de/
Andreas Schuster
09.05.2007, Seite 48
Vielen Dank für
Ihre Aufmerksamkeit.
Andreas Schuster
Deutsche Telekom AG
Konzernsicherheit
[email protected]