Browser- und Anwendungsforensik. Autoren: Prof. Dr.-Ing. Felix C. Freiling Dr.-Ing. Andreas Dewald. Friedrich-Alexander Universität Erlangen-Nürnberg

Transkript

1 Browser- und Anwendungsforensik Autoren: Prof. Dr.-Ing. Felix C. Freiling Dr.-Ing. Andreas Dewald Friedrich-Alexander Universität Erlangen-Nürnberg

2

3 Modul Browser- und Anwendungsforensik Studienbrief 1: Einführung in die Browser- und Anwendungsforensik Autoren: Prof. Dr.-Ing. Felix C. Freiling Dr.-Ing. Andreas Dewald 1. Auflage Friedrich-Alexander Universität Erlangen-Nürnberg

4 2015 Friedrich-Alexander Universität Erlangen-Nürnberg Erlangen 1. Auflage (24. März 2015) 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.

5 Inhaltsverzeichnis Seite 3 Inhaltsverzeichnis Einleitung zu den Studienbriefen 4 I. Abkürzungen der Randsymbole und Farbkodierungen II. Zu den Autoren III. Modullehrziele Studienbrief 1 Einführung in die Browser- und Anwendungsforensik Lehrziele Advanced Organizer Einführung Beispiel 1: Tötung durch Unterlassen Beispiel 2: Die globale Spam-Industrie Ausblick Browser- und Anwendungsforensik(BRAP) Browserforensik Anwendungsforensik Zusammenfassung Mobilfunkforensik Zugriff auf Smartphones und Mobiltelefone Smartphones: Überblick über die Systeme Root-Zugriff und Datenanalyse bei Android Android-Forensik mit ADEL Zusammenfassung Verschleierungstechniken Reverse Engineering Verschleierungstechniken zum Anti Reverse Engineering Zusammenfassung Verzeichnisse 53 I. Abbildungen II. Beispiele III. Definitionen IV. Kontrollaufgaben V. Tabellen VI. Literatur

6 Seite 4 Einleitung zu den Studienbriefen Einleitung zu den Studienbriefen I. Abkürzungen der Randsymbole und Farbkodierungen Beispiel Definition Kontrollaufgabe Quelltext B D K Q

7 Zu den Autoren Seite 5 II. Zu den Autoren Felix Freiling ist seit Dezember 2010 Inhaber des Lehrstuhls für IT- Sicherheitsinfrastrukturen an der Friedrich-Alexander-Universität Erlangen- Nürnberg. Zuvor war er bereits als Professor für Informatik an der RWTH Aachen ( ) und der Universität Mannheim ( ) 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.

8 Seite 6 Einleitung zu den Studienbriefen III. Modullehrziele Was wird Ihnen in diesem Modul vermittelt? Ein Großteil der Systeminteraktion erfolgt heute durch Anwendungsprogramme wie Browser, -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 -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.

