Tatort Internet: Zeig mir das Bild vom Tod

Inhaltsverzeichnis

Gestern gingen tatsächlich Schlagzeilen über eine vor der Küste Brasiliens abgestürzte Air-France-Maschine durch die Nachrichten. Das Flugzeug gilt immer noch als verschollen und exklusive Bilder der Katastrophe wären ein gutes Lockmittel, um die Empfänger dazu zu veranlassen, auf den Anhang zu klicken. Zu gut für meinen Geschmack! Bei so was schrillen bei mir sofort die Alarmglocken.

Ich speichere also den Anhang der E-Mail in einem "Shared Folder", auf den auch meine virtuelle Malware-Analyseumgebung Zugriff hat. Keine Experimente mit meinem Arbeitsplatz-System. Im geschützten virtuellen Umfeld lade ich die Powerpoint-Datei zunächst bei Virustotal hoch, um zu schauen, ob sich bereits einer der AV-Hersteller die Mühe gemacht hat, sie zu analysieren. Fehlanzeige! Gerade mal ein Hersteller stuft sie als irgendwie "verdächtig" ein. Ein leider nicht eben seltenes Ergebnis für Schädlinge, die gerade frisch die Runde machen.

Also an die Arbeit – das könnte spannend werden. Erstmal sehen, ob die einfachen Methoden was zu Tage fördern. Es ist erstaunlich, wie oft man schon mit dem Unix-Befehl strings verdächtige Zeichenketten wie einen typischen PE-Header, Importnamen wie Createfile oder WinExec aufspüren kann. Das sind dann eindeutige Anzeichen für ausführbaren Code, der in einer Office-Datei eigentlich nichts zu suchen hat. Doch hier fördert strings außer ein paar Powerpoint-typischen Zeichenketten wie "Arial" nichts Lesbares zu Tage.

Im nächsten Schritt setzte ich das schon deutlich raffiniertere Tool Officecat des Snort-Teams auf die mysteriöse Powerpoint-Datei an. Erst kürzlich leistete es mir bei der Analyse einer angeblichen Rechnung wertvolle Dienste, weil es nicht nur behauptete, dass die Datei infiziert sei, sondern auch noch den "Common Vulnerability Enumerator" CVE-2006-6456 ausspuckte. Dieser Zeiger auf die Schwachstellendatenbank des MITRE versorgte mich mit Links zu diversen Beschreibungen der ausgenutzten Lücke in Microsoft Word einschließlich des Microsoft Security Bulletins MS07-014, mit dem die Lücke geschlossen wurde.

Doch bei meinen angeblichen Crash-Bildern liefert Officecat nur die wenig glaubwürdige Aussage: "SAFE File". Dass diese Datei wirklich sicher sein soll, kann ich mir beim besten Willen nicht vorstellen. Schon eher glaube ich, dass der einfache, signaturbasierte Ansatz von Officecat mal wieder versagt hat. Denn ohne die passende Signatur für bereits bekannte und analysierte Exploits gehen diese Tests in Leere.

Also werde ich wohl selbst den Honigtopf spielen und die Powerpoint-Datei in meiner abgesicherten Umgebung mit einem alten, ungepatchten Office 2003 öffnen. Es wäre doch gelacht, wenn sich der Übeltäter nicht durch auffällige Aktivitäten wie das Erstellen neuer Dateien oder das Nachladen von Schadcode aus dem Internet verrät.

Ein wahrer Segen ist dabei das Tool ProcMon aus der SysInternals-Suite, das alle Aktivitäten an Dateissystem, Registry und den Start neuer Prozesse protokolliert. Und in der Tat: Direkt nach dem Öffnen der Powerpoint-Datei erscheint ein neuer Prozess namens fssm32.exe. Des Weiteren öffnet Powerpoint im Hintergrund eine plötzlich aufgetauchte Datei unter Temp\Celebrities_Without_Makeup.pps. Eine geschickte Taktik, die ich schon des Öfteren bei bösartigen Dateien in Formaten wie DOC, XLS, PPT oder auch PDF beobachtet habe: Erst legen sie eine ausführbare Datei ab und führen sie aus. Direkt im Anschluss öffnen sie eine harmlose Datei, wie hier die Präsentation der abgeschminkten Modeschönheiten, um das Opfer nicht misstrauisch zu machen.

