Browser- und Anwendungsforensik - IT

Transcription

Browser- und Anwendungsforensik
Autoren:
Prof. Dr.-Ing. Felix C. Freiling
Dr.-Ing. Andreas Dewald
Friedrich-Alexander-Universität Erlangen-Nürnberg
Modul 16
Browser- und Anwendungsforensik
Studienbrief 1: Einführung in die Browser- und Anwendungsforensik
Autoren:
Prof. Dr.-Ing. Felix C. Freiling
Dr.-Ing. Andreas Dewald
2. Auflage
Friedrich-Alexander-Universität Erlangen-Nürnberg
© 2015 Friedrich-Alexander-Universität Erlangen-Nürnberg
Department Informatik
Martensstr. 3
91058 Erlangen
2. Auflage (27.10.2014)
Didaktische und redaktionelle Bearbeitung:
Romy Rahnfeld
Das Werk einschließlich seiner Teile ist urheberrechtlich geschützt. Jede Verwendung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne
Zustimmung der Verfasser unzulässig und strafbar. Das gilt insbesondere
für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen.
Um die Lesbarkeit zu vereinfachen, wird auf die zusätzliche Formulierung
der weiblichen Form bei Personenbezeichnungen verzichtet. Wir weisen deshalb darauf hin, dass die Verwendung der männlichen Form explizit als
geschlechtsunabhängig verstanden werden soll.
Das diesem Bericht zugrundeliegende Vorhaben wurde mit Mitteln des Bundesministeriums für Bildung, und Forschung unter dem Förderkennzeichen
160H11068 gefördert. Die Verantwortung für den Inhalt dieser Veröffentlichung liegt beim Autor.
Inhaltsverzeichnis
Seite 3
Inhaltsverzeichnis
Einleitung zu den Studienbriefen
I.
Abkürzungen der Randsymbole und Farbkodierungen . . . . . . . . .
II.
Zu den Autoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
III.
Modullehrziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
Studienbrief 1 Einführung in die Browser- und Anwendungsforensik
1.1 Lehrziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Advanced Organizer . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.1 Beispiel 1: Tötung durch Unterlassen . . . . . . . . . . . . . .
1.3.2 Beispiel 2: Die globale Spam-Industrie . . . . . . . . . . . . .
1.3.3 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4 Browser- und Anwendungsforensik(BRAP) . . . . . . . . . . . . . . .
1.4.1 Browserforensik . . . . . . . . . . . . . . . . . . . . . . . . .
1.4.2 Anwendungsforensik . . . . . . . . . . . . . . . . . . . . . .
1.4.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . .
1.5 Mobilfunkforensik . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.1 Zugriff auf Smartphones und Mobiltelefone . . . . . . . . . .
1.5.2 Smartphones: Überblick über die Systeme . . . . . . . . . . .
1.5.3 Root-Zugriff und Datenanalyse bei Android . . . . . . . . . .
1.5.4 Android-Forensik mit ADEL . . . . . . . . . . . . . . . . . . .
1.6 Verschleierungstechniken . . . . . . . . . . . . . . . . . . . . . . . .
1.6.1 Reverse Engineering . . . . . . . . . . . . . . . . . . . . . . .
1.6.2 Verschleierungstechniken zum Anti Reverse Engineering . . .
7
Verzeichnisse
I.
Abbildungen . .
II.
Beispiele . . . .
III.
Definitionen . . .
IV.
Kontrollaufgaben
V.
Tabellen . . . . .
VI.
Literatur . . . . .
4
5
6
7
7
7
7
8
13
14
14
18
22
23
24
26
28
29
30
30
31
34
51
53
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
53
53
54
54
54
54
Seite 4
I. Abkürzungen der Randsymbole und Farbkodierungen
Beispiel
B
Definition
D
Kontrollaufgabe
K
Quelltext
Q
Zu den Autoren
Seite 5
II. Zu den Autoren
Felix Freiling ist seit Dezember 2010 Inhaber des Lehrstuhls für ITSicherheitsinfrastrukturen an der Friedrich-Alexander-Universität ErlangenNürnberg. Zuvor war er bereits als Professor für Informatik an der RWTH Aachen
(2003-2005) und der Universität Mannheim (2005-2010) tätig. Schwerpunkte
seiner Arbeitsgruppe in Forschung und Lehre sind offensive Methoden der
IT-Sicherheit, technische Aspekte der Cyberkriminalität sowie digitale Forensik.
In den Verfahren zur Online-Durchsuchung und zur Vorratsdatenspeicherung
vor dem Bundesverfassungsgericht diente Felix Freiling als sachverständige
Auskunftsperson.
Andreas Dewald studierte Informatik an der Universität Mannheim. Für seine
Diplomarbeit “Detection and Prevention of Malicious Websites” erhielt er 2010 den
Studienpreis der Gesellschaft für Datenschutz und Datensicherheit. Er promovierte
2012 unter der Betreuung von Felix Freiling an der Friedrich-Alexander-Universität
Erlangen-Nürnberg mit einer Dissertation über “Formalisierung digitaler Spuren
und ihre Einbettung in die Forensische Informatik”. Er ist wissenschaftlicher Mitarbeiter am Lehrstuhl 1 für Informatik der Friedrich-Alexander-Universität und
Autor der Bücher “Client-Honeypots: Exploring Malicious Websites” und “Forensische Informatik”.
Seite 6
III. Modullehrziele
Was wird Ihnen in diesem Modul vermittelt?
Ein Großteil der Systeminteraktion erfolgt heute durch Anwendungsprogramme wie Browser, E-Mail-Clients,
oder Office-Software. Die Spuren, die dadurch auf der Festplatte oder im Speicher entstehen, sind für eine
Ermittlung in der Regel hochgradig relevant. Die Spuren können aber nur mit einem tiefen Verständnis der
Anwendung selbst sicher interpretiert werden. Diese Lehrveranstaltung gibt einen Überblick über Techniken
und Werkzeuge für die Analyse von Anwendungsprogrammen.
Themen der drei Studienbriefe.
Die Inhalte des Moduls sind in drei Studienbriefe gegliedert. Der erste Studienbrief soll Ihnen einen Überblick
geben über verschiedene bekannte Erscheinungsformen von Anwendungsspuren, etwa von Browsern oder
im Bereich der Mobilfunkforensik. Der zweite Studienbrief gibt Ihnen einen Einblick in die Aussagekraft von
Multimediaspuren, also von Digitalkameras, eine zunehmend wichtigere Klasse von Anwendungsspuren.
Der dritte Studienbrief schließlich stellt eine umfassende Theorie über die Aussagekraft digitaler Spuren vor.
Neben der Einführung einer gemeinsamen Terminologie dient dieser Studienbrief auch dazu, grundsätzliche
Zusammenhänge zwischen Spuren und ihrer Bedeutung darzulegen.
Was können Sie nach erfolgreichem Abschluss dieses Studienbriefs?
Die Veranstaltung vermittelt grundlegende Kenntnisse und Kompetenzen in der Analyse von Spuren,
die durch Anwendungsprogramme wie Browser oder E-Mail-Clients entstehen. Nach Abschluss dieses
Moduls haben Sie einen Überblick über verschiedene Erscheinungsformen von Anwendungsspuren und
können für einfache Fälle angeben, welche Anwendungsspuren für die Ermittlung jeweils relevant sein
könnten. Sie besitzen zudem einen Überblick über die Methoden der Multimediaforensik und können für
konkrete Ermittlungen angeben, welche Multimediaspuren für Ermittlungsfragen von Interesse sein können.
Schließlich können Sie auch Aussagen darüber machen, unter welchen Voraussetzungen aufgefundene
Spuren tatsächlich das aussagen, was man ihnen nach herrschender Meinung zusagt. Im Rahmen der
praktischen Übung lernen Sie, die Spuren zu benennen, die eine konkrete Anwendung erzeugt.
Studienbrief 1 Einführung in die Browser- und
Anwendungsforensik
1.1 Lehrziele
In diesem Studienbrief erhalten Sie zunächst einen Überblick über das Gebiet
der Browser- und Anwendungsforensik sowie eine Motivation der Relevanz des
Themas. Weiterhin wird Ihnen ein kurzer Einblick in die verwandten Bereiche der
Mobilfunkforensik und der generellen Verschleierungstechniken (Obfuscation)
gegeben.
1.2 Advanced Organizer
Dieses Modul setzt Kenntnisse der Module “Datenträgerforensik” (M12) und “LiveAnalyse” (M13) sowie “Grundlagen digitaler Forensik” (M10) voraus. Während
sich Datenträgerforensik mit den Spuren beschäftigt, die durch die Dateisysteme
entstehen, betrachten wir in diesem Modul einerseits typische Kombinationen von
Dateisystemmetadaten sowie Inhalte von Dateien als Spuren. Hier geht es also
grundlegend um die Analyse und Interpretation der durch Festplattenforensik
oder Live-Analyse sichergestellten Daten. Dies geschieht im Kontext bekannter
oder auch unbekannter Anwendungsprogramme.
Bei den Inhalten zu Verschleierungstechniken gibt es leichte Überschneidungen
mit dem Modul “Reverse Engineering” (M15).
Danksagungen
Die Autoren bedanken sich bei den Studierenden des ersten Durchgangs dieses
Moduls im “Master Online Digitale Forensik”, insbesondere Felix Ramisch, Martin
Rojak, Sven Borchert, Torben Griebe und Daniel Keller, für hilfreiche Hinweise und
Verbesserungsvorschläge zum Text der ersten Auflage. Wir bedanken uns weiterhin
bei Michael Spreitzenbarth und Tilo Müller für Vorarbeiten zu den Abschnitten
1.5 und 1.6.
1.3 Einführung
Ein Großteil der Systeminteraktion erfolgt heute durch Anwendungsprogramme
wie Browser, E-Mail-Clients, oder Office-Software. Die Spuren, die dadurch auf
der Festplatte oder im Speicher entstehen, sind für eine Ermittlung in der Regel
hochgradig relevant. Die Spuren können aber nur mit einem tiefen Verständnis
der Anwendung selbst sicher interpretiert werden. Dieser Studienbrief gibt einen
Überblick über die verschiedenen, im Bereich der Browser- und Anwendungsforensik anzusiedelnden Themengebiete. Spezielle Bereiche dieser Thematik werden
in den folgenden Studienbriefen vertieft.
Um das Thema dieses Moduls zu motivieren, wollen wir anfangs zwei Beispiele
für die Notwendigkeit der in diesem Modul vorgestellten Techniken geben.
1.3.1 Beispiel 1: Tötung durch Unterlassen
Das erste Beispiel für die Wichtigkeit der in diesem Modul behandelten Techniken
ist ein Gerichtsfall aus dem Jahr 2009 in Trier [Wientjes, 2011]. Die Anklage lautete
hier auf Tötung durch Unterlassen.
Seite 7
Seite 8
Angeklagt war ein junger Mann, der Experte für ein bestimmtes Betäubungsmittel
war, das er selbst sporadisch und sehr fein dosiert konsumiert. Seine Ex-Freundin
nahm eine größere Menge des Mittels ein, wofür es Zeugen gab. Der Angeklagte
erkannte die Überdosis, brachte die junge Frau zum Erbrechen und danach in die
stabile Seitenlage. Nachdem er einige Stunden mit ihr allein im Zimmer einer WG
war, verließ er das Haus. Eine Mitbewohnerin fand die Frau später nur noch leblos
vor. Den Ermittlern stellte sich nun die Frage, was sich in diesen Stunden in dem
Zimmer zugetragen hat.
Der Angeklagte sagte aus, dass die junge Frau sich selbst umbringen wollte. In dem
Prozess musste nun geklärt werden, ob der Angeklagte den Todeskampf bemerkte
und warum er nichts unternahm.
Der entscheidende Hinweis kam von einem Informatiker, der den Computer untersucht hatte, der in dem WG-Zimmer des Opfers stand. Er konnte nachweisen, dass
in den Stunden des Todeskampfes nach den Begriffen „GBL Überdosis“, „blaue
Pupillen“, „starre Pupillen“ und „Totenstarre“ gesucht wurde. Dies waren Anwendungsspuren, die ein Browser-Plugin auf der Festplatte abgelegt hatte. Ein
medizinischer Gutachter bestätigte, dass sich der Zeitverlauf der Eingabe deckte
mit dem zu erwartenden Verlauf des Todeseintritts. Das Gericht kam daraufhin
zu der Überzeugung, dass der Angeklagte den Todeskampf in vollem Bewusstsein beigewohnt und nichts unternommen hatte. Er wurde zu 7 Jahren Gefängnis
verurteilt.
1.3.2 Beispiel 2: Die globale Spam-Industrie
Unter Spam versteht man Massen-E-Mails, die unaufgefordert zugestellt werden
und mit Werbung oder bösartiger Software verbunden sind. Trotz Antipathie
und einer Multi-Million Dollar Antispam Industrie existiert Spam weiterhin. Täglich werden die Posteingänge mit Milliarden von unerwünschten Nachrichten
überflutet [Levchenko et al., 2011].
Jeder, der einen Email-Account besitzt, hat schon einmal eine Spam-Mail mit einem
Betreff à la „Excellent hardness is easy!“ bekommen, doch (angeblich) niemand
hat schon einmal auf ein solches Angebot reagiert [Kanich et al., 2008]. Das führt
uns zu der Frage, warum es dann immer noch Spam gibt.
Um das Phänomen Spam durchgreifend bekämpfen zu können, muss man es ganzheitlich behandeln und sich auch mit dem Aufbau der globalen Spam-Industrie
auseinandersetzen. Hierzu kommen Methoden der Live-Analyse und der Anwendungsforensik zum Einsatz. Die Emails und deren Versendung sind nämlich nur
der offensichtliche Teil des Spams. Im Hintergrund verbirgt sich eine komplexe
Verknüpfung von sowohl technischen als auch wirtschaftlichen Komponenten, die
aus dem Besuch der (Spam-)Website finanziellen Nutzen ziehen. Diese Wertschöpfungskette besteht aus dem Versenden von Spam i. d. R. durch ein Botnetz, der
Registrierung von Domains, dem Hosten von Webserver und ggf. Proxys und der
Bezahlung sowie Herstellung der Produkte.
Im Folgenden gehen wir auf die Strukturen der Spam-Industrie ein, wie sie in den
Artikeln von Levchenko et al. [2011] und Kanich et al. [2008] beschrieben werden.
1.3.2.1 Die Spam-Industrie
Die Spam-Industrie ist aufgeteilt in mehrere Bereiche. Die Produkt-Anbieter arbeiten mit ihren Vertriebspartnern — Spam-Botnetze, Bezahlungsdienste, Banken usw.
— zusammen und beteiligen diese an den Gewinnen. Dabei findet alles online statt
1.3 Einführung
Seite 9
– dank der erfolgreichen Verbreitung von internetbasierten Vertriebsprogrammen
wie pay-per-click, pay-per-lead, pay-per-sale usw.
Abb. 1.1: Grum-Botnetz
Wertschöpfungskette
[Levchenko et al., 2011,
Fig. 1]
Um die Arbeitsweise eines Spam-Netzwerks zu illustrieren, geben wir ein Beispiel für den Ablauf eines „Spam-Geschäfts“, wie es weltweit tausendfach täglich
passiert. Die Zusammenhänge sind nochmals in Abbildung 1.1 dargestellt:
1. Über ein Botnetz (hier das Grum-Botnetz) wird eine Spam-Nachricht verschickt. Die Nachricht enthält ein mit URL unterlegtes Bild für verschreibungspflichtige Medikamente inklusive einer Preisliste.
2. Ein Klick auf das Bild sorgt für eine DNS-Auflösungsanfrage nach
medicshopnerx.ru.
3. Die Domain wurde bei reg.ru am 18.10. registriert. Der Nameserver steht
in China.
4. Die DNS-Auflösung ergibt einen Rechner in Brasilien.
5. Der Browser sendet eine http-Anfrage und liefert die Webseite von Pharmacy
Express. Pharmacy Express ist eine Marke, die mit einem Vertriebsprogramm
in Russland assoziiert ist. Der Rechner in Brasilien ist möglicherweise nur
ein Proxy.
6. Der Einkauf auf der Webseite führt zur Zahlungsaufforderung per Kreditkarte auf der Webseite payquickonline.com. Die IP-Adresse stammt aus
der Türkei, der Betrag wandert jedoch zur Azerigazbank in Baku, Aserbaidschan.
7. 10 Tage später trifft das Produkt per Post ein. Die Absenderadresse liegt in
Indien.
Dieses Beispiel verdeutlicht die Arbeitsteilung: Botnetz, Proxy, Pharmacy ExpressWebseite, (Online-)Bezahlungsdienst, Bank, Pharma Unternehmen und Absender
arbeiten zusammen. Das Botnetz verschickt den Spam massenhaft, in dem ein Link
zu dem Proxy eingebaut ist. Durch diese Indirektion wird der eigentliche Server
der Pharmacy Express Webseite verschleiert. Die Bezahlung wickelt eine weitere
Stelle ab, die mit einer Bank zusammenarbeitet. Zum Schluss wird das Produkt
von einem Hersteller angefertigt und verschickt.
Diese Aufteilung ist zum Teil nötig, da die einzelnen Beteiligten eine spezielle
Aufgabe übernehmen (ein Botnetz-Betreiber kann höchstwahrscheinlich keine
Pharmazeutika herstellen). Zum anderen dient dies natürlich der Verschleierung.
Proxy, Webseite und Bezahlungsdienst könnten zusammengefasst werden, doch
wäre dann die Quelle viel leichter zu identifizieren und lokalisieren.
Seite 10
Abb. 1.2: Ablauf der
Spam-Analyse [Levchenko et al., 2011, Fig. 2]
1.3.2.2 Analyse
Um an die oben genannten Informationen über die Spam-Industrie zu gelangen,
haben die Autoren auf mehreren Ebenen Daten gesammelt (siehe Abbildung 1.2).
Die Techniken, die dabei angewendet wurden, stammten aus dem Bereich der
Live-Analyse und dem Bereich der Anwendungsanalyse.
Im Folgenden betrachten wir nun die einzelnen Ebenen im Detail, beginnend mit
der Sammlung von Daten bzw. Spam:
1. Ausgangspunkt waren Spam-, URL-Feeds und ein „eigenes“ Botnetz zur
Spam-Sammlung.
1.3 Einführung
Seite 11
2. Diese Eingaben wurden verarbeitet und dabei die eingebundenen URLs
extrahiert. Dies geschah mittels automatischen Parsern, die die HTMLNachrichten nach entsprechenden Marken (Tags) durchsuchten.
3. Neben einem DNS Crawler kamen mehrere Web Crawler zum Einsatz, die
die vorher extrahierten Seiten besuchten und HTTP-Interaktionen sowie die
endgültige Webseite dokumentierten.
4. Die Webseiten wurden nach deren Inhalt sortiert, indem bestimmte Muster
wie beispielsweise Logos und spezifische Begriffe im HTML-Text ausgenutzt
wurden.
5. Danach konnten den Links eine bestimmte Kategorie, je nach Art der angebotenen Produkte, zugewiesen werden. Diese Einteilungen wurden stichprobenartig überprüft.
6. Zum Schluss wurden gezielt Produkte gekauft und die Daten für die weitere
Auswertung in eine Datenbank aufgenommen.
Insgesamt stellten Levchenko et al. [2011] fast eine Milliarde URLs aus 12 Quellen,
darunter fünf Botnetzen, sicher und speicherten sie in einer Datenbank. Von der
Milliarde an URLs wurden 15 Millionen mit den Web Crawlern besucht, Weiterleitungen, DNS-Namen, HTTP-Header von jedem zwischengeschalteten Server,
sowie den endgültigen Server dokumentiert. Außerdem wurde die letzte Seite
als DOM und als Screenshot gespeichert. Um diese Masse an Webseitenaufrufen
durchzuführen, verwaltete jeder Crawler dabei 100 Firefox-Instanzen.
Da in den Daten sehr viel Redundanz enthalten ist, sind die Ergebnisse laut Levchenko et al. [2011] durchaus repräsentativ. Es wurden über 98% der URLs abgedeckt, obwohl nur 20% der 18 Millionen unterschiedlich registrierten Domains
durchsucht wurden. Allerdings beschränkten sie sich dabei auf drei Kategorien
von Produkten, da diese unter den Top 5 Produkten liegen, die durch die SpamIndustrie vermarktet werden:
1. Pharmazeutika,
2. gefälschte Produkte (Replicas) und
3. raubkopierte Software.
Die zwei zu den Top 5 fehlenden Kategorien sind Pornografie und Glücksspiele.
Stage
URLs
Domains
Web clusters
Programs
Pharmacy
Software
Replicas
Total
346,993,046
54,220
968
30
3,071,828
7,252
51
5
15,330,404
7,530
20
10
365,395,278
69,002
1,039
45
Mittelscontent clustering, also der Einteilung in mehrere Kategorien nach bestimmten Kriterien, wie beispielsweise spezielle Schlagwörter im HTML-Text, wurden
Seiten mit ähnlichem Inhalt zusammengefasst. Diese konnten dann nach Vertriebsprogrammen und Erscheinungsbild gegliedert werden (siehe Abbildung 1.3). Die
Abbildung zeigt die drei oben genannten Kategorien Pharmazeutika, Fälschungen und Software jeweils mit der Anzahl an URLs und den dahinter steckenden
Webseiten. Daraus geht hervor, dass Pharmazeutika deutlich vor Fälschungen und
Software liegen.
Die Vertriebsprogramme wurden ebenfalls eingeteilt und deren Marktanteil bzw.
deren Spam-Volumen gemessen. Abbildung 1.4 listet die Programme mit der
Anzahl ihrer Domains und URLs sowie deren Spam-Anteil. Die Statistik zeigt
Abb. 1.3: Aufteilung der
Spam-Produkte [Levchenko et al., 2011, Tab. III]
content clustering
Seite 12
sink feeds
Abb. 1.4: Kategorisierung nach Vertriebsprogrammen [Levchenko
et al., 2011, Tab. IV]
jedoch nur Spam aussink feeds, d. h. Botnetz-Quellen wurden herausgelassen, um
normale E-Mail-Konten besser zu repräsentieren. Für die Zuordnung wurden
manuelle Filter erstellt, die die Webseiteninhalte der Programme abbilden.
Affiliate
Program
Distinct
Domains
Received
URLs
Feed
Volume
RxPrm
Mailn
PhEx
EDEx
ZCashPh
DrMax
Grow
USHC
MaxGm
VgREX
Stud
ManXt
GlvMd
OLPh
Eva
WldPh
PHOL
Aptke
HrbGr
RxPnr
Stmul
Maxx
DrgRev
UltPh
Green
Vrlty
RxRev
Medi
ClFr
CanPh
RxCsh
Staln
RX–Promotion
Mailien
Pharmacy Express
ED Express
ZedCash (Pharma)
Dr. Maxman
Viagrow
US HealthCare
MaxGentleman
VigREX
Stud Extreme
ManXtenz
GlavMed
Online Pharmacy
EvaPharmacy
World Pharmacy
PH Online
Swiss Apotheke
HerbalGrowth
RX Partners
Stimul-cash
MAXX Extend
DrugRevenue
Ultimate Pharmacy
Greenline
Virility
RX Rev Share
MediTrust
Club-first
Canadian Pharmacy
RXCash
Stallion
Total
10,585
14,444
14,381
63
6,976
5,641
382
167
672
39
42
33
2,933
2,894
11,281
691
101
117
17
449
50
23
122
12
1,766
9
299
24
1,270
133
22
2
54,220
160,521,810
69,961,207
69,959,629
1,578
42,282,943
32,184,860
5,210,668
3,196,538
1,144,703
426,873
68,907
50,394
28,313,136
17,226,271
12,795,646
10,412,850
2,971,368
1,586,456
265,131
229,257
157,537
104,201
51,637
44,126
25,021
23,528
9,696
6,156
3,310
1,392
287
80
346,993,046
24.92%
23.49%
23.48%
0.01%
14.54%
10.95%
1.68%
1.31%
0.41%
0.14%
0.03%
0.02%
10.32%
5.16%
8.7%
3.55%
0.96%
0.55%
0.09%
0.21%
0.07%
0.04%
0.04%
0.02%
0.36%
0.01%
0.04%
0.01%
0.07%
0.03%
< 0.01%
< 0.01%
93.18%
Royal
EuSft
ASR
OEM
SftSl
Royal Software
EuroSoft
Auth. Soft. Resellers
OEM Soft Store
Soft Sales
Total
572
1,161
4,117
1,367
35
7,252
2,291,571
694,810
65,918
19,436
93
3,071,828
0.79%
0.48%
0.61%
0.24%
< 0.01%
2.12%
ZCashR
UltRp
Dstn
Exqst
DmdRp
Prge
OneRp
Luxry
AffAc
SwsRp
WchSh
ZedCash (Replica)
Ultimate Replica
Distinction Replica
Exquisite Replicas
Diamond Replicas
Prestige Replicas
One Replica
Luxury Replica
Aff. Accessories
Swiss Rep. & Co.
WatchShop
Total
6,984
5,017
127
128
1,307
101
77
25
187
15
546
7,530
13,243,513
10,451,198
1,249,886
620,642
506,486
382,964
20,313
8,279
3,669
76
2,086,891
15,330,404
4.56%
3.55%
0.37%
0.22%
0.27%
0.1%
0.02%
0.01%
0.02%
< 0.01%
0.17%
4.73%
69,002
365,395,278
100%
Gr and Total
Interessant ist die Verteilung der Spam-Infrastruktur: Viele Konzern-Netzwerke arbeiten mit wenig Banken zusammen (siehe Abbildung 1.5, gegliedert nach Banken
mit deren Landessitz und zugehörigen Spam-Programmen).
1.3.2.3 Gegenmaßnahmen
Als technische Gegenmaßnahme könnte man auf die einschlägigen Registrare
einwirken und sie motivieren, nicht mit den Vertriebsprogrammen zusammenzuarbeiten, bzw. man könnte die einschlägigen Autonomen Systeme kontaktieren,
1.3 Einführung
Seite 13
Bank Name
BIN
Country
Affiliate Programs
Azerigazbank
B&N
B&S Card Service
Borgun Hf
Canadian Imperial Bank of Commerce
Cartu Bank
DnB Nord (Pirma)
Latvia Savings
Latvijas Pasta Banka
St. Kitts & Nevis Anguilla National Bank
State Bank of Mauritius
Visa Iceland
Wells Fargo
Wirecard AG
404610
425175
490763
423262
452551
478765
492175
490849
489431
427852
474140
450744
449215
424500
Azerbaijan
Russia
Germany
Iceland
Canada
Georgia
Latvia
Latvia
Latvia
St. Kitts & Nevis
Mauritius
Iceland
USA
Germany
GlvMd, RxPrm, PhEx, Stmul, RxPnr, WldPh
ASR
MaxGm
Trust
WldPh
DrgRev
Eva, OLPh, USHC
EuSft, OEM, WchSh, Royal, SftSl
SftSl
DmdRp, VgREX, Dstn, Luxry, SwsRp, OneRp
DrgRev
Staln
Green
ClFr
Abb. 1.5: Verteilung von
Vertriebsprogrammen
auf Banken [Levchenko
et al., 2011, Tab. V]
Abb. 1.6: Folgen der Abschaltung bestimmter
Elemente der SpamIndustrie [Levchenko
et al., 2011, Fig. 5]
damit sie die relevanten Hosts vom Netz nehmen. Abbildung 1.6 (links und mitte)
zeigt die Auswirkungen eines solchen Vorgehens in Bezug auf die Menge von Spam,
die dadurch beeinflusst wird. Die Beeinflussung von 5 Registraren allein würde
somit theoretisch eine Reduktion des Spam-Aufkommens von 60% bewirken.
Spam-Reduktion durch Abschalten der Registrare oder DNS und Web Hoster ist
wesentlich ineffizienter als durch „Ausschalten“ der Banken. Für eine effiziente,
langfristige Bekämpfung von Spam könnte man versuchen, die Banken überzeugen,
nicht mehr mit den Spam-Anbietern zusammenzuarbeiten. Ein Abkoppeln einer
einzigen Bank vom Kreditkartengeschäft, nämlich der Azerigazbank, würde schon
60% des Spams betreffen. Der Erfolg wäre jedoch nur mittelfristig von Bedeutung,
da sich die Spam-Industrie neue Banken suchen würde. Trotzdem wäre dies mit
einiger Zeit und einigen Kosten für die Spam-Industrie verbunden.
Problematisch bei diesem Vorgehen ist jedoch, dass in einigen Ländern der Verkauf
der durch Spam beworbenen Produkte nicht komplett illegal ist und dort ansässige
Banken bevorzugt von der Spam-Industrie genutzt werden. Würden westliche
Banken bestimmte Transaktionen nicht vornehmen, wären die Auswirkungen
für die Spam-Konzerne durchaus spürbar. Für einige der Top Spam-Produkte
(chemische Medikamente, Fälschungen und illegale Software) gäbe es sogar legale
Umsetzungen für einen solchen erzwungenen Grundsatz. Nichtsdestotrotz wären
die politischen Auswirkungen eines solchen Eingriffs problematisch.
1.3.3 Ausblick
Im Rahmen dieses Studienbriefs geben wir zunächst eine allgemeine Einführung
in den Bereich der Browser- und Anwendungsforensik. Anschließend betrachten
wir beispielhaft die Rahmenbedingungen der Mobilfunkforensik, eines wichtigen
Teilbereichs der Anwendungsforensik. Abschließend geben wir eine kurze Einführung in Verschleierungstechniken, die die Analyse proprietärer Datenformate und
Software erschweren sollen.
Seite 14
1.4 Browser- und Anwendungsforensik(BRAP)
Browser- und Anwendungsforensik (engl. Browser and Application Forensics) ist ein
Teilgebiet des Computer Activity Mining (CAM), bei dem Aktionen des Computers
durch Spuren auf diesem Computer selbst nachvollzogen werden [Berghel, 2008].
Bei Ermittlungen werden häufig Computer bzw. Festplatten oder FestplattenImages konfisziert, die danach untersucht werden müssen. Während klassische
Dateisystemforensik auf die Wiederherstellung und Sicherung von gelöschten
oder versteckten Daten abzielt, nutzt CAM eher das Verhalten oder Vorgehen des
Nutzers aus. Dies geschieht häufig auf der Basis von lokalen Logdateien. BRAP
verbindet beides durch die Analyse der Programme, sogenanntes Application Footbzw. Fingerprinting. D. h. es werden bestimmte möglichst eindeutige Merkmale der
Programme betrachtet und diese Merkmale dazu genutzt, Spuren dieser Programme später wiederzuerkennen. Dies ist auch teilweise aus dem Internet möglich, z.
B. bei Browsern. Wichtig sind also die Spuren, die eine Anwendung hinterlässt
und welche Bedeutung diese haben und welche Informationen darin enthalten
sind (siehe auch Studienbrief 3 dieses Moduls).
BRAP-Forensik baut eher auf technisch unvermeidbaren Spuren auf, d. h. Spuren, die ohne direkte Einflussmöglichkeit des Benutzers von der Anwendung
hinterlassen werden (siehe Modul 10, Grundlagen digitaler Forensik). Diese Spuren sind typischerweise schwerer gänzlich zu vermeiden und meist schwer zu
manipulieren.
Gerade auch vor Gericht spielt CAM eine wichtige Rolle bei der elektronischen
Auswertung. Sehr häufig wird mittels CAM nach Spuren und Beweisen für Straftaten gesucht. Dies wird vor allem bei Fällen angewendet, die Computerbetrug
oder -sabotage, sexuelle Belästigung, Kinderpornografie, EULA-Lizenzverstöße
oder Identitätsdiebstahl beinhalten.
Durch die große Verbreitung des Internets, egal ob Smartphone, Laptop, PC oder
sogar Navigationsgeräte und Entertainment-Systeme im Auto, spielt BrowserForensik bei vielen Untersuchungen eine Rolle und kann den entscheidenden
Ausschlag geben, wie die Beispiele von oben gezeigt haben.
Wir gehen im Folgenden zunächst auf die klassische Browserforensik ein, also die
Analyse von Spuren in/von Web-Browsern. Im Anschluss folgt ein Überblick über
Themen in der Anwendungsforensik. Beide Abschnitte sollen schlaglichtartig in
das Thema einführen.
1.4.1 Browserforensik
Der Besuch einer Webseite hinterlässt Spuren in der Browser History und im Browser Cache. Es erfolgen Einträge von Cookies, Veränderungen von Zeitstempeln und
den Logdateien des Webservers. Außerdem werden Caches im Netz (HTTP, DNS)
verändert. Da HTTP zustandslos ist, verwenden fast alle kommerziellen Seiten
Cookies, deren Inhalt mit Parsertools angezeigt werden kann (siehe Abbildung 1.7).
Interessant ist bei den Cookies, dass sie teilweise für 10 Jahre gültig sind. Beim Besuch der Website www.microsoft.com werden beispielsweise sieben Cookies von
webtrends.com, atdmt.com, indextools.com und dcstest.wtlice.com angelegt
[Berghel, 2008]. Auch der Browser-Cache kann mit entsprechenden Tools geparst
werden. Im Firefox geht es sogar noch einfacher durch Eingabe von about:cache in
der Browserzeile. Im Internet Explorer können diese Informationen nur von Hand
gelöscht werden, während in Firefox das Löschen flexibler ist (z. B. bis Anwendung
geschlossen wird).
Seite 15
Figure1a. ExampleWebTrends cookie.
leAbb. 1.7: Beispiele von
tigespeicherten Cookies
b[Berghel, 2008]
ri
p
H
(I
B
re
a
sh
co
p
IE
cl
d
B
Seit kurzem gibt es den sogenanntenprivate browsing-Modus in allen gängigen
Browsern, der es dem Benutzer ermöglichen soll unerkannt zu surfen. Dieser
Modus soll vor allem verhindern, dass ein lokaler Angreifer im Browserverlauf
nachvollziehen kann, was der Benutzer gemacht hat. Zu diesem Zweck wird die
Ablage von Daten auf dem Computer nach Möglichkeit vermieden. Beispielsweise
werden kein Verlauf oder keine Cookies mehr gespeichert. Zudem soll ein Angreifer im Netz keine private und public sessions sowie private sessions untereinander
verknüpfen können. D. h. es soll nicht möglich sein, einen Computer im öffentlichen Modus zu identifizieren und ihn im privaten Modus verfolgen zu können.
Weiterhin soll ein Browser im privaten Modus nicht über Neustarts hinweg identifizierbar sein. Außerdem soll ein Webserver nicht herausfinden können, ob private
browsing überhaupt eingeschaltet ist.
Eine Studie von Aggarwal et al. [2010] untersucht den privaten Modus in den vier
gängigsten Browsern Firefox, Safari, Chrome und dem Internet Explorer. Wir gehen
im Folgenden auf die Ergebnisse dieser Studie näher ein, da sie die Möglichkeiten
und Grenzen der Browserforensik deutlich vor Augen führt.
In Abbildung 1.8 geht es um den Wechsel vom public Modus in den privaten
Modus. Die Blockierung des Zugriffs soll die Verbindung von private sessions mit
früheren public sessions vermeiden. Safari ignoriert hier das Szenario „Angreifer
im Netz“ und gibt den Zugriff auf History, Cookies und HTML5 lokale Daten
frei, im Gegensatz zu den anderen Browsern. Alle Browser erlauben jedoch die
Verwendung von SSL Zertifikaten, was inkonsistent mit der Verwendung von
Cookies ist.
Kritisch ist auch das Ausschalten des privaten Modus, also der Wechsel von private
zurück zu public (s. Abbildung 1.9). Dabei sollen möglichst wenige Daten aus der
privaten Session übrig bleiben, um einem lokalen Angreifer nicht zu ermöglichen
auf diese Session Rückschlüsse ziehen zu können. Bookmarks und Downloads
bleiben hier bei allen Browsern erhalten, der Benutzerfreundlichkeit halber. Allerdings lässt sich daraus, bei einer hinreichenden Anzahl an neuen Bookmarks und
Downloads, ohne Probleme der Browserverlauf nachvollziehen.
Innerhalb einer private session sollen möglichst wenig persistente Spuren auf der
Festplatte hinterlassen werden. Inkonsistent ist hier bei allen Browsern der Verlauf.
private browsing
Seite 16
Abb. 1.8: Ist ein Zustand
aus früheren public Modi im privaten Modus
erreichbar? [Aggarwal
et al., 2010, Tab. 1]
Web Cache
Swap-File
History
Cookies
HTML5 local storage
Bookmarks
Password database
Formautocompletion
User approved SSL self-signed cert
Downloaded items list
Downloaded items
Search box search terms
Browser’s web cache
Client certs
Customprotocol handlers
Per-sitezoomlevel
FF
no
no
no
yes
yes
yes
yes
no
yes
yes
no
yes
yes
no
Safari
yes
yes
yes
yes
yes
yes
yes
yes
yes
yes
no
yes
n/a
n/a
Chrome
no
no
no
yes
yes
yes
yes
yes
yes
yes
no
yes
n/a
yes
IE
no
no
no
yes
yes
no
yes
n/a
yes
yes
no
yes
n/a
n/a
Während die History nicht gespeichert wird, bleibt derWeb Cache des Browsers
erhalten. Zwar speichert Firefox Cookies und den Web Cache nur temporär im
Hauptspeicher, doch können diese Daten bei hoher Hauptspeicherbelastung in
das sogenannteSwap-File ausgelagert und somit doch auf Festplatte gespeichert
werden.
Kontrollaufgabe 1.1
K
Überprüfen Sie eine der Erkenntnisse von Aggarwal et al. [2010] aus Abbildung 1.10 in der aktuellen Version Ihres eigenen Browsers.
Insgesamt zeigt die Studie von Aggarwal et al. also deutliche Lücken bei den Browsern auf, die vor allem zugunsten der Benutzerfreundlichkeit bestehen bleiben. Z.
B. möchte man häufig nicht, dass Downloads nach dem Beenden des Browsers
von der Festplatte verschwinden. Nichtsdestotrotz ist anhand dieser Daten ein
Zurückverfolgen des Browserverlaufs, sogar in zeitlicher Reihenfolge möglich,
wenn man auch noch Dateizeitstempel beachtet.
whitelist
Fingerprinting
Eine weitere Schwachstelle sind die Browser-Addons, die meist ohne Rücksicht
auf private browsing entwickelt wurden und trotz eingeschaltetem private browsing
Modus Daten auf dem Rechner speichern. Das Security-AddOn NoScript speichert
zum Beispiel eine Liste von Webseiten (whitelist) auf der Festplatte, für die Javascript
erlaubt ist. Diese Liste ist auch nach dem Browserneustart erreichbar. Surft ein
Nutzer im privaten Modus und schaltet eine Webseite in NoScript frei, so ist trotz
private browsing ersichtlich, dass er diese Seite besucht hat.
Weiterhin können Browser durch Fingerprinting aus dem Netz identifiziert werden,
was umso besser funktioniert, je mehr Anonymisierungsfunktionen eingeschalten
sind. Der Webserver kann viele Daten aus dem Client abfragen, bzw. bekommt
sie teilweise automatisch geschickt. Die meisten Browser senden nämlich ihren
Namen, sowie Version, Betriebssystem und Sprache bzw. Zeichensatz automatisch mit jedem HTTP-Header an die Webserver (Variable User Agent). Neben
den Cookies sind auch eindeutige Informationen per AJAX übertragbar, wie etwa
History
Cookies
HTML5 Local storage
Bookmarks
Password database
Formautocompletion
Downloaded items
Client certs
Per-sitezoomlevel
FF
no
no
no
yes
no
no
no
no
yes
no
no
yes
yes
no
Seite 17
Safari
no
no
no
yes
no
no
yes
no
yes
no
no
n/a
n/a
n/a
Chrome
no
no
no
yes
no
no
yes
no
yes
no
no
n/a
n/a
no
IE
no
no
no
yes
no
no
yes
n/a
yes
no
no
yes
n/a
n/a
Abb. 1.9: Ist ein Zustand
aus früheren privaten
Modi im public Modus
erreichbar? [Aggarwal
et al., 2010, Tab. 2]
die Zeitzone, Bildschirmauflösung, Browser Plugins mit Versionsnummer und
Systemschriftarten (siehe Abbildung 1.11). .
Eckersley [2010] hat dieses Phänomen im Rahmen des Projekts “Panopticlick”
untersucht. Dazu brachte er mehr als 400.000 Benutzer dazu, die Webseite http:
//panopticlick.eff.org zu besuchen. Von diesen Besuchern wurde der BrowserFingerprint genommen. Das Ergebnis der Untersuchung zeigt Abbildung 1.12.
Es ist ein Histogramm der gemessenen Fingerprints: Auf der x-Achse werden
die verschiedenen Fingerprints gelistet, auf der y-Achse deren Häufigkeit (die
Fingerprints sind nach abnehmender Häufigkeit sortiert). Die Größe der Menge ist
jeweils ein Maß für die Anonymität, die man als Besucher hat (Anonymitätsmenge).
Gehört man mit dem eigenen Fingerprint also in eine der häufiger auftretenden
Fälle (weiter links), so ist man innerhalb dieser großen Menge nicht von anderen
zu unterscheiden. Liegt der eigene Fingerprint weiter rechts auf der Skala, wird
die Anonymitätsmenge immer kleiner, bis sie irgendwann die Größe 1 erreicht,
mit dem Ergebnis, dass der eigene Fingerprint eindeutig ist.
Anonymitätsmenge
Interessant ist folgende Beobachtung: Je mehr Einstellungen man selbst am Browser
vorgenommen hat, also je weiter man von der „Basisversion“ abweicht, umso besser
ist man identifizierbar. In der Studie von Eckersley [2010] stellte sich heraus, dass
83,6% aller Fingerprints eindeutig sind und weitere 5,3% einer von Zweien ist.
Wenn Flash oder Java installiert ist, sind sogar 94,2% eindeutig identifizierbar. Im
Durchschnitt ist nur jeder 286.777 Browser-Fingerprint gleich, weshalb sich die
meisten Browser eindeutig identifizieren lassen. Man beachte, dass die Skalen
logarithmisch sind. Die im angesprochenen 83,6% eindeutige Fingerprints sind
der Abschnitt ganz rechts unten (y = 1, x ab etwa einem Wert von 20.000).
Kontrollaufgabe 1.2
Besuchen Sie die Seite http://panopticlick.eff.org und testen Sie die
Einzigartigkeit Ihres Browsers. Unter wievielen Browser-Fingerprints ist ihr
Browser identifizierbar?
K
Seite 18
Abb. 1.10: Ist ein Zustand an einem bestimmten Punkt einer
privaten Session später wieder erreichbar
innerhalb derselben privaten Session? [Aggarwal et al., 2010, Tab. 3]
History
Cookies
HTML5 Local storage
Bookmarks
Password database
Formautocompletion
Downloaded items
Client certs
Per-sitezoomlevel
FF
no
no
no
yes
no
no
no
no
yes
no
no
yes
yes
no
Safari
no
no
no
yes
no
no
yes
no
yes
no
no
n/a
n/a
n/a
Chrome
no
no
no
yes
no
no
yes
no
yes
no
no
n/a
n/a
no
IE
no
no
no
yes
no
no
yes
n/a
yes
no
no
yes
n/a
n/a
1.4.2 Anwendungsforensik
Browser sind als universelle Anwendungen natürlich besonders interessant. Jedoch
hinterlassen viele, wenn nicht sogar alle Anwendungen digitale Spuren. Wir gehen
im Folgenden auf ein paar Beispiele ein.
1.4.2.1 Word-Dateien
Es ist seit langem bekannt, dass Microsoft Word-Dateien „versteckte“ Daten enthalten [Byers, 2004]. Dazu zählen auch Informationen, die in Word selbst nicht
ausgelesen werden können, bis vor einiger Zeit etwa die Änderungshistorie des
Dokumentes. Weitere Beispiele für “versteckte” Daten sind der Benutzername des
Autors, Informationen über Hardware (Drucker, letzter Zeitpunkt des Druckens)
und teilweise sogar gelöschten Text. Mit Tools wie strings oder das Betrachten
der Word-Datei in einem Hex-Editor sind häufig schon einige Daten auslesbar.
Für die weitere Analyse kommt man nicht umhin, das MS Word-Format selbst zu
analysieren.
K
Kontrollaufgabe 1.3
In manchen Versionen von Microsoft Word kann bei der richtigen Wahl der
Einstellungen folgendes passieren: Sie öffnen ein Word-Dokument, drucken
es aus und schließen das Dokument. Word fragt Sie anschließend, ob Sie das
Dokument speichern möchten, obwohl Sie das Dokument nicht verändert
haben. Was ist passiert?
Das Irak-Dossier.
Um zu verdeutlichen welche kritischen Informationen in solchen versteckten Daten
enthalten sein können, folgt nun ein reales Beispiel, bei dem versteckte Daten für
öffentlichen Aufruhr sorgten.
Im Jahr 2003 wurde von der britischen Regierung ein Dossier über die vom Irak
ausgehenden Gefahren erstellt und an den damaligen US-Außenminister Colin
Powell übermittelt. Diese Informationen wurden später in einer Anhörung vor den
5
V ariable
User Agent
HT T P ACCEPT
headers
Cookies enabled?
Screen resolution
T imezone
Browser plugins,
plugin versions
and MIME types
System fonts
Partial
supercookie test
Source
R emarks
Transmitted by HT T P, Contains Browser micro-version, OS
logged by server
version, language, toolbars and sometimes other info.
Transmitted by HT T P,
logged by server
Inferred in HT T P,
logged by server
J avaScript AJ AX post
J avaScript AJ AX post
J avaScript AJ AX post Sorted beforecollection. Microsoft Internet Explorer offers no way to enumerate plugins; we used the PluginDetect
J avaScript library to check for 8 common plugins on that platform, plus extra code to estimate the Adobe Acrobat
Reader version.
Flash applet or J ava
Not sorted; see Section 6.4.
applet, collected by
J avaScript/ AJ AX
J avaScript AJ AX post We did not implement tests for Flash
LSO cookies, Silverlight cookies, HT ML
5 databases, or DOM globalStorage.
Vereinten Nationen dazu benutzt, um einen Angriff auf den Irak zu rechtfertigen.
Später wurde das Dokument als Word-Datei online gestellt.1
Wie sich später herausstellte, wurden größere Teile des Textes aus einer Ausarbeitung eines Studenten kopiert, ohne die korrekte Quelle anzugeben. Dies war
peinlich genug. Noch peinlicher wurde es allerdings, als Forscher begannen, die
versteckten Metadaten des Dokuments zu untersuchen. Diese enthielten, neben
anderen Informationen, auch die Benutzerkennungen der Autoren der letzten
zehn Änderungen (siehe Abbildung 1.13). Des Weiteren kann man den Daten
entnehmen, dass die Word-Datei auf eine Diskette kopiert wurde (A:\).
Im Verlauf wurde die Datei offenbar vom Benutzer “cic22” zuletzt editiert. Dieses Kürzel gehörte offenbar zum „Communications Information Centre“, also
zum Presseamt der britischen Regierung. Der Verlauf zeigt weiter die Benutzer
phamil, jpratt, ablackshaw und MKhan, die später als Mitarbeiter der Regierung
identifiziert wurden. Die Kennung phamil gehörte offenbar Paul Hamill, einem
Mitarbeiter des Außenministeriums. Die Kennung jpratt konnte John Pratt zugeordnet werden, einem Mitarbeiter des britischen Premierministers Tony Blair, und
die Kennung ablackshaw gehörte offensichtlich Alison Blackshaw, der persönlichen Assistentin von Blairs Pressesprecher. Im Verlauf an letzter Stelle stand die
Kennung MKahn, die später einem gewissen Murtaza Khan zugeordnet werden
konnte. Dieser gehörte offenbar zur Gruppe von Personen, die zuerst die Datei
bearbeitet hatten. Brisant an dem Vorgang war nun, dass Murtaza Kahn eine Art
„Praktikant“ in der Pressestelle von Blair war. Die Tatsache, dass ein unerfahrener Neuling die erste Version eines so wichtigen Dokumentes erstellte, erklärte
einerseits die mangelhafte Qualität der Quellenangaben und setzte andererseits
die Gewissenhaftigkeit der Regierung Blair in ein schlechtes Licht.
1
Das Dossier wurde für die Nachwelt online archiviert und war am 26.10.2012 unter http://www.casi.
org.uk/discuss/2003/msg00457.html verfügbar. Eine ausführliche Diskussion findet sich auch auf
der folgenden Webseite: http://www.computerbytesman.com/privacy/blair.htm (aufgerufen am
26.10.2012).
Seite 19
Abb. 1.11: Serverseitig
verfügbare Browser-Infos
[Eckersley, 2010, Tab. 1]
Seite 20
Abb. 1.12: Eindeutigkeit
von Browser-Fingerprints
[Eckersley, 2010, Fig. 1]
Abhilfe.
In neuen Versionen von Microsoft Word hat man auf die Gefahren versteckter
Informationen reagiert und bietet Funktionen wie “Für Freigabe vorbereiten” an.
K
Kontrollaufgabe 1.4
Rufen Sie ein kürzlich von Ihnen erstelltes Word-Dokument auf und betrachten Sie die Dokumentinformationen. Suchen Sie die Funktion “Für
Freigabe vorbereiten”. Welche Informationen werden dadurch aus der Datei
entfernt? Wiederholen Sie das Experiment mit einem Ihnen zugeschickten
Word-Dokument.
1.4.2.2 Geschwärzte PDF-Dokumente
Ein weiteres gängiges Format für Texte aller Art sind PDF-Dateien. Das PDFFormat ist in seiner neusten Version sehr komplex geworden und enthält viele
Features. In vielen Kontexten werden diese Features falsch angewendet, etwa bei
der Unkenntlichmachung (Schwärzung) von Text, etwa in veröffentlichten Gerichtsoder Regierungsakten. Probleme treten auf, wenn etwa eine Schwärzung durch
weißen Text auf weißem Hintergrund bzw. schwarzem Text auf schwarzem Grund
gelöst wird. Dies kann meist durch einfaches Copy&Paste umgangen werden.
Auch wenn im PDF-Dokument eine Schwärzung durch die Überlagerung mit
schwarzen Balken realisiert wird, lassen sich die Balken spätestens bei Betrachtung
des PDF-Quelltextes entfernen.
Wirksames Schwärzen ist also ziemlich schwer und die einzige sichere Variante
besteht vermutlich darin, den Text auszudrucken, zu schwärzende Stellen auszuschneiden und den Text wieder einzuscannen.
Seite 21
Abb. 1.13: WordMetadaten des IrakDossiers [Berghel, 2008]
1.4.2.3 Thumbnails in Bildern
Thumbnails sind kleinere Versionen von Bildern, die der Windows Explorer anzeigt.
Sie werden in der DateiThumbs.db zwischengespeichert und bleiben erhalten, selbst
wenn die Original-Dateien gelöscht werden. Gleiches trifft auch auf Vorschaubilder
zu, die in den sogenannten EXIF-Daten von Bildern gespeichert werden. Bei EXIFDaten handelt es sich um zusätzliche Metadaten, die einem Bild im Dateiformat
zugeordnet werden. Diese werden in der Regel als Name/Wert-Paare gespeichert,
d.h. zu einem gegebenen Namen enthält das Format einen Wert. Grafikprogramme
verändern die EXIF-Daten derjenigen Einträge, die sie kennen. Die Einträge, die sie
nicht kennen, bleiben unverändert. Bildveränderungen (z.B. Zuschneiden) können
durch Auslesen dieser Daten also manchmal rekonstruiert werden.
Eine Studie von Murdoch and Dornseif [2004] zeigt, dass öffentliche Bilder im Internet häufig manipuliert worden sind. Eine Zusammenfassung einiger Funde zeigt
Abbildung 1.14. Das jeweilig größere Bild zeigt die im Netz gefundene Datei, das
kleinere den damit verbundenen Thumbnail. Diese Dateien gehören zur Kategorie
„abgeschnittene Freunde“, bei denen „unpassende“ Personen entfernt wurden.
Besonders kritisch sind die versteckten Daten jedoch, wenn die Bildveränderung
eigentlich ein Akt der Anonymisierung sein sollte.
Die Abbildungen 1.15 und 1.16 bzw. 1.15 und 1.16 zeigen, welche Informationen
Thumbs.db
Seite 22
Abb. 1.14: Beispiele für rekonstruierte Bilder [Murdoch
and Dornseif, 2004]
in einem vermeintlich anonymisierten Bild stecken können. Obwohl das restliche
Bild unscharf ist (aufgrund der geringen Auflösung des Thumbnails), lässt sich
trotzdem noch die Person erkennen.
Abb. 1.15: Beispiel für ein
vermeintlich anonymes
Bild im Internet (Kategorie „Ausschneiden zum
Identitätsschutz“) Murdoch and Dornseif [2004]
1.4.3 Zusammenfassung
Die vorgestellten Beispiele sollen die Mächtigkeit der Browser- und Anwendungsforensik verdeutlichen. In Anwendungsdaten stecken in der Regel sehr viele Informationen, zumal zu Anwendungsformaten häufig keine (öffentliche) Dokumentation
existiert. Als universelle Standardanwendungen sind Browser natürlich besonders
interessant und werden darum auch im Titel dieses Moduls hervorgehoben. Wer
die Spuren des Browsers entschlüsseln kann, der kann auch viel über die OnlineAktivitäten des Benutzers aussagen. Anwendungsdaten stecken aber auch im
Betriebssystem selbst. Ein Beispiel sind die Daten, die im Windows-Papierkorb vorgehalten werden, denn diese enthalten nicht nur den ursprünglichen Speicherort
sondern auch den Löschzeitpunkt [Berghel, 2008].
Der Schlüssel zum Verständnis von Anwendungsdaten liegt in der Analyse der
Datenformate selbst. Für viele Standardfälle gibt es dazu bereits Werkzeuge. Jedoch
wird man in der Praxis auch häufig vor bisher wenig untersuchten Dateiformaten stehen. Darum ist es wichtig, Techniken zu erlernen, wie man unbekannte
1.5 Mobilfunkforensik
Seite 23
Abb. 1.16: Bild aus Abbildung 1.15 nach Wiederherstellung mittels
Thumbnail [Murdoch and
Dornseif, 2004]
Abb. 1.17: Weiteres Beispiel aus der Kategorie
„Ausschneiden zum Identitätsschutz“ [Murdoch
and Dornseif, 2004]
Dateiformate untersuchen kann. Diese Techniken werden insbesondere in Studienbrief 3 im Mittelpunkt des Interesses stehen. Insgesamt wird Anwendungsforensik
auch in Zukunft aktuell bleiben, weil davon auszugehen ist, dass immer neue
Anwendungen entstehen werden.
Als Spezialfall der Anwendungsforensik betrachten wir im Folgenden die Analyse von Mobiltelefonen. Die Zahl der Mobiltelefone hat sich von 1996 bis 2007
versechsfacht –– Tendenz steigend (siehe Abbildungen 1.19 und 1.20). Gleichzeitig
hat der Funktionsumfang sehr stark zugenommen, während man früher „nur“
telefonieren konnte, surft man heute mit seinem Smartphone auf Facebook, checkt
seine E-Mails und fragt Siri nach dem Wetter morgen. Das Handy wird immer
mehr zum mobilen Computer und Laptop-Ersatz.
Man unterscheidet heute zwischen klassischen Mobiltelefonen (so genannten
feature phones) und Smartphones. Eigentlich sind beides auch nur “normale” Computer, die unter anderem auch telefonieren können. Aus forensischer Sicht gibt es
allerdings deutliche Unterschiede zum PC, da meist proprietäre Betriebssysteme
und wenig-untersuchte Dateisysteme verwendet werden. Standardisierte Strukturen, wie sie aus der Dateisystem- und Speicheranalyse im Desktop-Bereich lange
bekannt sind, sind bisher wenig erforscht. Standardtools aus dem Desktop-Bereich
(wie etwa dd) sind zumeist auch nicht einsetzbar. Problematisch ist vor allem die
Tatsache, dass Mobiltelefone den Zugang zum internen Speicher mit speziellen
Hardware-Schutzmechanismen versperren. Man kann bei Mobiltelefonen in der
Regel also nicht “einfach so” die Festplatte (sprich: den Speicherchip) ausbauen
oder von einer Live-CD booten.
Aufgrund der wachsenden Bedeutung der Mobilfunkforensik wollten wir uns
Seite 24
Abb. 1.18: Bild aus Abbildung 1.17 nach Wiederherstellung mittels
Thumbnail [Murdoch
and Dornseif, 2004]
nun mit diesem Thema auseinandersetzen. Zu Beginn werden die Zugriffsmöglichkeiten dargestellt. Danach folgen kursorische Abschnitte zu den SmartphoneBetriebssystemen und deren Analyse. Abschließend wird noch das Analysetool
ADEL vorgestellt, welches am Lehrstuhl für IT-Sicherheitsinfrastrukturen der FAU
entwickelt wurde.
Abb. 1.19: Überwachungsmaßnahmen
der Telekommunikation (Bundesnetzagentur, zitiert nach
Spreitzenbarth [2009])
1.5.1 Zugriff auf Smartphones und Mobiltelefone
Bei Smartphones gibt es trotz aller Schwierigkeiten verschiedene Möglichkeiten,
Zugriff auf die gespeicherten Daten zu bekommen. Die besten Ergebnisse werden
durch das Auslöten des Flash-Speicherbbausteins erzielt. Diese Methode ist allerdings aufwendig und teuer (die dazu benötigte Spezialhardware kostet schätzungs-
Seite 25
Abb. 1.20: Anzahl sichergestellte Mobiltelefone
beim BKA, Abteilung
TESIT-6 (BKA, zitiert nach
Spreitzenbarth [2009])
weise 20.000€). Das Auslöten des Speichers hat den Vorteil, dass keine (unbekannte)
Software (Betriebssystem oder App) zwischen Flashspeicher und Ausgabe agiert.
So können in diesem Fall Manipulationen zur Laufzeit ausgeschlossen werden.
Verhältnismäßig sicher ist auch der Zugriff über die so genannte JTAG-Schnittstelle.2
Die Abkürzung JTAG steht für “Joint Test Action Group” und stellt eine HardwareDebug-Schnittstelle zur Verfügung, die jedoch nicht auf allen Telefonen vorhanden
ist. Zum Auslesen ist außerdem wieder Spezialhardware (ca. 200€) erforderlich.
Die Ergebnisse sind entsprechend gut zu verwenden.
Eine billigere Variante sind sogenannte Software Agents, also Apps, die auf dem
Gerät installiert werden. Sie greifen auf die Systemdatenbanken auf Basis ihrer
Berechtigungen zu. Hierzu sind jedoch Veränderungen auf dem Gerät notwendig
und die Ergebnisse könnten durch Shadow-Datenbanken gefälscht sein. Eine ShadowDatenbank ist eine zweite, gefälschte Datenbank, die unautorisierten Nutzern
angezeigt wird.
Herkömmliche Software-Lösungen werden auf dem PC installiert und greifen
über ein Datenkabel auf das Telefon zu. Dazu werden allerdings die Treiber des
Smartphones verwendet, deren Konsistenz aus forensischer Sicht fragwürdig sein
kann. Dieser Fall ist ähnlich zur Benutzung des Betriebssystems des Beschuldigten
in der Live-Analyse (siehe Modul 13). Außerdem ist der Zugriff über Treiber bzw.
Betriebssystem eingeschränkt (siehe auch Kapitel 1.5.3).
Bei Android-Smartphones gibt es noch eine Speziallösung, die Entwicklerschnittstelle adb (Android Debug Bridge), die ähnlich wie herkömmliche SoftwareLösungen arbeitet, jedoch nicht auf den Treibern des Smartphones aufsetzt.3 Diese
Schnittstelle kann über einen mit dem Smartphone verbundenen Computer angesprochen werden. Hierdurch können Logfiles ausgelesen werden, Daten hochund heruntergeladen werden usw.
Im Gegensatz zu Smartphones sind die Zugriffsmöglichkeiten bei herkömmlichen
Mobiltelefonen etwas eingeschränkter. Tabelle 1.1 vergleicht einige Aspekte beider
2
3
Mehr Informationen zu JTAG sind unter http://www.mikrocontroller.net/articles/JTAG zu finden.
Mehr Informationen zu adb finden Sie unter http://developer.android.com/guide/developing/
tools/adb.html.
JTAG-Schnittstelle
Software Agents
Seite 26
Geräteklassen. Bemerkenswert ist, dass bei Mobiltelefonen in der Regel der Zugriff
auf den internen Speicher nur durch Auslöten oder über JTAG funktioniert.
Tabelle 1.1: Vergleich Mobiltelefon vs. Smartphone
Mobiltelefone
proprietäres Dateisystem
closed source ohne Dokumentation
geringer Funktionsumfang
geringe Speicherkapazität
nur JTAG/Auslöten Speicherbaustein
Smartphones
(meist) bekannte Dateisysteme
allerdings: Schutzmechanismen
(oft) open source
hoher Funktionsumfang
hohe Speicherkapazität
zusätzlich: Softwarelösungen,
Schnittstelle adb usw.
Um die Schwierigkeiten bei der Analyse auf Daten aus Mobiltelefonen zu verdeutlichen, wird nun die Analyse einer SMS auf einem Nokia Series 40 dargestellt
(basierend auf Spreitzenbarth [2009]). Die SMS liegt auf dem Smartphone als
einfacher Binärstrom vor (siehe Abbildung 1.21). Dieser muss jedoch manuell
nachvollzogen werden, da kein einheitlicher Standard existiert.
Abb. 1.21: Aufbau
einer SMS Spreitzenbarth [2009]
In Abbildung 1.22 ist die SMS genauer beschrieben. Interessant sind hierbei aus
forensischer Sicht vor allem Daten wie die Nummer des Absenders, das Datum und
der Inhalt der Mitteilung. Das Datum liegt dabei im Format YYMMDDHHMMSS
vor, wobei die einzelnen Zeichen Byte für Byte vertauscht werden. Ein Wert von
“90” ist also als “09” zu interpretieren. Die SMS ist somit am 16.04.09 um 20:04:49
Uhr von der Nummer +491705489447 versendet worden. Der Inhalt der SMS ist
mit einem 127 bit GSM Alphabet codiert, das auf einem ASCII-Alphabet basiert.
Für genauere Informationen zum Decodieren der Nachricht siehe Spreitzenbarth
[2009].
Abb. 1.22: Detaillierter Aufbau einer SMS
[Spreitzenbarth, 2009]
1.5.2 Smartphones: Überblick über die Systeme
Es gibt verschiedenste Smartphones und Smartphone-Betriebssysteme. Zu den
am weitesten verbreiteten Systemen zählen Android, Symbian, iOS und Research In Motion (RIM). Microsoft spielt trotz seiner Bekanntheit bei den PCBetriebssystemen eine eher untergeordnete Rolle (siehe Abbildung 1.23). In den folgenden Unterkapiteln werden nun einige dieser Systeme kursorisch vorgestellt.
Seite 27
Abb. 1.23: Anzahl Smartphones nach Typ (zitiert
nach Spreitzenbarth
[2009]
1.5.2.1 Apple iOS
iOS basiert auf Mac OS X, welches Ähnlichkeiten zu Unix besitzt und auf Smartphones, Tablets und TV-Boxen eingesetzt wird. Die Synchronisation erfolgt über
iTunes oder iCloud. Dies kann bei der forensischen Analyse ausgenutzt werden,
wobei jedoch deutlich mehr Daten direkt auf dem iPhone vorliegen als auf dem
Backup. Dabei handelt es sich beispielsweise um den Keyboard Cache, gelöschte
Daten, GoogleMaps-Sucheinträge, Browser-Cache usw.
1.5.2.2 Google Android
Googles Smartphone-Betriebssystem beruht auf einem modifizierten Linux, welches, wie iOS, auf Smartphones, Tablets und TVs eingesetzt wird. Es ist größtenteils
als open source Software verfügbar, was die Analyse deutlich vereinfacht. Außerdem ist der Zugriff über die adb-Schnittstelle wesentlich leichter und billiger als
andere zuverlässige Verfahren. Zum Zugriff auf die Daten im Rahmen einer forensischen Analyse gibt es mehrere Ansätze, die oben bereits näher beschrieben
wurden, wobei die Entwicklerschnittstelle adb herausragt. Wir werden später in
Abschnitt 1.5.4 nochmals auf dieses Thema zurückkommen.
1.5.2.3 (Microsoft) Windows Phone
Microsoft verwendet für seine Smartphones die eigene Windows Win32 API, was
die Parallelen zu Windows 7 bzw. Windows 8 erklärt. Das Betriebssystem ist auf
Smartphones verschiedener Hersteller zu finden. In Bezug auf die forensische
Analyse ist das Windows Phone noch relativ unerforscht, vermutlich auf Grund
der geringeren Verbreitung.
1.5.2.4 RIM Blackberry
Das System RIM Blackberry ist closed source und wird auf Smartphones und
Tablets eingesetzt. Tragende Rolle übernimmt der Blackberry Enterprise Server
(BES), der für Synchronisation und Backup sorgt. Die Kommunikation mit dem
Server erfolgt verschlüsselt. Apps basieren auf Java und QNX. Die forensische Analyse von Blackberry ist ziemlich unerforscht, da, deutlich einfacher, der Enterprise
Server sichergestellt und untersucht werden kann.
Seite 28
1.5.3 Root-Zugriff und Datenanalyse bei Android
Wir gehen nun etwas spezifischer auf die Möglichkeiten einer forensischen Datenanalyse bei Android ein. Da Android auf Linux basiert, werden die Berechtigungen typischerweise in User und Group eingeteilt. Besonders interessante
Stellen im Android-Dateisystem sind ausserdem vor der Analyse besonders geschützt. Die einzige Möglichkeit, diesen Schutz zu umgehen, ist das Erlangen von
root-Rechten.
In der Regel ist es durch die Hersteller von Android-Smartphones unerwünscht,
wenn Benutzer root-Rechte auf dem Telefon besitzen, da diese dann beliebige Veränderungen am System vornehmen können. Dennoch gibt es neben verschiedenen
Schwachstellen, die mittels einex Exploits root-Zugang ermöglichen, mittlerweile
auch “offizielle” Wege. Bei Samsung und HTC etwa werden bereits Smartphones verkauft, die einen offenen Bootloader besitzen. Über diesen kann man ein
modifiziertes Betriebssystem booten (analog zum Booten mittels einer Live-CD).
Die angesprochenen root-Exploits sind in der Regel nur für ältere Versionen von
Android verfügbar. Diese erlauben das so genannte “rooten” des Telefons und
anschließend das Austauschen des Kernels. In einem solchen modifizierten Kernel
kann man dann eine root-Shell erhalten, mit der man privilegierte Systembefehle
absetzen kann.
In Android gibt es verschiedene Stellen im Dateisystem, an denen sich interessante
Daten verbergen. Jede App hat eine eigene Datenbank (SQLite), deren Daten unter
/data/data/ und /sdcard/data/data/ liegen. Dokumente, Musik und Bilder sind
unter /sdcard/ zu finden. Außerdem hat jede App ihren eigenen Arbeitsspeicherbereich.
Die SQLite-Datenbank lässt sich mit Parsern verhältnismäßig einfach darstellen.
Dadurch ist der Zugriff beispielsweise auf SMS wesentlich einfacher als bei Mobiltelefonen, deren SMS-Format erst aufwendig ermittelt werden muss (siehe oben).
Struktur der Daten
Dalvik Debug
Monitor Server
Wear-Levelling
Chunks
Der interne Flash-Speicher ist in der Regel mit einem YAFFS2- oder EXT4Dateisystem formatiert, während die Speicherkarte Dateisysteme mit FAT oder
EXT3 beherbergt. Der Arbeitsspeicher liegt in Form einer leicht modifizierten
hprof-Variante vor. Bilder sind im JPEG-Format ggf. mit EXIF-Erweiterung (siehe Abschnitt 1.4) vorhanden und können zusätzliche Informationen wie GPSKoordinaten, Typ der Kamera und Zeitstempel beinhalten. FAT, EXT3 und EXT4
sind bekannte Formate, die einfach ausgelesen werden können. Mit dem ProgrammDalvik Debug Monitor Server können sogar die hprof-Daten im RAM analysiert werden.
Obwohl YAFFS2 ein offener Standard ist, ist es nicht sehr gut erforscht und erfasst
[Spreitzenbarth et al., 2011]. Die ungenaue Dokumentation kommt vor allem bei
Wear-Leveling und Garbage-Collection zum tragen. Wear-Leveling ist eine Technik,
die von SSDs und USB-Sticks verwendet wird, um die Lebenszeit der Hardware zu
verlängern. Dabei werden Schreibzugriffe möglichst gleichmäßig verteilt. GarbageCollection gibt nicht genutzten Speicher wieder frei.
Das YAFFS2-Dateisystem wurde extra für NAND-Flashspeicher entwickelt und
ist inChunks und Blöcke, entsprechend dem NAND-Speicher, gegliedert. Blöcke
werden in Chunks beschrieben, können jedoch nur als Ganzes gelöscht werden.
Der Speicher ist in YAFFS2 in Objekte gegliedert, die Daten, Hard Links, Soft Links
oder spezielle Objekte, wie Devices oder Pipes, beinhalten können. Beim Einhängen
von YAFFS2 werden alle diese Informationen über das Gerät in den RAM geladen.
Es wird dabei die Ordnerstruktur sowie eine Hash-Tabelle für die Objektnummern
erzeugt.
Für die Blockverwaltung existieren mehrere Stadien, um belegte Blöcke,Bad Blocks,
zu löschende Blöcke usw. zu identifizieren. Insgesamt werden 10 Zustände verwaltet, darunter FULL für volle Blöcke, EMPTY für Leere und DEAD für kaputte
Blöcke, sogenannte Bad Blocks. Initial haben alle Blöcke den Status UNKNOWN,
der durch einen Scan festgelegt wird. Interessant ist noch der Zustand ALLOCATING, der dem Block zugewiesen wird, der aktuell für Schreiboperationen
verwendet wird, bis er komplett gefüllt ist. YAFFS2 beschreibt dabei die Chunks
innerhalb eines Blocks und die Blöcke des NAND-Speichers in strikter sequentieller Reihenfolge solange leere Blöcke existieren. Dadurch kann ein chronologisches Logfile über die Modifikationen geführt werden und macht YAFFS2 zu
einem sogenanntenlog-structured file system. Da keine Daten überschrieben werden,
existieren eigentlich immer veraltete Blöcke, weshalb die oben angesprochene
Garbage-Collection erforderlich ist.
Seite 29
Bad Blocks
log-structured file system
Für weiter Infos zu YAFFS2 sei auf Spreitzenbarth et al. [2011] und Zimmermann
and Spreitzenbarth [2012] verwiesen.
1.5.4 Android-Forensik mit ADEL
Abschließend soll nun noch das Projekt ADEL (Android Data Extractor Lite) vorgestellt werden. ADEL ist ein Tool, dass Android-Systeme automatisch analysiert,
in dem es die Daten in SQLite-Datenbanken mit Hilfe der Android Debug Bridge
adb ausliest und forensisch untersucht [Freiling et al., 2011].
ADEL wurde für Android 2.x unter den Voraussetzungen der forensischen Korrektheit, der Erweiterbarkeit und der Bedienbarkeit entwickelt. Forensisch korrekt
bedeutet, dass keine Daten verändert werden, weder vom Benutzer, noch von
einem Betriebssystem. Um dieses Ziel zu erreichen arbeitet ADEL lediglich lesend (read only) auf Kopien und fertigt Hashes vor und nach jeder Bearbeitung an.
Das Programm ist in Python geschrieben und in Module eingeteilt, wodurch es
erweiterbar ist und viele Apps bzw. deren Datenbanken analysieren kann.
Eine Besonderheit von ADEL ist, dass es EXIF-Daten aus JPEGs, GPS und weitere
ortsbestimmte Daten extrahieren, verknüpfen und daraus Bewegungsprofile erzeugen kann. Für die Bewegungsprofile werden geographische Daten aus Apps, wie
beispielsweise der Twitter App, sowie aus System Cache-Datenbanken, Widgets
und den Navigationsverläufen in GoogleMaps entnommen [Spreitzenbarth and
Schmitt., 2012]). Selbst der Browser speichert lokale Suchen.
Abb. 1.24: ADELBewegungsprofil [Spreitzenbarth and Schmitt.,
2012]
Seite 30
Abbildung 1.24 zeigt ein Bewegungsprofil eines Test-Smartphones um den Brienzersee in der Schweiz. Kreise zeigen ungefähr den Standort an, an dem telefoniert
wurde, eine Nachricht verschickt wurde oder ein Bild aufgenommen wurde (grünes JPG-Zeichen). Es wurden viele WiFi-Router erkannt und vermerkt, auf deren
Basis sich der Weg des Smartphones nachvollziehen lässt. Die Ortung liegt dabei im
Schnitt bei 50 bis 100 Metern, während sich die Daten von Mobilfunkgesellschaften
im Bereich größer 500 Meter befinden.
Zusammenfassend spielt die Mobilfunkforensik in heutigen Untersuchungen eine
nicht zu unterschätzende Rolle, da häufig der Nachweis einer Kommunikation im
Fokus einer Ermittlung stehen kann und moderne Smartphones eine Vielzahl zusätzlicher Daten —- wie beispielsweise Bewegungsdaten –– liefern können. Solche
Daten können in einem Verfahren gezielt dazu herangezogen werden, Aussagen zu
überprüfen oder zu widerlegen (beispielsweise in Bezug auf einen Aufenthaltsort
zu einer bestimmten Zeit im Falle der zuvor genannten Bewegungsdaten).
1.6 Verschleierungstechniken
Zur Analyse unbekannter Anwendungen und Dateiformate bedient man sich häufig Techniken des Reverse Engineering (siehe auch Modul M15). Wir betrachten
im Folgenden den Teil des Reverse Engineering, der sich auf die Rekonstruktion
des Quellcodes aus übersetztem (Binär-)Code bezieht. In diesem Bereich gibt es
mittlerweile viele Ansätze, um Reverse Engineering zu verhindern. Wir betrachten
im Folgenden einige dieser Methoden im Überblick. Dieser Überblick soll es Ihnen erlauben, die praktischen Möglichkeiten der Anwendungsanalyse realistisch
einschätzen zu können und die Arbeitsweise des „Gegners“ kennen zu lernen.
(Verschleierung wird dabei manchmal auch mit dem englischen Begriff Obfuscation
benannt.) Die Vorstellung der Techniken erfolgt nur kursorisch denn eine vertiefende Einführung mit Anwendungen auf die Malware-Analyse erfolgte bereits in
Modul 15 (Reverse Engineering).
control flow
Verschleierungstechniken sollen den Quellcode und damit schlussendlich auch
die Intention und den Zweck einer Software verbergen. Sie transformieren ein
Programm in ein anderes Programm, sollen jedoch nicht die ursprüngliche Funktionalität verändern. Es ist also wichtig, dass trotz aller Verschleierung das transformierte Programm dasselbe Programmverhalten an den Tag legt und dabei effizient
bleibt, d. h. die resultierende Laufzeit sollte vergleichbar mit der des ursprünglichen Programmabschnitts sein [Drape, 2004]. Ziel der Obfuscation ist es vor allem,
den Kontrollfluss (control flow) so zu verkomplizieren, dass dessen eigentliche
Funktionalität nicht mehr erkennbar ist [Majumdar and Thomborson, 2006]. Dabei
wird meist auf objektorientierte Sprachen und sehr häufig auf kryptografische
Verschlüsselung zurückgegriffen.
Verschleierungstechniken sind ein zweischneidiges Schwert. Aus Sicht der Forensik stehen häufig dubiose oder gar strafbare Handlungen im Vordergrund, etwa
die Analyse von Schadsoftware, Raubkopien oder plagiierten Codes. In einem
solchen Fall spricht man auch häufig von Anti-Forensik. Es gibt jedoch auch legitime Anwendungen von Verschleierungstechniken, etwa zum Schutz geistigen
Eigentums in Software (Schutz vor Raubkopien) [Wroblewski, 2002].
Allgemein wird bei der Analyse von verschleierter Software angenommen, dass
sich das Programm unter der vollen Kontrolle des Rechners befindet, auf dem es
läuft. Der Administrator, Antivirenhersteller oder sonstige Analytiker kann also
zum Beispiel auf den kompletten (Binär-)Code des Programms zugreifen und die
Seite 31
aktuell verwendeten Daten verändern, beispielsweise innerhalb eines Debuggers
Vrba and Halvorsen [2010].
Im Folgenden werden wir uns kurz mit der “Gegentechnik” zu Obfuscation, dem
Reverse Engineering, beschäftigen. Danach folgt etwas Theorie zu Fragen der
Verschleierung mit einigen Beispielen. Zum Schluss sehen wir uns einige Verschleierungstechniken genauer an.
1.6.1 Reverse Engineering
Die Techniken des Reverse Engineering unterteilt man in der Regel in zwei Bereiche:
die statische und die dynamische Analyse. Bei der statischen Analyse wird lediglich
der Code der Schadsoftware mit Hilfe von Disassembler und Decompiler betrachtet.
Im Gegensatz dazu wird bei der dynamischen Analyse das Programmverhalten
zur Laufzeit unter Verwendung von Debuggern analysiert. Tabelle 1.2 nennt einige
Programme, die für die statische und dynamische Analyse verwendet werden.
Technik
Disassembler (statisch)
Decompiler (statisch)
Java-Bytecode
Javap/jasmine
Jd/jad
Debugger (dynamisch)
Jdb/JDebugTool
X86 Binärcode
IDA pro
Hexrays Decompiler
(IDA Plugin)
OllyDbg/Immunity
Debugger
statische Analyse
Tabelle 1.2: Reverse Engineering Tools
Im Folgenden konzentrieren wir uns der Einfachheit halber auf Java-Bytecode.
Das gleiche Thema im Kontext von x86-Binärcode wird im Modul 15 (Reverse
Engineering) genauer behandelt. Wir gehen die Schritte einer statischen Analyse
einers binär vorhandenen Java-Fragments durch.
Folgender Java-Bytecode soll im Folgenden beispielhaft statisch analysiert werden:
Quelltext 1.1
06 3b 03 3c 1b 07 a2 00 15 1a 06 a3 00 0b
06 3b 84 01 01 a7 ff f1 06 3b a7 ff ec b1
Allgemein versucht man im Rahmen der statischen Analyse folgende Schritte in
der beschriebenen Reihenfolge durchzuführen:
1. Disassemblierung, d.h. erstellen von “Maschinensprache” aus Binärcode
2. Erstellen des Kontrollflussgraphen (Control Flow Graph)
3. Elimination nicht erreichbarer Code-Fragmente (Dead Code Elimination)
4. Vereinfachung des Kontrollflussgraphen (Control Flow Graph)
5. Übersetzung in Pseudo Code, der möglichst nahe am Quellcode ist
Disassambly.
Zuerst wird aus dem nicht lesbaren Bytecode eine lesbarere Variante erstellt. Dies
erfolgt mittels entsprechender Programme automatisch. Das so genannte “Disassembly” kann einfacher interpretiert und nachvollzogen werden als der binär
codierte Bytecode.
Q
Seite 32
Stack-Maschine
Q
Der folgende Quelltext zeigt die Ausgabe des Disassemblers auf den oben gezeigten Binärcode. In der ersten Spalte steht die Zeilennummer, mit der einzelne
Instruktionen identifiziert werden können. In eckigen Klammern folgt der ByteWert, aus dem der Befehl besteht, der in der rechten Spalte dargestellt ist. Das
Maschinenmodell von Java ist eine Stack-Maschine. Argumente werden dabei auf
einen internen “Stapel” (Stack) geladen und dann mittels einer Operation manipuliert. Es gibt auch benannte Speicherzellen (ähnlich Registern), die mit load- und
store-Befehlen angesprochen werden können.
Quelltext 1.2
0:
1:
2:
3:
4:
5:
6:
9:
10:
11:
14:
15:
16:
19:
22:
23:
24:
27:
[06]
[3b]
[03]
[3c]
[1b]
[07]
[a2,00,15]
[1a]
[06]
[a3,00,0b]
[06]
[3b]
[84,01,01]
[a7,ff,f1]
[06]
[3b]
[a7,ff,ec]
[b1]
iconst_3
istore_0
iconst_0
istore_1
iload_1
iconst_4
if_icmpge 27
iload_0
iconst_3
if_icmpgt 22
iconst_3
istore_0
iinc 1, 1
goto 4
iconst_3
istore_0
goto 4
return
In Zeile 0 bis 3 werden zwei Variablen (in den Speicherzeillen 0 und 1) initialisiert.
Anschließend werden die Variable 1 und die Konstante 4 auf den Stack geladen
und in Zeile 6 verglichen (“compare greater equal”). Wenn Variable 1 größer oder
gleich vier ist, springt der der Ablauf in Zeile 27 (return), ansonsten wird Variable
0 geladen und getestet, ob sie größer als 3 ist. In jedem Fall wird Variable 0 auf 3
gesetzt und in Zeile 4 gesprungen. Sollte Variable 0 kleiner gleich 3 sein, so wird
zusätzlich noch Variable 1 inkrementiert (iinc).
Kontrollflussgraph.
Als Kontrollflussgraph (Control Flow Graph) eines Programms bezeichnet man
den gerichteten Graphen, der wie folgt entsteht: Die Knoten des Graphen sind
die einzelnen (Programm-)Anweisungen; zwischen zwei Knoten a und b besteht
eine gerichtete Kante, falls nach Anweisung a potentiell Anweisung b ausgeführt
werden kann. Der Einfachheit halber werden sequentiell im Programm aufeinanderfolgende Anweisungen zu einem Konoten zusammengefasst.
Abbildung 1.25 zeigt den Kontrollflussgraphen des oben gezeigten Programmes.
Variable 0 wurde dabei als x bezeichnet und Variable 1 als i. Der Kontrollflussgraph
hilft in der Regel deutlich beim Verständnis eines Programmes. So wird etwa der
Rücksprung 19 und 24 deutlicher und man erkennt die typische Ablaufstruktur
einer while-Schleife, die im Disassembly eher schwierig zu erfassen ist. Außerdem
ist nun ersichtlich, dass der Vergleich in Zeile 11 überflüssig ist, da x (Variable 0)
immer 3 ist.
Seite 33
Abb. 1.25: Control
Flow Graph des JavaProgrammes
Dead Code Elimination.
Wie aus dem Kontrollflussgraphen zu ersehen ist, ist die Abfrage des Wertes von x
überflüssig, da x von Anfang an den Wert 3 hat und niemals einen anderen Wert
annimmt. Die Abfrage x <= 3 ergibt als immer den Wert true und kann durch
diesen ersetzt werden. Der false-Zweig wird daher nie erreicht (so genannter dead
Code) und kann im Graph eliminiert werden. Gleichzeitig fällt damit x (Variable
0) weg, da sie nirgends im Programm gelesen wird. Dies ist in Abbildung 1.26
dargestellt. Man kann den Code also deutlich vereinfachen.
Abb. 1.26: Kontrollflussgraph während Dead
Code Elimination
Vereinfachter Kontrollflussgraph.
Nachdem die unnötige Variable und Verzweigung aus dem Kontrollflussgraph
entfernt wurden, ist die while-Schleife noch deutlicher zu sehen (siehe Abbildung
1.27).
Überführung in Pseudo Code.
Man kann nun also den vereinfachten Kontrollflussgraph in den (vermuteten)
Quellcode überführen. Diese Umwandung ist natürlich niemals eindeutig machbar
sondern basiert auf typischen Mustern, wie sie von Compilern generiert werden,
hier etwa das Muster einer while-Schleife:
Seite 34
Abb. 1.27: Vereinfachter Kontrollflussgraph
Q
Quelltext 1.3
i = 0
while (i < 4)
i++
Wir haben also aus dem Binärcode den vermuteten Quellcode rekonstrieren können.
Dass dies im allgemeinen Fall etwas schwieriger ist als in diesem Beispiel, dürfte
klar sein. Wir betrachten im Folgenden einige Ansätze, wie die statische Analyse
in der Praxis erschwert werden kann.
1.6.2 Verschleierungstechniken zum Anti Reverse
Engineering
Beispiele für Code-Verschleierungen sind im Netz sehr einfach zu finden. Es gibt
mittlerweile sogar Wettbewerbe auf diesem Gebiet, bei dem man ein möglichst
Seite 35
einfaches Programm möglichst elegant möglichst unleserlich machen soll (“Obfuscated C Contest” bzw. “Obfuscated Perl Contest”).
Beispiel 1.1
B
Das folgende Programm ist ein Beispiel für ein Programm aus dem “Obfuscated C Contest”. Es berechnet beispielsweise die Kreiszahl π.
# d e f i n e _ −F<00||−−F−OO−−;
i n t F =00 ,OO= 0 0 ; main ( ) { F_OO ( ) ; p r i n t f ( " % 1 . 3 f \n " , 4 . ∗ − F/OO/OO) ; } F_OO ( )
{
_−_−_−_
_−_−_−_−_−_−_−_−_
_−_−_−_−_−_−_−_−_−_−_−_
_−_−_−_−_−_−_−_−_−_−_−_−_−_
_−_−_−_−_−_−_−_−_−_−_−_−_−_−_
_−_−_−_−_−_−_−_−_−_−_−_−_−_−_
_−_−_−_−_−_−_−_−_−_−_−_−_−_−_−_
_−_−_−_−_−_−_−_−_−_−_−_−_−_−_−_
_−_−_−_−_−_−_−_−_−_−_−_−_−_−_−_
_−_−_−_−_−_−_−_−_−_−_−_−_−_−_−_
_−_−_−_−_−_−_−_−_−_−_−_−_−_−_
_−_−_−_−_−_−_−_−_−_−_−_−_−_−_
_−_−_−_−_−_−_−_−_−_−_−_−_−_
_−_−_−_−_−_−_−_−_−_−_−_
_−_−_−_−_−_−_−_
_−_−_−_
}
Verschleierung findet meist mittels eigener Programme statt, da die Verschleierung „per Hand“ fehleranfällig und aufwendig ist. Ein Verschleierungsprogramm
(Obfuscator) ähnelt dabei einem Compiler, nur dass dieser möglichst unleserlichen
Code produzieren soll. Die Vorgehensweise solcher Tools ist in Abbildung 1.28
dargestellt. Als Eingabe erhält der Obfuscator das (zu verschleiernde) Originalprogramm P, in dem bestimmte Stellen als wichtig markiert wurden (precious code).
Diese Code-Stücke sollen mittels Transformationen verschleiert werden. Dieser
Code wird nun analysiert und mittels vorgegebener Code Transformationen umgewandelt. Zum Schluss entsteht aus dem Programm P das obfuskierte Programm
P 0.
ObfuscationLTool
P
Obfuscation
Level
Acceptable
overhead
Precious
code
Program
analysis
Abb. 1.28: Obfuscator
[Collberg and Nagra,
2009]
Obfuscating
transformations
1.LSelectLcode
2.LSelectLtransformation
3.LApplyLtransformation
4.LDone?
precious code
P'
1.6.2.1 Perfekte Verschleierung: Voll-Homomorphe
Verschlüsselung
Die Kryptographie kennt in Form von Verschlüsselungsroutinen schon lange sehr
gute Verschleierungsmethoden. Allerdings beziehen sich diese Methoden immer
auf die Verschlüsselung von Daten und niemals von Code. Um Code auszuführen,
muss man ihn stets zuvor entschlüsseln. Auf Daten hingegen wäre theoretisch
Seite 36
ein perfekt verschleiertes Rechnen möglich. Diese Idee ist unter dem Konzept der
voll-homomorphen Verschlüsselung bekannt, das wir im Folgenden kurz erklären.
Ein Verschlüsselungsverfahren e ist homomorph zu einer Rechenoperation ⊗, falls
es egal ist, ob man auf den Werten vor oder nach der Verschlüsselung rechnet,
also:
e(x ⊗ y) = e(x) ⊗ e(y)
Wenn ein Kryptosystem homomorph ist bezüglich der beiden in der Ganzzahlarithmetik notwendigen Rechenoperationen ist (+ und ∗ bzw. OR und AND), dann
spricht man von einem voll-homomorphen Kryptosystem. Nicht voll-homomorphe
Kryptosysteme nennt man zur Abgrenzung auch teil-homomorph. In der Praxis gibt
es viele teil-homomorphe Kryptosysteme (wie RSA), aber es gibt bisher noch kein
praktikables voll-homomorphes Kryptosystem.
Ein voll-homomorphes Kryptosystem hätte viele Anwendungsmöglichkeiten. So
könnte man beispielsweise verschlüsselte Daten abspeichern, könnte auf ihnen
rechnen, und bräuchte sie erst dann zu entschlüsseln, wenn das Endresultat benötigt wird. So könnte man zwar nicht den Algorithmus verschleiern (also was mit
den Daten geschieht), aber die konkreten Werte wären perfekt verschleiert.
Hätte man einen perfekten Obfuscator für beliebige Programme, könnte man
aus jedem beliebigen (teil-homomorphen) Kryptosystem ein voll-homomorphes
Kryptosystem herstellen. In der folgenden Formel bezeichnet OBF diesen perfekten
Obfuscator, e die Verschlüsselung und d die Entschlüsselung des Kryptosystems:
x ⊗ y = OBF(e(d(x) ⊗ d(y)))
(1.1)
Die Formel besagt, dass man x ⊗ y auf verschlüsselten Werten x und y berechnen
kann, indem man die Werte zunächst entschlüsselt, dann auf den entschlüsselten
Werten ⊗ berechnet, und das Ergebnis dann wieder verschlüsselt. Damit dies nicht
durch Reverse Engineering durchschaut werden kann, wird die gesamte Prozedur
durch den perfekten Obfuscator geschützt.
Wenn man also für x und y verschlüsselte Werte einsetzt, also e(x) und e(y), so
erhält man:
e(x) ⊗ e(y) = OBF(e(d(e(x)) ⊗ d(e(y))))
Da d(e(x)) = x und der Obfuscator die Werte nicht verändert, ergibt dies:
e(x) ⊗ e(y) = e(x ⊗ y)
Da wir keine Einschränkung der zu berechnenden Operation vorgenommen haben, kann man dies für jede Operation durchführen. Das Verfahren ist also vollhomomorph.
Noch verrückter ist die folgende Anwendung eines perfekten Obfuscators: Man
kann mit einem solchen Obfuscator aus jedem symmetrischen Kryptoverfahren
ein asymmetrisches erzeugen. Das asymmetrische Verschlüsseln würde durch
das verschleierte Verschlüsselt mit einem symmetrischen Schlüssel erreicht, das
asymmetrische Entschlüsseln analog durch verschleiertes Entschlüsseln:
Public(x) = OBF(ek (x))
(1.2)
Private(x) = OBF(deck (x))
(1.3)
Die Notation ek (x) bedeutet Verschlüsselung mittels festem Schlüssel k. Zu beachten
ist, dass der perfekte Obfuscator OBF den Wert des Schlüssels k perfekt schützt.
Seite 37
Wenn der Obfuscator effizient arbeitet, dann könnte man damit unter Umständen
sogar schnellere asymmetrische Kryptoverfahren erzeugen, als es sie heute gibt.
1.6.2.2 Definition von Obfuscator
Wir haben bis jetzt häufig von einem Obfuscator gesprochen. Nun wollen wir ihn
etwas genauer definieren.
Definition 1.1: Obfuscator
Ein Obfuscator OBF ist ein Compiler, der auf Eingabe eines Programms
P die Ausgabe P 0 = OBF(P) liefert, sodass die Funktionalität von P
erhalten bleibt, sich die Effizienz nicht merklich verschlechtert und die
Eingabe möglichst gut verschleiert wird.
D
Mit dieser Definition weiss man schon etwas genauer, was ein Obfuscator ist.
Allerdings sind einige Eigenschaften noch recht vage beschrieben, beispielsweise,
dass sich die Effizienz “nicht merklich verschlechtern” soll. Dies könnte man etwas
so verstehen, dass bezüglich der Effizienz das verschleierte Programm OBF(P)
nicht exponentiell langsamer sein darf als P. Unklar bleibt jedoch auch nach
längerem Nachdenken die Aussage, dass OBF(P) “unverständlicher als P” sein
soll. Dies ist jedoch der Kern der Verschleierung.
Es gibt in der Literatur mehrere Versuche, den Begriff der Unverständlichkeit
genauer zu definieren. Wie betrachten und diskutieren nun ein paar Vorschläge.
Definition 1.2: Virtual Black Box Obfuscator
Ein Obfuscator OBF wird als Virtual Black Box Obfuscator bezeichnet, wenn
aus einem verschleierten Programm OBF(P) = P 0 nur die Informationen
erlangt werden können, die auch durch eine reine Schnittstellenbetrachtung
(Black Box Zugriff) auf das unverschleierte Programm P erlangt werden
können. Bei einem Black Box Zugriff werden nur die Schnittstellen eines
Programmes betrachtet; innere Abläufe, Variablen oder Programmzustände
können nicht beobachtet bzw. eingesehen werden.
D
Ein Black Box-Zugriff ist ein Zugriff, der nur auf die Schnittstelle eines Programms
zugreift und nicht auf die inneren Abläufe und Zwischenwerte. Diese Definition
kommt dem Begriff eines perfekten Obfuscators darum sehr nahe. Sie ist aber
für viele praktische Formen der Verschleierung zu stark und so gut wie nie zu
erreichen.
Eine alternative Definition lautet:
Definition 1.3: Best Possible Obfuscator
Der Obfuscator OBF heißt best possible, falls OBF(P) weniger Informationen
über P verrät als jedes andere Programm mit derselben Funktionalität wie
P.
Diese Definition ist deutlich schwächer als Definition 1.2, allerdings müsste man
„jedes andere Programm“ testen (bzw. eine hinreichend große Menge), um diese
D
Seite 38
Definition zu verifizieren. Dies ist nicht praktikabel und darum ist die Definition
zu ungenau.
Versuchen wir es mit einer weiteren Definition. Eine weitere Möglichkeit, Definition 1.2 einzuschränken, ist die folgende:
Definition 1.4: t-Obfuscator
D
Der Obfuscator OBF heisst t-Obfuscator wenn für ihn die virtual Black Box
Eigenschaft mindestens für den Zeitraum t gilt.
Ein t-Obfuscator erfüllt also die virtual black box-Eigenschaft nicht für immer
sondern nur für eine begrenzte Zeit t. Bei sehr großen Werten von t kommt diese
Definition der Definition 1.2 sehr nahe. Bei sehr kleinen Werten von t ist sie bedeutungslos. Insofern hängt der Nutzen der Definition sehr vom konkreten Wert t
ab.
Eine letzte mögliche Definition lehnt sich an Begriffe aus der Kryptographie an.
Definition 1.5: Indistinguishable Obfuscator
D
Sei P eine Klasse von Programmen und seien P und Q aus P zwei unterscheidbare Programme. Der Obfuscator OBF heisst ununterscheidbar (engl. indistiguishable), falls OBF(P) und OBF(Q) nicht mehr unterscheidbar sind.
Diese Definition ist zwar stark abhängig von der Menge P, ist aber trotzdem noch
ganz gut handhabbar. Der Nachweis, dass OBF(P) und OBF(Q) nicht unterscheidbar sind, ist deutlich einfacher zu erbringen, als der Nachweis für einen Best Possible Obfuscator. Es existieren außerdem Klassen, mit deren Hilfe sich nachweislich
ununterscheidbare Programme erstellen lassen.
Point Functions
Q
Wir betrachten nun Beispiele solcher Klassen, mit denen man einen indistinguishable Obfuscator bauen kann. Basis für diese Klassen sind dabei die so genanntenPoint
Functions. Das sind Funktionen, die eine Eingabe bekommen und einen booleschen
Wert zurückliefern, der nur für eine ganz bestimmte Eingabe true zurückliefert
[Wee, 2005]. Beispiel für eine Point Function ist die folgende Funktion (in Pseudo
Code):
Quelltext 1.4
bool point_func(string pw){
if(pw == "secret"){
return true;
} else {
return false;
}
}
Die Funktion vergleicht den übergebenen Text mit dem Passwort “secret” und gibt
entsprechend wahr oder falsch aus. Diese Funktion ist allerdings nicht sicher in
Bezug auf ihre Verschleierung, da das Passwort „secret“ einfach aus dem Quelltext entnommen werden kann. In Kombination mit einer kryptografisch sicheren
Seite 39
Einwegfunktion lässt sich eine ununterscheidbare Obfuscation nach Definition 1.5
wie folgt konstruieren.
Quelltext 1.5
Q
bool indistinguishable_point_func(string pw){
if(hash(pw, SALT) == HASH){
return true;
} else {
return false;
}
}
Für eine sichere kryptografische Hash-Funktion (wie beispielsweise MD5) ist es
nicht effizient möglich, das Passwort aus dem Hash zu berechnen. Die beiden
Programme OBF(P) und OBF(Q) im nachfolgenden Beispiel sind im Sinne ihrer
Obfuscation nicht mehr zu unterscheiden, denn in beiden Fällen kann man nicht
effizient herausfinden, womit die Eingabe im Klartext verglichen wird.
Quelltext 1.6
Q
OBF(P):
if(md5(Input|Salt) ==
4cbe59a0e5f685fd48160888c568beab)
then true
else false;
OBF(Q):
if(md5(Input|Salt) ==
2f548f61bd37f628077e552ae1537be2)
then true
else false;
Weitere Beispiele für solche sicheren Kombinationen zur Verschleierung sind der
diskrete Logarithmus, der unter anderem beim Diffie-Hellman-Schlüsseltausch
verwendet wird, und die Faktorisierung, die die Grundlage für das Kryptosystem
RSA bildet.
Quelltext 1.7
//choose prime p and g < p-1
//k = g^c mod p with c constant
bool indistinguishable_point_func2(int x){
if(g^x mod p == k){
return true;
} else {
return false;
}
}
Q
Seite 40
Aus der Unentscheidbarkeit des Halteproblems folgt, dass Eigenschaften eines
Programms nicht allgemein effizient bestimmbar sind. Das bedeutet, dass Reverse
Engineering und Verschleierung individuell durchgeführt werden müssen, um
gute Ergebnisse zu erreichen. Dies wird in Abbildung 1.29 verdeutlicht. Zwar gibt
es sowohl Programme, deren Funktionalität verschleierbar ist, als auch Programme,
bei denen das nicht der Fall ist. Allerdings gibt es auch eine große Menge an
Programmen, bei denen unklar ist, ob sie verschleierbar sind oder nicht). Daraus
folgt, dass keine vollständige Automatisierung des Verschleierungsprozesses für
alle Programme möglich ist, bei der nicht die groben Strukturen des Algorithmus
enthalten sind oder größere Einschränkungen gemacht werden müssen. Praktisch
bedeutet das, dass man Obfuscation nicht für kryptografische Zwecke nutzen kann.
Es ist lediglich möglich das Reverse Engineering zu erschweren.
Abb. 1.29: Nachweisbarkeit für Obfuscation
1.6.2.3 Techniken
Im Nachfolgenden werden einige Verfahren zur Code-Verschleierung vorgestellt.
Inwieweit diese mit der Güte der Verschleierung zusammenhängen, wird im
nächsten Kapitel behandelt.
Umbenennen von Identifiern:
Das bloße Umbenennen von Bezeichnern erzeugt bereits eine verblüffend hohe
Verschleierungswirkung. Betrachten wir die folgenden beiden Code-Fragmente:
Q
Quelltext 1.8
for(int i = 0; i < size; ++i)
print(array[i]);
Q
Quelltext 1.9
for(int _$%& = 0; _$%& < _%$&; ++_$%&)
print(_&%$[_$%&)]);
Der erste Codeabschnitt ist deutlich lesbarer als der zweite. Im zweiten wurden
jedoch nur die Namen der Variablen ausgetauscht. Vor allem Sonderzeichen und
möglichst sinnlose und lange Zeichenketten eigenen sich gut als Ersatznamen.
Beliebt sind auch Hashes, etwa MD5 oder SHA1. Diese Technik macht jedoch
nur Sinn, wenn der eigentliche Kontrollfluss erhalten bleibt, wie etwa bei Java,
Javascript, Python etc.
Seite 41
Opaque Predicates:
Bedingungen, die immer nur einen Wert zurückliefern, heißen opake Prädikate
(Opaque Predicates). Wenn im Programmcode ein fester Wahrheitswert benötigt
wird, kann man diesen also durch ein möglichst kompliziertes opakes Prädikat
ersetzen. Betrachten wir wieder die folgenden beiden Code-Fragmente:
Quelltext 1.10
Q
if (b == true)
//...
Quelltext 1.11
Q
if (b == 2|(x^2 +x))
//...
Das opake Prädikat ist hierbei der Ausdruck “2|(x^2+x)”. Die beiden Programmfragmente sind auf das Ergebnis bezogen identisch, jedoch ist das Ergebnis der
zweiten Bedingung nicht einfach ersichtlich.
Bogus Control Flow / Dead Code:
Mit den Begriffen Bogus Control Flow und Dead Code bezeichnet man Verschleierungstechniken, die Programmabläufe suggerieren, die niemals genommen werden können. Beispielsweise wird der else-Zweig eines opaken Prädikates niemals
ausgeführt und enthält daher so genannten “toten” Code. Dies kann wiederum
genutzt werden, um den Quellcode künstlich zu vergrößern, ohne dass die Performance merklich eingeschränkt wird. Die folgenden beiden Code-Fragmente sind
gleichwertig. Das zweite ist aber schwerer zu verstehen als das erste:
Quelltext 1.12
Q
a();
b();
Quelltext 1.13
a();
if(opaque_true)
b();
else
deadcode();
Random Predicates:
Bei Random Predicates wird eine Verzweigung zufällig gewählt, jedoch danach
derselbe Code, unterschiedlich verschleiert, ausgeführt. Da der Code nach der
Q
Seite 42
Verschleierung stark verändert ist, fällt nicht auf, dass eigentlich dasselbe berechnet
wird.
Quelltext 1.14
Q
if(random){
OBF_1(b());
} else {
OBF_2(b());
}
Fake Loops:
dead code
Durch das Einfügen von zusätzlichen Schleifen, die nicht durchlaufen werden,
kann zusätzliche Verwirrung gestiftet werden. Die Performance bleibt auch annähernd gleich, da der Code-Rumpf der Schleife nie ausgeführt wird (dead code).
Nichtsdestotrotz fallen für die Schleife und insbesondere für verwendete Variablen
gewisse Kosten (im Sinne von Speicher und Rechenzeit) an.
Im Folgenden Quelltext-Beispiel wird zwar eine Schleife in den Code eingebaut.
Allerdings steigt der Programmfluss im ersten Schleifendurchlauf durch ein break
aus der Schleife aus. Dies ist durch die verschleierte Bedingung auf den ersten
Blick nicht klar. Für die (eigentlich unnötige) Variable i muss Speicher reserviert
werden.
Q
Quelltext 1.15
for(int i = 0; i < size; ++i){
if(OBF(true)){
break;
}
deadcode();
}
Verschlüsselung:
In der Praxis wird Code häufig verschlüsselt ausgeliefert und erst kurz vor der
Verwendung entschlüsselt. Steht zur Entschlüsselung keine Online-Verbindung
zur Verfügung, so muss der zur Entschlüsselung notwendige Schlüssel dem Programm mitgegeben werden, da dieses zur Laufzeit schließlich unverschlüsselt zur
Verfügung stehen muss. Der Schlüssel steckt zwar irgendwo im Programm drin,
doch er muss erst gefunden werden.
Gegen derartige Verfahren helfen meist nur Ansätze der dynamischen Analyse,
bei der sich der Code quasi “selbst entschlüsselt”. Dies wird in Abbildung 1.30
dargestellt. Links oben ist ein Code-Fragment abgebildet, das verschleiert werden
soll. Rechts unten ist der verschleierte Code angegeben. Die Abfrage der Bedingung
wird dabei durch den Vergleich von Hashes ersetzt. Wenn der Vergleich erfolgreich
war, wird der verschlüsselte Code zunächst entschlüsselt und dann mittels eval
aufgerufen.
Seite 43
Abb. 1.30: Nutzen von
Verschlüsselung zur Obfuscation
Merging von Funktionen bzw. Klassen:
Zwei Funktionen oder Klassen, die möglichst wenig miteinander zu tun haben, werden zu einer Funktion bzw. Klasse verschmolzen. Dadurch entsteht der Eindruck,
dass ihr Code zusammen gehört, weil sie über dieselbe Schnittstelle erreichbar
sind. In Wahrheit haben sie aber nichts miteinander zu tun. Der folgende Code
soll das verdeutlichen:
f l o a t foo [ 1 0 0 ] ;
void f ( i n t a , f l o a t b ) {
foo [ a ] = b ;
}
f l o a t g ( f l o a t c , char d ) {
return c ∗( f l o a t )d ;
}
i n t main ( void ) {
f (42 ,42.0);
float v = g(6.0 , 'a ' ) ;
return 0;
}
f l o a t foo [ 1 0 0 ] ;
Merge
Abb. 1.31: Merging von
Funktionen
void f g ( i n t a , f l o a t bc , char d , i n t w) {
i f (w == 1 ) {
foo [ a ] = bc ;
r e t u r n bc ∗ ( f l o a t ) d ;
}
i n t main ( void ) {
fg ( 4 2 , 4 2 . 0 , ' b ' , 1 ) ;
f l o a t v = fg ( 9 9 , 6 . 0 , ' a ' , 2 ) ;
return 0;
}
Im Beispiel werden die Funktionen f und g verschmolzen. Die Schnittstelle von
fg enthält nun einen zusätzlichen Parameter w, der darüber entscheidet, welche
Funktion ausgeführt werden soll.
Splitting von Funktionen bzw. Klassen:
Analog zur Verschmelzung von Funktionen bzw. Klassen ist auch das Umgekehrte
denkbar, nämlich das Aufteilen von Funktionen. Im Ergebnis wird der Zusammenhang der Codeteile verschleiert.
Abb. 1.32: Splitting von
Funktionen
Die Ausdrücke foo[a] = b und *(foo + a*sizeof(float)) = b sind gleichwertig, da ein Array lediglich einen zusammenhängenden Bereich im Speicher darstellt.
Es kann daher auch einfach der Pointer foo um a Einträge verschoben werden.
Seite 44
Zahlen „verschleiern“:
Zahlen und Berechnungen können durch Arithmetik, Lookup Tables und TeilHomomorphie vor dem Betrachter verborgen werden.
Ein Beispiel zur Zahlenverschleierung durch Arithmetik:
Quelltext 1.16
Q
y = x * 42;
//ebenso:
y = x << 5;
y += x << 3;
y += x << 1;
Ein Shift entspricht einer Multiplikation bzw. Division mit 2. Der Ausdruck x «
5 multipliziert x also fünfmal mit 2, also x · 25 . Das Ganze passiert in den Zeilen
darauf noch einmal analog. Insgesamt berechnet sich y daher wie folgt:
y = x · 25 + x · 23 + x · 21 = x · (25 + 23 + 2) = x · (32 + 8 + 2) = x · 42
lookup table
Tabelle 1.3: Abschätzung
Größe einer Lookup Table
Einfache Arrays, die Zahlenwerte speichern (lookup table), können Zahlen im Code ersetzen. So könnte z. B. statt 42 ein lt[10] oder lt[i] stehen. Allerdings ist
dies nur für kleine Werte und einfache Formeln sinnvoll. Tabelle 1.3 enthält eine
Abschätzung über die Größe und den Nutzen einer Lookup-Table unter verschiedenen Annahmen. Eine Funktion f (x, y) mit je 32-bit Werten würde als Lookup Table
also 236 GB benötigen, was eindeutig nicht umsetzbar für ein einzelnes Programm
ist.
Funktion
f(x,y)
f(x)
f(x)
f(x,y)
Werte
32-bit
23-bit
16-bit
8-bit
Summe
236 GB
16 GB
128 kB
64 kB
Wertung
zu viel
zu viel
okay
okay
Bei teil-homomorphen Funktionen wird ausgenutzt, dass bestimmte Aktionen
trotz Verschlüsselung noch möglich sind (siehe oben). Der folgende Quellcode
Seite 45
beschreibt einen “Trick”, um Zahlen zu verschleiern, so dass man trotzdem noch
auf ihnen rechnen kann.
Quelltext 1.17
Q
#define N (53*59) //Produkt zweier Primzahlen
int enc(int e, int p){
return p*N + e;
}
int dec(int e){
return e % N;
}
int encrypted_add(int a, int b){
return a + b;
}
int encrypted_mul(int a, int b){
Return a * b;
}
Zur Erläuterung: Betrachten Sie zunächst die Verschlüsselungsoperation enc. Die
zu verschleiernde Zahl ist die Eingabe e. Der Wert p ist ein “Verschleierungsfaktor”,
quasi ein Schlüssel, der e verschleiern soll. Die Verschleierung blendet e mit einem
Wert p*N.
Jetzt schauen Sie auf die Entschlüsselungsoperation dec: Hier wird der Blendfaktor
p durch die Modulo-Operation herausgerechnet, denn:
( p*N + e ) % N = e
Wenn man jetzt zwei solche verblendeten Zahlen in die Additions- bzw. Multiplikationsoperationen reinsteckt und anschliessend entschlüsselt, kommt tatsächlich
die Summe bzw. das Produkt der unverschleierten Zahlen heraus:
dec( encrypted_add( p1*N+e1, p2*N+e2 ) ) =
dec( p1*N+e1 + p2*N+e2) =
(p1*N + e1 + p2*N + e2) % N =
e1 + e2
Nachteil dieser Verschleierung von Zahlen ist, dass alle vorkommenden Zahlen
kleiner als N sein müssen, sonst kommt es zum Überlauf. Außerdem sind boolesche
Vergleiche nicht mehr möglich, da für eine Zahl durch die Modulo-Operation
mehrere Repräsentationen existieren.
Ein weiteres Beispiel fürTeil-Homomorphie ist RSA. RSA ist bzgl. der Multiplikation
homomorph, wie die folgenden Rechnungen zeigen:
E(x × y) = E(x) × E(y)
(1.4)
Teil-Homomorphie
Seite 46
RSA
Wie oben bereits beschrieben, bedeutet Teil-Homomorphie, dass die Multiplikation
mit zwei verschlüsselten Werten E(x) und E(y) dasselbe ergibt wie die Multiplikation der unverschlüsselten Werte x und y, die danach verschlüsselt werden, also
E(x × y). Dies kann man aus der Definition des RSA-Verfahrens ableiten:
n = p×q
e × d = 1 mod (p − 1)(q − 1)
(1.5)
(1.6)
Für den RSA-Algorithmus werden zuerst zwei ungleiche Primzahlen p und q
gewählt und aufmultipliziert (Formeln 1.5 und 1.6). Danach werden e und d so
gewählt, dass die Bedingung in Zeile zwei erfüllt ist. Die Werte e und d sind,
zusammen mit n, der öffentliche und der private Schlüssel.
RSA-Ver- und Entschlüsselung
C = M E mod n
(1.7)
d
(1.8)
M = C mod n
Nun kann verschlüsselt werden, indem die Nachricht M mit dem öffentlichen
Schlüssel e potenziert und modulo n genommen wird (Formeln 1.7 und 1.8). Entschlüsselung funktioniert analog, nur dass der private Schlüssel d verwendet
werden muss. Bei hinreichend großen Primzahlen p und q lassen sich keine Rückschlüsse von e auf d machen und umgekehrt.
RSA: Homomorphie
bzgl. Multiplikation
Die Homomorphie bzgl. der Multiplikation lässt sich nun wie folgt für zwei Nachrichten M1 und M2 beweisen (Formel 1.9).
(M1e mod n) × (M2e mod n) = (M1e × M2e ) mod n = (M1 × M2 )e mod n
(1.9)
Aliasing:
Aliasing lässt sich am besten anhand eines Beispielcodes nachvollziehen:
Q
Quelltext 1.18
int alias(int *a, int *b){
*a = 10;
*b = 5;
if((*a - *b) == 0)
code();
}
Die Funktion code() wird auf den ersten Blick niemals aufgerufen und ist toter
Code (dead code). Aber, wenn man folgenden Aufruf betrachtet, wird schnell klar,
dass code() doch aufgerufen werden kann.
Q
Quelltext 1.19
int a = 0;
alias(&a, &a);
Seite 47
Automatische Alias-Analyse ist ein NP-schweres Problem und kann daher nicht effizient gelöst werden. D. h. es ist nicht möglich, solche scheinbar nicht erreichbaren
Codeabschnitte automatisch zu finden.
Pointer Indirection:
Bei Pointer Indirektionen wird ein Pointer auf die entsprechende Stelle (Funktion,
Klasse, Variable) gesetzt und dieser statt dem eigentlichen Zugriff verwendet.
Betrachten wir ein Beispiel:
Quelltext 1.20
void
void
void
void
f()
g()
h()
k()
{
{
{
{
Q
}
f(); }
f(); g(); }
}
int main() {
h();
void (*p)() = &k;
p();
}
Um den Code zu analysieren, zeichnen wir den Aufrufgraphen. Im Aufrufgraph
sind die Funktionen die Knoten und es existiert eine Kante von Knoten a zu b,
wenn Funktion a im Quellcode Funktion b aufruft. Der Aufrufgraph ist abgebildet
in Abbildung 1.33. Wenn man sich das Beispiel anschaut, gibt es im Aufrufgraphen
auch einen Knoten für k, auf den aber keine Kante zeigt. Man hat auch p als Knoten,
auf den eine Kante aus main() zeigt, aber p ruft im Quellcode niemanden auf.
Wenn man aber den Code genauer anschaut, dann wird p als Funktionspointer
definiert und auf k “umgebogen”. Im Endeffekt wird also doch k aufgerufen, obwohl im Quellcode kein “normaler” Aufruf existiert (normal im Sinne der anderen
Aufrufe, die im Beispiel stehen).
Stellen Sie sich vor, der Pointer &k wäre noch irgendwie verschleiert, beispielsweise
mittels eines opaken Prädikates. Dann sieht man, dass es auch für automatische
Tools schwer wird, den “wahren” Aufrufgraphen zu erstellen.
k
Abb. 1.33: Aufrufgraph
des Beispiels zu Pointer
Indirection
g
h
f
main
p
Control Flow Flattening (chenxify):
Indem man Rekursionen und Schleifen ausrollt und bedingte Verzweigungen, z.
B. durch einen switch/next, abflacht, kann die Code-Komplexität erhöht werden.
Der folgende Quelltext zeigt ein Beispiel:
Seite 48
Abb. 1.34: Control
Flow Flattening
Die switch-Anweisung wird hier mehrfach rekursiv aufgerufen, wobei next den
nächsten Abschnitt definiert, der aufgerufen werden soll. Alle Codeabschnitte
müssen daher den Wert neu setzen.
Selbstmodifizierender Code:
Eine besonders raffinierte Verschleierungsspielart ist selbstmodifizierender Code.
Da das in einer Hochsprache schwer zu machen ist, ist das Beispiel in Assembler
(siehe Modul 15, Reverse Engineering). Betrachten Sie den statischen Kontrollflussgraphen des Codes in Abbildung 1.35, den tools wie z.B. IDA erzeugen. In
Abbildung 1.35 hat man ein Stück Assemblercode, der offenbar in einer Endlosschleife endet: In Adresse 14 wird immer direkt nach Adresse 9 gesprungen.
Adresse 16 wird niemals angesprungen.
Wenn man aber den Code ausführt, dann passiert doch etwas anderes: In Adresse
0 wird der Wert 12 in Register r0 geladen. In Adresse 3 der Wert 4 in Register r1.
Nun passiert das “Wunder” des selbstmodifizierenden Codes: in Zeile 6 wird der
Inhalt von r1 (also 4) an die Adresse geschrieben, die in Register r1 steht (also
12). An Adresse 12 steht aber der Opcode des Befehls inc r4 (siehe Abbildung
1.35). Durch die store-Operation wird aus dem Opcode 3 der Opcode 4. Nun steht
im Speicher also nicht mehr inc r4 sondern bra 4, was in Abbildung 1.36 dann
dargestellt ist.
Das Programm hat sich also selbst verändert. Solche Veränderungen sind statisch
(also ohne das Programm auszuführen) sehr schwer vorherzusehen und deswegen
sehr wirksam zur Obfuskierung.
Abb. 1.35: Statischer
CFG eines selbst modifizierenden Programms
Seite 49
Abb. 1.36: Dynamischer
Fluss dieses Programms
Unaligned Branches/Jumps:
Man kann Disassembler gezielt stören, indem man scheinbar “unsinnige” Sprungziele angibt, die trotzdem sinnvoll sein können. Das folgende Beispiel soll das
verdeutlichen:
Quelltext 1.21
main:
jmp entry;
db "obf"
entry:
...
Q
;disturb alignment
;code ...
Disassembler werden durch das obf im Hexdump gestört, sodass die Ausrichtung
nicht mehr stimmt und ein bestimmter Bereich um die Stelle falsch interpretiert
wird (siehe Abbildung 1.37: grün der richtige Code und rot der disassemblierte
Code).
Abb. 1.37: Disassembler
schlägt fehl
Seite 50
Interpretationsschicht bzw. VM-basiert:
VM-basierte Verschleierung führt eine eigene Interpretationsschicht in die Programmumgebung ein. Diese Interpretationsschicht verarbeitet Register, Stack,
Stack Pointer und das eigentliche Programm, welche als Variablen enthalten ist
(siehe Abbildung 1.38). Es wird so eine zusätzliche Indirektion eingeführt. Bevor
der eigentliche Code offengelegt werden kann, muss so vorher die Zwischenschicht
durch Reverse Engineering nachvollzogen werden. Diese Zwischenschicht könnte
sogar auf einer eigenen, pseudo-zufälligen Sprache basieren. Zusätzliche Komplexität lässt sich durch weitere Stufen erreichen (geschachtelte virtuelle Maschinen).
Abb. 1.38: VMbasierte Obfuscation
Remote-Execution:
Wichtige Code-Teile werden entfernt und beispielsweise mittels PHP auf einem
entfernten Rechner ausgeführt. Gerade bei Internet-Anwendungen oder Webseiten
(Javascript) ist diese Technik einfach umsetzbar.
Sonstige Obfuscation-Techniken:
Junk Code
Q
Es gibt eine Vielzahl weiterer Verschleierungstechniken. Arrays und Strings können
beispielsweise durch einfaches Permutieren oder Splitten ihren Inhalt verschleiern.
Weiterhin könnte sogenannterJunk Code eingefügt werden, also Code der eigentlich
nichts bewirkt, wie folgendes Beispiel zeigt:
Quelltext 1.22
a += 2;
a--;
--a;
Es existieren viele weitere Möglichkeiten den Code weiter zu verschleiern, beliebt
sind auch Kombinationen von Methoden, die das Nachvollziehen der Programmabläufe weiter erschweren. Nachdem meist ein Obfuscation-Programm zum
Einsatz kommt und dies nicht manuell durchgeführt wird, können diesem Tool
mehrere Verfahren übergeben werden, die dann nacheinander oder durcheinander
mehrfach ausgeführt werden können.
Seite 51
1.6.2.4 Güte der Obfuscation
Als Maß für die Obfuscation können aus der Softwareentwicklung bekannte Merkmale wiederverwendet werden. Sie sind jedoch gegenteilig zu verstehen bzw.
anzuwenden, für Software negative Effekte sind bei Obfuscation unter Umständen durchaus erwünscht. Tabelle 1.4 listet einige Komplexitätsmaße, die man zur
Bewertung der Güte einer Verschleierung verwenden kann.
1)
2)
3)
Program Length:
Cyclomatic Complexity:
Nesting Complexity:
4)
Data Flow Complexity:
5)
6)
IO-Complexity:
Data Structure Complexity:
7)
Callgraph Complexity usw.
Anzahl der Operationen
Anzahl linear unabhängiger Pfade in P
Verschachtelungs-Level von Abhängigkeiten
Anzahl der Referenzen zwischen BasicBlocks
Anzahl Ein/Ausgabe Parameter
Anzahl/Größe statischer Datenstrukturen
Allerdings ist bei allen diesen Maßen nicht klar, inwieweit sie mit dem menschlichen Verständnis des Codes korrelieren.
In diesem Abschnitt wurden verschiedene Ansätze zur Verschleierung als AntiForensik-Maßnahme gezeigt. Obgleich der Vielfalt hier kaum Grenzen gesetzt
sind, wurde ein grundlegendes Verständnis für die Problematik entwickelt, das in
einem konkreten Fall adaptiert werden kann. Tiefergehende Techniken im Bereich
des Reverse Engineering zur Erfassung der Funktionalität einer verdächtigen
Binärdatei werden in Modul 15 (Reverse Engineering) vertiefend behandelt.
Im Gegensatz zur statischen Analyse, bei der Code-Verschleierung schon mit
einfachen Mitteln gut umsetzbar ist, ist die dynamische Analyse vergleichsweise
schwerer zu verhindern, da sie auf dem reinen I/O-Verhalten des Programms
basiert. Nichtsdestotrotz existieren auch Techniken, wie z. B. INT 3-Erkennung,
Exception Handler oder “Sich-Selbst-Debuggen”, um die dynamische Analyse zu
erschweren. Auch dies wird in Modul 15 (Reverse Engineering) näher behandelt.
Tabelle 1.4: Merkmale für
die Güte der Obfuscation
Verzeichnisse
Seite 53
Verzeichnisse
I. Abbildungen
Abb. 1.1:
Abb. 1.2:
Abb. 1.3:
Abb. 1.4:
Abb. 1.5:
Abb. 1.6:
Abb. 1.7:
Abb. 1.8:
Abb. 1.9:
Abb. 1.10:
Abb.
Abb.
Abb.
Abb.
Abb.
1.11:
1.12:
1.13:
1.14:
1.15:
Abb. 1.16:
Abb. 1.17:
Abb. 1.18:
Abb. 1.19:
Abb. 1.20:
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
1.21:
1.22:
1.23:
1.24:
1.25:
1.26:
1.27:
1.28:
1.29:
1.30:
1.31:
1.32:
1.33:
1.34:
1.35:
1.36:
1.37:
1.38:
Grum-Botnetz Wertschöpfungskette [Levchenko et al., 2011, Fig. 1] . . . . . . . . . . . . . .
9
Ablauf der Spam-Analyse [Levchenko et al., 2011, Fig. 2] . . . . . . . . . . . . . . . . . . . . 10
Aufteilung der Spam-Produkte [Levchenko et al., 2011, Tab. III] . . . . . . . . . . . . . . . . 11
Kategorisierung nach Vertriebsprogrammen [Levchenko et al., 2011, Tab. IV] . . . . . . . . . 12
Verteilung von Vertriebsprogrammen auf Banken [Levchenko et al., 2011, Tab. V] . . . . . . 13
Folgen der Abschaltung bestimmter Elemente der Spam-Industrie [Levchenko et al., 2011, Fig. 5] 13
Beispiele von gespeicherten Cookies [Berghel, 2008] . . . . . . . . . . . . . . . . . . . . . . 15
Ist ein Zustand aus früheren public Modi im privaten Modus erreichbar? [Aggarwal et al., 2010,
Tab. 1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Ist ein Zustand aus früheren privaten Modi im public Modus erreichbar? [Aggarwal et al., 2010,
Tab. 2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Ist ein Zustand an einem bestimmten Punkt einer privaten Session später wieder erreichbar
innerhalb derselben privaten Session? [Aggarwal et al., 2010, Tab. 3] . . . . . . . . . . . . . 18
Serverseitig verfügbare Browser-Infos [Eckersley, 2010, Tab. 1] . . . . . . . . . . . . . . . . 19
Eindeutigkeit von Browser-Fingerprints [Eckersley, 2010, Fig. 1] . . . . . . . . . . . . . . . . 20
Word-Metadaten des Irak-Dossiers [Berghel, 2008] . . . . . . . . . . . . . . . . . . . . . . . 21
Beispiele für rekonstruierte Bilder [Murdoch and Dornseif, 2004] . . . . . . . . . . . . . . . . 22
Beispiel für ein vermeintlich anonymes Bild im Internet (Kategorie „Ausschneiden zum Identitätsschutz“) Murdoch and Dornseif [2004] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Bild aus Abbildung 1.15 nach Wiederherstellung mittels Thumbnail [Murdoch and Dornseif, 2004] 23
Weiteres Beispiel aus der Kategorie „Ausschneiden zum Identitätsschutz“ [Murdoch and
Dornseif, 2004] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Bild aus Abbildung 1.17 nach Wiederherstellung mittels Thumbnail [Murdoch and Dornseif, 2004] 24
Überwachungsmaßnahmen der Telekommunikation (Bundesnetzagentur, zitiert nach Spreitzenbarth [2009]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Anzahl sichergestellte Mobiltelefone beim BKA, Abteilung TESIT-6 (BKA, zitiert nach Spreitzenbarth [2009]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Aufbau einer SMS Spreitzenbarth [2009] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Detaillierter Aufbau einer SMS [Spreitzenbarth, 2009] . . . . . . . . . . . . . . . . . . . . . 26
Anzahl Smartphones nach Typ (zitiert nach Spreitzenbarth [2009] . . . . . . . . . . . . . . . 27
ADEL-Bewegungsprofil [Spreitzenbarth and Schmitt., 2012] . . . . . . . . . . . . . . . . . . 29
Control Flow Graph des Java-Programmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Kontrollflussgraph während Dead Code Elimination . . . . . . . . . . . . . . . . . . . . . . . 33
Vereinfachter Kontrollflussgraph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Obfuscator [Collberg and Nagra, 2009] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Nachweisbarkeit für Obfuscation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Nutzen von Verschlüsselung zur Obfuscation . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Merging von Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Splitting von Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Aufrufgraph des Beispiels zu Pointer Indirection . . . . . . . . . . . . . . . . . . . . . . . . . 47
Control Flow Flattening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Statischer CFG eines selbst modifizierenden Programms . . . . . . . . . . . . . . . . . . . . 48
Dynamischer Fluss dieses Programms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Disassembler schlägt fehl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
VM-basierte Obfuscation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
II. Beispiele
Beispiel 1.1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
Seite 54
Verzeichnisse
III. Definitionen
Definition
Definition
Definition
Definition
Definition
1.1:
1.2:
1.3:
1.4:
1.5:
Obfuscator . . . . . . . . . .
Virtual Black Box Obfuscator
Best Possible Obfuscator . .
t -Obfuscator . . . . . . . . .
Indistinguishable Obfuscator
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
37
37
37
38
38
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
16
17
18
20
Vergleich Mobiltelefon vs. Smartphone
Reverse Engineering Tools . . . . . . .
Abschätzung Größe einer Lookup Table
Merkmale für die Güte der Obfuscation
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
26
31
44
51
IV. Kontrollaufgaben
Kontrollaufgabe
Kontrollaufgabe
Kontrollaufgabe
Kontrollaufgabe
1.1
1.2
1.3
1.4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
V. Tabellen
Tabelle
Tabelle
Tabelle
Tabelle
1.1:
1.2:
1.3:
1.4:
VI. Literatur
Gaurav Aggarwal, Elie Bursztein, Collin Jackson, and Dan Boneh. An analysis of private browsing modes in
modern browsers. In USENIX Security Symposium, pages 79–94, 2010.
Hal Berghel. Brap forensics. Commun. ACM, 51(6):15–20, 2008.
Simon Byers. Information leakage caused by hidden data in published documents. IEEE Security and Privacy,
2(2):23–27, March 2004. ISSN 1540-7993. doi: 10.1109/MSECP.2004.1281241. URL http://dx.doi.org/10.
1109/MSECP.2004.1281241.
Christian Collberg and J. Nagra. Surreptitious Software: Obfuscation, Watermarking and Tamperproofing. AddisonWesley, 2009.
S. Drape. Obfuscation of Abstract Data-Types. Oxford: University of Oxford, 2004.
Peter Eckersley. How unique is your web browser? In Proceedings of the 10th international conference on Privacy
enhancing technologies, PETS’10, pages 1–18, Berlin, Heidelberg, 2010. Springer-Verlag. ISBN 3-642-14526-4,
978-3-642-14526-1. URL http://dl.acm.org/citation.cfm?id=1881151.1881152.
Felix Freiling, Sven Schmitt, and Michael Spreitzenbarth. Forensic analysis of smartphones: The android
data extractor lite (adel). In Proceedings of the 2011 ADFSL Conference on Digital Forensics, Security and Law,
pages 151–161, 2011.
Chris Kanich, Christian Kreibich, Kirill Levchenko, Brandon Enright, Geoffrey M. Voelker, Vern Paxson, and
Stefan Savage. Spamalytics: an empirical analysis of spam marketing conversion. In Proceedings of the 15th ACM
conference on Computer and communications security, CCS ’08, pages 3–14, New York, NY, USA, 2008. ACM. ISBN
978-1-59593-810-7. doi: 10.1145/1455770.1455774. URL http://doi.acm.org/10.1145/1455770.1455774.
Kirill Levchenko, Andreas Pitsillidis, Neha Chachra, Brandon Enright, Márk Félegyházi, Chris Grier, Tristan Halvorson, Chris Kanich, Christian Kreibich, He Liu, Damon McCoy, Nicholas Weaver, Vern Paxson, Geoffrey M. Voelker, and Stefan Savage. Click trajectories: End-to-end analysis of the spam value
chain. In Proceedings of the 2011 IEEE Symposium on Security and Privacy, SP ’11, pages 431–446, Washington, DC, USA, 2011. IEEE Computer Society. ISBN 978-0-7695-4402-1. doi: 10.1109/SP.2011.24. URL
http://dx.doi.org/10.1109/SP.2011.24.
Literatur
Seite 55
Anirban Majumdar and C. Thomborson. A Survey of Control-Flow Obfuscations. Berlin Heidelberg: Springer
Verlag, 2006.
Steven Murdoch and Maximillian Dornseif. Hidden data in interned published documents, 2004.
Michael Spreitzenbarth.
Mobile phone forensics.
Diplomarbeit, Universität Mannheim,
2009.
Retrieved 2012-04-04 from http://pi1.informatik.uni-mannheim.de/filepool/theses/
diplomarbeit-2009-spreitzenbarth.pdf.
Michael Spreitzenbarth and S. Schmitt. Forensic acquisition of location data on android smartphones, 2012.
Michael Spreitzenbarth, Sven Schmitt, and Christian Zimmermann. Reverse engineering of the android file
system. Technischer bericht, Friedrich-Alexander-Universität, Department Informatik, 2011. Online verfügbar unter http://www.opus.ub.uni-erlangen.de/opus/frontdoor.php?source_opus=2833, letzter Zugriff:
2012-04-04.
Zeljko Vrba and P. Halvorsen. Program obfuscation by strong cryptography. Oslo: University of Oslo, 2010.
H. Wee. On Obfuscating Point Functions. California: University of California, 2005.
Bernd Wientjes. Prozess: Junge studentin im todeskampf, ex-freund googelte: “rote augen tot”. Trierer
Volksfreund, January 2011.
G. Wroblewski. General Method of Program Code Obfuscation. Wroclaw, 2002.
Christian Zimmermann and Michael Spreitzenbarth. Forensic analysis of yaffs2. In Tagungsband der Konferenz
“SICHERHEIT — Schutz und Zuverlässigkeit” des Fachbereichs Sicherheit der Gesellschaft für Informatik, 2012.

Browser- und Anwendungsforensik - IT

Transcription

Similar documents

Systemnahe Programmierung [Sysprog] - IT

Präsentation

Automatische Web-History Analyse

Seminar P2P im Wintersemester 2011 - P2P Networks

Was müssen Sie über Citymautgebühren wissen?