9 Studienbrief 1 Einführung in die Browser- und Anwendungsforensik Seite 7 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 Live- Analyse (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 Michael Spreitzenbarth und Tilo Müller für Vorarbeiten zu den Abschnitten 1.5 und Einführung Ein Großteil der Systeminteraktion erfolgt heute durch Anwendungsprogramme wie Browser, -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 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. 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

10 Seite 8 Studienbrief 1 Einführung in die Browser- und Anwendungsforensik 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 Beispiel 2: Die globale Spam-Industrie Unter Spam versteht man Massen- s, 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 -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 s 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 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 dank der erfolgreichen Verbreitung von internetbasierten Vertriebsprogrammen wie pay-per-click, pay-per-lead, pay-per-sale usw.

11 1.3 Einführung Seite 9 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 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 Tage später trifft das Produkt per Post ein. Die Absenderadresse liegt in Indien. Dieses Beispiel verdeutlicht die Arbeitsteilung: Botnetz, Proxy, Pharmacy Express- Webseite, (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.

12 Seite 10 Studienbrief 1 Einführung in die Browser- und Anwendungsforensik Abb. 1.2: Ablauf der Spam-Analyse [Levchenko et al., 2011, Fig. 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.

13 1.3 Einführung Seite Diese Eingaben wurden verarbeitet und dabei die eingebundenen URLs extrahiert. Dies geschah mittels automatischen Parsern, die die HTML- Nachrichten 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 Spam- Industrie 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 Pharmacy Software Replicas Total URLs 346,993,046 3,071,828 15,330, ,395,278 Domains 54,220 7,252 7,530 69,002 Web clusters ,039 Programs 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. Abb. 1.3: Aufteilung der Spam-Produkte [Levchenko et al., 2011, Tab. III] content clustering

14 Seite 12 Studienbrief 1 Einführung in die Browser- und Anwendungsforensik sink feeds Abb. 1.4: Kategorisierung nach Vertriebsprogrammen [Levchenko et al., 2011, Tab. IV] 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 jedoch nur Spam aussink feeds, d. h. Botnetz-Quellen wurden herausgelassen, um normale -Konten besser zu repräsentieren. Für die Zuordnung wurden manuelle Filter erstellt, die die Webseiteninhalte der Programme abbilden. Affiliate Distinct Received Feed Program Domains URLs Volume RxPrm RX Promotion 10, ,521, % Mailn Mailien 14,444 69,961, % PhEx Pharmacy Express 14,381 69,959, % EDEx ED Express 63 1, % ZCashPh ZedCash (Pharma) 6,976 42,282, % DrMax Dr. Maxman 5,641 32,184, % Grow Viagrow 382 5,210, % USHC US HealthCare 167 3,196, % MaxGm MaxGentleman 672 1,144, % VgREX VigREX , % Stud Stud Extreme 42 68, % ManXt ManXtenz 33 50, % GlvMd GlavMed 2,933 28,313, % OLPh Online Pharmacy 2,894 17,226, % Eva EvaPharmacy 11,281 12,795, % WldPh World Pharmacy ,412, % PHOL PH Online 101 2,971, % Aptke Swiss Apotheke 117 1,586, % HrbGr HerbalGrowth , % RxPnr RX Partners , % Stmul Stimul-cash , % Maxx MAXX Extend , % DrgRev DrugRevenue , % UltPh Ultimate Pharmacy 12 44, % Green Greenline 1,766 25, % Vrlty Virility 9 23, % RxRev RX Rev Share 299 9, % Medi MediTrust 24 6, % ClFr Club-first 1,270 3, % CanPh Canadian Pharmacy 133 1, % RxCsh RXCash <0.01% Staln Stallion 2 80 <0.01% Total 54, ,993, % Royal Royal Software 572 2,291, % EuSft EuroSoft 1, , % ASR Auth. Soft. Resellers 4,117 65, % OEM OEM Soft Store 1,367 19, % SftSl Soft Sales <0.01% Total 7,252 3,071, % ZCashR ZedCash (Replica) 6,984 13,243, % UltRp Ultimate Replica 5,017 10,451, % Dstn Distinction Replica 127 1,249, % Exqst Exquisite Replicas , % DmdRp Diamond Replicas 1, , % Prge Prestige Replicas , % OneRp One Replica 77 20, % Luxry Luxury Replica 25 8, % AffAc Aff. Accessories 187 3, % SwsRp Swiss Rep. & Co <0.01% WchSh WatchShop 546 2,086, % Total 7,530 15,330, % Grand Total 69, ,395, % 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).

15 1.3 Einführung Seite 13 Bank Name BIN Country Affiliate Programs Azerigazbank Azerbaijan GlvMd, RxPrm, PhEx, Stmul, RxPnr, WldPh B&N Russia ASR B&S Card Service Germany MaxGm Borgun Hf Iceland Trust Canadian Imperial Bank of Commerce Canada WldPh Cartu Bank Georgia DrgRev DnB Nord (Pirma) Latvia Eva, OLPh, USHC Latvia Savings Latvia EuSft, OEM, WchSh, Royal, SftSl Latvijas Pasta Banka Latvia SftSl St. Kitts & Nevis Anguilla National Bank St. Kitts & Nevis DmdRp, VgREX, Dstn, Luxry, SwsRp, OneRp State Bank of Mauritius Mauritius DrgRev Visa Iceland Iceland Staln Wells Fargo USA Green Wirecard AG Germany ClFr Abb. 1.5: Verteilung von Vertriebsprogrammen auf Banken [Levchenko et al., 2011, Tab. V] Abb. 1.6: Folgen der Abschaltung bestimmter Elemente der Spam- Industrie [Levchenko et al., 2011, Fig. 5] 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, 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 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

16 Seite 14 Studienbrief 1 Einführung in die Browser- und Anwendungsforensik Teilbereichs der Anwendungsforensik. Abschließend geben wir eine kurze Einführung in Verschleierungstechniken, die die Analyse proprietärer Datenformate und Software erschweren sollen. 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 Festplatten- Images 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 Browser- Forensik 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 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 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

17 1.4 Browser- und Anwendungsforensik(BRAP) Seite 15 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). Figure1a. ExampleWebTrends cookie. 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. Aller- le ti b ri p H (I B re a sh co p IE cl d B Abb. 1.7: Beispiele von gespeicherten Cookies [Berghel, 2008] private browsing

18 Seite 16 Studienbrief 1 Einführung in die Browser- und Anwendungsforensik Abb. 1.8: Ist ein Zustand aus früheren public Modi im privaten Modus erreichbar? [Aggarwal et al., 2010, Tab. 1] FF Safari Chrome IE History no yes no no Cookies no yes no no HTML5local storage no yes no no Bookmarks yes yes yes yes Password database yes yes yes yes Formautocompletion yes yes yes no User approved SSL self-signed cert yes yes yes yes Downloaded items list no yes yes n/a Downloaded items yes yes yes yes Search box search terms yes yes yes yes Browser s web cache no no no no Client certs yes yes yes yes Customprotocol handlers yes n/a n/a n/a Per-sitezoomlevel no n/a yes n/a Abb. 1.9: Ist ein Zustand aus früheren privaten Modi im public Modus erreichbar? [Aggarwal et al., 2010, Tab. 2] FF Safari Chrome IE History no no no no Cookies no no no no HTML5Local storage no no no no Bookmarks yes yes yes yes Password database no no no no Formautocompletion no no no no User approved SSL self-signed cert no yes yes yes Downloaded items list no no no n/a Downloaded items yes yes yes yes Search box search terms no no no no Browser s web cache no no no no Client certs yes n/a n/a yes Customprotocol handlers yes n/a n/a n/a Per-sitezoomlevel no n/a no n/a

19 1.4 Browser- und Anwendungsforensik(BRAP) Seite 17 dings lässt sich daraus, bei einer hinreichenden Anzahl an neuen Bookmarks und Downloads, ohne Probleme der Browserverlauf nachvollziehen. FF Safari Chrome IE History no no no no Cookies no no no no HTML5Local storage no no no no Bookmarks yes yes yes yes Password database no no no no Formautocompletion no no no no User approved SSL self-signed cert no yes yes yes Downloaded items list no no no n/a Downloaded items yes yes yes yes Search box search terms no no no no Browser s web cache no no no no Client certs yes n/a n/a yes Customprotocol handlers yes n/a n/a n/a Per-sitezoomlevel no n/a no n/a Innerhalb einer private session sollen möglichst wenig persistente Spuren auf der Festplatte hinterlassen werden. Inkonsistent ist hier bei allen Browsern der Verlauf. 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. 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] Web Cache Swap-File Kontrollaufgabe 1.1 Überprüfen Sie eine der Erkenntnisse von Aggarwal et al. [2010] aus Abbildung 1.10 in der aktuellen Version Ihres eigenen Browsers. K 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. 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 whitelist Fingerprinting

20 Seite 18 Studienbrief 1 Einführung in die Browser- und Anwendungsforensik 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 die Zeitzone, Bildschirmauflösung, Browser Plugins mit Versionsnummer und 5 Systemschriftarten (siehe Abbildung 1.11).. Abb. 1.11: Serverseitig verfügbare Browser-Infos [Eckersley, 2010, Tab. 1] V ariable Source R emarks User Agent Transmitted by HT T P, Contains Browser micro-version, OS logged by server version, language, toolbars and sometimes other info. HT T P ACCEPT headers Transmitted by HT T P, logged by server Cookies enabled? Inferred in HT T P, logged by server Screen resolution J avascript AJ AX post T imezone J avascript AJ AX post Browser plugins, plugin versions and MIME types System fonts Partial supercookie test 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. Anonymitätsmenge Eckersley [2010] hat dieses Phänomen im Rahmen des Projekts Panopticlick untersucht. Dazu brachte er mehr als Benutzer dazu, die Webseite http: //panopticlick.eff.org zu besuchen. Von diesen Besuchern wurde der Browser- Fingerprint genommen. Das Ergebnis der Untersuchung zeigt Abbildung 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. 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 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 ).

21 1.4 Browser- und Anwendungsforensik(BRAP) Seite 19 Abb. 1.12: Eindeutigkeit von Browser-Fingerprints [Eckersley, 2010, Fig. 1] Kontrollaufgabe 1.2 Besuchen Sie die Seite und testen Sie die Einzigartigkeit Ihres Browsers. Unter wievielen Browser-Fingerprints ist ihr Browser identifizierbar? K 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 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.

22 Seite 20 Studienbrief 1 Einführung in die Browser- und Anwendungsforensik 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. Abb. 1.13: Word- Metadaten des Irak- Dossiers [Berghel, 2008] 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

23 1.4 Browser- und Anwendungsforensik(BRAP) Seite 21 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. Abhilfe. In neuen Versionen von Microsoft Word hat man auf die Gefahren versteckter Informationen reagiert und bietet Funktionen wie Für Freigabe vorbereiten an. 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. K Geschwärzte PDF-Dokumente Ein weiteres gängiges Format für Texte aller Art sind PDF-Dateien. Das PDF- Format 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 1 Das Dossier wurde für die Nachwelt online archiviert und war am unter org.uk/discuss/2003/msg00457.html verfügbar. Eine ausführliche Diskussion findet sich auch auf der folgenden Webseite: (aufgerufen am ).

24 Seite 22 Studienbrief 1 Einführung in die Browser- und Anwendungsforensik 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 Thumbnails in Bildern Thumbs.db 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 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. Abb. 1.14: Beispiele für rekonstruierte Bilder [Murdoch and Dornseif, 2004] Die Abbildungen 1.15 und 1.16 bzw und 1.16 zeigen, welche Informationen 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.

25 1.4 Browser- und Anwendungsforensik(BRAP) Seite 23 Abb. 1.15: Beispiel für ein vermeintlich anonymes Bild im Internet (Kategorie Ausschneiden zum Identitätsschutz ) Murdoch and Dornseif [2004] 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]