Außerdem zeigt Wireshark seltsamen HTTP-Traffic, bei dem ein POST-Request auf Port 8080 der IP-Adresse 202.52.X.Y abgesetzt wird. Ein Blick auf den whois-Dienst von heise Netze verrät mir, dass der Server in Kathmandu, Nepal, steht. Das kann beim besten Willen keines der regulär installierten Programme gewesen sein. Den Netzwerk-Sniffer lass ich bei so was routinemäßig auf dem Host-System mitlaufen. Da er außerhalb des Testsystems am Netzwerk lauscht, kann nicht einmal ein aktives Rootkit, das sich im Kernel eingenistet hat, seine Aktivitäten ganz vor ihm verstecken. Schlimmstenfalls würde ich immer noch einen verschlüsselten Datenstrom sehen.

Auch beim zweiten Blick lässt sich weder der Prozess noch die Datenübertragung nach Nepal auf eine natürliche Ursache zurückführen. Damit ist schon mal bewiesen, dass hier Malware am Werk ist. Doch die spannende Frage ist: Wie hat sie es angestellt, Code auszuführen? Selbst eine intensive Suche im Web bringt mich nicht weiter. Offenbar gibt es einfach keine vernünftigen Werkzeuge, um Makros aus Office-Dateien zu extrahieren oder sie gar auf Shellcode zu untersuchen. Also muss ich mir die wohl selber schreiben.

Das wäre weitaus einfacher, wenn die Datei bereits im neuen XML-Format vorläge, das Microsoft mit Office 2007 eingeführt hat. Da könnte man bereits mit einem Unzip-Tool halbwegs lesbare Dateien zutage fördern und im Editor anschauen. Doch meine Powerpoint-Datei ist im alten Binärformat. Also verbringe ich die nächsten Tage mit Recherche und der Lektüre mehrerer Microsoft-Artikel. Die Spannung steigt, als ich die erste, halbwegs lauffähige Version meines OfficeMalScanners auf die Powerpoint-Datei ansetze.

[pagebreak Premiere]

Premiere

Sieh an, das Tool funktioniert wie geplant und zeigt mir insgesamt 5 Streams an, aus denen sich das Powerpoint-Dokument zusammensetzt:

Pictures   [TYPE: Stream - OFFSET: 0x200 - LEN: 857541] 
CurrentUser [TYPE: Stream - OFFSET: 0xe3600 - LEN: 47] 
SummaryInformation   [TYPE: Stream - OFFSET: 0xd7800 - LEN: 44484] 
PowerPointDocument   [TYPE: Stream - OFFSET: 0xd1800 - LEN: 46958] 
DocumentSummaryInformation   [TYPE: Stream - OFFSET: 0xd7800 - LEN: 912] 

Allerdings sieht das bisher recht harmlos aus; insbesondere hat der Scanner kein VB-Makro gefunden. Dabei hatte ich extra eine spezielle Erkennungsroutine gebaut, die mir den Visual-Basic-Skriptcode sogar dekomprimiert in eine Datei geschrieben hätte. Na ja, dann eben beim nächsten Mal.

Anscheinend greift die Powerpoint-Datei etwas tiefer in die Trickkiste, um Code auszuführen. Wahrscheinlich nutzt sie eine der zahlreichen, bekannten – und eigentlich längst gepatchten – Sicherheitslücken in Powerpoint, über die man direkt eigenen Code einschleusen und ausführen kann. Trotzdem müsste der sich doch eigentlich in der Office-Datei aufspüren lassen, wenn man nach den richtigen Dingen sucht. Ich mach mich also erneut an die Arbeit, um mit einer neuen Scan-Routine ein wenig tiefer zu schürfen.

