int 1

Transcription

int 1
Kapitel 9:
Malware II
Software Reverse Engineering
Universität Mannheim
Lehrstuhl Praktische Informatik 1
Malware II
9.0 Übersicht
Software Reverse Engineering
Universität Mannheim
Lehrstuhl Praktische Informatik 1
Übersicht
• Malware Teil I:
 Code Obfuscation
• Malware Teil II: Weitere Methoden,
um Analyse zu verhindern/erschweren
 Statische Methoden
• Veränderung des PE-Files zur Erstellungszeit
 Dynamische Methoden
• Erkennung/Angriff von Analysetools zur Laufzeit
Software Reverse Engineering
3
Universität Mannheim
Lehrstuhl Praktische Informatik 1
Vorgestellte Techniken
• Packer
• Anti – Unpacking
 Anti – Dumping
 Anti – Emulation
 Anti – Debugging
• Weitere
 Erkennung von VM
 Verwendung von VM
 Code Injection
Software Reverse Engineering
4
Universität Mannheim
Lehrstuhl Praktische Informatik 1
Malware II
9.1 Packer
Software Reverse Engineering
Universität Mannheim
Lehrstuhl Praktische Informatik 1
Packer
• Verringerung des Speicherplatzbedarfs (Disketten,
Modemleitung, …) durch Binary-Komprimierung
• Zur Erstellzeit wird Programm gepackt
• Zur Laufzeit wird Programm vorab im Speicher
entpackt
• Heute
 nur noch zur Verschleierung des Binaries, da Programm
erst im entpackten Zustand „lesbar“
 Packer = Überbegriff auch für andere Arten der
Verschleierung, nicht nur Komprimierung
• Encrypter, Protector, …
Software Reverse Engineering
6
Universität Mannheim
Lehrstuhl Praktische Informatik 1
Statistiken
• ca. 80% aller binärer Malware ist gepackt
• ca. 65% aller gepackter Binärdateien sind Malware
• Symantec: ~2000 verschiedene Packer in ~200
Familien
Shadowserver Foundation Packer Statistics:
http://www.shadowserver.org/wiki/pmwiki.php/Stats/PackerStatistics
Software Reverse Engineering
7
Universität Mannheim
Lehrstuhl Praktische Informatik 1
Ein paar Packer
• Freie Packer
 UPX, http://upx.sourceforge.net
 FSG, http://www.xtreeme.prv.pl
• Kommerzielle Packer
 ASPack, http://www.aspack.com
• Kommerzielle Protectoren
 ASProtect , http://www.aspack.com
 Armadillo, http://www.siliconrealms.com
 Themida, http://www.oreans.com
Software Reverse Engineering
8
Universität Mannheim
Lehrstuhl Praktische Informatik 1
Packen
Originaler Einstiegspunkt (OEP)
Header
.text
Header
.text‘
.data
.data‘
.data
.rsrc‘
Gepacktes
Binary
Entpacker stub
Neue Section mit
komprimierten Daten
Software Reverse Engineering
Ungepacktes
Binary
.rsrc
Neuer Einstiegspunkt
9
Universität Mannheim
Lehrstuhl Praktische Informatik 1
Schritte beim Packen
• Originalen Header durch Packer-Header ersetzen
• Sections packen
 Komprimieren
 Optional verschlüsseln / Obfuscation Techniken
• Leere Section für entpacktes Programm erstellen
 Raw size = 0
• Entpacker-Stub erstellen
 Optional obfuscated / geschützt (Debugger-Erkennung, …)
• Neuen Einstiegspunkt auf Packer-Stub setzen
Software Reverse Engineering
10
Universität Mannheim
Lehrstuhl Praktische Informatik 1
Entpacken
Raw size=0
Header
Datei
Entpacker stub
In den Speicher laden
Header
Entpacker stub
Entpacken
Header
.text
Software Reverse Engineering
.data
.rsrc
Speicher
Entpacker stub
11
Universität Mannheim
Lehrstuhl Praktische Informatik 1
Schritte beim Entpacken
• Start am Einstiegspunkt des Entpacker-Stubs
• Rekonstruktion der gepackten Daten
 Leere Platzhaltersection wird gefüllt