26 Seite 24 Studienbrief 1 Einführung in die Browser- und Anwendungsforensik Abb. 1.18: Bild aus Abbildung 1.17 nach Wiederherstellung mittels Thumbnail [Murdoch and Dornseif, 2004] 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 Online- Aktivitä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 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. 1.5 Mobilfunkforensik 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 s 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

27 1.5 Mobilfunkforensik Seite 25 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 nun mit diesem Thema auseinandersetzen. Zu Beginn werden die Zugriffsmöglichkeiten dargestellt. Danach folgen kursorische Abschnitte zu den Smartphone- Betriebssystemen 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]) Abb. 1.20: Anzahl sichergestellte Mobiltelefone beim BKA, Abteilung TESIT-6 (BKA, zitiert nach Spreitzenbarth [2009])

28 Seite 26 Studienbrief 1 Einführung in die Browser- und Anwendungsforensik 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ätzungsweise ). 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. JTAG-Schnittstelle Software Agents 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 Hardware- Debug-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 Shadow- Datenbank 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 Software- Lö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 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 2 Mehr Informationen zu JTAG sind unter zu finden. 3 Mehr Informationen zu adb finden Sie unter tools/adb.html.

29 1.5 Mobilfunkforensik Seite 27 (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 um 20:04:49 Uhr von der Nummer 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] 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 PC- Betriebssystemen eine eher untergeordnete Rolle (siehe Abbildung 1.23). In den folgenden Unterkapiteln werden nun einige dieser Systeme kursorisch vorgestellt 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.