Ein paar Stunden später ist die neue Version fertig. Sie entdeckt in Office-Dateien versteckte, ausführbare Dateien an ihrem PE-Header; also dieses „MZ“ und so weiter, das man sieht, wenn man mal eine EXE-Datei in einem Editor öffnet. Eine eingebettete Windows-Objekt-Datei im OLE-Format erkenne ich an der typischen Office-Binärformat-Signatur \xD0\xCF\x11\xE0\xA1\xB1\x1a\xE1.

Außerdem habe ich gleich noch eine Reihe von Signaturen gebastelt, die typische Shellcode-Elemente aufspüren. Unter anderem springt das Tool auf die Kombination von Push- und Call-Befehlen an, wie sie für Funktionsaufrufe typisch sind. Aber auch einige komplexere und deshalb zuverlässigere Signaturen sind schon da. Das hier etwa ist ein Klassiker der Windows-Shellcode Programmierung, den immer noch viele Exploits genau so einsetzen:

mov eax, fs:[30h] 
mov eax, [eax+0Ch] 
mov esi, [eax+1Ch] 
lodsd 
mov ebp, [eax+08h] 
 

Wenn man Code einschleust, will man typischerweise Dateien aus dem Netz nachladen, auf Festplatte schreiben und starten. Dafür gibt es im System bereits Funktionen; um sie aufzurufen, muss man sie die allerdings erst mal finden. Bereits 2002 veröffentlichte die legendäre Hackergruppe "Last Stage of Delirium" dieses Verfahren, um zuverlässig die Basisadresse der zentralen Systembibliothek kernel32.dll im Speicher zu ermitteln. Sie stellt eine Reihe von nützlichen Systemfunktionen wie LoadLibraryA bereit, über die man dann weitere Bibliotheken nachladen kann.

Der Code selbst ist einfach gestrickt: An der Speicheradresse FS:0x30 eines aktiven Windows-Prozesses befindet sich immer ein Zeiger auf den genannten Process Environment Block (PEB), der unter anderem verkettete Listen über bereits geladene Module enthält. An denen hangelt sich der Code entlang, bis schließlich die gewünschte Basisadresse der kernel32.dll im Register ebp landet. Das wegweisende Paper Understanding Windows Shellcode (PDF) und ein paar andere Quellen lieferten die wichtigsten Maschinencode-Sequenzen für die Shellcode-Erkennung.

Doch weiter im Text – wir wollen ja schließlich eine Powerpoint-Datei auseinandernehmen. Ich teste also den OfficeMalScanner mit meinem neuen Scan-Modus und habe auch prompt Erfolg. Ein FS:30-Zugriff, um die Kernel32-Basis-Adresse zu finden, eine API-Hashing-Schleife zum Aufspüren bestimmter Funktionen und reihenweise Push/Call-Kombinationen:

FS:[30h] (Method 1) signature found at offset: 0x506e 
API-Hashing signature found at offset: 0x52fb 
PUSH DWORD[]/CALL[] signature found at offset: 0x50ab 
PUSH DWORD[]/CALL[] signature found at offset: 0x5137 
... 
 

Der Kontrollblick mit dem ebenfalls schnell zusammengebastelten Disassembler DisView.exe zeigt tatsächlich ab 0x506e eindeutig Shellcode. Aber so richtig zufrieden bin ich noch immer nicht.

[pagebreak Zugabe]

Zugabe