• Wiederherstellung der Imports
 Windows-Loader löst nur die Importe des Packers selber
auf, nicht aber die des gepackten Programms
• Verzweigung an den Originalen Einstiegspunkt des
gepackten Programms
Software Reverse Engineering
12
Universität Mannheim
Lehrstuhl Praktische Informatik 1
UPX
• Ungepacktes
Binary
• Mit UPX
gepacktes
Binary
Software Reverse Engineering
13
Universität Mannheim
Lehrstuhl Praktische Informatik 1
UPX
UPX0
Header
UPX1
.rsrc
Entpacker Stub
UPX0
UPX1
Header
Header
.rsrc
Entpacker Stub
.text
Software Reverse Engineering
.data
.rsrc
14
Entpacker Stub
Universität Mannheim
Lehrstuhl Praktische Informatik 1
Manuelles Entpacken
• Für Programmanalyse
 entpacktes Programm nötig [5]
• Manuelles Entpacken
 Programm nach Entpackvorgang an OEP anhalten
 Speicherdump erstellen
 Imports müssen rekonstruiert werden
• Vorgehensweise
 Entpacken von Hand (z.B. mit Debugger)
 Generische Entpacker
• Heuristiken, exec-after-write, ..
 Spezialisierte Entpacker
Software Reverse Engineering
15
Universität Mannheim
Lehrstuhl Praktische Informatik 1
Manuelles Entpacken von UPX
• Gepacktes Programm
startet an Entpacker-Stub
• Mit PUSHAD werden zu
Beginn alle Register auf den Stack gelegt
• Dann: Entpacken des Binaries
• Kurz bevor an OEP verzweigt wird, werden
Registerinhalte mit POPAD
zurück geholt
Software Reverse Engineering
16
Universität Mannheim
Lehrstuhl Praktische Informatik 1
Manuelles Entpacken von UPX
• Trick: Memory-Breakpoint auf Stackstellen setzen,
an denen die Register gespeichert wurden
• Beim POPAD triggert
Breakpoint
• Nachfolgendes JMP
verzweigt an OEP
Software Reverse Engineering
17
Universität Mannheim
Lehrstuhl Praktische Informatik 1
Malware II
9.2 Anti-Unpacking
Software Reverse Engineering
Universität Mannheim
Lehrstuhl Praktische Informatik 1
Anti Unpacking
• Viele Packer versuchen manuelles Entpacken zu
verhindern
• Verschiedene Ansätze




Anti – Dumping
Anti – Debugging
Anti – Emulation
Vorgestellte Verfahren auch zu anderen Abwehrzwecken
als nur Anti-Unpacking verwendet
• Referenz: Peter Ferrie‘s „Anti Unpacker Tricks“ *1+
Software Reverse Engineering
19
Universität Mannheim
Lehrstuhl Praktische Informatik 1
Process Dumping
• Process Dumping
 Speicherauszug eines Programms auf Festplatte schreiben
 z.B. um entpacktes Programm zu erhalten,
aber auch für nicht gepackte Dateien sinnvoll
• Orientierung am PE-Header (im Speicher)
 Wo liegen die Sections?
 Wie viele Sections gibt es?
 Wie groß sind die Sections?
• Anti-Dumping
 Verfahren um Dumping zu verhindern/ verfälschen
Software Reverse Engineering
20
Universität Mannheim
Lehrstuhl Praktische Informatik 1
Anti Dumping
• Durch Modifikation des PE-Headers im Speicher
 Komplettes Löschen des PE-Headers
 Verwendung ungültiger Größenangaben
• SizeOfImage
• Gegenmaßnahme: nicht auf PE-Header verlassen,
sondern selber den Speicher durchsuchen
Software Reverse Engineering
21
Universität Mannheim
Lehrstuhl Praktische Informatik 1
Anti Dumping
• Durch Modifikation des Programmcodes im Speicher
 Nanomites (Armadillo)