30 Seite 28 Studienbrief 1 Einführung in die Browser- und Anwendungsforensik Abb. 1.23: Anzahl Smartphones nach Typ (zitiert nach Spreitzenbarth [2009] 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 nochmals auf dieses Thema zurückkommen (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 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 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-

31 1.5 Mobilfunkforensik Seite 29 ä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). Der interne Flash-Speicher ist in der Regel mit einem YAFFS2- oder EXT4- Dateisystem 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 GPS- Koordinaten, 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. Garbage- Collection 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 ALLO- CATING, 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 Struktur der Daten Dalvik Debug Monitor Server Wear-Levelling Chunks Bad Blocks

32 Seite 30 Studienbrief 1 Einführung in die Browser- und Anwendungsforensik log-structured file system einem sogenanntenlog-structured file system. Da keine Daten überschrieben werden, existieren eigentlich immer veraltete Blöcke, weshalb die oben angesprochene Garbage-Collection erforderlich ist. Für weiter Infos zu YAFFS2 sei auf Spreitzenbarth et al. [2011] und Zimmermann and Spreitzenbarth [2012] verwiesen 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: ADEL- Bewegungsprofil [Spreitzenbarth and Schmitt., 2012] 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.

33 1.6 Verschleierungstechniken Seite Zusammenfassung 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). 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. control flow 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 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.