Mein Instinkt sagt mir, dass da noch mehr zu holen sein muss. Dabei fällt mir ein, dass Shellcode sehr häufig kodiert ist – zum einen um verdächtigen Code zu verbergen, zum anderen aus praktischen Gründen. So kann man in vielen Fällen bestimmte Zeichen nicht verwenden, etwa das Null-Zeichen, das das Ende eines Strings signalisiert und damit den Rest des Codes abschneidet. Andererseits enthalten viele Befehlssequenzen beziehungsweise Speicheradressen den Wert 0. Als Workaround verknüpft man seinen Code etwa via XOR zeichenweise mit einem bestimmten Wert und packt eine passende Dekodier-Routine davor, die das wieder rückgängig macht. Dabei muss man nur ein Zeichen verwenden, das im Code nicht vorkommt, weil es sonst wieder eine Null ergäbe.

Jetzt könnte ich mich zwar auf die Suche nach diesen Dekodierschleifen machen. Doch diesmal ziehe ich die Brute-Force-Keule dem Heuristik-Florett vor, lade das komplette Dokument in den Speicher und probiere einfach alle Byte-Werte systematisch durch. Nach jedem Durchlauf schaue ich erneut nach, ob sich jetzt eine PE- oder OLE-Signatur findet. Das dauert selbst bei dieser Datei mit knapp einem MByte nicht länger als eine Minute.

Bingo! Mit „scan brute“ spuckt mir mein Scanner gleich vier Dateien aus: eine eingebettete OLE-Datei und drei PE-Files. Alle vier waren via XOR mit 0x85 kodiert. Bei der OLE-Datei handelt es sich um die „Celebrities Without Makeup“, die ich schon vorher via Procmon zu Gesicht bekommen hatte. Und als ich die PE-Dateien bei Virustotal hochlade, erhalte ich prompt einige Trojaner- beziehungsweise Downloader Erkennungen.

Damit bin ich mit meiner Analyse fast fertig. Allerdings würde ich gern noch etwas besser verstehen, was der Shellcode eigentlich macht. Normalerweise befindet sich der FS:30-Code ziemlich am Anfang. Das wäre also bei 0x506e. Kurz davor, bei 0x5004 zeigt DisView einen typischen Funktionsprolog:

sub esp, 00000120h  
mov edi, esp 

Den nehme ich jetzt einfach mal als Start des Codes an. Doch eine statische Analyse des Assembler-Codes ist mir zu mühselig. Selbst mit einem richtig guten Disassembler wie IDA Pro ist das wegen der dynamisch geladenen Import-Namen und selbstmodifizierender Codeteile kein reines Vergnügen. Schöner wäre es, wenn ich den Code gleich live im Debugger beobachten könnte. Moment mal – ich hatte da doch mal ein Tool geschrieben, das Shellcode mit einer funktionierenden EXE-Hülle versieht. Da müsste man doch eigentlich nur…

Kurze Zeit später baut mir MalHost-Setup aus dem Shellcode ab 0x5004 die EXE-Datei evil.exe, die ich direkt starten kann. Damit das Teil dann nicht gleich unkontrolliert losrennt, lasse ich MalHost-Setup über den Parameter wait die ersten zwei Bytes noch mit 0xEB 0xFE überschreiben. In der Intel-Maschinensprache stehen die für

jmp eip 
 

also einen Sprung auf den Inhalt des Instruction Pointers eip, was eine kompakte Endlossschleife erzeugt. Das lässt mir genug Zeit, nach dem Start noch einen Kaffee zu holen. Soll er ruhig ein paar Runden drehen.

Dann kommt OllyDbg zum Einsatz. Mit File/Attach hänge ich mich mit dem Debugger an den Prozess evil.exe und lande nach Run/Pause (F9/F12) auch prompt auf meiner Endlosschleife. Um den Code zu untersuchen, muss ich ihn wieder in den Originalzustand zurückpatchen. Das geht schnell via rechte Maustaste und „Follow in Dump/Selection“. CTRL-E für den Edit-Modus und schon werden aus 0xEBFE die Original-Bytes 0x81EC; im Code-Fenster des Debuggers erscheint wieder der bekannte Funktionsprolog.