• Sprünge werden durch int 3 ersetzt
• Geschütztes Programm debugged sich selbst
• Bei Exceptions werden Sprünge simuliert
 Stolen Bytes (ASProtect)
• Einzelne Operationen/Funktionen in dynamisch
alloziierten Speicher kopieren und danach löschen
 Verschlüsseln der Pages
• Entschlüsselung erst bei Zugriff
• Optional nach Benutzung wieder verschlüsseln
Software Reverse Engineering
22
Universität Mannheim
Lehrstuhl Praktische Informatik 1
Anti Emulation
• AV-Scanner nutzen Emulatoren
 Binary wird vor Ausführung teilweise im Emulator
ausgeführt, bis „ausreichend“ entpackt
 Entpacktes Binary wird nach Viren durchsucht
• Emulatoren sind nicht vollständig
 Nicht alle Maschinenbefehle werden unterstützt
• FPU, MMX, …
 Nicht alle APIs werden emuliert
• User32!LoadKeyboardLayoutEx
 Nicht das komplette Programm wird ausgeführt
 Malware versucht Emulator zu erkennen
Software Reverse Engineering
23
Universität Mannheim
Lehrstuhl Praktische Informatik 1
Anti Debugging
• Es existieren zahlreiche Tricks, um Existenz von
Analysetools (z.B. Debugger) zur Laufzeit zu erkennen
 Generische Verfahren
 Programmspezifische Verfahren
• Nutzen bekannte Schwachstellen/Charakteristika
einzelner Analysetools aus
• Unterschiedliche Reaktionen auf Entdeckung
 Programmabbruch
 Analysetool/System angreifen
 Alternatives („gutartiges“) Verhalten zeigen
Software Reverse Engineering
24
Universität Mannheim
Lehrstuhl Praktische Informatik 1
Debugger Erkennung
• Debugger hinterlassen Spuren





PEB.BeingDebugged
NtGlobalFlags, Heap Flags
Fenster, Prozesse, Devices
OutputDebugString () und GetLastError()
Parent-PID
• Debugger-Erkennung mit Windows-APIs




IsDebuggerPresent ()
CheckRemoteDebuggerPresent ()
NtQueryInformationProcess ()
NtQuerySystemInformation ()
Software Reverse Engineering
25
Universität Mannheim
Lehrstuhl Praktische Informatik 1
Debugger Behinderung
• Debuggen verhindern/behindern
 Threads verstecken
 Sich selber debuggen (es kann nur einen Debugger geben)
 Eingaben blockieren
• Breakpoints entdecken/entfernen




Rekonstruktion des originalen Programm-Images
Checksummen berechnen
Nach int 3 (CC oder CD 03) suchen
HW-Breakpoints abfragen bzw. verändern
Software Reverse Engineering
26
Universität Mannheim
Lehrstuhl Praktische Informatik 1
Weitere Methoden
• Timing
 Zwischen zwei Zeitmessungen EXCEPTION erzeugen
 Debuggter Prozess benötigt viel länger, weil
ExceptionHandler des Debuggers aufgerufen wird
 SINGLE-STEP ist ebenfalls viel langsamer
• Exceptions
 Selbst erzeugte Exceptions gehen immer erst an Debugger
• Verwirrung des Analysten
• Erkennung, wenn Exception nicht weitergeleitet wird
Software Reverse Engineering
27
Universität Mannheim
Lehrstuhl Praktische Informatik 1
Weitere Methoden
• Thread Local Storage (TLS)
 Normalerweise beginnt Programmausführung am EP
 Programmausführung im Debugger beginnt bei EP
 TLS callbacks erlauben Code-Ausführung vor dem EP
• Dort dann Überprüfung auf Debugger
 Data Directory enthält TLS Table