34 Seite 32 Studienbrief 1 Einführung in die Browser- und Anwendungsforensik statische Analyse Tabelle 1.2: Reverse Engineering Tools 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 Java-Bytecode X86 Binärcode Disassembler (statisch) Javap/jasmine IDA pro Decompiler (statisch) Jd/jad Hexrays Decompiler (IDA Plugin) Debugger (dynamisch) Jdb/JDebugTool OllyDbg/Immunity Debugger 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: Q Quelltext b 03 3c 1b 07 a a 06 a3 00 0b 06 3b 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. Stack-Maschine 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 Byte- Wert, aus dem der Befehl besteht, der in der rechten Spalte dargestellt ist. Das Maschinenmodell von Java ist eine Stack-Maschine. Argumente werden dabei auf

35 1.6 Verschleierungstechniken Seite 33 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: [06] iconst_3 1: [3b] istore_0 2: [03] iconst_0 3: [3c] istore_1 4: [1b] iload_1 5: [07] iconst_4 6: [a2,00,15] if_icmpge 27 9: [1a] iload_0 10: [06] iconst_3 11: [a3,00,0b] if_icmpgt 22 14: [06] iconst_3 15: [3b] istore_0 16: [84,01,01] iinc 1, 1 19: [a7,ff,f1] goto 4 22: [06] iconst_3 23: [3b] istore_0 24: [a7,ff,ec] goto 4 27: [b1] return Q 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. 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

36 Seite 34 Studienbrief 1 Einführung in die Browser- und Anwendungsforensik Abb. 1.25: Control Flow Graph des Java-Programmes 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:

37 1.6 Verschleierungstechniken Seite 35 Abb. 1.27: Vereinfachter Kontrollflussgraph Quelltext 1.3 i = 0 while (i < 4) i++ Q 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 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

38 Seite 36 Studienbrief 1 Einführung in die Browser- und Anwendungsforensik einfaches Programm möglichst elegant möglichst unleserlich machen soll ( Obfuscated C Contest bzw. Obfuscated Perl Contest ). B Beispiel 1.1 Das folgende Programm ist ein Beispiel für ein Programm aus dem Obfuscated C Contest. Es berechnet beispielsweise die Kreiszahl π. # define _ F<00 F OO ; i n t F=00,OO=00; main ( ) { F_OO ( ) ; p r i n t f ("%1.3 f \n",4. F/OO/OO) ; } F_OO ( ) { _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ } precious code Abb. 1.28: Obfuscator [Collberg and Nagra, 2009] 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. P Obfuscation Level Acceptable overhead Precious code Program analysis ObfuscationLTool Obfuscating transformations 1.LSelectLcode 2.LSelectLtransformation 3.LApplyLtransformation 4.LDone? P' 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

39 1.6 Verschleierungstechniken Seite 37 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(e k (x)) (1.2) Private(x) = OBF(dec k (x)) (1.3) Die Notation e k (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.

40 Seite 38 Studienbrief 1 Einführung in die Browser- und Anwendungsforensik Wenn der Obfuscator effizient arbeitet, dann könnte man damit unter Umständen sogar schnellere asymmetrische Kryptoverfahren erzeugen, als es sie heute gibt Definition von Obfuscator Wir haben bis jetzt häufig von einem Obfuscator gesprochen. Nun wollen wir ihn etwas genauer definieren. D Definition 1.1: Obfuscator Ein Obfuscator OBF ist ein Compiler, der auf Eingabe eines Programms P die Ausgabe P = 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. 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. D 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 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. 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: D 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

41 1.6 Verschleierungstechniken Seite 39 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 Der Obfuscator OBF heisst t-obfuscator wenn für ihn die virtual Black Box Eigenschaft mindestens für den Zeitraum t gilt. D 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 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. D 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. 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): Point Functions Quelltext 1.4 bool point_func(string pw){ if(pw == "secret"){ return true; } else { return false; } } Q 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