Jetzt kann es losgehen. Im Live-Debugging gibt der Code seine Geheimnisse schnell preis. So verbirgt sich hinter dem call [ebp+4] bei 0x50ae der dynamische Import von GetFileSize. Der Shellcode durchläuft hier eine Art Selbstfindungsprozess: In einer Schleife probiert er alle File-Handles durch, bis er eines findet, das mit einer Datei der Größe 968.192 Bytes verbunden ist – also exakt der der Powerpoint-Datei. Danach springt er an bestimmte Stellen dieser Datei, entpackt die dort eingebetteten Programme, schreibt sie auf die Platte und startet sie.

Mission erfüllt! Damit gebe ich mich für diesmal zufrieden. Zwar musste ich letztlich eine komplette Scan-Suite schreiben, um dieser Powerpoint-Datei ihre Geheimnisse zu entlocken. Doch ich bin mir sicher, dass mir die noch gute Dienste leisten wird. Denn Unrat im Office-Format gibt es wie Sand am Meer.
Den Bedarf für bessere Tools zur Analyse von Office-Dateien hat übrigens auch Microsoft erkannt und kurze Zeit später das Office Visualization Tool (OffVis) zur öffentlichen Benutzung freigegeben. Es analysiert die Dateistruktur und gibt dabei auch Hinweise auf potenzielle Exploits. In meiner Powerpoint-Datei erkennt es unter anderem einen Exploit für eine der Powerpoint-Sicherheitslücken, die Microsoft vor einem Jahr zusammen mit 13 weiteren geschlossen hat (CVE-2009-0556 in MS09-17). Da es jedoch keine Möglichkeit bietet, Shellcode zu identifizieren oder eingebettete Executables aufzuspüren, kann es in meiner Werkzeugbox die OfficeMalScanner-Suite nicht ersetzen.

PS: Einige Antiviren-Produkte schlagen beim Download der OfficeMalScanner-Suite an. Dabei handelt es sich um Fehlalarme; die Hersteller wurden benachrichtigt.

Diskutieren Sie mit im Forum zu Tatort Internet oder werden Sie Fan von Tatort Internet auf Facebook

Über „Tatort Internet“

Die Serie "Tatort Internet" wurde ursprünglich im c't magazin ab Heft 13/2010 veröffentlicht. In den Artikeln können Sie Experten über die Schulter schauen, wie sie verdächtige Dateien analysieren und Schädlingen auf die Schliche kommen. Alle in der Serie vorgestellten Malware-Samples stammen aus echten Angriffen und wurden unter anderem mit den hier vorgestellten Methoden entlarvt. Die Geschichten "drumherum" wurden durch reale Vorkommnisse inspiriert ;-)

In unserer Serie „Tatort Internet“ untersuchen Experten verdächtige Dateien nach allen Regeln der Kunst. Schauen Sie Ihnen dabei über die Schulter, wie sie den echten Schädlingen auf die Schliche kommen – denn das Ganze hätte sich genau so abspielen können.

Der Experte dieser Folge, Frank Boldewin arbeitet als IT-Security-Architekt bei der GAD eG in Münster. In seiner spärlichen Freizeit beschäftigt er sich mit Analysen neuer Rootkit- und Trojaner-Technologien und veröffentlicht Tools und Whitepapers zu diesen Themen auf seiner Seite reconstructer.org. Dort hat er auch die im Artikel vorgestellte Suite zum Untersuchen von Office-Dateien veröffentlicht, die im Übrigen tatsächlich so ähnlich wie im Artikel entstanden ist. Die nächste Folge von Tatort Internet beschäftigt sich mit einer PDF-Datei mit Zeitbombe.

Übersicht aller Folgen:

1. Alarm beim Pizzadienst
2. Zeig mir das Bild vom Tod
3. PDF mit Zeitbombe
4. Angriff der Killervideos
5. Matrjoschka in Flash

(ju)