Loader
code
TLS
Init
Loader
code
Normaler Programmcode
Originaler Einstiegspunkt (OEP)
Debugger stoppt hier das 1. Mal
Software Reverse Engineering
28
Universität Mannheim
Lehrstuhl Praktische Informatik 1
Programmspezifische Methoden
• Analysetools hinterlassen ebenfalls Spuren
• Analysetools haben Schwachstellen
• Gängige Tools
 SoftICE
 Ollydbg, Immunity Debugger
 WinDbg
Software Reverse Engineering
29
Universität Mannheim
Lehrstuhl Praktische Informatik 1
SoftICE
• SoftICE legt Devices an
 \\.\SICE
 \\.\NTICE
• SoftICE verwendet Treiber
 Treiber auflisten und Versionsinformationen abfragen
• int 1
 Interrupt kann normalerweise nicht aus dem Usermode
aufgerufen werden
 wenn SoftICE hingegen läuft schon
Software Reverse Engineering
30
Universität Mannheim
Lehrstuhl Praktische Informatik 1
OllyDbg
• OutputDebugString()
 OllyDbg stürzt bei gewissen Strings ab, z.B. %s%s
• Fensternamen
 OllyDbg erstellt Fenster mit Namen „OLLYDBG“
• Guard Pages
 OllyDbg benutzt Guard Pages für Memory Breakpoints
 Methode: Guard Page erstellen und darin Code ausführen
• unter OllyDbg wird keine Exception geworfen
• Malformed files
 Memory corruption durch ungültige PE-Werte
• z.B. Export Address Table Entries > 0x4000‘0000
Software Reverse Engineering
31
Universität Mannheim
Lehrstuhl Praktische Informatik 1
WinDbg
• Fenster
 Auch WinDbg erstellt Fenster mit charakteristischem
Namen „WinDbgFrameClass“
• Prozessnamen
 Natürlich kann auch nach Prozess „windbg.exe“
gesucht werden
Software Reverse Engineering
32
Universität Mannheim
Lehrstuhl Praktische Informatik 1
Malware II
9.3 Weitere Methoden
Software Reverse Engineering
Universität Mannheim
Lehrstuhl Praktische Informatik 1
Erkennung von VM
• Häufig werden zur Analyse von Malware virtuelle
Maschinen eingesetzt
 Infektion des Systems hat keine Folgen
 Snapshot-Mechanismus: Speichern und Zurücksetzen
auf einen bestimmtem Systemzustand
• Typische Produkte
 VMWare
 Virtual PC
• Malware versucht die Existenz einer VM zu entdecken
Software Reverse Engineering
34
Universität Mannheim
Lehrstuhl Praktische Informatik 1
Erkennung von VMWare
• Offensichtliche Spuren




MAC Adresse hat konstantes Präfix
Geräte heissen „VMWare … Controller“
VMWare Tools befinden sich im Speicher
Registry-Einträge mit „VMWare“ im Schlüssel- oder Wert
• VMWare bietet I/O Kommunikation über Backdoor
mov eax, „VMXh“
mov ebx, 0
mov ecx, 10
mov dx, „VX“
in eax, dx
cmp ebx, „VMXh“
Software Reverse Engineering
//
//
//
//
magic value
any value
get VMWare version
port number
// ebx contains magic value if VMWare is present
35
Universität Mannheim
Lehrstuhl Praktische Informatik 1
Generische VM-Erkennung
• Es existiert generische VM-Erkennung
 Joanna Rutkowska: „Red Pill“ *2+
 Gleicher Code erkennt alle VMs
• SIDT – Store Interrupt Descriptor Table (IDT)
 Unprivilegierte Operation: Aufruf aus Ring 3 möglich
 Auslesen des IDTR-Registers
 Nur ein IDTR pro System: bei Verwendung einer VM
müssen sich „host“ und „guest“ Register teilen
 Innerhalb der VM steht ein anderer Wert in IDTR