42 Seite 40 Studienbrief 1 Einführung in die Browser- und Anwendungsforensik Einwegfunktion lässt sich eine ununterscheidbare Obfuscation nach Definition 1.5 wie folgt konstruieren. Q Quelltext 1.5 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. Q Quelltext 1.6 OBF(P): if(md5(input Salt) == 4cbe59a0e5f685fd c568beab) 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. Q 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; } }

43 1.6 Verschleierungstechniken Seite 41 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 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: Quelltext 1.8 for(int i = 0; i < size; ++i) print(array[i]); Q Quelltext 1.9 for(int _$%& = 0; _$%& < _%$&; ++_$%&) print(_&%$[_$%&)]); Q 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.

44 Seite 42 Studienbrief 1 Einführung in die Browser- und Anwendungsforensik 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: Q Quelltext 1.10 if (b == true) //... Q Quelltext 1.11 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: Q Quelltext 1.12 a(); b(); Q 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

45 1.6 Verschleierungstechniken Seite 43 Verschleierung stark verändert ist, fällt nicht auf, dass eigentlich dasselbe berechnet wird. Quelltext 1.14 if(random){ OBF_1(b()); } else { OBF_2(b()); } Q Fake Loops: 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. dead code 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. Quelltext 1.15 for(int i = 0; i < size; ++i){ if(obf(true)){ break; } deadcode(); } Q 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.

46 Seite 44 Studienbrief 1 Einführung in die Browser- und Anwendungsforensik 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: Abb. 1.31: Merging von Funktionen f l o a t foo [ ] ; 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 ( float )d ; } int main ( void ) { f ( 4 2, ) ; f l o a t v = g ( 6. 0, ' a ' ) ; return 0 ; } Merge f l o a t foo [ ] ; void fg ( int a, float bc, char d, int w) { i f (w == 1) { foo [ a ] = bc ; return bc ( f l o a t )d ; } int main ( void ) { fg ( 4 2, , ' 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.

47 1.6 Verschleierungstechniken Seite 45 Zahlen verschleiern : Zahlen und Berechnungen können durch Arithmetik, Lookup Tables und Teil- Homomorphie vor dem Betrachter verborgen werden. Ein Beispiel zur Zahlenverschleierung durch Arithmetik: Quelltext 1.16 y = x * 42; Q //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 2 5. Das Ganze passiert in den Zeilen darauf noch einmal analog. Insgesamt berechnet sich y daher wie folgt: y = x x x 2 1 = x ( ) = x ( ) = x 42 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 Werte Summe Wertung f(x,y) 32-bit 236 GB zu viel f(x) 23-bit 16 GB zu viel f(x) 16-bit 128 kb okay f(x,y) 8-bit 64 kb okay lookup table Tabelle 1.3: Abschätzung Größe einer Lookup Table Bei teil-homomorphen Funktionen wird ausgenutzt, dass bestimmte Aktionen trotz Verschlüsselung noch möglich sind (siehe oben). Der folgende Quellcode

48 Seite 46 Studienbrief 1 Einführung in die Browser- und Anwendungsforensik beschreibt einen Trick, um Zahlen zu verschleiern, so dass man trotzdem noch auf ihnen rechnen kann. Q Quelltext 1.17 #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. Teil-Homomorphie 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)

49 1.6 Verschleierungstechniken Seite 47 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: RSA n = p q (1.5) e d = 1 mod (p 1)(q 1) (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. C = M E mod n (1.7) M = C d mod n (1.8) RSA-Ver- und Entschlüsselung 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. Die Homomorphie bzgl. der Multiplikation lässt sich nun wie folgt für zwei Nachrichten M 1 und M 2 beweisen (Formel 1.9). (M e 1 mod n) (Me 2 mod n) = (Me 1 Me 2 ) mod n = (M 1 M 2 ) e mod n (1.9) RSA: Homomorphie bzgl. Multiplikation Aliasing: Aliasing lässt sich am besten anhand eines Beispielcodes nachvollziehen: Quelltext 1.18 int alias(int *a, int *b){ *a = 10; *b = 5; if((*a - *b) == 0) code(); } Q 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. Quelltext 1.19 int a = 0; alias(&a, &a); Q

50 Seite 48 Studienbrief 1 Einführung in die Browser- und Anwendungsforensik 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: Q Quelltext 1.20 void f() { } void g() { f(); } void h() { f(); g(); } void k() { } 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 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. Abb. 1.33: Aufrufgraph des Beispiels zu Pointer Indirection k h g 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:

51 1.6 Verschleierungstechniken Seite 49 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