als auf einem nativen System
Software Reverse Engineering
36
Universität Mannheim
Lehrstuhl Praktische Informatik 1
VM Obfuscators
• Herkömmliche Packer entpacken originalen
Programmcode (komplett oder teilweise)
• VM Obfuscatoren: Programmcode wird zu keiner
Zeit wiederhergestellt
• Statt dessen: Benutzung einer virtuellen Maschine
 Programmcode wird in Bytecode übersetzt
 Stark geschützter Interpreter führt Bytecode aus
 Teilweise wird bei jeder Übersetzung eine neue
VM-Sprache generiert
• Bekanntes Produkt: VMProtect
 http:// www.vmprotect.ru
Software Reverse Engineering
37
Universität Mannheim
Lehrstuhl Praktische Informatik 1
VM Obfuscators
• Analyse von Bytecode ist sehr aufwendig
• Ausführung des Bytecodes ist viel
langsamer/komplexer
 Es werden viel mehr Operationen ausgeführt
 Emulatoren brechen vorzeitig ab
• Durch Verwendung von (mehreren) Sprachtemplates
werden immer neue Sprachen erzeugt
 Kein „generischer Entpacker“ für VM Obfuscator möglich,
wenn man eine Sprache verstanden hat
• Beispiel-Analyse: HyperUnpackMe2 [3]
Software Reverse Engineering
38
Universität Mannheim
Lehrstuhl Praktische Informatik 1
Code Injection
• Code Injection =
Einschleusen von Code in anderen Prozess
 Unverdächtiger Prozess führt Schadcode aus,
z.B. Internet Explorer
 Kein zusätzlicher Prozess im Taskmanager sichtbar
 Eskalation von Sicherheitsprivilegien,
z.B. Internet Explorer darf „durch“ die Firewall
Malware
Schadcode
Injection
Internet Explorer
Schadcode
Software Reverse Engineering
39
F
i
r
e
w
a
l
l
Universität Mannheim
Lehrstuhl Praktische Informatik 1
Code Injection Techniken
• Es existieren zahlreiche Techniken, um Code in
anderen Prozess einzuschleusen
• Klassische Variante: CreateRemoteThread()




OpenProcess()
WriteProcessMemory()
CreateRemoteThread()
TerminateThread()
// IE öffnen
// Schadcode einfügen
// Schadcode ausführen
// eigenen Prozeß beenden
• Eingeschleuster Code kann unterschiedliche Aufgaben
erfüllen
 DLL Injection: Betroffener Prozess lädt bösartige DLL nach
Software Reverse Engineering
40
Universität Mannheim
Lehrstuhl Praktische Informatik 1
Code Injection Techniken
• AppInit_DLLs
 Unter „HKEY_LOCAL_MACHINE\Software\Microsoft\
Windows NT\CurrentVersion\Windows“ gelistete DLLs
werden automatisch in Anwendungen geladen
• SetWindowsHookEx()
 Lädt DLL in andere Prozesse
 DLL bietet Hookfunktion, die unter bestimmten
Vorraussetzungen ausgeführt wird
 z.B. bei Tastatureingaben
• SvcHost
 Dienst mit Schadcode für existierenden svchost registrieren
• u.v.m. [4]
Software Reverse Engineering
41
Universität Mannheim
Lehrstuhl Praktische Informatik 1
Malware II
9.4 Referenzen
Software Reverse Engineering
Universität Mannheim
Lehrstuhl Praktische Informatik 1
Referenzen
• Anti Unpacker Tricks
 [1] Peter Ferrie, http://pferrie.tripod.com/
• Red Pill
 [2] Joanna Rutkowska, http://invisiblethings.org/papers/redpill.html
• Defeating HyperUnpackMe2
 [3] Rolf Rolles, http://www.openrce.org/articles/full_view/28
• Blackout: What Really Happened
 [4] Jamie Butler and Kris Kendall
• A Study of the Packer Problem and Its Solutions (Ferrie et. al)
 [5] http://www.ecsl.cs.sunysb.edu/tr/TR237.pdf
Software Reverse Engineering
43
Universität Mannheim
Lehrstuhl Praktische Informatik 1