Voraussetzungen für die Entwicklung von Malware unter ... · PDF...

Rheinisch-Westfalische Technische Hochschule AachenFachgruppe Informatik

Diplomarbeit

Voraussetzungen fur dieEntwicklung von Malware unter

Windows Mobile 5

Boris Michael Leidner

1. Februar 2007

Betreuer:

Dipl.-Inform. Michael BecherLehrstuhl fur Praktische Informatik 1

Universitat Mannheim

Erstgutachter: Zweitgutachter:

Prof. Dr.-Ing. F. Freiling Prof. Dr.-Ing. H. MantelLehrstuhl fur Praktische Informatik 1 Security Engineering GroupUniversitat Mannheim RWTH Aachen

Diese Diplomarbeit wurde mit LATEX und dem KOMA-Script erstellt.

Danksagungen

Ich bedanke mich bei:

• Prof. Dr.-Ing. Felix Freiling, der sich auch nach dem Umzug seines Lehr-stuhls nach Mannheim als Erstgutachter fur meine Diplomarbeit angebotenhat;

• Prof. Dr.-Ing. Heiko Mantel, der sich als Zweitgutachter zur Verfugung ge-stellt hat;

• Dipl.-Inform. Michael Becher fur die Betreuung meiner Diplomarbeit, die in-spirierenden Gesprache und die vielen Ratschlage wahrend der letzten sechsMonate;

• Stefanie Bock, die fur die ausfuhrliche Korrektur meiner Arbeit einen großenTeil ihrer Zeit investiert hat.

Hiermit versichere ich, dass ich die Arbeit selbststandig verfasst und keine ande-ren als die angegebenen Quellen und Hilfsmittel benutzt, sowie Zitate kenntlichgemacht habe.

Aachen, den 1. Marz 2007

Boris Leidner

Zusammenfassung

Malware, wie Computerviren und Computerwurmer, ist schon langer eine Bedro-hung fur Desktop- und Serversysteme. Mit Windows Mobile 5.0 ist 2005 ein neuesBetriebssystem von Microsoft fur mobile Gerate, wie Pocket PCs und Smartpho-nes, auf den Markt gekommen. Diese Gerate bieten einen immer großer werden-den Funktionsumfang und erlauben unter anderem die Verwendung von Telefon-netzen und WLAN. In dieser Arbeit werden Voraussetzungen untersucht, die furdie Entwicklung eines Computerwurms fur Windows Mobile 5.0 benotigt wer-den. Dazu wird ein Baukasten erstellt, der als Machbarkeitsnachweis fur einenComputerwurm die Bedrohung durch mobile Malware aufzeigt. Fur den Baukas-ten wird eine typische Sicherheitslucke in ein Testprogramm eingebaut, so dassanhand dieser Sicherheitslucke die Infizierung und Verbreitung des Computer-wurms demonstriert werden kann. Andere Arbeiten bzgl. der Ausnutzung vonSicherheitslucken in alteren Windows Mobile-Versionen existieren zwar, sie sindjedoch nicht auf die Version 5.0 ubertragbar. Insbesondere wird in dieser Arbeitmehr Wert auf zuverlassige Ausfuhrung des Infizierungs- und Verbreitungsfunk-tion des Computerwurms gelegt. Bei der Erstellung des Baukastens werden dabeiverschiedene Probleme gelost, die sich auf Eigenheiten von Windows Mobile 5.0und der Hardware der mobilen Gerate beziehen.

Ein weiterer Teil der Arbeit versucht eine Sicherheitslucke in Windows Mobile 5.0durch Fuzzing-Techniken aufzudecken. Das Ergebnis der Suche ist, dass keine Si-cherheitslucken gefunden wurden. Weitere Untersuchungen weisen darauf hin,dass im Gegensatz zu alteren Windows Mobile-Versionen mit dem Pufferuber-laufschutz durch Security Cookies ein wesentlicher Schutzmechanismus fur Win-dows Mobile 5.0 aktiviert ist. Security Cookies stellen ein großes Hindernis bei derAusnutzung von Stack-basierten Pufferuberlaufen dar.

Es wird weiterhin untersucht, ob eine Suche nach Sicherheitslucken durch Fuz-zing als Sicherheitsmetrik herangezogen werden kann. Die Ubertragbarkeit desErgebnisses der Suche auf Ergebnisse anderer Sicherheitsuntersuchungen wirddiskutiert, denn die Fahigkeiten und Erfahrungen der Experten, sowie die Aus-wahl der Vorgehensweisen und Angriffsvektoren bei einer derartigen Untersu-chung sind nicht untereinander vergleichbar.

Im letzten Teil der Arbeit werden Sicherheitsmaßnahmen angegeben, die verschie-dene Voraussetzungen fur Computerwurmer beseitigen. Die Maßnahmen bezie-hen sich dabei großtenteils auf Unzulanglichkeiten des Betriebssystems. Es wer-den Maßnahmen fur den Betriebssystemhersteller, die Geratehersteller, Entwick-ler und Benutzer aufgezeigt.

Abstract

Computer viruses and worms are malware, which is a long known threat for desk-top and server computers. In 2005 Microsoft released Windows Mobile 5.0, an op-erating system for mobile devices like Pocket PCs and Smartphones. Such devicesoffer lots of functionality that is even likely to increase in the future. They providephone capabilities and allow the use of WiFi. This diploma thesis investigates re-quirements for the development of a computer worm, that can spread on devicesrunning Windows Mobile 5.0. In this investigation, a computer worm frameworkis created, that shows the threat of mobile malware. A test program with an ex-ploitable security vulnerabilty is written for use with the framework, so that theinfection and spreading of the computer worm can be demonstrated. Other workexists, that shows the exploitation of security vulnerabilities in older versions ofWindows Mobile. The results, however, can not be transferred on version 5.0. Inthis thesis, the reliability of the infection and spreading functions of the computerworm is highlighted. During the creation of the framework several problems aresolved, that refer to pecularities of Windows Mobile 5.0 and the underlying hard-ware.

In another part of the thesis, the author tries to find a security vulnerability in Win-dows Mobile 5.0 by using fuzzing techniques. The result is, that no vulnerabilitycould be found. Further research shows, that the stack protection by means of Se-curity Cookies, which is used in Windows Mobile 5.0, is a substantial protectionagainst stack-based buffer overflows.

Furthermore, it is tried to determine, if a search for security vulnerabilities withfuzzing techniques can be used as a security metric. The transferability of theresults of the search is discussed, because the skills and experiences of the expertsas well as the choice of methods for the search are not comparable among eachother.

In the last part of the thesis, security measures for the antagonization of variousrequirements for computer worms are specified. These measures mostly refer toinadequatenesses of the operating system. Measures are shown for the operatingsystem developer, device manufacturers, application developers and users.

Inhaltsverzeichnis

1 Einleitung 11.1 Mobile Gerate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Malware fur mobile Gerate . . . . . . . . . . . . . . . . . . . . . . . 21.3 Ziele und Aufbau dieser Arbeit . . . . . . . . . . . . . . . . . . . . . 31.4 Verwandte Arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Grundlagen 72.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Windows Mobile 5.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.2 Allgemeine Informationen . . . . . . . . . . . . . . . . . . . . 72.2.3 ActiveSync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.4 Pocket PCs und Smartphones . . . . . . . . . . . . . . . . . . 82.2.5 Die Speicherarchitektur . . . . . . . . . . . . . . . . . . . . . 92.2.6 Prozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.7 OEM Adaptation Layer . . . . . . . . . . . . . . . . . . . . . 102.2.8 Schnittstellen zum Betriebssystem . . . . . . . . . . . . . . . 102.2.9 Trusted Environment . . . . . . . . . . . . . . . . . . . . . . . 122.2.10 Security Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 142.2.11 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3 ARM-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3.2 Allgemeines zu ARM . . . . . . . . . . . . . . . . . . . . . . 152.3.3 Instruktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.3.4 Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.3.5 Unterprogramme und Parameterubergabe . . . . . . . . . . 172.3.6 RISC-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . 172.3.7 Harvard-Architektur . . . . . . . . . . . . . . . . . . . . . . . 172.3.8 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . 18

2.4 Malware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.5 Fuzzing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.5.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.5.2 Begriffsklarung . . . . . . . . . . . . . . . . . . . . . . . . . . 192.5.3 Das SPIKE Fuzzer Creation Kit . . . . . . . . . . . . . . . . . 202.5.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . 21

XI

Inhaltsverzeichnis

2.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3 Entwicklung eines Baukastens fur einen Computerwurm 233.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.2 Aufbau des Baukastens . . . . . . . . . . . . . . . . . . . . . . . . . . 233.3 Die Infizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.3.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.3.2 Voraussetzungen . . . . . . . . . . . . . . . . . . . . . . . . . 253.3.3 Werkzeuge fur die Entwicklung . . . . . . . . . . . . . . . . 263.3.4 Stack-basierter Pufferuberlauf . . . . . . . . . . . . . . . . . 263.3.5 Die Rucksprungadresse . . . . . . . . . . . . . . . . . . . . . 273.3.6 Security Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 273.3.7 Unterteilung des Shellcodes in Stages . . . . . . . . . . . . . 283.3.8 Das Null-Byte-Problem . . . . . . . . . . . . . . . . . . . . . 303.3.9 Selbstmodifizierende Programme auf ARM-Prozessoren . . 313.3.10 Die Schnittstelle zum Betriebssystem . . . . . . . . . . . . . 343.3.11 Probleme mit dem Stack . . . . . . . . . . . . . . . . . . . . . 373.3.12 Aufbau der zweiten Stage . . . . . . . . . . . . . . . . . . . . 373.3.13 Test des Shellcodes und der Infizierung . . . . . . . . . . . . 383.3.14 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . 40

3.4 Die Verbreitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.4.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.4.2 Werkzeuge fur die Entwicklung . . . . . . . . . . . . . . . . 413.4.3 Medium fur die Verbreitung . . . . . . . . . . . . . . . . . . 413.4.4 Algorithmen fur die Verbreitung . . . . . . . . . . . . . . . . 423.4.5 Aufbau des Computerwurmprogramms . . . . . . . . . . . 453.4.6 Test der Verbreitung . . . . . . . . . . . . . . . . . . . . . . . 453.4.7 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . 46

3.5 Die Schadensfunktion . . . . . . . . . . . . . . . . . . . . . . . . . . 473.5.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.5.2 Allgemeiner Schaden . . . . . . . . . . . . . . . . . . . . . . . 473.5.3 Wahlen kostenintensiver Rufnummern . . . . . . . . . . . . 473.5.4 Versenden kostenintensiver SMS-Mitteilungen . . . . . . . . 483.5.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . 49

3.6 Test des Shellcodes auf verschiedenen Geraten . . . . . . . . . . . . 493.7 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4 Suche nach Sicherheitslucken 514.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.2 Durchfuhrung des Fuzzings . . . . . . . . . . . . . . . . . . . . . . . 51

4.2.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.2.2 Allgemeines zu Fuzzing . . . . . . . . . . . . . . . . . . . . . 524.2.3 Angriffsvektoren . . . . . . . . . . . . . . . . . . . . . . . . . 524.2.4 UDP-Port 137 . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

XII

Inhaltsverzeichnis

4.2.5 ActiveSync Notification UDP-Port 1034 . . . . . . . . . . . . 544.2.6 WAP-Push UDP-Port 2948 . . . . . . . . . . . . . . . . . . . . 564.2.7 DHCP-Client auf Port 68 . . . . . . . . . . . . . . . . . . . . . 594.2.8 Beendigung der Suche . . . . . . . . . . . . . . . . . . . . . . 614.2.9 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . 61

4.3 Probleme bei der Suche nach Sicherheitslucken . . . . . . . . . . . . 614.3.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.3.2 Security Cookies in Windows Mobile 5.0 . . . . . . . . . . . 624.3.3 Probleme mit den Debuggern . . . . . . . . . . . . . . . . . . 664.3.4 Zeitaufwand und fehlende Informationen . . . . . . . . . . . 674.3.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . 67

4.4 Anwendbarkeit einer Sicherheitsmetrik . . . . . . . . . . . . . . . . 684.4.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684.4.2 Cost-to-break-Metrik . . . . . . . . . . . . . . . . . . . . . . . 684.4.3 Kritik an der Metrik . . . . . . . . . . . . . . . . . . . . . . . 704.4.4 Hacking Challenges . . . . . . . . . . . . . . . . . . . . . . . 714.4.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . 73


5 Verbesserung der Sicherheit in Windows Mobile 5.0 755.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.2 Sicherheitsmaßnahmen fur Betriebssystem- und Geratehersteller . 75

5.2.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.2.2 Unnotige Netzwerkdienste . . . . . . . . . . . . . . . . . . . 755.2.3 Trusted Environment . . . . . . . . . . . . . . . . . . . . . . . 765.2.4 Trennung von Anwendungsdaten . . . . . . . . . . . . . . . 785.2.5 Zugriff auf andere Prozesse . . . . . . . . . . . . . . . . . . . 795.2.6 Verschleierung der Syscalls . . . . . . . . . . . . . . . . . . . 805.2.7 Portstealing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825.2.8 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . 82

5.3 Sicherheitsmaßnahmen fur Entwickler . . . . . . . . . . . . . . . . . 835.3.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835.3.2 Security Cookies aktivieren . . . . . . . . . . . . . . . . . . . 835.3.3 Verwendung der Protected Store API . . . . . . . . . . . . . 835.3.4 Codesignierung von Anwendungen . . . . . . . . . . . . . . 845.3.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . 85

5.4 Sicherheitsmaßnahmen fur Benutzer . . . . . . . . . . . . . . . . . . 855.4.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855.4.2 Benutzerpasswort setzen . . . . . . . . . . . . . . . . . . . . 855.4.3 WLAN und Bluetooth . . . . . . . . . . . . . . . . . . . . . . 865.4.4 Unnotige Anwendungen . . . . . . . . . . . . . . . . . . . . 865.4.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . 87


XIII

Inhaltsverzeichnis

6 Fazit 896.1 Ergebnisse dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . 896.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

A Werkzeuge 93

B Inhalt der beigelegten CD 95

C Fuzzing 97C.1 Portscans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

C.1.1 TCP Syn Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . 97C.1.2 UDP Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

C.2 SPK-Dateien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98C.2.1 NetBIOS Name Registration Request . . . . . . . . . . . . . 98C.2.2 MMS-Benachrichtigung . . . . . . . . . . . . . . . . . . . . . 99C.2.3 DHCP ACK-Nachricht . . . . . . . . . . . . . . . . . . . . . . 100

C.3 Logbuch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

XIV

Abbildungsverzeichnis

2.1 Speicherarchitektur von Windows Mobile (aus [Mic06]) . . . . . . . 92.2 Definition der API-Satze in kfuncs.h . . . . . . . . . . . . . . . . . 112.3 Ausschnitt der APIs in kwin32.c . . . . . . . . . . . . . . . . . . . 122.4 Die Harvard-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1 Der Stack-Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.2 Ubertragung des Shellcodes . . . . . . . . . . . . . . . . . . . . . . . 293.3 Aufbau der ersten Stage . . . . . . . . . . . . . . . . . . . . . . . . . 303.4 Exploit-Zeichenkette, die in den Puffer ubergeben wird . . . . . . . 313.5 Aufbau der zweiten Stage . . . . . . . . . . . . . . . . . . . . . . . . 373.6 Der Vorgang der Infizierung . . . . . . . . . . . . . . . . . . . . . . . 403.7 Bildschirmfoto des MDA Vario nach der Ausfuhrung des Exploits . 403.8 NetBIOS-Pakete bei Eintritt in ein Netzwerk . . . . . . . . . . . . . 433.9 Bildschirmfoto nach der Infizierung des Gerats . . . . . . . . . . . . 46

4.1 Aufbau eines NetBIOS Name Registration Request (aus [RFC87b]) 534.2 Hexadezimalausgabe einer MMS-Benachrichtigung . . . . . . . . . 564.3 MMS-Benachrichtigung wird angezeigt . . . . . . . . . . . . . . . . 584.4 Aushandlung einer IP-Adresse uber DHCP . . . . . . . . . . . . . . 604.5 Stack-Frame mit SEH und Security Cookie auf x86-Architekturen . 654.6 Einsatz des Debuggermoduls beim Remote Debugging . . . . . . . 66

5.1 Permutation der Syscall-Adressen . . . . . . . . . . . . . . . . . . . 815.2 Nicht alle Prozesse werden angezeigt . . . . . . . . . . . . . . . . . 87

XV

Abbildungsverzeichnis

XVI

1 Einleitung

1.1 Mobile Gerate

Die Welt der mobilen Gerate wachst stetig. Dem MarktforschungsunternehmenGartner zufolge, konnten in der erste Halfte des Jahres 2006 insgesamt 42 Millio-nen Pocket PCs und Smartphones verkauft werden. Dies entspricht einer Steige-rung von 57% im Vergleich zum Vorjahr. Gartner sieht hier vor allem den Bereichder Smartphones als Wachstumstreiber (Quelle: [Hel06]). Microsoft entwickelt seit1996 die Betriebssysteme der Windows CE-Reihe (s. [HPC06]). Windows CE warvon Anfang an fur den Betrieb in mobilen Kleingeraten vorgesehen und hat sichmittlerweile zum Marktfuhrer der Betriebssysteme fur PDAs (bei Microsoft PocketPCs) etabliert. Laut Gartner konnte Windows CE im ersten Quartal 2005 einenMarktanteil von 46% in der Sparte Pocket PCs beanspruchen. Es folgten die Her-steller RIM mit 20,8% und Palm mit 20% (Quelle: [Hei05]).

Windows Mobile ist vor allem auf Pocket PCs sehr beliebt, nicht zuletzt wegenden hohen Verkaufsrangen der Gerate der Firma HTC. HTC liefert seine Geratebevorzugt mit Windows Mobile aus und bescherte Microsoft im zweiten Quar-tal 2006 einen Zuwachs von 84% in diesem Bereich. Nur der Bereich der reinenHandheld-Gerate (solche ohne Funktionen wie Telefon und WLAN) ging bei Mi-crosoft um 7% zuruck. Dieser wird bislang noch großtenteils von Nokia-Geratenmit dem Betriebssystem Symbian OS beherrscht (Quelle: [Hil06]). Dennoch haltWindows Mobile laut einer Studie von Canalys [Can06] einen Marktanteil von16,9% fur mobile Gerate im Allgemeinen und konnte bis zum dritten Quartal 20064,7% mehr Gerate verkaufen als noch im Jahr zuvor.

Mit Windows Mobile 5.0, einem Windows CE 5.0-Ableger, hat Microsoft Mitte2005 ein weiteres Windows CE-Betriebssystem fur mobile Gerate auf den Marktgebracht. Es ist mit einer großen Anzahl an Funktionen ausgestattet und sprichtvor allem die Leute an, die bereits andere Microsoft-Produkte wie den MicrosoftExchange Server einsetzen, da es sich in diese Produkte nahtlos integriert.

Die wachsende Verbreitung und die zunehmende Anzahl an Funktionen der mo-bilen Gerate macht sie zunehmend zum Ziel fur Angreifer. Wegen den vielfalti-gen Zugangen zu Netzwerken bieten sich auch immer mehr Moglichkeiten fur

1

1 Einleitung

die Verbreitung von Malware.

1.2 Malware fur mobile Gerate

Mit Zunahme der Komplexitat der mobilen Anwendungen steigt auch die Haufig-keit der sicherheitsrelevanten Programmierfehler an. Da mobile Gerate immermehr Anklang in der Offentlichkeit finden, stellt dies, in Verbindung mit der im-mer weiter ausgebauten Vernetzung der Gerate, ein wachsendes Risiko bezuglichder Verbreitung von Malware dar. Im Desktop- und Server-Bereich hat man diesbereits erlebt. Angriffe durch Computerviren und Computerwurmer sind heutean der Tagesordnung. Dies zeigen z. B. die Wildlists der WildList Organization In-ternational [WG06]. Diese Listen werden monatlich veroffentlicht und informie-ren uber Malware, die im jeweils vergangenen Monat aktiv war.

Die Frage ist nun, in wie weit sich diese Geschehnisse in der mobilen Welt wie-derholen konnten. Eugene Kaspersky, der Leiter der Antiviren-Forschung bei Kas-perky Labs, meint dazu: ”Malware development for mobiles is passing through the sa-me stages as malware for desktops. We will probably see a serious outbreak of viruses forhandhelds sometime soon“([Bre04]). Der gleichen Ansicht ist man bei der finnischenAntivirenfirma F-Secure: ”Pretty soon now, I’m afraid we will start to see mobile phonemalware infecting phones [. . . ]“, glaubt Mikko Hypponen, Direktor der Virenfor-schung bei F-Secure ([Bee06]). Weitere Quellen hierzu sind [Poß05, Mur03a].

Die ersten Machbarkeitsnachweise fur Computerviren, Computerwurmer sowieTrojanische Pferde fur mobile Gerate sind auch bereits veroffentlicht worden. ImMarz 2005 tauchte Commwarrior auf. Commwarrior (s. [HN05]) ist ein Compu-terwurm fur Mobiletelefone mit dem Betriebssystem Symbian OS. Er verbreitetsich uber die Bluetooth-Schnittstellte und uber den Versand von MMS. Damit al-lerdings ein Gerat infiziert werden kann, muss der Benutzer den Download derMMS und die Installation der angehangten Datei bestatigen.

Die Tabelle 1.2 zeigt Malware auf, die in der Vergangenheit mobile Gerate bedroh-te. Computerwurmer sind Malware, die sich vollstandig ohne Benutzerinterakti-on verbreiten. Fur Windows Mobile sind bislang lediglich verschiedene Compu-terviren und Trojanische Pferde entdeckt worden, jedoch keine Computerwurmer.

2

1.3 Ziele und Aufbau dieser Arbeit

Name Art Plattform EntdeckungDust11,13,14 Virus WinCE 4 Juli 2004Brador11 Trojaner WinCE 4.2 August 2004Skulls11 Virus Symbian OS November 2004Cabir11,12 Computerwurm Symbian OS Dezember 2004Commwarrior10 Computerwurm Symbian OS Marz 2005Cardtrp16 Trojaner Symbian OS September 2005RedBrowser11 Trojaner J2ME Februar 2006Crossover/Cxover17 Virus Windows (MSIL) Marz 2006

Tabelle 1.1: Ubersicht der mobilen Malware

1.3 Ziele und Aufbau dieser Arbeit

Diese Arbeit untersucht die Voraussetzungen, die notig sind, um einen Compu-terwurm zu entwickeln, der sich auf dem Betriebssystem Windows Mobile 5.0verbreiten kann. In diesem Rahmen wird es vor allem um die technischen Aspek-te gehen, die bei der Umsetzung notwendig sind. Konkret sollen folgende Fragenbeantwortet werden:

• Konnen typische Programmierfehler, die zu Pufferuberlaufen fuhren, unterWindows Mobile 5.0 von einem Angreifer fur das Ausfuhren von eigenemCode verwendet werden?

• Kann damit ein Computerwurm entwickelt werden, der sich uber WindowsMobile-Gerate verbreitet?

• Welcher Zeitaufwand und welche finanziellen Investitionen sind notig, umunter Verwendung von Fuzzing-Techniken eine Sicherheitslucke aufzude-cken, die fur die Verbreitung eines Computerwurms genutzt werden kann?

• Welche Maßnahmen konnen getroffen werden, damit Voraussetzungen fureinen Computerwurm eliminiert werden?

10[HN05]11[Mil05]12[NRT04]13[PF04]14[PFR04a, PFR04b, PFR04c]16[Wan05]17[Pei06, Lem06]

3

1 Einleitung

Nachdem in Kapitel 2 einige Grundlagen geklart worden sind, werden die erstenbeiden Fragen in Kapitel 3 behandelt. Hier geht es zunachst um die Frage, ob unterWindows Mobile 5.0 beliebiger Code ausgefuhrt werden kann, indem ein Stack-basierter Pufferuberlauf ausgenutzt wird. Es werden die ersten technischen Vor-aussetzungen fur die Infizierung durch einen Computerwurm untersucht. Fur dieUntersuchung wird Shellcode in ARM-Assembler entwickelt. Im weiteren Verlaufdes Kapitels wird vorausgesetzt, dass beliebiger Code ausgefuhrt werden kann,um die anderen Komponenten eines Computerwurms zu erforschen. Es steht nundie Entwicklung der Verbreitungfunktion eines Computerwurms im Mittelpunkt,da eine effiziente Verbreitung eine weitere Voraussetzung fur einen Computer-wurm darstellt. Zum Schluss werden dann noch einige mogliche Schadensfunk-tionen skizziert.

Als Nachstes wird in Kapitel 4 mit Fuzzing-Techniken nach Sicherheitslucken inWindows Mobile 5.0 gesucht. Im Anschluss daran werden Probleme bei der Sucheerlautert und die Verwendung der Suche als Sicherheitsmetrik diskutiert. Dazuwird uberlegt, ob sich bestimmen lasst, wie zeitaufwendig und kostenintensiv esist, nach einer Sicherheitslucke zu suchen und damit eine wichtige Voraussetzungfur einen Computerwurm zu schaffen.

In Kapitel 5 werden dann Probleme im Design von Windows Mobile 5.0 disku-tiert, welche die Entwicklung eines Computerwurms moglich machen oder un-terstutzen. Die Probleme werden aufgezahlt und Losungsmoglichkeiten vorge-stellt. Dabei wird zwischen Losungen fur Betriebssystemhersteller, Gerateherstel-ler, Entwicklern und Benutzer unterschieden.

Das letzte Kapitel 6 zieht ein Fazit dieser Arbeit. Weiterhin werden in einem Aus-blick einige Themengebiete angesprochen, die in zukunftigen Arbeiten interessantsein konnten.

Fur die Arbeit standen zwei Windows Mobile 5.0-Gerate zur Verfugung: ein MDAPro und ein MDA Vario. Zwei weitere Gerate wurden fur den Test des Shellcodesund der Verbreitung verwendet. Sofern nicht anders erwahnt, bezieht sich derBegriff Testgerate immer auf die oben genannten Gerate.

1.4 Verwandte Arbeiten

Es existieren bereits einige Arbeiten, die sich mit der Sicherheit von Windows Mo-bile beschaftigen. In Bezug auf das Ausnutzen von Stack-basierten Pufferuberlau-fen und der Entwicklung von Shellcodes fur Windows Mobile, wurden von Hur-man in [Hur05b] und von San in [san05b] bereits wichtige Beitrage geleistet. DieErgebnisse sind jedoch nicht alle auf Windows Mobile 5.0 ubertragbar, so dass die

4

1.4 Verwandte Arbeiten

Beispiel-Exploits nicht mehr auf neueren Geraten funktionieren. Außerdem sinddie angenommenen Voraussetzungen fur die Ausnutzung einer Sicherheitsluckenicht immer ausreichend fur die Verbreitung eines Computerwurms. Die auftre-tenden Probleme werden in dieser Arbeit herausgestellt und Losungen gesucht.Insbesondere wird Wert auf Zuverlassigkeit des entwickelten Exploits gelegt, umso die Bedrohung durch Computerwurmer besser einschatzen zu konnen. Weite-re Informationen zu ARM-Programmierung und der Entwicklung von Shellcodesfur Windows Mobile sind in [Hur05a, san05a, Fog03, Fog04, Fog05, CP05, Mul05]zu finden.

In [Mul06c] untersucht Collin Mulliner zwei ausgesuchte Probleme, die sich durchden großen Funktionsumfang von Smartphones1 ergeben. Das erste Problem ent-steht durch die verschiedenen drahtlosen Netzwerke, in denen ein Smartphonekommunizieren kann. Durch einen Angriff uber WLAN konnte ein Gerat uber-nommen und so der Zugriff auf die Telefonfunktionen erlangt werden. Mullinerstellt einen Machbarkeitsnachweis fur einen derartigen Angriff vor und demons-triert außerdem eine Technik namens Labeling, mit der mobile Gerate vor diesenUbergriffen geschutzt werden konnen. Beim Labeling werden Prozesse und Da-teien markiert, um den Zugriff auf verschiedene Ressourcen zu regulieren (s. a.[MVDL06]).

Das zweite von ihm untersuchte Problem beschaftigt sich mit der Sicherheitsana-lyse des Clients fur den Multimedia Message Service (MMS), der auf den Gerateninstalliert ist. Die Sicherheitsanalyse ist aufwendig, da sie ohne Quellcode durch-gefuhrt werden muss. Mulliner beschreibt einen neuen Ansatz mittels einer virtu-ellen Infrastruktur, welcher die Effekte der echten Infrastruktur auf den Analyse-prozess berucksichtigt. Anstatt eines GSM-Netzwerks verwendet er ein WLAN-Netzwerk fur den Versand von MMS-Nachrichten. Es wurden verschiedene Si-cherheitslucken mit Hilfe von Fuzzing gefunden. Eine der Sicherheitslucken lasstsich fur das Ausfuhren von beliebigem Code verwenden. In [Mul06b] wurde vondem Fund bereits berichtet und die Ausnutzung vorgefuhrt. Ob dies auch aufGeraten mit Windows Mobile 5.0 funktioniert war Mulliner nicht bekannt, da erbislang keine entsprechenden Gerate testen konnte (s. a. [Mul06a]). Die MasterThesis [Mul06c] wurde im Juni 2006 von Mulliner abgeschlossen, jedoch erst ei-nige Monate spater veroffentlicht. Aus diesem Grund stand sie erst in einem fort-geschrittenen Stadium der Diplomarbeit zur Verfugung. Die Ergebnisse sind furWindows Mobile 5.0 nicht relevant, so dass sie keine Auswirkungen auf diese Ar-beit hatten.

Es gibt drei weitere Veroffentlichungen von mobiler Malware fur Windows Mobi-le. In [PF04] beschaftigt sich die Firma Airscanner mit WinCE4.Dust, dem erstenComputervirus fur Windows Mobile. Die Sicherheitsfirma Symantec berichtet in[Chi04] uber Brador.A, einem Trojanischen Pferd fur Windows Mobile, das eine

1Mit Smartphones bezeichnet Mulliner alle Windows Mobile-Gerate

5

1 Einleitung

Hintertur fur Angreifer offen lasst. In [Pei06] analysiert Peikari den Computervi-rus Crossover, der sich von einem Windows PC auf ein Windows Mobile-Geratubertragen kann. Miller gibt in [Mil05] einen Uberblick uber mobile Malware inder Vergangenheit.

Generelle Untersuchungen der Sicherheit von Betriebssystemen fur mobile Geratesind zum Teil von Murmann in [Mur03b] behandelt worden. Asselineau geht in[Ass06] konkret auf Windows Mobile ein und zeigt z. B. wie ein laufender Prozessfremde Prozesse ubernehmen kann.

In [Lit03] stellt Litchfield Ansatze vor, mit denen der Stack-Schutz unter WindowsServer 2003 umgangen werden kann. Die Ergebnisse werden im Rahmen dieserArbeit auf ihre Ubertragbarkeit fur Windows Mobile 5.0 untersucht.

6

2 Grundlagen

2.1 Einleitung

Dieses Kapitel beschaftigt sich mit den notwendigen Grundlagen fur die spaterenKapitel. Es werden besondere Merkmale des Betriebssystems Windows Mobile5.0 herausgestellt, die bei der Entwicklung des Computerwurmbaukastens rele-vant sind. Desweiteren wird die ARM-Architektur fur Prozessoren erlautert. IhreEigenschaften sind insbesondere bei der Entwicklung von Shellcode interessant.Anschließend werden verschiedene Begriffe aus dem Bereich Malware definiertund erklart. Zum Schluss beschaftigt sich das Kapitel noch mit den Grundlagenzu Fuzzing-Techniken und der Vorstellung des SPIKE Fuzzer Creation Toolkit.

2.2 Windows Mobile 5.0

2.2.1 Einleitung

Dieser Abschnitt beschaftigt sich mit dem Betriebssystem Windows Mobile 5.0.Zunachst werden allgemeine Information zum Betriebssystem angegeben. An-schließend wird die ActiveSync-Schnittstelle beschrieben und die Unterscheidungzwischen Pocket PCs und Smartphones geklart. Weiterhin werden Speicher- undProzessarchitektur, das OEM Adaptation Layer, die Schnittstellen zum Betriebs-system, das Trusted Environment sowie der Stack-Schutz durch Security Cookieserwahnt.

2.2.2 Allgemeine Informationen

Windows Mobile ist ein reduziertes Windows-Betriebssystem fur mobile Gerate vonder Firma Microsoft. Die aktuelle Version der Windows Mobile-Reihe ist die Ver-sion 5, die auf den Windows CE 5.0-Kernel basiert. Die Versionen Windows Mobilefor Pocket PCs und Windows Mobile for Smartphones enthalten angepasste Software

7

2 Grundlagen

fur Pocket PCs und Smartphones. Optisch ahnelt die Oberflache des Betriebssys-tems der von Windows 98, da sie sehr einfach aufgebaut ist und schlichte Fenster-dialoge verwendet. Auch bei Windows Mobile gibt es die zentrale hierarchischeDatenbank, die Windows Registry. In ihr werden Konfigurationen des Betriebssys-tems abgelegt.

2.2.3 ActiveSync

Die Ubertragung von Anwendungsdaten zwischen einem Windows Mobile-Geratund einem Desktop-PC wird mit der Softwareschnittstelle ActiveSync durchge-fuhrt. Uber AchtiveSync-Verbindungen werden beispielsweise Kalender, Termineund Kontaktdaten synchronisiert oder es werden Prozesse mit einem Debuggeranalysiert. ActiveSync ist auf den Windows Mobile-Geraten vorinstalliert (Ver-gleich ”ActiveSync“ auf [MS:06]).

2.2.4 Pocket PCs und Smartphones

Microsoft unterteilt die Welt der mobilen Gerate in Pocket PCs und Smartphones.Pocket PCs, wie der MDA Pro oder der MDA Vario, sind kleine Taschencompu-ter, die in der Regel eine vollstandige Tastatur besitzen. Sie werden mit Softwareausgestattet, mit der Adressen, Termine und Aufgaben verwaltet werden konnen.Zusatzlich beinhalten sie Microsoft Mobile Office, welches die Programme WordMobile, Excel Mobile, Outlook Mobile und PowerPoint Mobile enthalt. Weiterhinsind Pocket PCs mit einem mehr oder weniger großen Touch-LCD-Display ausge-stattet, das uber einen Stift bedient werden kann. Viele haben eingebaute WLAN-Adapter, Bluetooth-Adapter, SD-Kartenleser und Digitalkameras. Die Gerate, dieuber Telefonfunktionen verfugen, werden Pocket PC Phones genannt. In diesemFall sind auch Telefonanwendungen im Softwarepaket enthalten.

Smartphones sind Gerate, die vorwiegend als Mobiltelefon genutzt werden, je-doch uber zusatzliche Anwendungsmoglichkeiten wie die Pocket PCs verfugen.Smartphones haben eine fur Mobiltelefone ubliche Zifferntastatur und sind furdie einhandige Bedienung ausgelegt. Die Displays sind zudem kleiner und derSoftwareumfang fallt geringer aus. So ist z. B. Mobile Office standardmaßig nichtinstalliert. Wie bei Pocket PCs konnen aber auch hier zusatzliche Programme in-stalliert werden.

Durch die immer weiter fortschreitende Miniaturisierung der Gerate, werden dieBegriffe Pocket PC und Smartphone immer diffuser. So kommt es vor, dass Smart-phones ab und zu Funktionen aufweisen, die ursprunglich nur den Pocket PCszugedacht waren. Naheres zu Microsofts Unterscheidung von Pocket PCs und

8


Smartphones kann in [Mic] gefunden werden.

2.2.5 Die Speicherarchitektur

Windows Mobile 5.0 verwendet fur den Speicher einen einzigen 4 Gigabyte gro-ßen virtuellen Adressraum (s. Abb. 2.1), der in einen User- und einen Kernelbe-reich von je 2 Gigabyte Große unterteilt ist. Im Userbereich befinden sich 33 Slotsfur User-Prozesse, von denen jeder 32 Megabyte groß ist. Die andere Halfte ist einevirtuelle RAM-Disk, der so genannte Object Store. Dieser enthalt alle Programmeund Daten, die seit der Werksinstallation hinzugekommen sind. Wird das Systemin den Ruhezustand versetzt oder durch einen Softreset neugestartet, so bleibendie Daten in ihm erhalten. Der Kernelbereich enthalt den Betriebssystemkern unddie Software mit dem das Gerat ausgeliefert wurde. Auf ihn konnen nur solcheProzesse zugreifen, die im Kernel Mode ausgefuhrt werden.

Abbildung 2.1: Speicherarchitektur von Windows Mobile (aus [Mic06])

2.2.6 Prozesse

Jeder Prozess erhalt beim Start eine eindeutige Slotnummer, die seinen eigenenSpeicherbereich angibt. Fur einen Prozess mit der Slotnummer 2 ist dies der 32Megabyte große Bereich 0x04000000 – 0x06000000. Darin liegen sein Code,

9

2 Grundlagen

Stack und Heap. Ein Prozess kann zusatzliche Threads fur die parallele Ausfuh-rung von Aufgaben haben. In diesem Fall beinhaltet der Slot auch die Stacks derThreads. Die Anzahl der Threads ist nur durch die Große des Slots beschrankt. DerSlot Null hat eine besondere Bedeutung. Er wird immer auf den Slot abgebildet,dessen Prozess gerade ausgefuhrt wird. Dadurch kann ein Prozess sich selbst uberden Slot Null referenzieren, ohne seine echte Slotnummer zu kennen.

Alle Prozesse befinden sich gleichzeitig im selben virtuellen Adressraum. JederProzess unter Windows Mobile 5.0 lauft entweder im User Mode oder Kernel Mo-de. Der Kernel Mode ist privilegierter und erlaubt unter anderem den Zugriff aufden Kernelbereich des Speichers. Viele altere Windows Mobile Gerate wurden vonden Gerateherstellern fur den so genannten Full-Kernel Mode ubersetzt. Dies ver-anlasst, dass alle Prozesse im Kernel Mode ausgefuhrt werden und die sonst not-wendigen Uberprufungen auf User- oder Kernel Mode wegfallen. Die Performan-ce des Systems wird damit gesteigert (vgl. [MS:06] unter ”Full-Kernel Mode“).

Das Betriebssystem und die Software, die vom Geratehersteller vorinstalliert wur-den, sind im ROM des Gerates abgelegt. Sofern ein Modul im ROM nicht kompri-miert ist, wird es direkt an dieser Stelle ausgefuhrt und nicht erst in den RAMgeladen. Lediglich die Segmente eines Moduls, wie Stack, Daten und Heap, dieveranderliche Daten enthalten, werden im RAM untergebracht. Diese Techniknennt man eXecute In Place (XIP).

2.2.7 OEM Adaptation Layer

Ein wichtiges Merkmal von Windows Mobile ist das OEM Adaptation Layer (kurzOAL). Dies ist eine Programmierschicht zwischen der Windows-Kernel und derHardware. Sie muss von den Gerateherstellern fur jedes Gerat speziell angepasstwerden. Die Entwicklung geschieht dabei im Platform Builder von Microsoft. DerPlatform Builder wird mit samtlichen Werkzeugen ausgeliefert, die fur die Ent-wicklung, das Testen und das Debuggen von Windows Mobile-Plattformen beno-tigt werden. Mehr Informationen zum Platform Builder kann auf [MS:06] unter

”About Platform Builder“ gefunden werden.

2.2.8 Schnittstellen zum Betriebssystem

Die Schnittstelle zum Betriebssystem fur Anwendungsprogramme wird auf un-terster Schicht durch die System Calls (auch Syscalls) realisiert. Diese werden vonden verschiedenen Programmbibliotheken der Windows-API gekapselt. Program-mierer einer hoheren Programmiersprache brauchen sich deswegen in der Regelnicht mit Syscalls zu beschaftigen. Die zugehorigen API-Funktionen sind oftmals

10


einfacher zu bedienen als die entsprechenden Syscalls.

Syscalls werden ublicherweise uber Software Interrupts (kurz SWI) ausgelost. Je-de Prozessor-Architektur verfugt uber eine spezielle Instruktion, mit der mandie SWI aufrufen kann. Unter x86-Assembler ist dies die Anweisung int. BeimARM-Assembler nutzt man die swi-Instruktion. Windows Mobile verwendet je-doch eine andere Technik um Syscalls zu implementieren. Ein Syscall wird aus-gelost, indem der aufrufende Prozess einen Sprung zu einer ungultigen Adres-se ausfuhrt. Dieser Sprung erzeugt eine Prefetch-Abort-Trap, welche vom System-prozess nk.exe abgefangen wird. Diese Ausnahme wird immer dann generiert,wenn der Prozessor eine Instruktion nicht laden konnte. Fur den Speicherbereichder Trap-Adressen ist dieser Umstand gegeben. Der Systemprozess erkennt dannanhand der Adresse die angeforderte Syscall-Funktion und sorgt fur deren Aus-fuhrung. Die Funktionen werden dabei von anderen Serverprozessen ausgefuhrt.Dies sind je nachdem die Prozesse filesys.exe, gwes.exe, device.exe oderservices.exe. (Vgl. Windows CE Dokumentation auf [MS:06] und [Loh06]).

Die Adressen, die fur die Traps verwendet werden, befinden sich im Kernelspei-cher 0xf0000000–0xf0010000. Die Syscalls sind in API-Satze unterteilt, dieverschiedene Aufgabenbereiche haben. Die Abbildung 2.2 zeigt den Ausschnittder Header-Datei kfuncs.h aus dem Windows CE 5.0 SDK, der die zugehorigenAPI-Satznummern definiert.

#define SH_WIN32 0#define SH_CURTHREAD 1#define SH_CURPROC 2#define SH_CURTOKEN 3#define SH_LAST_NOTIFY 16#define SH_GDI 16#define SH_WMGR 17#define SH_WNET 18network redirector#define SH_COMM 19#define SH_FILESYS_APIS 20#define SH_SHELL 21#define SH_DEVMGR_APIS 22#define SH_TAPI 23#define SH_PATCHER 24#define SH_SERVICES 26#define SH_LASTRESERVED 26

Abbildung 2.2: Definition der API-Satze in kfuncs.h

Die Funktionen in jedem API-Satz sind durchnummeriert und in mehreren Datei-en des Windows CE-Quellcodes definiert. Fur den ersten API-Satz SH_WIN32 ist

11

2 Grundlagen

dies die Datei kwin32.c. Ein Ausschnitt der API-Funktionen ist in Abbildung 2.3zu sehen. Die Trap-Adressen der Funktionen konnen durch die Formel

const PFNVOID Win32Methods[] = {[...]

(PFNVOID)SC_CacheRangeFlush, // 34[...]

(PFNVOID)SC_CreateProc, // 53(PFNVOID)SC_CreateThread, // 54

[...](PFNVOID)SC_SetKMode, // 108

[...](PFNVOID)SC_GetModuleHandleW, // 131

[...](PFNVOID)SC_GetProcAddressA, // 144

[...](PFNVOID)SC_LoadLibraryExW, // 148

[...]

Abbildung 2.3: Ausschnitt der APIs in kwin32.c

Adresse = 0xf0010000− 4 · (0xff · Satz + Funktion)

berechnet werden (Vgl. [san05b]). Eine nicht vollstandige Liste von System Callsund den zugehorigen Satz- und Funktionsnummern fur Windows CE 4.2 ist auf[Hen06] zu finden. Diese funktionierten im Test bis einschließlich Windows CE5.1.

Die Trap-Adressen konnen außerdem uber einen Remote Debugger, wie dem vonMicrosoft Visual Studio, bestimmt werden. Wird beispielsweise die API-FunktionMessageBox verwendet, so kann man im Einzelschrittmodus erkennen, dass in-nerhalb der API ein Sprung zu der Adresse 0xf000bb38 vollzogen wird.

2.2.9 Trusted Environment

Windows Mobile 5.0 bietet den Gerateherstellern die Moglichkeit, zusatzliche Si-cherheit bei der Ausfuhrung von Programmen zu gewahrleisten, indem es dieErstellung eines Trusted Environment unterstutzt. In einer solchen Umgebung istes moglich Sicherheitsmechanismen zu implementieren, die das Betriebssystemvor unsicheren Anwendungen schutzen. Sie verhindern das Laden von nicht ver-trauenswurdigen Modulen, die Beschrankung des Zugriffs auf die verschiedenenAPIs und einen Schreibschutz fur bestimmte Bereiche der Windows Registry.

12


Ob eine Anwendung vertrauenswurdig ist, wird mit Hilfe einer digitalen Signaturin der Anwendungsdatei entschieden. Dafur ist es notwendig, dass die Entwick-ler ihre Anwendungsdateien im Rahmen des Mobile2Market Zertifizierungs- undMarketingprogramms an Microsofts Partner VeriSign oder Geotrust schicken. Diesesignieren die Datein und senden sie an die Entwickler zuruck. Die Anwendungs-dateien erhalten, je nachdem ob sie normal oder privilegiert ausgefuhrt werdensollen, verschiedene Signaturen. Auf den Geraten sind Stammzertifikate vorinstal-liert, uber die entschieden wird, ob eine Anwendung fur normale oder privilegier-te Ausfuhrung signiert wurde. Unabhangig davon, konnen Geratehersteller aucheine eigene Zertifikatsumgebung aufbauen, die sich dann aber nur fur die eigenenGerate verwenden lasst (s. ”Mobile2Market: Certification & Marketing Program“und ”Codesigning for Windows Mobile-based Smartphones and Pocket PCs“ auf[MS:06]).

Das Trusted Environment gilt allgemein fur alle ausfuhrbaren Module. Modulesind hierbei Anwendungen, Programmbibliotheken und auch Geratetreiber. Esexistieren drei mogliche Einstufungen fur ein Modul. OEM_CERTIFY_TRUST be-deutet, dass das Modul privilegierten Zugriff auf das System hat. Eine Einstufungals OEM_CERTIFY_RUN erlaubt die Ausfuhrung des Moduls, verbietet jedoch denZugriff auf einen privilegierten Teil der Windows-API (Trusted API) und Teile derWindows Registry. Einem Modul, das als OEM_CERTIFY_FALSE eingestuft wor-den ist, wird die Ausfuhrung komplett untersagt. Im letzten Fall war die Signaturentweder nicht vorhanden oder ungultig.

Fur Pocket PCs ist auch fur die Verwendung der privilegierten Funktionen nurein OEM_CERTIFY_RUN notwendig. Eine Ausnahme sind die Geratetreiber, die alsOEM_CERTIFY_TRUST signiert werden mussen. Zusatzlich hat der Benutzer dieMoglichkeit Anwendungen zu erlauben, die nach ihrer Signatur zufolge nicht auf-gefuhrt werden durften. Das Betriebssystem fragt dazu bei der Ausfuhrung nacheiner Bestatigung des Benutzers. Wird die Ausfuhrung erlaubt, so stehen dem Pro-gramm alle Funktionen, auch die privilegierten, zur Verfugung. Auf Smartphonesist immer eine Einstufung als OEM_CERTIFY_TRUST notig, damit privilegierteFunktionen verwendet werden konnen. Unsignierte Anwendungen konnen aus-gefuhrt werden, wenn der Benutzer dies bestatigt. Sie haben jedoch keinen Zugriffauf die privilegierten Funktionen des Systems.

Fur die Verwendung einer Trusted Environment ist die Deaktivierung des Full-Kernel Modes notwendig. Eine detailliertere Beschreibung der Trusted Environ-ment kann auf [MS:06] unter ”Trusted Environment Creation“gefunden werden.Unter ”Codesigning for Windows Mobile-based Smartphones and Pocket PCs“sind weitere Informationen zur Signierung von Programmen zu finden.

13

2 Grundlagen

2.2.10 Security Cookies

Microsoft implementiert einen Stack-Schutz fur Windows Mobile 5.0, der sicher-stellt, dass Pufferuberlaufe welche die Rucksprungadresse uberschreiben, nichtausgenutzt werden konnen. Dazu wird ein vier Byte großer so genannter Securi-ty Cookie (auch Canary) zwischen Rucksprungadresse und den lokalen Variablenplatziert. Der Cookie wird beim Starten einer Funktion auf den Stack gelegt. EineKopie dieses Cookies ist immer als Referenz im Datenbereich des Prozesses ge-speichert. Bevor eine Funktion beendet wird, wird der Cookie auf dem Stack mitseiner Referenz im Datenbereich verglichen. Unterscheiden sich die beiden Werte,so hat ein lokaler Puffer den Cookie auf dem Stack uberschrieben und es wird einAusnahmefehler generiert, der den Prozess vorzeitig beendet. Fur jeden Prozesswird der Security Cookie ausreichend zufallig festgelegt. Es gibt also nur eine Re-ferenz des Cookies im Datenbereich, die fur alle Funktionen verwendet wird. Fureine genaue Beschreibung dieser Option siehe [MS:06] unter ”Compiler SecurityChecks In Depth“und [Bra04].

2.2.11 Zusammenfassung

Der Abschnitt behandelte Grundlagen zu Windows Mobile 5.0, die fur die weitereArbeit gebraucht werden. Es wurden allgemeine Informationen zum Betriebssys-tem gegeben, die ActiveSync-Schnittstelle sowie der Unterschied zwischen PocketPCs und Smartphones erlautert. Zudem wurde die Speicher- und Prozessarchitek-tur, das OEM Adaptation Layer, die Schnittstellen zum Betriebssystem, das Trus-ted Environment und der Stack-Schutz durch Security Cookies erklart.

Der nachsten Abschnitt behandelt die ARM-Architektur.

2.3 ARM-Architektur

2.3.1 Einleitung

Der folgende Abschnitt behandelt die Grundlagen der ARM-Architektur, da dieProzessoren fur Windows Mobile 5.0-Gerate nach dieser Prozessorarchitektur im-plementiert werden. Zunachst werden die verschiedenen Instruktionen und Re-gister dieser Prozessoren beschrieben. Danach wird aufgezeigt, wie die Parame-terubergabe von Unterprogrammen in der ARM-Architektur funktioniert. An-schließend wird die Bedeutung der RISC-Architektur erwahnt und die Effekte derHarvard-Architektur fur Speicherzugriffe beschrieben

14

2.3 ARM-Architektur

2.3.2 Allgemeines zu ARM

Das Betriebssystem Windows Mobile 5.0 unterstutzt ausschließlich Prozessorender ARM-Architektur. Die ARM-Architektur ist eine Spezifikation fur Prozesso-ren von der Firma Advanced RISC Machines (ARM). Die Firma ARM baut sel-ber keine Prozessoren, sondern entwickelt die CPU-Spezifikationen und verkauftdiese an Lizenznehmer. Die ARM-Architektur beschreibt Prozessoren, die einesehr kleine Baugroße aufweisen und trotzdem eine hohe Leistung liefern konnen.Die kleine Bauweise und die einfachen Strukturen machen diese Prozessoren sehrenergiesparend. Zudem ist die produzierte Abwarme sehr gering.

Die Informationen in diesem Abschnitt sollen einen Uberblick uber die ARM-Architektur geben. Eine umfangreichere Einleitung kann in [Sea00] gefunden wer-den. Fur die Schreibweise der Instruktionen wird die GNU ARM Assembler Syntax(s. [GNU]) verwendet.

2.3.3 Instruktionen

Hier werden einige Instruktionen der ARM-Prozessoren erlautert. Die maschi-nensprachlichen Instruktionen werden in Assembler durch ihre Mnemonics dar-gestellt.

• Verzweigungen

b marke # Sprung zu ’marke’bl funktion # Funktionsaufruf mit Sicherung

# der Rucksprungadressebeq marke # Sprung zu ’marke’, wenn beim

# letzten Vergleich Gleichheit# festgestellt wurde

• Arithmetische/Logische Instruktionen

and r0, r1, r2 # r0 = r1 AND r2sub sp, sp, #0xc # sp = sp - 12

• Vergleichsinstruktionen

cmp r0, r1 # r0 == r1?cmp r0, #4 # r0 == 4?

• Load/Store-Instruktionen

15

2 Grundlagen

ldr r12, [sp] # Lade Wert von Adresse# sp nach Register r12

str r0, [r4, #0xc] # Speichere Wert von# r0 an Adresse r4+12

• Coprozessor-Instruktionen

mrc p15, 0, r0, c1, c0mcr p15, 0, r0, c1, c0

Alle Instruktionen konnen bedingt ausgefuhrt werden, indem Suffixe wie eq fur

”gleich“ oder gt fur ”großer als“ an die Mnemonics angehangt werden. Auf die-sem Weg werden beispielsweise die Programmverzweigungen durch bedingteSprunge vollzogen.

ARM-Prozessoren konnen in verschiedenen Modi laufen. In dieser Arbeit sindnur der User Mode und der System Mode interessant. Der System Mode ist der pri-vilegierte Prozessormodus, in dem z. B. auch Puffer und Caches gesteuert werdenkonnen. Windows Mobile schaltet in den System Mode des Prozessor, wenn dasBetriebssystem im Kernel Mode ausgefuhrt wird.

2.3.4 Register

ARM-Prozessoren besitzen 31 Allzweckregister mit je 32 Bit, von denen immernur 16 Register gleichzeitig sichtbar sind. Die restlichen werden fur die Beschleu-nigung von Ausnahmenbehandlungen verwendet. Ublicherweise verwendet mandie Allzweckregister r0–r13, das Linkregister r14 (oder lr), den Programmzei-ger r15 (oder pc) und die Statusregister cpsr und spsr.

Die Register r0–r13 haben keine spezifische Aufgabe und konnen von der Soft-ware frei verwendet werden. Das Linkregister wird bei Funktionsaufrufen alsRucksprungadresse verwendet. Instruktionen wie bl setzten das Linkregister au-tomatisch. Der Programcounter enthalt die Adresse der nachsten auszufuhrendenInstruktion. Wird er ausgelesen, so wird die Adresse der Instruktion plus achtByte zuruckgegeben. Wird eine Adresse in den Programcounter geschrieben, sofuhrt der Prozessor die nachste Instruktion an dieser Adresse aus. Die Statusre-gister werden unter anderem dazu verwendet, um nach Vergleichsoperationenbedingte Sprunge oder andere Anweisungen auszufuhren.

16

2.3 ARM-Architektur

2.3.5 Unterprogramme und Parameterubergabe

Der ARM Architecture Procedure Call Standard (AAPCS) definiert unter anderemwie in der ARM-Architektur Parameter an Unterprogramme ubergeben werdenund wie der Ruckgabewert an das aufrufende Programm zuruckgegeben wird.Fur die ersten vier Parameter bei dem Aufruf eines Unterprogramms werden dieRegister r0–r3 verwendet. Werden mehr Parameter benotigt, so muss zusatzlich,wie in der x86-Architektur, der Stack fur die Ubergabe verwendet werden. DerRuckgabewert eines Unterprogramms wird uber das Register r0 zuruckgegeben.Eine vollstandige Abhandlung kann in [Ear06] gefunden werden.

2.3.6 RISC-Architektur

ARM-Prozessoren sind Reduced Instruction Set Computer (RISC), also Rechner, diemit einem minimalen Satz an Instruktionen fester Lange auskommen und die ubereine große Zahl an Registern verfugen. Sie arbeiten nach dem Load/Store-Prinzip,bei dem Datenoperationen nur in den Registern ausgefuhrt werden konnen undnicht im Hauptspeicher. Um Speicherwerte zu manipulieren, mussen diese zuerstin Register geladen und nach der Manipulation wieder in den Speicher zuruckgeschrieben werden. Die Instruktionen der ARM-Prozessoren sind alle vier Bytelang. Einige ARM-Prozessoren, wie die Intel XScale Prozessoren (s. [Int04] und[Int06]), erlauben den Einsatz eines zweiten Instruktionssatzes, des so genanntenThumb Mode. In diesem Modus sind alle Instruktionen nur noch zwei Byte lang.

2.3.7 Harvard-Architektur

ARM-Prozessoren implementieren die Harvard-Architektur bezuglich des Zugriffsauf den Hauptspeicher (s. Abb. 2.4). Die Harvard-Architektur besitzt, anders alsdie klassische Von-Neumann-Architektur, getrennte Speicherleitungen fur Instruk-tionen und Daten. Die Instruktionsleitung wird verwendet, wenn der ProzessorInstruktionen aus dem Hauptspeicher nachladen muss. Die Datenleitung wird im-mer dann gebraucht, wenn Daten aus dem Hauptspeicher gelesen oder in ihn ge-schrieben werden mussen (Load/Store). Jede Leitung kann dabei eigene Schreib-puffer, Lesepuffer und Caches besitzen, die jeweils unabhangig von den Puffernund Caches der anderen Leitungen arbeiten.

Durch die Separation kann es zu Inkonsistenzen kommen. Der Instruktionsbushat einen Vorratspuffer, den so genannten Prefetch-Buffer. Dieser halt Instruktionenbereit, die vermutlich in Zukunft ausgefuhrt werden. Der Datenbus besitzt einenSchreibcache. Dieser kann entweder als Write-Trough-Cache oder Write-Back-Cache

17

2 Grundlagen

implementiert sein. Ein Write-Trough-Cache kopiert Daten in den Speicher, un-mittelbar nachdem sie in den Cache geschrieben worden sind. Im Gegensatz dazukopiert ein Write-Back-Cache die Daten erst dann in den Speicher, wenn die Ca-cheleitung fur andere Speicherbereiche verwendet werden soll. [Sea00] gibt wei-tere Informationen uber Caches und Puffer und der Separation von Instruktions-und Datenleitung.

Abbildung 2.4: Die Harvard-Architektur


Dieser Abschnitt informierte uber die Grundlagen der ARM-Architektur. Nachder Erlauterung von allgemeinen Informationen wurden die Instruktionen undRegister der ARM-Prozessoren beschrieben. Desweiteren wurde die Parameter-ubergabe zwischen Unterprogrammen sowie die RISC-Architektur erklart. ZumSchluss wurden noch Effekte der Harvard-Architektur aufgezeigt, welche diverseSpeicherzugriffe beeinflussen.

Der nachste Abschnitt definiert verschiedene Begriffe aus dem Bereich Malware.

2.4 Malware

Mit Malware (”Malicious Software“) bezeichnet man eine ganze Reihe von schad-hafter Software. Darunter fallen z. B. Computerviren, Computerwurmer, Trojani-sche Pferde, Backdoors und Spyware. Dieser Abschnitt fuhrt die verschiedenenBegriffe nach den Definitionen aus [Ayc06] ein.

Ein Computervirus ist eine Malware, die bei Ausfuhrung versucht, sich in einen an-deren ausfuhrbaren Code zu kopieren. Gelingt dies, so wurde dieser Code infiziert.Der infizierte Code kann nun erneut weiteren Code infizieren. Diese Selbstrepli-zierung in bereits vorhandenen ausfuhrbaren Code ist die Hauptcharakteristik

18

2.5 Fuzzing

eines Computervirus. Ublicherweise verbreiten sich Viren innerhalb eines einzi-gen Rechners. Sie konnen sich auch von einem Computer zum anderen verbrei-ten. Dies geschieht dann jedoch nur uber manuell transportierte Medien, wie Dis-ketten, CD-ROMs oder USB-Flash-Geraten. Mit anderen Worten: Viren verbreitensich nicht uber Computernetzwerke.

Ein Computerwurm hat viele Gemeinsamkeiten mit einem Computervirus. Com-puterwurmer sind auch selbstreplizierend, aber sie unterscheiden sich von denComputerviren auf zwei Arten. Zum einen sind sie selbststandig und nicht vonanderem ausfuhrbarem Code abhangig. Zweitens verbreiten sie sich uber Netz-werke von einem Rechner zum anderen. Der bekannteste Computerwurm ist derMorris Computerwurm, der nach seinem Erschaffer Robert Morris benannt wurdeund 1988 im Internet kursierte.

Ein Trojanisches Pferd ist ein Programm, welches vorgibt etwas Gutes zu leisten,jedoch insgeheim zusatzlich schadhafte Aktionen durchfuhrt. Eine Backdoor istein Mechanismus, der normale Sicherheitsuberprufungen umgeht. Unter Spywareversteht man Software, die Informationen auf einem Computer sammelt und die-se an jemand anderen verschickt.

Im nachsten Abschnitt werden Begriffe aus dem Bereich Fuzzing erklart.

2.5 Fuzzing

2.5.1 Einleitung

Dieser Abschnitt behandelt Fuzzing als Vorgehensweise fur die Suche nach Sicher-heitslucken. Es werden grundlegende Begriffe erlautert und im Speziellen auf dasSPIKE Fuzzer Creation Kit eingegangen.

2.5.2 Begriffsklarung

Fuzz-Testing oder Fuzzing ist die automatisierte Suche nach Sicherheitslucken inSoftware. Dabei werden semi-gultige Eingaben generiert, die Fehler in der Softwa-re auslosen sollen. Die einfachste Art Fuzzing anzuwenden ist die Erstellung vonrein zufalligen Eingaben. Dabei kann es jedoch passieren, dass die Software die-se Eingaben verwirft, weil sie bereits durch einfache Uberprufungen als ungultigerkannt werden. Der Trick ist die Eingaben moglichst in der Struktur zu bauen,wie sie von der Software erwartet wird. Einzelne Teile der Eingabe konnen dabei

19

2 Grundlagen

manipulieren werden, damit Fehler in tieferen Schichten der Software provoziertwerden.

Fur ein erfolgreiches Fuzzing mussen Informationen uber die Struktur der Einga-ben bekannt sein. Diese konnen z. B. durch das Mitschneiden von gultigen Einga-ben in Erfahrung gebracht werden. Das Fuzzing beschaftigt sich in dem Fall mitder Manipulation dieser gultigen Eingaben fur die Erstellung von fehlerprovozie-renden Eingaben.

Ausfuhrliche Abhandlungen zum Themas Fuzzing sind von van Sprundel [Spr05]und anderen [Ait02, Jur06, DeM06] veroffentlicht worden. Auf [Koz05] ist einegroße Zahl an Fuzzing-Werkzeugen aufgelistet. In dieser Arbeit wurde fur dasFuzzing das SPIKE-Framework ausgewahlt. Der nachste Unterabschnitt gibt eineUbersicht uber den Ansatz und die Benutzung von SPIKE.

2.5.3 Das SPIKE Fuzzer Creation Kit

Das SPIKE Fuzzer Creation Kit stellt eine generische Fuzzing-API fur die Program-miersprache C zur Verfugung. Mit ihrer Hilfe konnen Fuzzer auch fur bislang un-bekannte Protokolle sehr schnell entwickelt werden. SPIKE unterstutzt die Kom-munikation uber UDP und TCP, so dass die generierten Daten direkt verschicktwerden konnen. Es besteht die Moglichkeit, die zu fuzzenden Datenstrukturenvom eigentlichen Fuzzer-Programm zu trennen. Dazu werden SPK-Dateien (mitEndung .spk) erstellt, die dann vom Fuzzer eingelesen werden konnen.

SPK-Dateien beschreiben die Strukturen von Protokollnachrichten oder anderenEingaben, die fur den Test der Software verwendet werden. In ihnen gibt es kon-stante Elemente, die z. B. mit den folgenden Schlusselwortern gebaut werden.

// konstante binare Datens_binary("00 01 02 03");// konstante Zeichenkettes_string("Zeichenkette");// Zeichenkette aus 100 ’A’ss_string_repeat("A",100);

Zudem gibt es die SPIKE-Variablen, die fur das automatische Fuzzing verwendetwerden. Diese Variablen werden beispielsweise so deklariert:

// Integervariable (1 Byte)s_int_variable(0x15, 3);// Integervariable (2 Byte, Little Endian)

20

2.6 Zusammenfassung

s_int_variable(0x0cc0, 4);// Zeichenkettenvariables_string_variable("Erste Zeichenkette");

Fur Integervariablen muss als zweiter Parameter ein Typ angegeben werden. Die-ser legt fest, wie der Integerwert kodiert wird. Dadurch wird sichergestellt, dassder Wert so verwendet wird, wie das Protokoll es vorschreibt. Die verschiedenenTypen sind in der Datei include/listener.h definiert:

#define BINARYBIGENDIAN 1#define ASCII 2#define ONEBYTE 3#define BINARYLITTLEENDIANHALFWORD 4#define BINARYBIGENDIANHALFWORD 5#define ZEROXASCIIHEX 6#define ASCIIHEX 7#define ASCIIUNSIGNED 8#define INTELENDIANWORD 9

Der erste Parameter stellt den Standardwert fur die Variable dar. Dieser wirdwahrend des Fuzzing durch andere, von SPIKE ausgewahlte Werte, belegt. Beimautomatischen Fuzzing mit SPIKE werden alle Variablen der Reihe nach gefuzzt.Jede Variable wird dabei mit verschiedenen Werten belegt, die typischerweise zuFehlern in Software fuhren. Wurden samtliche Variablen mit samtlichen mogli-chen Werten belegt, so ist ein kompletter Fuzzinglauf beendet.

Weitere Informationen zur API konnen in der Dokumentation und dem Quellcodevon SPIKE nachgelesen werden (s. Anhang A).


Der Abschnitt klarte die Grundlagen von Fuzzing und gab einen Uberblick uberdas SPIKE Fuzzer Creation Kit. SPIKE wird in Kapitel 4 verwendet, um Sicher-heitslucken durch Fuzzinglaufe aufzudecken.

2.6 Zusammenfassung

In diesem Kapitel wurden Informationen zu Windows Mobile 5.0, der ARM-Ar-chitektur, Malware und Fuzzing gegeben. Die Grundlagen von Windows Mobile

21

2 Grundlagen

5.0 und der ARM-Architektur werden fur die Ausnutzung von Sicherheitsluckenund der Entwicklung von Shellcode im Rahmen des Computerwurmbaukastensbenotigt. Der Abschnitt uber Malware definierte verschiedene Begriffe fur die Un-terscheidung von schadhafter Software, die in dieser Arbeit erwahnt wird. Zuletztwurden Grundlagen zu Fuzzing erlautert, die im Kapitel 4 fur die Suche nach Si-cherheitslucken benotigt werden.

Das folgende Kapitel wird sich nun mit der Entwicklung des Baukastens fur einenComputerwurm fur Windows Mobile 5.0 beschaftigen.

22

3 Entwicklung eines Baukastens fureinen Computerwurm

3.1 Einleitung

Im letztem Kapitel wurden notwendige Grundlagen erarbeitet. In diesem Kapitelgeht es nun um die ersten Voraussetzungen, die fur die Verbreitung von Com-puterwurmern notwendig sind. Die Voraussetzungen sind technischer Natur undbeziehen sich auf Eigenheiten des Betriebssystems Windows Mobile 5.0 und derARM-Architektur der mobilen Gerate. Im Rahmen dieses Kapitels wird ein Bau-kasten fur einen Computerwurm entwickelt. Dieser soll sich auf Windows Mobile5.0-Geraten verbreiten konnen. Die verschiedenen Probleme die einem Computer-wurmautor begegnen, werden dabei uberwunden. Das Ergebnis ist ein Machbar-keitsnachweis fur einen Computerwurm, der sich uber eine konstruierte Sicher-heitslucke auf Windows Mobile-Geraten verbreiten kann.

3.2 Aufbau des Baukastens

Der Baukasten soll einen Machbarkeitsnachweis fur Computerwurmer unter Win-dows Mobile 5.0 darstellen und die Bedrohung fur mobile Gerate aufzeigen. DieKomponenten des Baukastens werden unabhangig voneinander entwickelt undnicht zu einem funktionierenden Computerwurm zusammengestellt. Insbeson-dere wird die Infizierungsfunktion fur den Computerwurm nicht fur eine realeSicherheitslucke entwickelt. Dies soll ausschließen, dass der Baukasten von tech-nisch weniger versierten Personen missbraucht werden kann. Der Quellcode desBaukastens wird nicht fur die Offentlichkeit zuganglich sein.

Der Baukasten setzt sich aus den drei Komponenten Infizierung, Verbreitung undder Schadensfunktion zusammen. Mit Infizierung ist der Vorgang gemeint, beidem ein Computerwurm uber eine Sicherheitslucke eines Programms in ein Sys-tem eindringt und sich dort manifestiert. Die Manifestierung ist vollzogen, wennsich der Computerwurm in das ausgenutzte Programm integriert hat, seinen ei-genen Code ausgefuhrt hat und die Schnittstellen zum Betriebssystem verwenden

23

3 Entwicklung eines Baukastens fur einen Computerwurm

kann. Eine langerfristige Manifestierung, die sogar einen Reboot des Gerates uber-leben wurde, ist ein zusatzlicher Pluspunkt. Die Infizierung stellt den aufwen-digsten, problematischsten und den am ausfuhrlichsten beschriebenen Abschnittdieses Kapitels in Abschnitt 3.3 dar. Es wird auf samtliche Probleme eingegangen,die bei der Entwicklung von so genanntem Shellcode auftreten. Dabei werden aufBesonderheiten der ARM-Architektur und des Betriebssystems Windows Mobile5.0 eingegangen.

Die Verbreitung in Abschnitt 3.4 ist der Programmteil eines Computerwurms, dersich um die Auswahl weiterer zu infizierender Gerate im Netzwerk bemuht. Da-bei ist vor allem die Entdeckung dieser Gerate und der Auswahlalgorithmus inter-essant. Die letzte Komponente, die Schadensfunktion in Abschnitt 3.5, ist der Teil,der das eigentliche bosartige Verhalten des Computerwurms bestimmt. In diesemAbschnitt wird bereits klar sein, dass sich beliebige Schadensfunktionen einbau-en lassen und es werden verschiedene mogliche Varianten bezuglich dieses Teilsdiskutiert.

Der gesamte Quellcode kann auf der beiliegenden CD gefunden werden. In An-hang B ist der Inhalt der CD aufgelistet.

3.3 Die Infizierung

3.3.1 Einleitung

In diesem Abschnitt wird die Infizierungfunktion des Computerwurms entwi-ckelt. Dafur wird eine Stack-basierte Sicherheitslucke in eine Testanwendung ein-gebaut, mit der exemplarisch die Durchfuhrbarkeit einer Infizierung gezeigt wer-den kann.

Es wird gezeigt, wie Prozessorinstruktionen (Shellcode) uber eine Benutzereinga-be des Testprogramms eingeschleust und anschließend vom Prozessor ausgefuhrtwerden konnen. Dabei wird das Problem der Harvard-Architektur fur Speicher-zugriffe gelost. Durch dieses Problem wurde der Shellcode ansonsten nicht zu-verlassig ausgefuhrt werden. In den Arbeiten von Hurman [Hur05b] und San[san05b] wurde dieses Problem nicht vollstandig gelost, da ihre Ansatze nicht aufallen Geraten funktionieren. In Abschnitt 3.3.9 wird eine zuverlassige Losung furdieses Problem vorgestellt.

Fur das auftretende Großenproblem des Shellcode wird zudem eine Unterteilungin Stages vorgenommen. Die eigentliche Nutzlast des Shellcodes wird in der zwei-ten Stage als ausfuhrbare EXE-Datei untergebracht. Diese wird auf das Dateisys-

24

3.3 Die Infizierung

tem des mobilen Gerats kopiert und anschließend ausgefuhrt. Auf diesem Wegwird gewahrleistet, dass das eigentliche Programm des Computerwurms spaterin einer hoheren Programmiersprache entwickelt werden kann.

Das letzte Problem ist der Zugriff auf die Schnittstellen des Betriebssystems. Die-ser ist notwendig, um Kontrolle uber Netzwerk und andere Ressourcen des Be-triebssystems zu erlangen. Fur Windows CE 4.2 gibt es einen Ansatz von Hur-man, der aber nicht mehr unter Windows Mobile 5.0 funktioniert. Deswegen wirdin Abschnitt 3.3.10 ein neuer Ansatz entwickelt, der das Problem mit Hilfe vonSystem Calls vollstandig lost.

Zum Schluss des Abschnitts 3.3 steht ein Exploit fur die konstruierte Sicherheits-lucke des Testprogramms zur Verfugung, der zuverlassig ausgefuhrt werden kannund somit fur einen Computerwurm ideal ware.

3.3.2 Voraussetzungen

Damit eine Infizierung moglich ist, mussen gewisse Umstande gegeben sein. Zu-erst ist es notwendig, dass sich der Programmfluss des Systems durch den Com-puterwurm direkt beeinflussen lasst. Dies geschieht, indem der ComputerwurmKontrolle uber die CPU erlangt und ihr die auszufuhrenden Maschinenbefehlevorgibt. Dies kann etwa durch Pufferuberlaufe geschehen (siehe z. B. [Koz04] und[MSK03]).

Zweitens muss der injizierte Code die selben Moglichkeiten auf dem System er-halten, die auch ein normal ausgefuhrtes Programm besitzen wurde. Nur uberdie Schnittstellen zum Betriebssystem ist es moglich, auf Netzwerke, Dateisys-teme und andere Ressourcen zuzugreifen. Da der Code des Computerwurms ineinen fremden Kontext eingefugt wird, namlich in einen bereits laufenden Pro-zess, ist dies nicht ganz einfach. Insbesondere bei dem Betriebssystem WindowsMobile 5.0 auf Prozessoren der ARM-Architektur muss der Autor eines Compu-terwurms viele Probleme losen. Diese Probleme werden im Laufe der folgendenAbschnitte 3.3.5–3.3.12 beschrieben und gelost.

Es existieren bereits Beispiele fur die Ausnutzung von Windows CE 4-Geratenuber Stack-basierte Pufferuberlaufe (s. [Hur05b, san05b, Hur05a, san05a]). UnterWindows Mobile 5.0 sind diese jedoch nicht funktionsfahig. Aus diesem Grundwird der Shellcode, der fur eine solche Infizierung notig ist, neu entwickelt. Anden Punkten, wo sich das Vorgehen von den anderen Arbeiten unterscheidet,wird speziell auf die Unterschiede eingegangen. Bei der Entwicklung kommenzum Teil neue Problemlosungen und andere Vorgehensweisen zum Einsatz. DerSchwerpunkt bei der Erstellung des Shellcodes ist die Zuverlassigkeit in Bezugauf Gerate- und Systemunabhangigkeit. Dies ist eine wesentliche Voraussetzung

25


dafur, dass sich ein Computerwurm auf moglichst vielen Geraten verbreiten kann.

3.3.3 Werkzeuge fur die Entwicklung

Die Entwicklung des Shellcodes erfolgt mit dem GNU Assembler (GAS) unter Li-nux, der fur das Zielsystem arm-wince-pe ubersetzt worden sein muss. DerGAS ist in den binutils von GNU enthalten. Fur die korrekte Ubersetzung derInstruktionen fur ARM-Assembler ist zum Zeitpunkt dieser Arbeit die aktuellsteVersion aus dem CVS-Repository notwendig. Altere Versionen ubersetzten einigeSprungbefehle falsch. Die verwendeten Programmversionen konnen in Anhang Agefunden werden.

3.3.4 Stack-basierter Pufferuberlauf

Stack-basierte Pufferuberlaufe sind weit verbreitete Auswirkungen von Program-mierfehlern in den Programmiersprachen C/C++. Aus diesem Grund soll die In-fizierung exemplarisch am Beispiel eines Stack-basierten Pufferuberlaufs gezeigtwerden.

Abbildung 3.1: Der Stack-Frame

Die Ausnutzung von Stack-basierten Pufferuberlaufen unter Windows Mobile 5.0unterscheidet sich zunachst einmal nicht von der Ausnutzung unter anderen Sys-temen. Ein lokaler Puffer in einer Funktion wird durch Benutzereingaben uber

26

3.3 Die Infizierung

seine Große hinaus beschrieben. Dadurch werden die nachfolgenden Speicher-adressen auf dem Stack (s. Abb. 3.1) mit Werten belegt, die der Benutzer vor-geben kann. Dies betrifft auch die Speicheradresse, in der sich die Rucksprung-adresse der Funktion befindet. Wird diese beschrieben, so setzt das Programmdie Ausfuhrung an der veranderten Rucksprungadresse fort, sobald die laufendeFunktion beendet wird.

Die Rucksprungadresse zeigt nun auf einen Speicherbereich, den der Benutzer un-ter Kontrolle hat. Hier wird in der Regel die Adresse des Puffers gewahlt, uber denman die Rucksprungadresse uberschrieben hat. Im ersten Teil des Puffers werdendeshalb bewusst Maschinenbefehle hinterlegt, die von der CPU ausgefuhrt wer-den konnen. Dies ist der Shellcode.

Fur eine genaue Beschreibung von Stack-basierten Pufferuberlaufen und wie mandiese im Allgemeinen ausnutzt, seien [One96], [Koz04] und [MSK03] empfohlen.

3.3.5 Die Rucksprungadresse

Beim Uberschreiben der Rucksprungadresse wird die Adresse des uberlaufendenPuffers verwendet, damit der Shellcode ausgefuhrt werden kann. Der Prozess desauszunutzenden Programms befindet sich mitsamt Stack und anderen Daten ineinem Speicher-Slot. Dieser wurde ihm vom Betriebssystem zugeordnet. Die Spei-cheradresse des Puffers in diesem Slot kann bis auf das erste Byte – das hochst-wertige – vorher bestimmt werden; beispielsweise uber Debugging. Das erste Bytebestimmt die Nummer des Slots und wird je nach Belegung der anderen Slots ver-geben. Ein paar Slots sind immer von den gleichen Systemprozessen belegt, trotz-dem kann die Slotnummer eines beliebigen Prozesses nicht eindeutig bestimmtwerden (vgl. Abschnitt 2.2.5 und 2.2.6).

Da jeder Slot bei Ausfuhrung des zugehorigen Prozesses auch durch den Slot Nulladressierbar ist, wird die echte Slotnummer nicht benotigt. Das hochstwertigeByte der Rucksprungadresse kann deswegen auf Null gesetzt werden.

3.3.6 Security Cookies

Der Stack-Schutz durch Security Cookies stellt ein wesentliches Hindernis bei derAusnutzung von Stack-basierten Pufferuberlaufen dar. Um Security Cookies ver-wenden zu konnen, mussen die jeweiligen Programme beispielsweise unter Mi-crosoft Visual Studio mit der Option /GS compiliert werden. Bezuglich der Uber-setzung des Betriebssystems fur Windows Mobile muss diese Option im PlatformBuilder gesetzt werden. Da eine Uberprufung des Stacks zur Laufzeit eine gewisse

27


Rechenzeit beansprucht, haben viele Geratehersteller in der Vergangenheit dieseOption fur ihre OEM-Versionen von Windows Mobile deaktiviert. Dies gilt z. B.fur die Gerate, die in [Hur05b] und [san05b] getestet wurden. Auf ihnen liefenjedoch altere Versionen von Windows Mobile, so dass dieser Umstand fur neueGenerationen nicht mehr gegeben sein muss. In Abschnitt 4.3.2 wird gezeigt wer-den, dass Security Cookies bei der Ubersetzung von Windows Mobile 5.0 durch-aus verwendet wurde. Das Testprogramm mit der konstruierten Sicherheitsluckewird fur die Entwicklung des Baukastens ohne Security Cookies ubersetzt.

3.3.7 Unterteilung des Shellcodes in Stages

Die Benutzereingabe, die den Puffer fullen soll, ist meist auf eine bestimmte Großebeschrankt. Deswegen muss der Shellcode mit moglichst wenigen Instruktionenauskommen. Fur Linux-Systeme auf x86-Architekturen existieren Shellcodevari-anten mit ca. 40 Bytes Lange, die bei Einschleusung den Zugriff auf das Systemerlauben (s. Metasploit Project auf [Met]).

Fur Windows Mobile 5.0 auf ARM-Prozessoren ist die Lange des benotigten Shell-codes sehr viel großer (mehrere 100 Bytes). Dies hat verschiedene Grunde. ZumEinen belegt eine Instruktion der ARM-Prozessoren immer vier Byte; im Gegen-satz zu x86-Prozessoren, bei denen einfache Instruktionen mit zwei Byte auskom-men. Durch die feste Lange der Instruktionen konnen ARM-Prozessoren jedocheinfachere Instruktionsdecoder implementieren. Dies macht sie sparsamer und inder Produktion kostengunstiger. Es existiert die Moglichkeit, in den so genanntenThumb Mode zu wechseln, in dem jede Instruktion nur noch zwei Bytes belegt. Die-ser zusatzliche Satz an Instruktionen wird aber nicht von allen ARM-Prozessorenimplementiert. Im Hinblick darauf, dass der Shellcode fur einen Computerwurmverwendet werden soll, ist der Einsatz des Thumb-Modes nicht sinnvoll. Dieswurde eine unbestimmte Anzahl von Geraten von der Infizierung ausschließenund die Verbreitung des Computerwurms negativ beeintrachtigen.

Weiterhin ist es bei der ARM-Architektur nicht moglich, Werte im Arbeitspeichermit einer einzelnen Instruktion zu manipulieren. Speicherwerte mussen immerzuerst in CPU-Register geladen und nach der Manipulation wieder gesichert wer-den. Dazu sind also mindestens drei Instruktionen notwendig. Dieses Load/Store-Prinzip ist ein weiterer Unterschied zu der x86-Architektur, der den Shellcode mit-unter wesentlich vergroßert (s. a. [Sea00]).

Eine weitere Vergroßerung des Shellcodes entsteht durch die Verwendung der Be-triebssystemschnittstelle von Windows. Shellcode fur Linux nutzt haufig einenSystem Call fur den Aufruf eines Shell-Interpreters. Ein Shell-Interpreter unterLinux ist machtig genug, um das gesamte System zu kontrollieren. Das Pendantzum Linux-Shell-Interpreter unter Windows ist die Kommandozeile cmd.exe. Sie

28

3.3 Die Infizierung

bietet nicht annahernd die gleiche Funktionalitat (s. [Koz04]), deswegen ergibt eswenig Sinn sich mit ihr zu beschaftigen. Als Ersatz steht die Windows-API zurVerfugung, fur deren Einbindung in den Shellcode jedoch Vorarbeiten und eineMenge Instruktionen notwendig sind. Auf die genaue Vorgehensweise wird in3.3.10 eingegangen.

Es existiert nicht immer eine Losung des Großenproblems. Steht nicht genug Spei-cher im Puffer zur Verfugung, so kann nicht jede beliebige Funktionalitat pro-grammiert werden. Da ein Computerwurm ein sehr komplexes Programm seinkann, soll gewahrleistet werden, dass Shellcode unbestimmter Große ausgefuhrtwerden kann. Zu diesem Zweck wird der Shellcode in zwei Teile aufgeteilt, inso genannte Stages (siehe z. B. [Met]). Die erste Stage enthalt den kleineren Teildes Shellcodes und wird beim Ausnutzen der Schwachstelle in den auszunutzen-den Puffer geschrieben. Sie ist fur das Nachladen der zweiten Stage zustandig.Fur den Baukasten wird davon ausgegangen, dass der Pufferuberlauf uber dasIP-Netzwerk ausgenutzt wird. Deswegen ist es praktisch, die zweite Stage uberdiese bereits vorhandene Schnittstelle nachzuladen. Dazu baut die erste Stage ei-ne TCP/IP-Verbindung zu dem angreifenden Gerat auf, welches daraufhin diezweite Stage sendet. Die zweite Stage wird nicht auf den Stack geschrieben, dader Stack anschließend wieder fur lokale Variablen und Rucksprungadressen vonFunktionen verwendet werden soll. Als Speicherplatz wird deswegen der Heapverwendet, auf dem dafur genugend Speicher bereit steht. Nachdem die komplet-te zweite Stage ubertragen worden ist, wird sie ausgefuhrt. Die zweite Stage stelltden eigentlichen Programmteil eines Computerwurms dar. Sie ist fur die Verbrei-tung und die Schadensfunktion zustandig und ist in Bezug auf ihre Große prak-tisch unbeschrankt. Der Vorgang der Ubertragung kann in Abbildung 3.2 nach-vollzogen werden.

Abbildung 3.2: Ubertragung des Shellcodes

29


3.3.8 Das Null-Byte-Problem

Es sollen noch zusatzliche Anforderungen an die erste Stage des Shellcodes ge-stellt werden. Bei einem Pufferuberlauf werden die Eingaben des Benutzers in denPuffer kopiert. Dieser Puffer wird dann durch eine uberlange Eingabe zum Uber-laufen gebracht. Handelt es sich bei der Eingabe um eine Zeichenkette (String),so werden meist String-Funktionen wie strcpy oder sprintf fur den Kopier-vorgang verwendet. Strings sind in der Regel Null-terminiert, also durch ein aus-gezeichnetes Byte mit dem Wert Null abgeschlossen. Das bedeutet aber, dass derKopiervorgang abgebrochen wird, sobald ein Null-Byte in der Eingabe des Be-nutzers vorkommt. Da in der Benutzereingabe unter anderem der Shellcode un-tergebracht werden soll, muss garantiert werden, dass dieser keine Null-Bytesenthalt. Ansonsten wurde nicht der gesamte Shellcode in den Puffer kopiert wer-den. Dann wurde moglicherweise nicht einmal ein Pufferuberlauf auftreten, mitdem die Rucksprungadresse modifiziert werden kann.

ARM-Instruktionen, aus denen der Shellcode besteht, sind in der Regel nicht freivon Null-Bytes. Fast alle ARM-Instruktionen, die auf das Register R0 zugreifen,enthalten ein Null-Byte. Auch Instruktionen wie b oder bl, die fur die Verzwei-gung des Programmflusses (Branches) zustandig sind, bestehen haufig aus Null-Bytes. Es gibt nun zwei Moglichkeiten, dies zu umgehen. Zum Einen kann ver-sucht werden, den Shellcode im Puffer – die erste Stage – ausnahmslos durchNull-Byte-freie Instruktionen zu implementieren. Dies ist fur mehrere hundert By-tes jedoch sehr muhselig. Der Shellcode lasst sich spater auch nur schlecht modi-fizieren, da immer wieder auf entstehende Null-Bytes geachtet werden muss. Eskann außerdem notig sein, Daten in den Shellcode zu integrieren, die Null-Bytesenthalten mussen. In diesem Fall mussen Null-Bytes ohnehin kodiert werden.

Abbildung 3.3: Aufbau der ersten Stage

Die gangigste Methode fur die Losung des Null-Byte-Problems ist der Einsatz vonselbstmodifizierendem Shellcode (s. a. [Koz04, san05b, Hur05b]). Die erste Stagewird dazu nochmal in zwei Teile unterteilt. Der erste Teil ist ein Decoder, der ein-malig durch Null-Byte-freie Instruktionen implementiert wird. Der zweite Teil istdie Nutzlast und enthalt die eigentliche Funktion der ersten Stage (s. Abb. 3.3).Sie ist jedoch vor der Injektion in den Puffer so codiert worden, dass keine Null-Bytes mehr auftreten. Die gesamte erste Stage ist damit frei von Null-Bytes. DerDecoder hat zu Beginn der Ausfuhrung die Aufgabe, die Nutzlast der ersten Sta-ge zu decodieren, damit wieder gultige ARM-Instruktionen entstehen. Nach derDecodierung wird dann die Nutzlast ausgefuhrt. Diese Methode vereinfacht die

30

3.3 Die Infizierung

Entwicklung des zweiten Teils der ersten Stage, da ohne Rucksicht auf Null-Bytesprogrammiert werden kann. Die Codierung sorgt unabhangig von den gewahltenInstruktionen fur eine gultige Zeichenkette ohne Null-Bytes. Im vorliegenden Fallwird fur die Codierung/Decodierung die XOR-Funktion verwendet. Jede Instruk-tion der Nutzlast wird mit dem selben 4-Byte-Schlussel codiert. Dieser Schlusselist selbst frei von Null-Bytes und wird so gewahlt, dass auch alle codierten In-struktionen keine Null-Bytes enthalten.

Abbildung 3.4: Exploit-Zeichenkette, die in den Puffer ubergeben wird

Es bleibt zu erwahnen, dass die Rucksprungadresse, die an den Shellcode an-gehangt wird, eine Null enthalten wird. Zumindest dann, wenn die Adressierunguber den Prozessslot Null verwendet wird und die wahre Slotnummer nicht ge-raten werden soll. Dies stellt jedoch kein Problem dar: Die Benutzereingabe kannso gebaut werden, dass sie mit der Rucksprungadresse abschließt. In diesem Fallbefindet sich die Null – das hochstwertige Byte (Most Significant Byte) – ganz amEnde der Benutzereingabe. Windows Mobile verwendet den ARM-Prozessor imLittle Endian-Modus, in dem Bytes in der Reihenfolge der Wertigkeit gespeichertwerden.

Zwischen dem Shellcode und der Rucksprungadresse muss naturlich ein Null-Byte-freier Zwischenraum mit der richtigen Große geschaffen werden, damit dieRucksprungadresse auch an die richtige Stelle geschrieben wird. Dies lasst sichaber mit ein paar Tests sehr zuverlassig bewerkstelligen. Abbildung 3.4 zeigt denAufbau der Exploit-Zeichenkette.

Die zweite Stage des Shellcodes muss nicht codiert werden, da sie von der erstenStage empfangen und nicht als Zeichenkette kopiert wird.

3.3.9 Selbstmodifizierende Programme auf ARM-Prozessoren

Die erste Stage des Shellcodes ist ein selbstmodifizierendes Programm. Es veran-dert den eigenen Programmcode vor der Ausfuhrung zwecks Nullfreiheit. Diesfuhrt zu einem Problem auf ARM-Prozessoren, die fur Speicherzugriffe die Har-vard-Architektur (s. Abb. 2.4) verwenden.

Bezuglich des selbstmodifizierenden Shellcodes und der getrennten Caches stel-len sich zwei Probleme dar. Die Modifikation des codierten Shellcodes findet uber

31


den Datencache statt. Der Prozessor bekommt die Instruktionen jedoch vom In-struktionscache geliefert. Jetzt kann es passieren, dass der codierte Shellcode aufVerdacht in den Prefetch-Cache geladen und erst anschließend decodiert wird.Der Prefetch-Mechanismus erfahrt nichts von dieser Veranderung und beliefertden Prozessor mit den unveranderten codierten Instruktionen. Um dies zu umge-hen, muss man den Instruktionscache fur ungultig erklaren.

Das zweite Problem tritt nur bei Write-Back-Caches auf. Wenn der Shellcode de-codiert worden ist, kann es sein, dass die Veranderungen in den Datencache ge-schrieben, aber noch nicht in den Speicher kopiert worden sind. In diesem Fallwurden trotzdem die uncodierten Instruktionen ausgefuhrt werden und der Shell-code wurde nicht funktionieren. Dieses Problem kann man beheben, indem manalle Write-Back-Caches vor der Ausfuhrung des Shellcodes von Hand leert.

Zusatzlich zum Datencache existiert ein Schreibpuffer. Dieser Puffer wird gefullt,wann immer Daten in den Speicher geschrieben werden sollen. Der Schreibvor-gang in den Schreibpuffer kann mit hoherer Geschwindigkeit geschehen als derSchreibvorgang in den Hauptspeicher. Der Vorteil ist, dass die CPU andere In-struktionen ausfuhren kann, sobald die Daten in den Schreibpuffer geschriebenwurden. Der Schreibpuffer schreibt dann – unabhangig von der CPU – seine Datenin den Hauptspeicher. Wenn Instruktionen in den Speicher geschrieben werden,muss darauf geachtet werden, dass alle Instruktionen den Schreibpuffer wiederverlassen, bevor diese ausgefuhrt werden. Ansonsten werden die vorherigen Da-ten des Speichers als Instruktionen interpretiert.

Im Allgemeinen werden diese Probleme durch Instruction Memory Barriers, kurzIMBs, behoben. IMBs sind Sequenzen von Instruktionen, die gewahrleisten, dassselbstmodifizierter Code im Anschluss zuverlassig ausgefuhrt werden kann. Die-se sind von ARM-Implementation zu ARM-Implementation unterschiedlich, dennverschiedene ARM-Prozessoren besitzen unterschiedliche Caches. Tabelle 3.3.9zeigt Instruktionen fur die Beeinflussung samtlicher Caches und Puffer eines IntelXScale Prozessors.

Hurman verwendet in seinem Shellcode (aus [Hur05b]) die folgenden Instruktio-nen fur die Leerung der Caches und Puffer:

mcr p15, 0, r0, c7, c10, 4mrc p15, 0, r1, c2, c0, 0mov r1, r1

Diese Instruktionen sind jedoch nicht ausreichend. Auf dem Testgerat MDA Prowurde die zweite Stage nicht korrekt ausgefuhrt, da noch nicht alle Instruktio-nen geschrieben worden waren. Außerdem muss der Prozessor fur diese Art vonInstruktionen im System Mode laufen; d. h. Windows muss in den Kernel Mode

32

3.3 Die Infizierung

Funktion InstruktionInvalidate I&D cache & BTB MCR p15, 0, Rd, c7, c7, 0Invalidate I cache & BTB MCR p15, 0, Rd, c7, c5, 0Invalidate I cache line MCR p15, 0, Rd, c7, c5, 1Invalidate D cache MCR p15, 0, Rd, c7, c6, 0Invalidate D cache line MCR p15, 0, Rd, c7, c6, 1Clean D cache line MCR p15, 0, Rd, c7, c10, 1Drain Write (& Fill) Buffer MCR p15, 0, Rd, c7, c10, 4Invalidate Branch Target Buffer MCR p15, 0, Rd, c7, c5, 6Allocate Line in the Data Cache MCR p15, 0, Rd, c7, c2, 5

Tabelle 3.1: Intel XScale Cache-Funktionen aus [Int04]

versetzt werden (vgl. Abschnitt 2.3.3).

In [Sea00] wird empfohlen, selbstmodifizierenden Code nur in Ausnahmen zuverwenden; vor allem weil die notigen Instruktionen fur die Invalidierung bzw.Leerung der Caches empfindliche Performanceeinbruche verursachen. Trotzdemwird selbstmodifizierender Code in allen gangigen Betriebssystemen verwendet.Wenn zum Beispiel ein Programm gestartet wird, dann muss dessen Code vomBetriebssystem in den Arbeitsspeicher geladen und anschließend ausgefuhrt wer-den. Im Gesamtkontext des Systems verandert sich das System dabei selbst. Dasselbe gilt fur das Einbinden von Programmbibliotheken in ein Programm zurLaufzeit (dynamic linking).

Da Selbstmodifizierung auf Betriebssystemebene verwendet wird, ist es sinnvoll,durch Betriebssysteme eine Funktion bereitzustellen, mit der man die Caches ma-nipulieren kann. Seit Windows Mobile 4.2 existiert dafur die Windows-API-Funk-tion CacheRangeFlush (Vergl. [MS:06]). Der Aufruf lautet wie folgt:

void CacheRangeFlush(LPVOID pAddr,DWORD dwLength,DWORD dwFlags

);

Setzt man die ersten beiden Argumente auf Null und das dritte Argument aufCACHE_SYNC_ALL, so werden alle Caches entsprechend invalidiert und/oder zu-ruckgeschrieben. Fur den Shellcode ist nun sichergestellt, dass alle Instruktionen,die zuvor geschrieben worden sind, ausgefuhrt werden konnen.

Die Verwendung der CacheRangeFlush-API beseitigt diese Probleme auf allenARM-Prozessoren. Sie wird von den Gerateherstellern fur alle Gerate entspre-

33


chend angepasst und verlangt nicht, dass sich der aufrufende Prozess im KernelMode befindet. Dies ist die bessere Losung, die in dem Shellcode dieser Arbeitgenutzt wird.

3.3.10 Die Schnittstelle zum Betriebssystem

Der Shellcode benotigt Funktionen des Betriebssystems. Dazu stehen sowohl diegrundlegenden System Calls, als auch die Windows-API zur Verfugung. Es sollennun die verschiedenen Ansatze fur die Bereitstellung solcher Funktionen vorge-stellt werden.

System Calls

Die in Abschnitt 2.2.8 eingefuhrten Syscalls bieten dem Shellcode eine einfacheMethode, mit dem Betriebssystem zu kommunizieren, ohne die Windows-APIzu verwenden. Fur die Bibliotheken der Windows-API musste der Shellcode zurLaufzeit nach Moduladressen fur die verschiedenen DLLs suchen.

Die Adressen der benotigten Syscalls werden nach der Formel aus Abschnitt 2.2.8berechnet und im Shellcode direkt verwendet. Der folgende Code demonstriertden Aufruf des Syscalls MessageBox(Handle, Msg, Title, Flags).

_start:mov r0, #0 # 1. Parameter: Windowhandleadr r1, string1 # 2. Parameter: Nachrichtadr t2, string2 # 3. Parameter: Dialogtitelmov r3, #0 # 4. Parameter: Flagsmov lr, pc # Rucksprungadresse sichernldr pc, MessageBoxW # Sprung an Syscall-Adresse

MessageBoxW:.dword 0xf000bb38 # Trap-Adresse von MessageBoxW

string1:[...] # Nachricht (Unicode-String)

string2:[...] # Dialogtitel (Unicode-String)

34

3.3 Die Infizierung

Windows-API

Wenn die Funktionen der Windows-API verwenden werden sollen, mussen ihreAdressen herausgefunden werden. Diese konnen jedoch nicht als konstant ange-nommen werden, da der Shellcode auf moglichst vielen Geraten laufen soll. Des-wegen wird ein Verfahren benotigt, dass die Adressen im Shellcode herausfindet.

Ein Ansatz, der von Tim Hurman in [Hur05b] und San im Phrack-Artikel [san05b]genutzt wird, macht sich die Datenstruktur KInfoTable im Windows-Kernel zu-nutze. Uber diese kann man an die Adressen der Module und ihrer Funktionengelangen. Die Adresse der Struktur ist fest.

Um die benotigten Module und Funktionen in der Liste zu finden, verwendetman ihre Dateinamen. Die Liste enthalt Eintrage fur Dateinamen, anhand dererman die Module und Funktionen identifizieren kann. Die Dateinamen mussenfur den Vergleich auch im Shellcode bereitgehalten werden. Dort nehmen sie,insbesondere als Unicode-Zeichenketten, erheblichen Speicherplatz ein. Aus die-sem Grund wenden Hurman und San ein Hashing auf die Strings an. Pro Moduloder Funktion mussen so nur noch vier Bytes gespeichert werden. Dabei erhohtsich entsprechend der Aufwand beim Vergleich, da zuvor die Dateinamen in derKInfoTable-Struktur gehasht werden mussen. Außerdem sind Kollisionen beimHashing nicht ausgeschlossen.

Da die Struktur im Speicherbereich der Kernel liegt, muss der Prozess, in den derShellcode injiziert wird, im Kernel Mode laufen. Hurman und San gehen jedochdavon aus, dass der Full-Kernel Mode aktiviert ist, bei dem alle Prozesse immerim Kernel Mode ausgefuhrt werden. Fur neuere Gerate ist dieser allerdings deak-tiviert, z. B. bei den Testgeraten. Der Ansatz von Hurman und San kann also nichtuberall funktionieren. Dies ist eine zu große Einschrankung. Ein besserer Ansatzkann mit Syscalls und den Bibliotheksfunktionen gewahlt werden.

Syscalls und Windows-API

Der Decoder der ersten Stage benotigt keine Funktionen des Betriebssystems. Erstdie Nutzlast der zweiten Stage benotigt Funktionen, um die Netzwerkverbindungfur die zweite Stage aufzubauen, Speicher auf dem Heap zu allozieren und dieCaches zu invalidieren. Eine Liste der benotigten Funktionen wird hier aufgelistet:

• realloc alloziert bzw. realloziert Speicher auf dem Heap.

• socket erstellt den Socket fur die Kommunikation uber TCP/IP.

• connect verbindet sich uber TCP/IP mit dem angreifenden Gerat.

35


• recv empfangt die zweite Stage.

• CacheRangeFlush sorgt dafur, dass die zweite Stage auf dem Heap zu-verlassig ausgefuhrt werden kann.

Diese Funktionen sind jedoch nicht alle uber Syscalls zu erreichen. Aus diesemGrund werden Bibliotheksfunktionen benotigt. Diese konnen durch einen klei-nen Satz an Syscalls verwendet werden: LoadLibrary, GetModuleHandle undGetProcAddress. LoadLibrary kann ein Bibliotheksmodul fur den aktuellenProzess laden. GetModuleHandle gibt den Handle fur ein Modul zuruck, wel-ches zuvor geladen wurde. Meist reicht GetModuleHandle aus, da Bibliothekenwie coredll.dll und winsock.dll zuvor geladen wurden 1. Hat man nun einHandle fur ein solches Modul, so kann man mit GetProcAddress die Adresseeiner bestimmten Funktion in dem Modul herausbekommen. Damit lassen sichdie oben genannten Funktionen in den Shellcode einbinden.

In der Regel mussen Modul- und Funktionsnamen als Unicode-Zeichenketten an-gegeben werden. Diese sind doppelt so lang wie normale ANSI-Zeichenkettenund nehmen dementsprechend doppelt soviel Platz im Shellcode ein. Fur dieFunktion GetProcAddress existiert jedoch ein Syscall GetProcAddressA, derauch mit ANSI-Zeichenketten auskommt. Funktionsnamen mussen also nicht inUnicode bereitgestellt werden. Die Aufrufe der drei Funktionen sehen folgender-maßen aus (Quelle: [MS:06]):

HINSTANCE LoadLibraryW(LPCTSTR lpLibFileName

);

HMODULE GetModuleHandleW(LPCTSTR lpModuleName

);

FARPROC GetProcAddressA(HMODULE hModule,LPCSTR lpProcName

);

Diese drei Syscalls liefern den Zugriff auf samtliche Bibliotheksfunktionen derWindows-API, ohne dass, wie in [Hur05b] und [san05b], in den Kernel Mode ge-wechselt werden muss.

1coredll.dll ist immer geladen. Andere Bibliotheken nur, wenn sie von der auszunutzendenAnwendung selbst benotigt werden.

36

3.3 Die Infizierung

3.3.11 Probleme mit dem Stack

Der Stack unter Windows Mobile ist sehr sensibel. Wahrend der Entwicklungdes Shellcodes wurde immer wieder festgestellt, dass der Remote Debugger denStack-Bereich zerstorte, in dem der Shellcode abgelegt wurde. Dies geschah immerdann, wenn der Stack-Frame einer Funktion nach ihrer Beendigung nicht mehrverwendet wurde. Der Debugger scheint davon auszugehen, dass diese Bereicheanschließend nicht mehr benutzt werden, was fur normale Programme richtig ist.Der Shellcode residiert jedoch auch nach dem Beenden der ausgefuhrten Funktionim alten Stack-Frame und kann durch die Uberschreibung nicht mehr ausgefuhrtwerden. An dieser Stelle konnte der Shellcode nur ”blind“, d. h. ohne Hilfe desDebuggers, entwickelt werden.

3.3.12 Aufbau der zweiten Stage

Fur die zweite Stage kann nun uberlegt werden, wie das eigentliche Programmdes Computerwurms entwickelt werden soll. An dieser Stelle ist die Program-mierung in ARM-Assembler viel zu aufwendig, und die Entwicklung soll in einerhoheren Programmiersprache wie C fortgefuhrt werden. Compiler fur hohere Pro-grammiersprachen erstellen in der Regel ausfuhrbare Dateien oder Bibliotheken.Um moglichst unabhangig vom Compiler und der genutzten Programmierspra-che zu sein, empfiehlt es sich, eine ausfuhrbare Datei des Computerwurmpro-gramms zu erstellen und diese in der zweiten Stage des Shellcodes mitzufuhren.Der erste Teil der zweiten Stage, der Loader, hat die Aufgabe, die angehangtenDatei auf das Dateisystem des Gerats zu schreiben. Anschließend fuhrt er diesein einem neuen Prozess aus und beendet den aktuellen Prozess des ausgenutztenProgramms.

Abbildung 3.5: Aufbau der zweiten Stage

Die Datei sollte versteckt auf dem Gerat gespeichert werden, so dass ein neugie-riger Benutzer diese nicht auf Anhieb entdecken kann. Dies wird hier mit demAttribut fur versteckte Dateien erreicht.

Beim Start eines neuen Prozesses wird eine Signatur in der ausfuhrbaren Da-tei uberpruft (vgl. 2.2.9). Ist eine solche Signatur nicht vorhanden oder kann ihreEchtheit nicht verifiziert werden, so fragt das Betriebssystem uber einen Dialog

37


nach, ob der Benutzer dies zulassen mochte. Dies ist aus der Sicht eines Compu-terwurms ein unerwunschtes Verhalten, da er nun von der Reaktion des Benutzersabhangig ist. Im Rahmen dieser Arbeit wurde jedoch eine Moglichkeit gefunden,dieses Verhalten zu andern. Dazu muss man einen Schlussel in der Windows Re-gistry verandern, bevor man den neuen Prozess erstellt. Auf Pocket PCs kann dieWindows Registry ohne Einschrankung manipuliert werden, da dort alle Prozes-se Zugriff auf die Trusted API haben. Dies bestatigten auch die Versuche auf denTestgeraten.

Der Schlussel ist in den Einstellungen fur die Sicherheitsrichtlinien zu finden. DieDefault-Einstellung ist

; Unsigned Prompt Policy[HKEY_LOCAL_MACHINE\Security\Policies\Policies]

"0000101a"=dword:0

Diese muss vom Wert 0 auf den Wert 1 gesetzt werden (aus [MS:06], ”Default Secu-rity Policy Settings“). Nun erhalt der Benutzer keine Aufforderung mehr und dasHauptprogramm des Computerwurms wird in einem neuen Prozess aufgerufen.

Um dies alles zu realisieren, werden einige Funktionen der Windows-API beno-tigt. RegOpenKeyEx, RegSetValueEx und RegCloseKey werden fur die Mani-pulation der Registry verwendet. CreateFile, WriteFile und CloseHandleerstellen die ausfuhrbare Datei und fullen sie mit dem Anhang der zweiten Sta-ge. CreateProcess fuhrt diese Datei in einem neuen Prozess aus. Der Prozessder ausgenutzten Anwendung wird ab sofort nicht mehr benotigt und wird mitGetCurrentProcess und TerminateProcess beendet. All diese Funktionenkonnen wieder uber die drei Syscalls LoadLibrary, GetModuleHandle undGetProcAddress zuganglich gemacht werden.

Mit dieser Technik kann das eigentliche Computerwurmprogramm in einer ho-heren Programmiersprache entwickelt werden, und man braucht sich nun keineGedanken mehr um das Zusammenspiel zwischen Shellcode und dem Compu-terwurmprogramm zu machen.

3.3.13 Test des Shellcodes und der Infizierung

Nun soll die Funktion des Shellcodes uberpruft und die Infizierung durchgefuhrtwerden. Die Infizierung geht von einem Linux-Rechner aus, der sich im selbenNetzwerk befindet wie eins der Testgerate. Es werden folgende Teile des Baukas-tens benotigt (s. a. Anhang B):

38

3.3 Die Infizierung

• stage_one.binDer Shellcode der ersten Stage.

• exploitEin Programm zum Erstellen des Exploits aus Shellcode und einer Ruck-sprungadresse.

• vuln_stack_exploit.shShellscript, welches die Puffereingabe fur vuln_stack.exe mit exploitbaut und versendet.

• stage_two-exploitation_testDer Shellcode der zweiten Stage. Dieser enthalt ein kleines Programm inForm einer EXE-Datei, welche eine Nachrichtenbox anzeigt.

• provide_stage_two.shShellscript fur das Bereitstellen der zweiten Stage. .

Wir gehen hier davon aus, dass der angreifende Linux-Rechner die IP-Adresse192.168.254.101 und das Testgerat die IP-Adresse 192.168.254.140 be-sitzt. Sofern sich die Adresse des Angreifers andert, muss diese auch im Quell-code der ersten Stage geandert werden. Ansonsten kann die zweite Stage nichtnachgeladen werden.

Vorgehensweise fur die Ausnutzung (s. Abb. 3.6):

1. Zu Anfang wird das auszunutzende Programm vuln stack.exe auf dasTestgerat geladen und ausgefuhrt. Das Programm meldet sich dann mit ei-ner Nachrichtenbox, die geschlossen werden muss. Anschließend wartet esauf eingehende Verbindungen an TCP-Port 4074.

2. Jetzt wird die zweite Stage des Shellcodes bereitgestellt. Dazu wird das Shell-script provide stage two.sh auf dem Angreifersystem gestartet. Nunwartet das Script an TCP-Port 65535 auf eingehende Verbindungen.

3. Jetzt kann das Shellscript vuln stack exploit.sh auf dem Angreifer-system gestartet werden. Dieses baut eine Verbindung zum Port 4074 desTestgerates auf und versendet den Exploit mit dem Shellcode. Der Pufferin vuln stack.exe lauft uber, die Rucksprungadresse wird uberschriebenund die erste Stage wird ausgefuhrt. Die erste Stage sorgt dann fur das Nach-laden der zweiten Stage von dem Rechner des Angreifers. Schließlich wirdeine Nachricht (s. Abb. 3.7) bezuglich der erfolgreichen Infektion auf demTestgerat ausgegeben.

39


Abbildung 3.6: Der Vorgang der Infizierung

Abbildung 3.7: Bildschirmfoto des MDA Vario nach der Ausfuhrung des Exploits


In diesem Abschnitt wurde gezeigt, dass es auch unter Windows Mobile 5 moglichist, Stack-basierte Pufferuberlaufe auszunutzen und Shellcode auszufuhren. Die-ser Shellcode ist zudem wesentlich unabhangiger vom Prozessor und der Konfi-guration des Betriebsystems als die Ansatze aus [Hur05b] und [san05b]. Im Ge-gensatz zu den Shellcodes von Hurman und San, lost der hier entwickelte Shell-code das Problem der Harvard Architektur vollstandig. Außerdem ist es nichtnotig, dass das Betriebssystem im Full-Kernel Mode ausgefuhrt wird, da wederauf Kernelstrukturen zugegriffen wird, noch ARM-Instruktionen verwendet wer-den, die im privilegierten Prozessormodus ausgefuhrt werden mussen (vgl. Ab-schnitt 3.3.9). Die Windows-API wurde in Abschnitt 3.3.10 allein durch Syscallszuganglich gemacht. Das Problem der Shellcode-Große wurde durch das Nachla-

40

3.4 Die Verbreitung

den einer zweiten Stage gelost. Zusatzliche wurde noch eine Technik erlautert, diees erlaubt, das eigentliche Computerwurmprogramm in einer hoheren Program-miersprache zu schreiben (vgl. Abschnitt 3.3.12). Die Programmierung dieses Pro-gramms ist Aufgabe der nachsten Abschnitte 3.4 und 3.5.

3.4 Die Verbreitung

3.4.1 Einleitung

Dieser Abschnitt behandelt die Verbreitungsfunktion des Computerwurms. Die-ser Teil wird in der Programmiersprache C entwickelt. In Abschnitt 3.4.4 werdenzwei verschiedene Algorithmen vorgestellt, die fur die Auswahl weiterer zu in-fizierender Gerate zustandig sind. In Abschnitt 3.4.5 wird der Aufbau des kom-pletten Computerwurmprogramms erlautert und in Abschnitt 3.4.6 die Funkti-onsweise der Verbreitung getestet.

3.4.2 Werkzeuge fur die Entwicklung

Die Verbreitungsfunktion ist Teil der ausfuhrbaren Datei, die in der zweiten Stageubertragen wird. Fur die Entwicklung wird die Programmiersprache C verwen-det und der GNU C-Compiler, der fur das Zielsystem arm-wince-pe kompiliertworden ist. Das Projekt CeGCC (s. [CEG]) stellt einen vorkompilierten GNU C-Compiler inklusive Header-Dateien fur Windows CE bereit. Dieser kann fur dieEntwicklung von Windows CE-Programmen unter Linux genutzt werden. Weite-re Angaben zu den Werkzeugen konnen im Anhang A gefunden werden.

3.4.3 Medium fur die Verbreitung

Das Medium fur die Verbreitung des Computerwurms ist in dieser Arbeit das IP-Netzwerk, denn das ausnutzbare Programm enthalt eine Schwachstelle, die uberIP erreichbar ist. Windows Mobile-Gerate haben diverse Schnittstellen, uber dieein solches Netzwerk erreichbar sein kann. Darunter fallen WLAN, GPRS undUMTS. Die WLAN-Schnittstelle wird hiervon am haufigsten verwendet, da es oftkostengunstig ist uber einen freien WLAN-Accesspoint das Internet zu nutzen.Bluetooth und IrDA werden meist nur fur Gerat-zu-Gerat-Verbindungen benutztund das auch selten uber IP. GPRS und UMTS bieten ausschließlich den direk-ten Zugang zum Internet an und keinen Zugang zu lokalen Netzwerken. Lokale

41


Netzwerke sind jedoch vorteilhaft fur die Verbreitung, wie in Abschnitt 3.4.4 fest-gestellt werden kann.

3.4.4 Algorithmen fur die Verbreitung

Als nachstes muss die Frage gestellt werden, wie die Gerate ausfindig gemachtwerden sollen, die fur eine Infizierung in Frage kommen. Da sich der Computer-wurm uber IP-Netzwerke verbreiten soll, werden hier zwei unterschiedliche Al-gorithmen vorgestellt, die dieses bewerkstelligen. Der erste Ansatz ist eine naiveAufzahlung von IP-Adressen. Der zweite Algorithmus basiert auf einer Reaktionauf bestimmte Netzwerkereignisse.

Kanonische Enumeration von IP-Adressen

Die einfachste Vorgehensweise ist die kanonische Enumeration von IP-Adressen.Hierbei werden alle Netzwerkschnittstellen des Gerats aufgezahlt und anhandder eigenen IP-Adressen und den Netzwerkmasken der Schnittstellen auf mogli-che andere Netzwerkteilnehmer geschlossen. Der folgende Algorithmus zeigt dieVorgehensweise:

Fur jede Netzwerkschnittstelle nNetzgroße = n.Netzmaske BITWEISE_XOR 0xffffffffVon i = 1 bis Netzgroße - 1

Infiziere(n.Adresse BITWEISE_UND n.Netzmaske + i);

Hierbei ergeben sich zwei Nachteile. Zum Einen ist die Laufzeit des Algorith-mus linear abhangig von der Anzahl der Adressen im Netzwerk. In einem Testbenotigte eine Implementation des Algorithmus ca. 30 Sekunden fur ein kom-plettes Klasse C-Netzwerk (Netzmaske 255.255.255.0) mit 256 Adressen. Fureine Schnittstelle, die unmittelbar an das Internet angebunden ist (Netzmaske0.0.0.0), wurde der Algorithmus erst nach knapp sechs Tagen terminieren. EineMoglichkeit ware noch, sich auf die Netzwerkadressen der Mobilfunkanbieter zubeschranken. Dies wurde die Wahrscheinlichkeit ein mobiles Gerat zu erreichenvermutlich wesentlich erhohen.

Der Algorithmus ist fur Tests in lokalen Netzwerken implementiert worden. Dieentsprechenden Zeilen im Code der Verbreitungsfunktion des Computerwurmswurden auskommentiert.

42

3.4 Die Verbreitung

Infizierung bei Empfang von NetBIOS-Paketen

Um Akkulaufzeit zu sparen, schalten die Gerate wenige Minuten (Werkseinstel-lung Testgerate: 2 Minuten) nach der letzten Benutzung in den Standby-Modus.Dieses kleine Zeitfenster, wahrend dem sich ein mobiles Gerat in einem Netzwerkbefinden kann, ist ein Problem. Ab dem Moment, wo das Gerat in den Standby-Modus schaltet, ist die WLAN-Schnittstelle nicht mehr verfugbar und das Geratkann nicht mehr infiziert werden. Es soll jedoch moglichst jedes Gerat infiziertwerden, das ein Netzwerk betritt.

Jedes Windows Mobile-Gerat, das ein Netzwerk betritt, sendet zu Beginn eine Fol-ge von NetBIOS-Paketen auf dem UDP-Port 137 an die Broadcast-Adresse desNetzwerks (s. Abb. 3.8). Uber diese Pakete kundigen die Gerate ihre Prasenz imNetBIOS Name Service (s. [RFC87a, RFC87b]) an. Dies geschieht z. B. immer dann,wenn der Benutzer das Gerat einschaltet und die WLAN-Schnittstelle wieder ak-tiviert wird. Dieses Verhalten kann man sich zunutze machen, denn so erfahrtman welche Gerate sich im Netzwerk befinden und welche IP-Adresse sie besit-zen. Dafur ist es notwendig, an dem zugehorigen UDP-Port 137 auf eingehendeNetBIOS-Pakete zu lauschen. Dieser Port ist jedoch standardmaßig von dem Pro-zess device.exe belegt. Dieser Prozess kummert sich nicht nur um die Imple-mentation des NetBIOS-Protokolls, sondern auch um verschiedene andere Gerate-treiber. Aus diesem Grund kann er nicht beendet werden.

Abbildung 3.8: NetBIOS-Pakete bei Eintritt in ein Netzwerk

Es gibt nun zwei Moglichkeiten, um die NetBIOS-Pakete trotzdem zu empfangen,mit Hilfe des Packet Capturing oder durch Portstealing.

43


Packet Capturing

Unter Packet Capturing versteht man das Empfangen von Netzwerkdaten auf derSicherungsschicht des OSI Referenzmodells.

Unter den meisten Windows-Betriebssystemen ist es uber die Winsock-Bibliotheknicht moglich auf die Netzwerkadapter zuzugreifen. Mochte man Packet Captu-ring implementieren, so steht einem jedoch die Open Source Bibliothek WinPCAP(s. [Win06]) zur Verfugung. Uber diese Bilbiothek konnen samtliche Pakete auf-gezeichnet werden, die einen ausgewahlten Netzwerkadapter passieren. Damitkonnte man die NetBIOS-Pakete empfangen, ohne dass der Port 137 freigegebenwerden muss. Die Implementierung wurde jedoch aus Zeitgrunden in dieser Ar-beit nicht vorgenommen.

Portstealing

Wahrend der Erforschung von Verbreitungsfunktionen wurde das folgende un-vorteilhafte Verhalten von Windows Mobile 5.0 bezuglich der Bindung von Netz-werkports festgestellt. Das normale Verhalten ware folgenderweise: Wenn ein Pro-zess an einem Port an einer Adresse lauscht (z. B. Port 137 und Adresse 0.0.0.0),dann tut er dies ausschließlich allein. Kein weiterer Prozess kann sich anschlie-ßend an diesen Port binden, bis dieser wieder freigegeben wird. Dabei gibt esjedoch eine Ausnahme. Mit der spezifischen Socket-Option SO_REUSEADDR kannein zweiter Prozess die Bindung an den Port erzwingen. Die wurde vorgesehen,damit bei einem Absturz eines Server-Prozesses, der Port ubernommen und derentsprechende Dienst schnellstmoglich wieder aufgenommen werden kann. DieBindung des abgesturzten Prozesses verfallt erst nach einiger Zeit, da der Port fureventuell ausstehende Daten offen gehalten wird.

Dieses Sicherheitsproblem ist schon von anderen Windows-Betriebssystemen be-kannt. In Windows NT 4.0 SP4, Windows XP, Windows 2000 und Windows 2003Server kann man sich mit einer weiteren Socket-Option SO_EXCLUSIVEADDRUSEbehelfen. Wird diese Option von dem ersten Prozess gesetzt, so ist es einem wei-teren Prozess unmoglich, einen Port zu ubernehmen. Unglucklicherweise hat Mi-crosoft diese Option fur Windows Mobile bislang nicht implementiert (vgl. ”UsingSO_REUSEADDR and SO_EXCLUSIVEADDRUSE“ auf [MS:06]).

Wenn dieses Fehlverhalten unter Windows Mobile ausgenutzt werden soll, soreicht die bloße Verwendung von SO_REUSEADDR jedoch nicht aus. Beim erstenVersuch scheitert die Bindung des Ports und der ursprungliche Prozess behalt dievolle Kontrolle. Versucht man jedoch ein zweites Mal, den Port mit einem anderenProzess (oder Thread) zu binden, so gelingt dies. Dieses Verhalten kann genutzt

44

3.4 Die Verbreitung

werden, um den NetBIOS-Port zu ubernehmen. Der Vorgang wird in dieser ArbeitPortstealing genannt.

Die Verbeitungsfunktion des Computerwurmprogramms worm.exe, welches ausdem Quellcode auf der beiliegenden CD ubersetzt werden kann, (s. Anhang A)verwendet die Portstealing-Methode, um neue Gerate in einem Netzwerk uberden NetBIOS-Port aufzuspuren.

3.4.5 Aufbau des Computerwurmprogramms

Das Computerwurmprogramm worm.exe verwendet drei Threads:

• Haupt-Thread

• Thread fur die Bereithaltung der zweiten Stage an einem TCP-Port

• Thread fur die Verbreitung auf andere Gerate

Der Haupt-Thread erfullt die folgenden Aufgaben:

• Anzeige des Bestatigungsdialogs vor Ausfuhrung

• Verwendung der Portsteal-Methode, um auf dem NetBIOS-Port zu lauschen

• Starten der beiden Neben-Threads fur die Verbreitung und die Bereitstellungder zweiten Stage

• Endlosschleife

Der Verbreitungs-Thread arbeitet nach dem Prinzip, das in Abschnitt 3.4.4 vorge-stellt wurde.

3.4.6 Test der Verbreitung

Fur den Test der Verbreitung wird davon ausgegangen, dass eins von zwei Test-geraten bereits infiziert wurde. Das Computerwurmprogramm worm.exe wirddeswegen auf dem ersten Gerat manuell ausgefuhrt. Zunachst muss noch eineSicherheitsabfrage bestatigt werden (s. Abb. 3.9), um den Computerwurm zu ak-tivieren. Andernfalls wird das Computerwurmprogramm beendet.

45


Auf dem zweiten Testgerat wird das Programm vuln_stack.exemit der Sicher-heitslucke gestartet. Als nachstes mussen beide Gerate im selben WLAN-Netz-werk eingeloggt sein. Zuerst wird auf dem infizierten Gerat WLAN aktiviert undanschließend auf dem zweiten. In dem Moment, wo das zweite Gerat das Netz-werk betritt, erfolgt die Infizierung und die Sicherheitsabfrage des Computer-wurmprogramms ist auch auf dem zweiten Gerat sichtbar.

Die benotigten Dateien fur die Erstellung von vuln_stack.exe und worm.exekonnen auf der CD gefunden werden (s. Anhang B).

Abbildung 3.9: Bildschirmfoto nach der Infizierung des Gerats


Dieser Abschnitt hat zwei Algorithmen fur die Verbreitung des Computerwurmsaufgezeigt. Mit Portstealing wurde in Abschnitt 3.4.4 eine Unzulanglichkeit inWindows Mobile ausgenutzt, mit der andere Gerate auf Anhieb in einem Netz-werk gefunden werden konnen. Zusatzlich wurde in Abschnitt 3.4.5 der Aufbaudes Computerwurmprograms erklart und in Abschnitt 3.4.6 seine Funktion ge-testet. Der nachste Abschnitt wird nun mogliche Schadensfunktionen diskutieren,die in einem Computerwurm zum Einsatz kommen konnen.

46

3.5 Die Schadensfunktion

3.5 Die Schadensfunktion

3.5.1 Einleitung

Der Computerwurm ist jetzt in der Lage, sich uber eine Sicherheitslucke in ei-nem IP-Netzwerk zu verbreiten. Nun soll diskutiert werden, in welchem Rahmenein Computerwurm Schaden anrichten kann. Dafur wird zunachst der allgemei-ne Schaden betrachtet. Im Anschluss wird gezeigt, wie die Telefon-API von Win-dows Mobile 5.0 fur das stille Anrufen einer Telefonummer und die SMS-API furdas stille Versenden von SMS-Kurzmitteilungen verwendet werden kann. BeideFunktionen konnen dabei hohe Kosten verursachen.

3.5.2 Allgemeiner Schaden

Die Verbreitung des Computerwurms bringt an sich schon Schaden mit sich, daRessourcen des Systems verbraucht werden. Auf den mobilen Windows-Geratenwerden z. B. Arbeitsspeicher und Akkulaufzeit verbraucht, wenn das Programmlauft. Das Netzwerk wird mit zusatzlichem Verkehr belastet, den der Computer-wurm fur die Infizierung benotigt.

Es konnen jedoch auch gezielt Schadensfunktionen in den Computerwurm einge-baut werden. Die folgenden Abschnitte gehen auf ausgewahlte Szenarien ein undzeigen, wie eine entsprechende Schadensfunktion eines Computerwurms imple-mentiert werden kann.

3.5.3 Wahlen kostenintensiver Rufnummern

Beschreibung

Die erste Schadensfunktion betrifft alle Gerate mit Windows Mobile, die Telefon-funktionen haben. Die Schadensfunktion des Computerwurms veranlasst dabeieinen Anruf einer kostenintensiven Rufnummer. Solche Rufnummern sind z. B.09009-Nummern von teuren Mehrwertdiensten.

Implementation

Die Telefonfunktionen werden uber die Telefon-API von Windows (TAPI) imple-mentiert. Um eine Telefonnummer anzurufen werden die folgenden Funktionen

47


verwendet, die uber die Bibliothek cellcore.dll (s. [MS:06]) bereitgestellt wer-den:

• lineInitialize bereitet die Anwendung fur die Verwendung der TAPIvor.

• lineOpen offnet ein Gerat, das fur eine Telefonverbindung verwendet wer-den kann. In diesem Fall ist dies das Cellphone Device.

• lineNegotiateAPIVersion handelt die Version der TAPI aus.

• lineGetDevCaps ermittelt die Fahigkeiten des Telefongerats.

• lineMakeCall ruft eine Rufnummer uber eine zuvor geoffnete Leitung an.

• lineDrop schließt die verwendete Leitung wieder.

Das Programm dialer (s. Anhang B) verwendet die genannten Funktionen. Eswahlt eine Rufnummer an und beendet nach zehn Sekunden die Verbindung. DerAnruf erfolgt ohne eine Bestatigung der Benutzers und ohne Ruckmeldung uberdie graphische Oberflache des Gerats. Lediglich ein kleines Symbol verandert sichfur den Zeitraum des Anrufs. Der Anruf wird auch nicht in der Anrufliste ver-merkt. Dies verhindert, dass der Benutzer von der Ausfuhrung der Schadensfunk-tion erfahrt.

3.5.4 Versenden kostenintensiver SMS-Mitteilungen

Beschreibung

Eine weitere Schadensfunktion verursacht Kosten, indem sie eine Textkurzmittei-lung (SMS) uber den Short Message Service versendet. Die SMS kann z. B. an einekostenintensive Premium SMS-Rufnummer gerichtet sein.

Premium SMS-Dienste werden nach [dia06] in der Regel dafur benutzt, um ver-schiedene Dienstleistungen im Internet oder anderen Medien abzurechnen undseien eins der wichtigsten Abrechnungsmittel im so genannten Mobile Paymentin Deutschland. Beispiele dafur sind die Angebote fur Klingetone und Handylo-gos aus der Fernsehwerbung. Premium SMS-Rufnummern sind in Deutschlandfunfstellig (11111-99999). Haufig muss ein spezielles Schlusselwort in der Text-mitteilung mitgeschickt werden, um einen Premium SMS-Dienst in Anspruch zunehmen.

Ein unserioser Anbieter von Premium SMS-Diensten konnte von einer derartigenSchadensfunktion innerhalb eines mobilen Computerwurms profitieren.

48

3.6 Test des Shellcodes auf verschiedenen Geraten

Implementation

Die Implementation der Schadensfunktion ist simpel. Das Programm SMSSender(s. Anhang B) verwendet dafur die folgenden drei Funktionen der SMS-API vonWindows Mobile (s. [MS:06]):

• SmsOpen offnet die Komponente der SMS-API fur das Versenden von SMS-Kurzmitteilungen.

• SmsSendMessage sendet eine SMS-Kurzmitteilung.

• SmsClose schließt die Komponente der SMS-API wieder.

SMSSender versendet die SMS ohne dass der Benutzer dies mitbekommt. Es gibtkeinerlei graphische Ausgaben bei diesem Vorgang, und die gesendete SMS wirdauch nicht auf dem Gerat gespeichert. Erst auf einer ausfuhrlichen Rechnung desMobiltelefonanbieters kann die SMS nachvollzogen werden.


Es wurden zwei Schadensfunktionen erlautert und implementiert. Beide konnenhohe Kosten erzeugen, ohne dass der Benutzer dies mitbekommt. Computerwur-mer, die derartige Schadensfunktionen enthalten, konnen somit großen finanziel-len Schaden anrichten.

3.6 Test des Shellcodes auf verschiedenen Geraten

Der in dieser Arbeit entwickelte Shellcode wurde auf vier unterschiedlichen Win-dows Mobile 5.0-Geraten getestet. Dies sind der MDA Pro und der MDA Vario,die von Anfang an fur diese Arbeit zur Verfugung standen, sowie ein weitererMDA Vario und ein MDA Vario II. Alle Gerate sind Pocket PCs und verfugenuber eine WLAN-Schnittstelle. Sie unterscheiden sich im Wesentlichen durch ihreHardware und die Build-Version des Betriebssystems. Insgesamt wurden so dreiverschiedene Prozessoren, zwei verschiedenen OS-Versionen und drei verschie-dene Build-Versionen getestet. Unter den Prozessoren waren zwei OMAP850 vonder Firma Texas Instruments, ein XScale-Prozessor PXA270 von Intel und ein Sam-sung SC32442.

Die Infizierung und Verbreitung funktionierte auf allen Geraten exakt so, wie siein den Abschnitten 3.3.13 und 3.4.6 beschrieben wurden. Die zwei zusatzlichen

49


Gerate bestatigten noch einmal die Ubertragbarkeit des Shellcodes und des Com-puterwurmprogramms.

3.7 Zusammenfassung

In diesem Kapitel konnte ein Computerwurm entwickelt werden, der sich aufWindows Mobile 5.0-Geraten mit WLAN-Funktion verbreiten kann. Der Com-puterwurm wurde dabei in die Komponenten Infizierung, Verbreitung und dieSchadensfunktion aufgeteilt. Lediglich die Schadensfunktion wurde nicht in dasComputerwurmprogramm integriert, damit eine Zweckentfremdung erschwertwird.

Die Infizierung in Abschnitt 3.3 war der aufwendigste Teil des Baukastens, dahier Probleme durch die Eigenheiten des Betriebssystems und der Prozessorarchi-tektur gegeben sind. Es wurde eine Sicherheitslucke konstruiert, an der die Infi-zierung entwickelt wurde. Die Verbreitungsfunktion wurde so gebaut, dass dasComputerwurmprogramm andere Gerate in einem WLAN-Netzwerk infizierenkann. Die Verbreitung wurden dazu in der Programmiersprache C entwickelt.

Der Test auf insgesamt vier verschiedenen Geraten, mit unterschiedlichen Prozes-soren und Betriebssystemversionen, bestatigte die Zuverlassigkeit des Shellcodesund des Computerwurmprogramms. Die ersten Voraussetzungen fur einen Com-puterwurm sind damit geschaffen.

Die Infizierung und Verbreitung des Computerwurms wurde lediglich fur diekonstruierte Sicherheitslucke des Testprogramms implementiert. Dieses Testpro-gramm stellt keine Gefahr dar, da es generell nicht auf Windows Mobile-Geratenenthalten und nur fur den Zweck dieser Arbeit entwickelt worden ist.

Zum Schluss wurden noch zwei Schadensfunktionen beschrieben. Die eine kannbeliebige Telefonnummern anwahlen, die andere versendet SMS-Kurznachrich-ten. Beide werden vom Benutzer wahrend der Ausfuhrung nicht bemerkt undkonnen hohe Kosten verursachen.

Das nachste Kapitel beschaftigt sich nun mit einer weiteren Voraussetzung, derSuche nach einer echten Sicherheitslucke, die fur eine Infizierung verwendet wer-den kann.

50

4 Suche nach Sicherheitslucken

4.1 Einleitung

Der zentrale Punkt dieses Kapitels ist die Suche nach einer Sicherheitslucken inWindows Mobile 5.0. Im ersten Teil geht es konkret um die Suche nach einer Si-cherheitslucke, die fur die Infizierung eines Computerwurms in Frage kommt.Das Finden einer Sicherheitslucke wurde eine Voraussetzung fur einen Computer-wurm schaffen. Fur die Suche nach Sicherheitslucken wurden Fuzzing-Technikeneingesetzt, da kein kompletter Quellcode von Windows Mobile 5.0 zur Verfugungstand.

Der zweite Teil dieses Kapitels beschreibt Probleme, die bei der Suche nach Sicher-heitslucken aufgetreten sind. Der letzte Teil beschaftigt sich mit Sicherheitsmetri-ken fur die Auswertung des Suchergebnisses. Hier wird diskutiert, inwieweit dieKosten fur das Finden einer Sicherheitslucke in Windows Mobile 5.0 durch einenErfolg oder Misserfolg der Suche abgeschatzt werden konnen.

4.2 Durchfuhrung des Fuzzings

4.2.1 Einleitung

Dieser Abschnitt beschaftigt sich mit der Suche nach einer kritischen Sicherheits-lucken in Windows Mobile 5.0 unter Einsatz von Fuzzing-Techniken. Zuerst wer-den mogliche Angriffsvektoren gesucht, die fur Fuzzinglaufe in Frage kommen.Dazu werden Portscans durchgefuhrt. Anschließend werden ausgewahlte UDP-Ports auf ihre Protokolle untersucht und gefuzzt. Fur die Fuzzinglaufe wird dasFuzzer Creation Toolkit SPIKE verwendet.

51


4.2.2 Allgemeines zu Fuzzing

Fur die Suche nach Sicherheitslucken in Windows Mobile 5.0 wurden Fuzzing-Techniken verwendet, da kein kompletter Quellcode fur Windows Mobile 5.0 zurVerfugung stand. Das Ziel war eine kritische Sicherheitslucke zu finden. Eine Si-cherheitslucke ist kritisch, wenn uber sie beliebiger Code ausgefuhrt werden kannund dies fur die Verbreitung eines Computerwurms verwendet werden kann. Beider Suche nach Sicherheitslucken wurden samtliche Schritte in einem Logbuchdokumentiert (s. Anhang C.3).

Das hauptsachliche Werkzeug beim Fuzzing war das SPIKE Fuzzer Creation Tool-kit, da man mit ihm sehr gut Protokollnachrichten nachbauen kann. Der ersteSchritt ist die Bestimmung von Angriffsvektoren im folgenden Abschnitt.

4.2.3 Angriffsvektoren

Bei der Suche nach Angriffsvektoren fur ein mobiles Gerat ist die Durchfuhrungeines Portscans angebracht. Dadurch kann in Erfahrung gebracht werden, welcheDienste die Gerate uber das IP-Netzwerk bereitstellen. Windows Mobile 5.0 be-sitzt keine eigene Firewall, somit sind offene Ports immer von außen erreichbar.In unserem Fall wurde uber die WLAN-Schnittstelle mit dem Netzwerkdiagnose-werkzeug und Sicherheitsscanner nmap gescannt.

Ein TCP-Scan auf die Testgerate mit der IP-Adresse liefert keine offenen Ports(s. Anhang C.1.1). Fur das TCP-Protokoll sind also keine Angriffsvektoren vor-handen. Bei dem UDP-Scan konnten jedoch offene UDP-Ports gefunden werden(s. Anhang C.1.2). Dies sind die Ports 137, 138, 1034 und 2948.

Die folgenden Unterabschnitte behandeln die einzelnen Fuzzinglaufe auf die aus-gewahlten Ports, die mit den Portscans gefunden worden sind. Da fur das FuzzingKenntnisse uber die Funktionsweise der Dienste vorhanden sein mussen, werdendiese soweit moglich in den jeweiligen Unterabschnitten erarbeitet.

4.2.4 UDP-Port 137

Hintergrund

Der UDP-Port 137 wird vom NetBIOS Name Service verwendet. Dieser ist Bestand-teil der NetBIOS-Protokollfamilie (s. Beschreibungen in [RFC87a, RFC87b]) unddient der Bekanntmachung verschiedener Gerate in einem TCP/IP-Netzwerk. Da-

52


fur sendet jeder Teilnehmer im Netzwerk einen Name Registration Request (NRR).Abbildung 4.1 stellt den Aufbau eines NRR-Datagramms dar. Dieses Datagramm

Abbildung 4.1: Aufbau eines NetBIOS Name Registration Request (aus [RFC87b])

wird von jedem Netzwerkteilnehmer gesendet, der NetBIOS einsetzt. Beim Fuz-zing werden fehlerhafte NRRs benutzt, um mogliche versteckte Programmierfeh-ler zu entdecken.

Fuzzing

Zuerst wird die SPK-Datei nbnrr.spk erstellt, welche die Struktur des NRR-Datagramms wiedergibt. Als Vorlage fur diese Datei dient der Mitschnitt einesNRR-Datagramms. Dies kann z. B. mit dem Programm wireshark vorgenom-men werden. Innerhalb von wireshark konnen einzelne Pakete exportiert werden.Das so isolierte NRR-Datagramm wird in der SPK-Datei unter Berucksichtigungseiner Felder nachgebaut (s. Anhang C.2.1). Die Datei enthalt nun die logischenElemente des NRR-Datagramms, so dass SPIKE gezielt einzelne von ihnen mani-pulieren kann.

Um nun einen Fuzzinglauf mit SPIKE zu starten, wird zunachst noch ein klei-nes C-Programm benotigt, welches die SPIKE-API verwendet, um die manipu-lierten Datagramme zu generieren und uber UDP zu versenden. Das Programmgeneric_send_udp, das im Framework von SPIKE enthalten ist, kann fur dieseZwecke verwendet werden. Der Syntax des Aufrufs ist:

$ generic_send_udp <Ziel> <Port> <SPK-Datei><Startvariable> <Start-String> <Stringanzahl>

Ziel und Port bezeichnet die Adresse bzw. den Port des Gerates, das gefuzzt wer-den soll. Die SPK-Datei enthalt die Information uber den Aufbau der zu senden-den Datagramme. Mit Startvariable und Startstring kann der Fuzzinglauf an einer

53


beliebigen Stelle gestartet werden. Dies ist vor allem dann nutzlich, wenn Data-gramme, die Fehler provozieren, wiederholt gesendet und alle vorherigen Data-gramme ausgelassen werden soll. Die Stringanzahl bestimmt die Anzahl der zusendenden Datagramme. Der Wert 0 bedeutet, dass die Anzahl nicht begrenztwird, sondern nur von den verschiedenen Moglichkeiten fur die Variablenbele-gungen abhangt.

Die Testgerate werden mit dem folgenden Aufruf gefuzzt:

$ generic_send_udp <Gerate-IP> 137 nbnrr.spk 0 0 0

Samtliche in der SPK-Datei definierten Variablen werden nun durch SPIKE mitsamtlichen Werten belegt. Es werden so viele Datagramme verschickt, bis alle Va-riablen durchlaufen worden sind.

Ergebnis

Die Testgerate zeigten oberflachlich auch nach dem Fuzzinglauf kein Fehlverhal-ten. Der Prozess device.exe ist fur die Implementierung der NetBIOS-Protokol-le verantwortlich. Dies lasst sich im Remote Process Viewer aus den Visual StudioRemote Tools uberprufen, denn der Prozess device.exe ist der einzige Prozess,der mit der Bibliothek netbios.dll verlinkt ist. Er lasst sich jedoch nicht mit denRemote Debuggern von Visual Studio oder IDA Pro debuggen, da er ein System-prozess ist. Dies behindert die Untersuchung von Fehlern innerhalb der NetBIOS-Implementierung.

Da das Gerat jedoch keine Funktionsstorung zeigte, wurde davon ausgegangen,dass der Fuzzinglauf keine Fehler provozieren konnte.

4.2.5 ActiveSync Notification UDP-Port 1034

Hintergrund

Der Dienst auf Port 1034 ist bei der Internet Assigned Numbers Authority (IANA)als activesync-notify registriert (vgl. [IAN06]). Fur diesen Dienst konnte jedoch kei-ne offizielle Dokumentation gefunden werden. Der einzige Hinweis wurde in ei-nem Forenbeitrag [HWF05] gefunden. Der Beitrag gibt an, dass ActiveSync-Serveruber diesen Port Benachrichtigungen via Wireless Datagram Protocol (WDP) ver-schicken, sobald eine neue E-Mail fur ein mobiles Gerat eingetroffen ist. Voraus-setzung dafur ist jedoch die Aktivierung des Up-To-Date-Modus, den zum einender Exchange-Server und zum anderen das mobile Gerat unterstutzen mussen.

54


Der weitere Plan an dieser Stelle war das Mitschneiden einer E-Mail-Benachrichti-gung, um das genaue Format der Ubertragung feststellen zu konnen. Dafur mussein Testsystem aufgesetzt werden, welches die folgenden Komponenten enthalt:

• Microsoft Windows Server 2003

• Microsoft Exchange 2003 fur Up-To-Date-Notification konfiguriert

Die Einrichtung eines Exchange-Servers mit Up-To-Date-Notification uber eineActiveSync-Verbindung ließ sich in der beschrankten Zeit jedoch nicht vorneh-men.

Fuzzing

Es wurde kein Fuzzing mit SPIKE durchgefuhrt, da das Protokollformat in deraufgewendeten Zeit unbekannt blieb. Auch die manuelle Kommunikation uberUDP-Port 1034 mit dem Programm netcat lieferte keine Information uber das Pro-tokoll. Zum Schluss wurden noch zufallige Daten an den Port gesendet. Dafurwurde der folgende Aufruf verwendet:

$ cat /dev/urandom | nc -u <Gerate-IP> 1034

Die Testgerate blieben auch nach diesem Versuch stabil.

Ergebnis

Der Versuch der Durchfuhrung eines Fuzzinglaufs war hier nicht erfolgreich. Da-mit Fuzzing auf eine Protokollimplementation angewendet werden kann, mussdas Protokoll zumindest in Grundzugen bekannt sein. Diese Informationen fehl-ten jedoch. An dieser Stelle sind weitere Untersuchungen durch die Verwendungeines Testsystems interessant. Es ist anzunehmen, dass ein Mircosoft Exchange-Server generell in der Lage ist, uber den angegebenen Port mit den WindowsMobile-Geraten zu kommunizieren. In diesem Fall konnte die Kommunikationabgefangen und das verwendete Protokoll analysiert werden. Die Vorbereitungenfur das Aufsetzen eines Testsystems sprengten jedoch den Zeitrahmen fur diesenTeil der Arbeit.

55


4.2.6 WAP-Push UDP-Port 2948

Hintergrund

Der UDP-Port 2948 wird fur das Versenden von MMS-Benachrichtigungen uberdas IP-Netzwerk genutzt. In [Mul06c, Mul06b] wurden bereits Schwachstellen furWindows CE 4.2-Gerate gefunden, die den MMS Composer der Firma Arcsoft inden Versionen 1.5 und 2.0 betreffen. Da sich auf den hier eingesetzten Testgerateneine neue Version des MMS Composers befindet (3.0.7.20), lohnt sich eine erneuteUntersuchung. Fur die alteren Versionen waren die Schwachstellen, nach Mulli-ners Aussagen zufolge, nicht ausnutzbar.

Die MMS-Benachrichtigungen sind nach [WAP02] kodiert. Ein Beispiel fur einegultige MMS-Benachrichtigung ist in Abbildung 4.2 zu sehen. Sie basiert auf derMMS-Benachrichtigung, die in [Mul06b] abgebildet ist. Aus diesen Daten wird

0006 2261 7070 6c69 6361 7469 6f6e 2f76 |.."application/v|6e64 2e77 6170 2e6d 6d73 2d6d 6573 7361 |nd.wap.mms-messa|6765 00af 848c 8298 3030 3030 3030 3030 |ge......00000000|3031 008d 9089 1280 7465 7374 4065 7861 |01......test@exa|6d70 6c65 2e63 6f6d 0096 4469 6573 2069 |mple.com..Dies i|7374 2065 696e 2054 6573 7400 8a82 8e01 |st ein Test.....|7888 0680 047a a77d 6483 6874 7470 3a2f |x....z.}d.http:/|2f31 3932 2e31 3638 2e32 3534 2e31 3031 |/192.168.254.101|2f74 6573 7432 00 |/test2.|

Abbildung 4.2: Hexadezimalausgabe einer MMS-Benachrichtigung

jetzt erneut eine SPK-Datei gebaut. Dazu wird die Spezifikation der MMS-Benach-richtigung aus [WAP02] zu Hilfe genommen. Die resultierende SPK-Datei ist inAnhang C.2.2 zu finden. In der Datei sind nur funf Felder als Variablen deklariert.Dies sind der Content Type, die X-Mms-Transaction-ID, das From-Feld, das Subjectund die X-Mms-Content-Location. Diese Felder enthalten Zeichenketten variablerGroße. An diesen Stellen sind Pufferuberlaufe erfahrungsgemaß am wahrschein-lichsten.

Fur den Empfang der MMS-Benachrichtigungen ist der Prozess tmail.exe desMMS-Composers zustandig. Dieser ist ein Usermode-Prozess und kann mit einemRemote Debugger uberwacht werden. In dem hier vorliegenden Fall wird IDAPro als Remote Debugger verwendet und es wird auf Ausnahmefehler im Prozesstmail.exe gewartet.

56


Fuzzing

Fur den Fuzzinglauf wird wieder das Programm generic_send_udp verwen-det, da auch diesmal ein UDP-Port gefuzzt werden soll. Der Aufruf lautet zu-nachst:

$ generic_send_udp <Gerate-IP> 2948 mms.spk 0 0 0

Da sich nicht alle Felder (vor allem die Transaktion-IDs) andern, unterscheidet derMMS Composer die Benachrichtigungen nicht von einander. Er nimmt nur dieerste korrekt formatierte Nachricht an und verwirft alle anderen. Im Posteingangwird dann auch nur eine Nachricht angezeigt (s. Abb. 4.3). Zu viele Datagram-me auf einmal zu verschicken ist in diesem Fall also nicht zielfuhrend. Aus die-sem Grund wurden nun einzelne Datagramme ubersprungen. Der nachste Auf-ruf, diesmal mit Ausgabe, lautet nun:

$ generic_send_udp <Gerate-IP> 2948 mms.spk 0 1 1Target is <Gerate-IP>Total Number of Strings is 681fd=3Fuzzing Variable 0:1Variablesize= 5004

Reached maximum packets to send (1).

Es wurde jetzt nur ein Datagramm gesendet, bei dem Variable 0 (Content-Type)mit einer Zeichenkette der Lange 5004 Byte belegt wurde. Der Debugger brichtjedoch auch diesmal nicht ab. Die nachste Variable wird gefuzzt:


Jetzt bricht IDA Pro ab und warnt mit folgender Meldung:

: The instruction at 0xD67EFC referenced memory at0x2409435A. The memory could not be read (0x00D67EFC ->2409435A)

Im Codefenster zeigt der Debugger die Instruktion an, die diesen Zugriffsfehlerverursacht hat.

57


Abbildung 4.3: MMS-Benachrichtigung wird angezeigt

00D67ECC loc_D67ECC00D67ECC LDR R3, [R1]00D67ED0 LDRB R3, [R3,R4]00D67ED4 CMP R3, #0x2000D67ED8 BCC loc_D67F0800D67EDC CMP R3, #0x7E00D67EE0 BHI loc_D67F0800D67EE4 STRB R3, [LR,R5]00D67EE8 LDR R3, [R1]00D67EEC ADD LR, LR, #100D67EF0 ADD R3, R3, #100D67EF4 STR R3, [R1]00D67EF8 LDR R4, [R0,#4]

PC -> 00D67EFC LDRB R3, [R3,R4]00D67F00 CMP R3, #000D67F04 BNE loc_D67ECC

Die Fehlermeldung besagt, dass eine Instruktion aus einen Speicherbereich lesenwollte, der fur sie nicht erreichbar war. Es wurde keine Moglichkeit gefunden, andieser Stelle fremden Code einzuschleusen. Dafur ware es notwendig gewesen,den Programcounter PC auf den Speicherbereich zu lenken, der durch die Varia-ble 0 belegt wurde. Dies ließ sich jedoch nicht bewerkstelligen. Es war lediglichmoglich, eine Adresse bei einer Leseoperation (LDRB R3, [R3,R4]) zu mani-pulieren.

58


Zwei weitere derartige Fehler wurden gefunden, die im Logbuch nachvollzogenwerden konnen. Auch bei ihnen wird die Anwendung beendet. Sie sind jedochgenauso wenig ausnutzbar, da sich auch bei ihnen kein Code ausfuhren lasst.

Wahrend des Fuzzings konnte ab und zu die Nachricht ”Medienbenachrichtigungkonnte nicht dekodiert werden“ auf dem Display des Testgerates gelesen werden.Das passierte immer dann, wenn das Format der Benachrichtigung fehlerhaft war.Die Fehlermeldung ist jedoch kein Fehler in der Software, da diese nur auf diefehlerhafte Nachricht hinweist.

Ergebnis

Es ist zu vermuten, dass die hier gefundenen Fehler auch in alteren Versionen desMMS Composers vorhanden waren und diese von Mulliner in [Mul06c, Mul06b]bereits gefunden wurden. Die Fehler konnten auch in Windows Mobile 5.0 nichtfur die Ausfuhrung von Shellcode verwendet werden.

Die Fehlermeldung auf dem Testgerat stellt, sofern sie wiederholt durch fehler-hafte MMS-Benachrichtigungen erzwungen wird, eine Behinderung bei der Ver-wendung des Gerats dar. Dies kann sehr einfach fur eine DoS-Attacke ausgenutztwerden.

4.2.7 DHCP-Client auf Port 68

Hintergrund

Windows Mobile-Gerate sind standardmaßig so konfiguriert, dass sie bei Eintrittin ein Netzwerk (z. B. uber WLAN) eine IP-Adresse via DHCP (siehe [Dro97])beziehen. Dazu sendet ein Client zunachst eine DHCP DISCOVER-Nachricht. Aufdiese Nachricht antwortet dann ein DHCP-Server und bietet dem Client eine IP-Adresse an. Dies geschieht mittels der DHCP OFFER-Nachricht. Der Client kanndieses Angebot nun annehmen und mit einem DHCP REQUEST die angeboteneIP-Adresse anfordern. Der DHCP-Server bestatigt dies abschließend mit einemDHCP ACK. Abbildung 4.4 zeigt die Kommunikation zwischen Client und Server.Sofern ein Client bereits in der Vergangenheit eine IP-Adresse zugewiesen bekam,kann er den ersten Schritt uberspringen und seine bisherige Adresse direkt miteinem DHCP REQUEST anfordern.

Fur das Fuzzing des DHCP-Clients auf dem mobilen Gerat wird ein WLAN-Netz-werk ohne DHCP-Server verwendet. Im WLAN-Netzwerk befinden sich ein Win-dows Mobile-Testgerat und ein Linux-Notebook. Das Notebook wird den Fuz-

59


Abbildung 4.4: Aushandlung einer IP-Adresse uber DHCP

zinglauf durchfuhren und die Rolle des DHCP-Servers ubernehmen. Gegenstanddes Fuzzinglaufs ist die DHCP ACK-Nachricht. Es wird davon ausgegangen, dassder Client keinen DHCP OFFER benotigt und unmittelbar nach der Assoziationim WLAN-Netzwerk den DHCP REQUEST schickt.

Bei dem UDP-Scan wurde der Port 68 nicht als offener Port gefunden. Dies ist derFall, da die Aushandlung der IP-Adresse zu diesem Zeitpunkt bereits abgeschlos-sen war und der Dienst nicht mehr benotigt wurde.

Fuzzing

Die SPK-Datei (Anhang C.2.3) fur den Fuzzinglauf wird anhand eines Mitschnittsvon DHCP-Verkehr und nach den Beschreibungen in [Dro97] erstellt. Wichtig istnoch, dass der Feldeintrag Transaction ID in der SPK-Datei angepasst wird. Ermuss identisch mit der Transaction ID aus dem DHCP REQUEST sein.

Die verschiedenen Felder, die in der SPK-Datei als Variablen deklariert wordensind, werden nun mit dem folgenden Aufruf gefuzzt:

$ generic_send_udp <Gerate-IP> 68 dhcp.spk 0 0 0

Die Gerate-IP muss dabei die selbe IP-Adresse sein, die in der generierten DHCPACK-Nachricht verwendet wurde.

Der Prozess device.exe ist auf den Windows Mobile-Geraten fur DHCP zustan-dig. Im Remote Process Viewer ist erkennbar, dass dieser Prozess mit dem Moduldhcp.dll gelinkt ist. Ein Anhangen der Debugger ist somit nicht moglich, dadevice.exe, wie bereits bekannt, ein Systemprozess ist.

60

4.3 Probleme bei der Suche nach Sicherheitslucken

Ergebnis

Der Fuzzinglauf wurde beendet ohne eine nachhaltige Beeintrachtigung des Test-gerats. Wahrend des Fuzzings konnte festgestellt werden, dass das Testgerat einersehr hohen Netzwerklast ausgesetzt war. Die Reaktionszeiten bei der Bedienungwaren entsprechend lang. Eine derartige Belastung kann als DoS-Attacke ange-sehen werden, bei der nicht nur die Reaktion des Gerats verschlechtert, sondernauch die Akkulaufzeit drastisch verkurzt wird. Dies ist ein allgemeines Problem,welches schwer zu beheben ist.

4.2.8 Beendigung der Suche

Die Suche nach Sicherheitslucken in Windows Mobile wurde nach insgesamt 44Stunden Arbeitszeit beendet, ohne dass eine kritische Sicherheitslucke entdecktwerden konnte, die es erlauben wurde, fremden Code auf Windows Mobile 5.0-Geraten auszufuhren. Es bleibt zu erwahnen, dass wegen den vielen Ansatzenauch nur sehr oberflachlich getestet wurde. Fur jeden einzelnen Dienst kann ge-nerell sehr viel mehr Zeit investiert werden, als es in dieser Arbeit moglich war.


Dieser Abschnitt hat sich mit der Durchfuhrung des Fuzzings im Rahmen derSuche nach Sicherheitslucken beschaftigt. Untersucht wurden die generell offe-nen UDP-Ports 137, 1034, 2948 und das DHCP-Protokoll auf UDP-Port 68 fur dieAushandlung einer IP-Adresse. Es konnte keine kritische Sicherheitslucke ent-deckt werden, die es ermoglicht hatte fremden Code auf den mobilen Geratenauszufuhren.

Der nachste Abschnitt behandelt technische und grundsatzliche Probleme, die beider Suche nach Sicherheitslucken aufgetreten sind.


4.3.1 Einleitung

Es wurden verschiedene Probleme bei der Suche nach Sicherheitslucken festge-stellt. Ein Problem war der Stack-Schutz durch Security Cookies, der auf den Test-

61


geraten verwendet wurde und nicht umgangen werden konnte. Weiterhin wur-den Unzulanglichkeiten bei den verwendeten Debuggern festgestellt, welche dieSuche nach Sicherheitslucken erschwerten. Das letzte Problem stellte der hoheZeitaufwand bei der Suche dar.

4.3.2 Security Cookies in Windows Mobile 5.0

Das erste Problem betrifft den Pufferuberlaufschutz durch Security Cookies (vgl.Abschnitt 2.2.10). Zuvor wurde angenommen, dass der Schutz gegen Stack-ba-sierte Pufferuberlaufe auf Windows Mobile 5.0-Geraten nicht aktiv ist. Hinwei-se darauf lieferten [Hur05b] und [san05b], in denen Windows CE 4.2-Gerate oh-ne Stack-Schutz verwendet wurden. Wahrend der Suche nach Sicherheitsluckenkonnte jedoch entdeckt werden, dass die Software der Testgerate durchaus mitdem Stack-Schutz ubersetzt wurden.

Um festzustellen, ob ein Programm mit dem Stack-Schutz ubersetzt worden ist,muss sein Maschinencode analysiert werden. Gesucht wird nach einschlagigenSequenzen von Instruktionen, die den Stack-Schutz implementieren. Im Prologeiner jeden Funktion, die mit den Security Cookies geschutzt ist, findet man fol-gende Instruktionen:

ldr r3, cookie_refldr r3, [r3]str r3, [sp, offset]

cookie_ref ist in diesem Fall ein Zeiger auf eine Stelle im Datenbereich des Pro-zesses, an dem der Referenzwert fur den Security Cookie abgelegt worden ist.Der Zeiger wird in das Register geladen und dereferenziert. Der Wert an der Spei-cherstelle, auf die der Zeiger zeigt, wird ausgelesen und in eine lokale Variablegeschrieben. Der Zugriff auf die lokale Variable erfolgt mit einem offset rela-tiv zum aktuellen Stack-Frame, also zum Stackpointer sp. Diese lokale Variableenthalt den Security Cookie.

Im Epilog jeder Funktion, die durch Security Cookies geschutzt ist, muss der Coo-kie auf dem Stack mit seinem Referenzwert im Datenbereich verglichen werden.Dies kann auch an mehreren Stellen einer Funktion passieren, wenn die Funktionan mehreren Stellen beendet werden kann. Fur die Uberprufung des Cookies sindnun folgende Instruktionen zustandig:

ldr r0, [sp, offset]bl check_security_cookie

62


Hier wird zuerst der Cookie vom Stack in das Register r0 geladen. Das Regis-ter dient gleichzeitig als erster Parameter fur den Aufruf der nachsten Funktioncheck_security_cookie. Diese Funktion vergleicht den Cookie mit seiner Re-ferenz. Sind beide Werte gleich, so hat kein Pufferuberlauf stattgefunden und dieFunktion kehrt normal zuruck, so dass der Prozess weiterhin ausgefuhrt wird.Falls sich die beiden Werte jedoch unterscheiden, so sorgt die Funktion dafur, dassein Ausnahmefehler generiert und der Prozess beendet wird.

Es war nicht sofort ersichtlich, ob die Software auf den Testgeraten mit dem Puf-feruberlaufschutz ubersetzt worden ist. Bei einem Programm, das auf den Geratenim ROM vorinstalliert ist, muss man sich im laufenden Betrieb mit einem RemoteDebugger an den Prozess des Programms anhangen. Nur so kann man den Co-de des Programms einsehen, denn Dateien im ROM konnen lediglich ausgefuhrtund nicht direkt aus dem Dateisystem gelesen werden. Ist das Programm vomBetriebssystem in den Speicher geladen worden, so kann der Code im Debuggerangesehen werden. Dies kann z. B. mit dem Microsoft Remote Debugger von Visu-al Studio oder mit IDA Pro geschehen. Beide Debugger sind hierfur ausreichendgeeignet.

Als konkretes Beispiel wird die Anwendung tmail.exe betrachtet. Dies ist derMMS Composer von der Firma ArcSoft (s. [Arc06]), der fur den Empfang und dieVersendung von Multimedia-Nachrichten verwendet wird. Er ist im Software-paket der Testgerate enthalten. Nach einigem Suchen findet man beispielsweisefolgende Adressen, an denen die Implementation des Stack-Schutzes festgestelltwerden kann.

tmail.exe:00014658 LDR R3, =0x4D714tmail.exe:0001465C LDR R3, [R3]tmail.exe:00014660 STR R3, [SP,#0x2A8][...]

// Rumpf der Funktion[...]tmail.exe:00014678 LDR R0, [SP,#0x2A8]tmail.exe:0001467C BL loc_418A4

Der Zeiger auf die Referenz des Security Cookies befindet sich hier konkret an derSpeicherstelle 0x004d714. Die lokale Variable fur den Cookie befindet sich amOffset 0x2a8 des Stack-Frames. Die Funktion, die anschließend aufgerufen wirdist die, die zuvor check_security_cookie genannt wurde.

Die Untersuchung zeigt, dass die Software auf den Testgeraten durchaus mit demStack-Schutz ubersetzt worden ist. Im Rahmen der Suche nach ausnutzbaren Si-cherheitslucken stellt dies eine große Einschrankung dar. Stack-basierte Puffer-uberlaufe konnen auf den Testgeraten, zumindest auf gewohnte Art und Weise,

63


nicht mehr ausgenutzt werden.

Umgehung des Stack-Schutzes

Der Pufferuberlaufschutz durch Security Cookies wurde bereits fur die Uberset-zung des Betriebssystems Windows 2003 Server verwendet. In [Lit03] werden einpaar Ansatze aufgezeigt, die in vielen Fallen den Pufferuberlaufschutz umgehenkonnen. Die Ansatze machen sich dabei die Implementation des Structured Ex-ception Handling auf x86-Architekturen zunutze.

Structured Exception Handling (SEH) wird eingesetzt, um Hardware- und Software-Exceptions abzufangen und auf sie zu reagieren. Exceptions sind beispielsweiseDivison-durch-Null- oder Speicherzugriffsfehler. Fur die Bearbeitung der Excep-tions werden spezielle Exception Handler definiert. In ihnen kann auf Exceptionsreagiert werden, so dass die Ausfuhrung des Programms fortgesetzt oder aberkontrolliert beendet werden kann. Der folgende Ausschnitt zeigt den notwendi-gen Code fur die Behandlung von Exceptions in C/C++:

try {// zu uberwachender Code

}except (Exception-Filter) {

// Exception Handler}

Der auf Exceptions zu uberwachende Code wird in den try-Block gesetzt. Derexcept-Block definiert einen Exception Handler fur einen ausgewahlten Filter.Der Filter definiert, fur welche Exceptions der Handler zustandig ist.

Bei der Ubersetzung durch den Compiler werden die Informationen uber denzu verwendenden Exception Handler fur x86-Architekturen auf dem Stack ge-speichert. Dazu wird dort die Struktur EXCEPTION_REGISTRATION angelegt.Sie enthalt einen Zeiger auf den verwendeten Exception Handler und einen Zei-ger auf die nachste EXCEPTION_REGISTRATION-Struktur. Jede Funktion besitzteinen eigenen Exception Handler und dementsprechend auch eine fur sie spezi-fische EXCEPTION_REGISTRATION-Struktur in ihrem Stack-Frame (s. Abb. 4.5).Die Zeiger in den Strukturen bilden eine einfach verkettete Liste.

Eine Funktion, in der ein Pufferuberlauf erzwungen werden kann und in der SEHverwendet wird, kann unter Umstanden trotz Security Cookies ausgenutzt wer-den. Dazu muss mit dem Pufferuberlauf der Zeiger auf den Exception Handler inder EXCEPTION_REGISTRATION-Struktur uberschrieben werden. Anschließend

64


Abbildung 4.5: Stack-Frame mit SEH und Security Cookie auf x86-Architekturen

muss nur noch eine Exception generiert werden, damit der veranderte Excepti-on Handler aufgerufen wird. Bei der Wahl des Zeigers auf einen neuen Excepti-on Handler gibt es ein paar Einschrankungen, so dass z. B. keine Stack-Adressenverwendet werden konnen. Es existieren jedoch andere Moglichkeiten dafur. In[Lit03] erklart Litchfield diesen Ansatz im Detail. Mehr zum Thema SEH kann in[Pie97] in Erfahrung gebracht werden.

Fur RISC-Architekturen wird das Structured Exception Handling jedoch andersimplementiert als fur x86-Architekturen. Hier werden keine Strukturen auf demStack gespeichert, die fur das Exception Handling verwendet werden. Stattdessenwerden die notwendigen Informationen zum Zeitpunkt der Ubersetzung gene-riert und in der Code- und PDATA-Sektion eines Prozesses hinterlegt (s. [MS:06]unter ”SEH in RISC Environments“). Ein Stack-basierter Pufferuberlauf kann die-se Bereiche aber nicht uberschreiben, um den Zeiger auf den Exception Handlerzu manipulieren. Samtliche Ansatze aus [Lit03], die das SEH fur die Umgehungdes Pufferuberlaufschutzes nutzen, sind damit unter Windows Mobile 5.0 nutzlos.

Der Pufferuberlaufschutz durch Security Cookies ist fur Windows Mobile 5.0 alsoeffektiver als fur Windows 2003 Server. Fur die Suche nach Sicherheitslucken be-deutet dies, dass generell weniger ausnutzbare Schwachstellen gefunden werdenkonnen.

65


4.3.3 Probleme mit den Debuggern

Ein generelles Problem bei der Suche nach Sicherheitslucken sind die Mangelder verwendeten Debugger. Fur das Debugging waren im Zeitraum der Arbeitdrei verschiedene Debugger bekannt, die prinzipiell mit Windows CE-basiertenGeraten arbeiten sollten: der Remote Debugger von Mircosoft Visual Studio 2005,IDA Pro von der Firma DataRescue und der GNU Debugger GDB.

Alle drei Debugger arbeiten nach dem selben Prinzip (s. Abb. 4.6). Der eigentli-che Debugger lauft auf einem Desktop-Rechner. Uber die ActiveSync-Verbindungzum Windows Mobile-Gerat wird ein Debuggermodul (stub) ubertragen und an-schließend ausgefuhrt. Dieses Modul kann nun ein Programm starten und debug-gen oder sich an einen bereits laufenden Prozess anhangen. Letzteres setzt jedochvoraus, dass es sich um einen User-Prozess handelt. Systemprozesse konnen aufdiese Art und Weise nicht gedebuggt werden. Insbesondere konnen so SystemCalls nicht untersucht werden, da diese von Systemprozessen ausgefuhrt werden.Der Ansatz ist auch dann ein Problem, wenn ein Fehler das gesamte Gerat zumStillstand bringt. In diesem Fall kann das Debuggermodul nicht mehr mit demDebugger kommunizieren und es konnen keine weiteren Informationen uber denFehler in Erfahrung gebracht werden.

Abbildung 4.6: Einsatz des Debuggermoduls beim Remote Debugging

Der Remote Debugger von Microsoft ist in der Entwicklungsoberflache von Visu-al Studio integriert. Seine Funktionen beschranken sich auf das notwendigste. Erkann Quellcode und disassemblierten Code miteinander in Verbindung bringen,zeigt jedoch keine Symbolinformationen im disassemblierten Code an. Steht keinQuellcode zur Verfugung, so fehlen wichtige Informationen, um die Ablaufe in ei-nem Prozess zu verstehen. Beim Fuzzing ist dies jedoch unerlasslich. Zudem kames oft zur Trennung der Verbindung zum Desktop-Rechner ohne einen erkennba-ren Grund, oder es gab lange Wartezeiten bevor weitere Instruktionen ausgefuhrtwurden. In einigen Fallen waren sogar Neustarts des Desktop-Rechners und desmobilen Gerats notwendig, damit das Debuggen erneut aufgenommen werdenkonnte.

DataRescues IDA Pro verfugt uber einen Remote Debugger mit wesentlich mehr

66


Funktionalitat. Da IDA Pro als Disassembler fur Binarprogramme konzipiert ist,liefert er wichtige Informationen uber verwendete Variablen und Speicherberei-che. Der Benutzer ist in der Lage Variablen und Unterprogramme zu benennen,um so die Lesbarkeit des disassemblierten Codes zu erhohen. Kommentare furSprungmarkierungen und Referenzen auf selbige erleichtern die Verfolgung desProgrammflusses. IDA Pro konnte nur auf dem MDA Pro zum laufen gebrachtwerden, nicht aber auf dem MDA Vario. Auf letzterem kam es zu diversen Feh-lermeldungen. Das Unterbrechen eines laufenden Prozesses war in IDA Pro nichtmoglich. Bei den Versuchen beendete der Debugger die Sitzung umgehend miteiner Fehlermeldung. Auch bei IDA Pro gab es immer wieder unerklarliche Ab-bruche der Debugger-Verbindung. Neustarts der Systeme waren haufig ebensonotwendig.

Der GNU Debugger GDB ist dafur ausgelegt, auch Windows Mobile-Gerate zudebuggen, sofern er fur das Zielsystem arm-wince-pe ubersetzt worden ist. Ge-testet wurde der vorkompilierte GDB aus dem CEGCC-Projekt [CEG]. Fur dieVerbindung zu den mobilen Geraten war das SynCE-Projekt notwendig. Im Testgelang es, die Verbindung mit den Geraten uber SynCE herzustellen, jedoch nichtden GDB uber die SynCE-Verbindung zu benutzen. Das SynCE-Projekt ist nochsehr experimentell und sucht zur Zeit personelle Unterstutzung bei der Entwick-lung (s. [Syn07] und Anhang A).

4.3.4 Zeitaufwand und fehlende Informationen

Wenn man Software fuzzen mochte, ist es notwendig zu verstehen, wie diesefunktioniert. Da die fehlerhaften Eingaben beim Fuzzing auf korrekt formatiertenEingaben basieren, muss das Format der Nachricht bzw. des Protokolls bekanntsein. Im Abschnitt 4.2.5 z. B. fehlten Informationen uber das verwendete Protokollkomplett. Auch der Versuch ein Testsystem aufzusetzen, konnte die Informatio-nen in der gegebenen Zeit nicht liefern. Der Zeitaufwand ist generell sehr groß.Einen großen Teil machte die Erarbeitung von Grundlagen im Vorfeld der Sucheund die Einarbeitung in die verschiedenen Details der Protokolle aus.


Dieser Abschnitt gab einen Uberblick uber die Probleme bei der Suche nach Si-cherheitslucken. Der Stack-Schutz durch Security Cookies konnte auf den Win-dows Mobile 5.0-Geraten festgestellt werden. Dieser stellt eine großes Hindernisbei der Ausnutzung von Stack-basierten Pufferuberlaufen dar. Bereits bekannteTechniken fur die Umgehung dieses Schutzes auf anderen Betriebssystemen konn-ten auf Windows Mobile 5.0 nicht angewendet werden, da das Structured Excepti-

67


on Handling hier anders implementiert ist. Stack-basierte Pufferuberlaufe konnendeswegen im Allgemeinen nicht mehr ausgenutzt werden. Das zweite Problembetraf die verwendeten Debugger, die ihre Aufgabe nicht immer zufriedenstellenderledigten oder die gar nicht verwendet werden konnten. Zum Schluss wurdenoch der immense Zeitaufwand als Problem bei der Suche nach Sicherheitsluckenangefuhrt.

4.4 Anwendbarkeit einer Sicherheitsmetrik

4.4.1 Einleitung

In diesem Abschnitt geht es nun um die Frage, ob die Ergebnisse aus der Su-che Aufschluss daruber geben, wie hoch der Aufwand zum Finden einer Sicher-heitslucke in Windows Mobile 5.0 ist. Es wird diskutiert, inwieweit eine Metrikangewendet werden kann, um die Sicherheit von Windows Mobile 5.0 zu bewer-ten.

4.4.2 Cost-to-break-Metrik

Die Cost-to-break (CTB) wurden von Schechter in [Sch02] eingefuhrt und bezeich-nen die niedrigsten erwarteten Kosten, die notwendig sind, um in einem Systemeine Sicherheitslucke zu entdecken und auszunutzen.

CTB-Metriken werden in der Kryptographie verwendet, wo sie fur die Bewer-tung von Verschlusselungsverfahren eingesetzt werden. Angriffe auf diese Ver-fahren sind schon lange ausfuhrlich erforscht und auf algorithmische Problemereduziert worden. Beispiele dafur sind Brute Force-Angriffe auf den Digital En-cryption Standard (DES) (s. [BDR+96]) oder Faktorisierungsalgorithmen fur dasBrechen von Public Key-Verfahren wie RSA (s. [RSA06a]). Die CTB hierfur wer-den zunachst nicht in Dollar oder Euro gerechnet, sondern in Recheneinheiten.Mochte man die finanziellen CTB berechnen, so kann man dies uber die Kostenfur die Rechenleistung vornehmen. Die Rechenleistung wird dabei von der einge-setzten Hardware bestimmt. Diese reicht von gunstigen Heimcomputern bis hinzu teurer Spezialhardware wie Field Programmable Gate Arrays (FPGA) und App-lication Specific Integrated Circuits (ASIC). Da die Probleme berechenbar sind, istes fur jede Hardware nur eine Frage der Zeit, bis die Algorithmen terminierenund das Ergebnis liefern. Fur eine bestimmte Hardware mit bestimmter Rechen-leistung kann ein Erwartungswert fur die Termination des Algorithmus angege-ben werden. Unter Berucksichtigung der Ausgaben fur die verwendete Hardware

68


konnen dann auch die finanziellen CTB bestimmt werden.

In [BDR+96] berechnen die Autoren den Aufwand fur das Brechen einer mittelsDES verschlusselten Nachricht. Mit Brute Force-Angriffen werden alle moglichenSchlussel durchprobiert, um die unverschlusselte Nachricht zu entschlusseln. Eswird dabei zwischen mehreren Angreiferklassen unterschiedenen. Jede Angreifer-klasse hat verschiedene finanzielle Moglichkeiten und Ausrustungen fur den Ein-satz des Brute Force-Algorithmus. In Tabelle 4.1 ist der zeitliche Aufwand fur jedeAngreiferklasse dargestellt. Die Autoren bestimmen aufgrund dieser Ergebnissedie minimalen Schlussellangen fur den sicheren Einsatz des DES-Kryptoverfahr-ens gegen die verschiedenen Angreiferklassen.

Angreifertyp Budget Werkzeug Zeit und Kosten pro Schlussel40 Bit 56 Bit

Einfacher Hacker winzig Computer 1 Woche nicht machbar400$ FPGA 5h (0,08$) 38 Jahre (5$)

Kleines Unternehmen 10T$ FPGA 12m (0,08$) 18 Monate (5$)Konzernabteilung 300T$ FPGA 24s (0,08$) 19 Tage (5000$)

ASIC 0,18s (0,001$) 3h (8$)Großes Unternehmen 10M$ FPGA 0,7s (0,08$) 13h (5000$)

ASIC 0,005s (0,001$) 6m (38$)Geheimdienst 300M$ ASIC 0,0002s (0,001$) 12s (38$)

Tabelle 4.1: Aufwand fur das Brechen von DES (Ergebnisse aus [BDR+96])

Es muss bemerkt werden, dass Brute Force-Angriffe auf Kryptosysteme nur WorstCase-Szenarien fur Angreifer darstellen. Moglicherweise gibt es, etwa wegen Un-zulanglichkeiten des Systems, noch andere, schneller durchfuhrbare Angriffe. Au-ßerdem kann der Angreifer mit Gluck nur einen Bruchteil der Zeit benotigen,welche fur eine komplette Durchsuchung des Schlusselraums notwendig gewe-sen ware. In diesen Fallen sind die wahren CTB geringer als die Kosten, die ausden Ergebnissen der Brute Force-Angriffe bestimmt wurden.

Bei einer Suche nach Sicherheitslucken in Software ist die Berechnung der CTB ausPrinzip schon komplizierter. Hier gibt es keine Ressource wie Recheneinheiten, dadie Suche nicht auf einen berechenbaren Algorithmus reduziert werden kann. Esgeht vorwiegend um Implementierungs- und Programmierfehler in der Softwareund nicht um Probleme im Design eines Verfahrens. Die moglichen Fehler konnenzudem sehr unterschiedlich sein.

Ursprunglich war die Idee, die CTB-Metrik ahnlich wie in der Kryptographie auchauf die Suche nach Sicherheitslucken in Windows Mobile 5.0 anzuwenden. StattRechenschritte sollte dabei der Aufwand eines Experten, der auf die Suche an-gesetzt wird, betrachtet werden. Dieser wird fur seine Arbeit mit einem festen

69


Stundenlohn vergutet. Die gesamten anfallenden Kosten sind dann die CTB, aus-gedruckt in einer Wahrung. Nach der Suche sollte eine Aussage uber die finanzi-ellen Kosten getatigt werden, die ein Angreifer benotigt, um eine kritische Sicher-heitslucke in Windows Mobile 5.0 zu entdecken. Auf diesem Weg konnte dann dieSicherheit des Betriebssystems gegenuber Angreiferklassen, die ein bestimmtesBudget zur Verfugung haben, bewertet werden. Es existieren zwei Falle, je nachErfolg der Suche. Entweder die Suche wird beendet, weil eine Sicherheitsluckegefunden wurde oder aber sie wird abgebrochen, weil der finanzielle Rahmenoder die angesetzte Zeit aufgebraucht wurde, bevor eine Sicherheitslucke gefun-den werden konnte.

Der erste Fall hat ein eindeutiges Ergebnis: Das System ist unsicher und kannmit einem bestimmten Aufwand gebrochen werden. Der Aufwand gibt dabei eineobere Grenze fur die CTB an. Dies ist nachvollziehbar, da ein anderer Experte oderAngreifer, der z. B. die selben Mittel einsetzt, genauso erfolgreich sein kann.

Der zweite Fall sagt aus: Es ist nicht moglich, das System mit dem aufgebrachtenAufwand zu brechen. Der aufgebrachte Aufwand kann jetzt als untere Grenze furdie CTB angesehen werden, da argumentiert werden kann, dass mehr Aufwandnotwendig ist, um das System zu brechen. Die zweite Aussage ist interessanterals die erste, da sie etwas uber die Sicherheit und nicht uber die Unsicherheit desSystems aussagt. Sie ist jedoch einfacher zu kritisieren. Es stellen sich Fragen nachden Erfahrungen und Fahigkeiten des Experten, nach der Vorgehensweise beimFuzzing und nach der generellen Ubertragbarkeit des Ergebnisses.

4.4.3 Kritik an der Metrik

Ein Kritikpunkt bezieht sich auf die Bewertung der Experten. Die Suche wurdenur von einer einzigen Person durchgefuhrt, dem Autor der Diplomarbeit. Es istnicht bekannt, in wie weit sich die Fahigkeiten des Autors mit denen von anderenExperten und potentiellen Gegnern vergleichen lassen. Selbst wenn dies moglichware, musste zudem davon ausgegangen werden, dass zwei Experten mit glei-chen Fahigkeiten und Erfahrungen auch mit der selben Wahrscheinlichkeit Si-cherheitslucken finden. Dies ist jedoch nicht plausibel, da der Zufall eine sehrgroße Rolle spielt. Außerdem fallt es selbst erfahrenen Experten in diesem Bereichschwer abzuschatzen, in wie weit sie in der Lage sind, Sicherheitslucken zu finden.Dies liegt unter anderem daran, dass es keinen strukturierten Prozess fur die Su-che nach Sicherheitslucken gibt. Dave Aitel, Autor von IT-Sicherheitsbuchern undGrunder der Sicherheitsfirma Immunity, schreibt auf der Mailingliste dailydave[Ait06], dass er und andere Sicherheitsforscher nicht sagen konnen, ob und wannsie eine Sicherheitslucke finden werden. Es komme dabei lediglich auf Ausdauer,Erfahrung und Bauchgefuhl an (s. a. [Spr06]). Eine Suche nach Sicherheitslucken

70


ist ein kreativer Vorgang. Wenn es schon nicht moglich ist die eigenen Ergebnis-se vorauszusagen, dann konnen auch die Erfolge anderer Experten bei der Suchenach Sicherheitslucken nicht eingeschatzt werden. Schechter beschaftigt sich in[Sch04] mit der Messung von Sicherheit in Software und den Schwierigkeiten beider Bestimmung der CTB. Er schreibt, dass eins der Probleme bei der Messungder CTB sei, dass sie eine Funktion der Kosten derer darstellen, die ein Systembrechen mochten und nicht derer, die es schutzen. Es sei unmoglich die benotig-ten Fahigkeiten, Zeit und andere Ressourcen samtlicher Gegner zu erforschen undsogar unwahrscheinlich, dass die Gegner diese fur sich selbst bestimmen konnen.

Da sich die Suche nach Sicherheitslucken in dieser Arbeit auf Fuzzing-Technikenbeschrankte, kann auch keine Aussage daruber gemacht werden, was mit ande-ren Techniken moglich gewesen ware. Verschiedene Techniken sind untereinanderschwer vergleichbar. Ein Experte, dem der Quellcode von Windows Mobile 5.0fur seine Untersuchungen zur Verfugung steht, hat mit einem Quellcode-Auditmoglicherweise mehr Erfolg bei der Suche. Jemand, der sich auf statische Binary-Analysen spezialisiert hat, konnte Schwachstellen durch Reverse Engineering derROM-Images von Windows Mobile 5.0-Geraten aufdecken. Es ist nicht bekannt,welche Teile der gesamten Angriffsflache eines Systems von den einzelnen Tech-niken abgedeckt werden. Deswegen kann nicht argumentiert werden, dass dieErgebnisse eines einzelnen Verfahrens fur die Abschatzung der Ergebnisse allermoglichen Verfahren ausreichend sind. Der Fuzzing-Technik wird im Allgemei-nen nachgesagt, dass man mit ihr in der Regel nur simple Fehler findet, die großeAuswirkungen haben (z. B. Remote Code Injection). Kompliziertere Fehler wer-den dabei eher nicht entdeckt (s. a. [Jur06]). Eine Abschatzung des Aufwands nurdurch Fuzzing-Techniken ist nicht ausreichend fur eine Aussage uber die CTB.

Durch die zeitliche Beschrankung ist auch die Anzahl der untersuchten Angriffs-vektoren beschrankt. In dieser Arbeit wurden z. B. lediglich ausgesuchte Netz-werkdienste untersucht. Die durchgefuhrten Fuzzinglaufe haben zudem keinenAnspruch auf Vollstandigkeit. Eine vollstandige Uberprufung ist aus Zeitgrundennicht moglich, so dass der Autor nach eigenem Ermessen vorgehen musste. Ei-ne zusatzliche Belegung einer SPIKE-Variablen, ein anderes Fuzzing Frameworkoder die Konzentration auf eine zusatzliche DHCP-Protokollnachricht hatte zuvollig neuen Ergebnissen bei der Suche fuhren konnen.

4.4.4 Hacking Challenges

Hacking Challenges, Bug Challenges oder Bug Bounties sind Wettbewerbe, dievon diversen Firmen angeboten werden, um die Sicherheit ihrer Software odersonstiger Systeme zu demonstrieren. Die Firmen geben offentlich bekannt, dassderjenige, der zuerst eine Sicherheitslucke in ihrem Produkt findet, ein Preisgeld

71


fur den Fund erhalt. Der Hintergedanke dabei ist, dass das Preisgeld fur die Ab-schatzung der CTB des Systems verwendet werden kann, sofern es niemandemgelingt, das System zu brechen.

Auf [RSA06b] bietet die Firma RSA Laboratories zwei Cryptographic Challengesan. Bei der Factoring Challenge geht es um die Faktorisierung von großen Zah-len, die auch im RSA Kryptoverfahren Verwendung finden. Die Zerlegung einerZahl in ihre Primfaktoren ist sehr aufwendig. Diese praktische Hurde gewahr-leistet die Geheimhaltung von Informationen in Public Key-Kryptoverfahren wiedem von RSA. Die RSA Laboratories haben acht Zahlen verschiedener Lange zurVerfugung gestellt, die faktorisiert werden sollen. Potentielle Teilnehmer werdendurch Preisgelder motiviert. Es wurden bereits zwei Zahlen der Lange 576 Bit und640 Bit faktorisiert, fur die jeweils 10.000 $ und 20.000 $ vergeben wurden. Fur diebislang unfaktorisierte Zahl mit der Lange 2048 Bit ist ein Preisgeld von 200.000 $ausgeschrieben.

Das Ziel der zweiten Challenge, der Secret-Key Challenge, ist es, den geheimenSchlussel herauszufinden, der bei einer symmetrischen Verschlusselung verwen-det wurde. Es existiert ein verschlusselter Text, bei dem der Digital EncryptionStandard (DES), und zwolf weitere, bei denen der Block-Cipher RC5 verwendetwurde. Fur die Einsendung einer Losung werden jeweils 10.000 $ ausgezahlt.

Es mag den Anschein haben, dass Hacking Challenges Vorteile gegenuber beauf-tragten Suchen nach Sicherheitslucken haben. Durch eine offentliche Ausschrei-bung des Wettbewerbs konnten wesentlich mehr Experten dazu motiviert wer-den, nach Sicherheitslucken zu suchen. Zudem gibt es keine Beschrankung derVorgehensweisen und Angriffsvektoren. Es gibt jedoch auch Argumente gegenHacking Challenges.

Die meisten Wettbewerbe werden unfair ausgetragen. Ein Beispiel dafur ist dieHacking Challenge der Firma Argus Systems vom April 2001. Hacker aus derganzen Welt wurden aufgefordert, Argus’ Sicherheitsprodukt Pitbull Secure WebAppliance zu knacken. Das Preisgeld wurde dabei mit 48.000 $ angesetzt. Bereits24 Stunden nach Beginn des Wettbewerbs konnte die polnische Hackergruppe LastStage of Delirium (LSD) den kompletten Zugriff auf das System fur sich beanspru-chen. Die Sicherheitslucke wurde Argus unterbreitet, doch selbst 18 Monate nachdem Wettbewerb wurde der großte Teil des Preisgeldes noch unterschlagen. Le-diglich 5000 $ wurden an LSD ausgezahlt (Quellen: [Del01, Pou02]).

Schneier behandelt Hacking Contests in [Sch00] und nennt dort weitere Beispie-le fur unfaire Wettbewerbe. Er bemangelt zudem, dass es keine Informationendaruber gebe, wer an den Wettbewerben teilnehme, welchen zeitlichen Aufwanddie Teilnehmer betreiben und ob nicht alle nur die gleichen Angriffe ausprobierenwurden. Weiterhin seien die Preisgelder kein großer Anreiz fur Sicherheitsexper-ten, da sie besser gestellt seien, wenn sie fur den Arbeitsaufwand bezahlt wurden.

72


Dem ist hinzuzufugen, dass die Preisgelder meist nicht einmal als Aufwands-entschadigung ausreichend sind. Um einen der RC5-Contests der RSA Laborato-ries zu gewinnen, investierte ein Teilnehmer uber 5 Jahre seiner Zeit. Als Preisgelderhielt er aber nur die ausgeschriebenen 10.000 $ (von [RSA06b]). Zudem hatte espassieren konnen, dass jemand anderes den Wettbewerb zuerst beendet und diebereits investierte Zeit vergeudet gewesen ware. Viele Sicherheitsexperten werdensich aus diesen Grunden erst gar nicht beteiligt haben. Schechter argumentiert in[Sch04], dass selbst die großen Preisgelder in der Factoring Challenge von RSAnicht groß genug sind, da ein kriminelles Individuum, mit der Moglichkeit RSAPublic Keys zu faktorisieren, Millionen von Dollar machen konnte.

Der letzte Punkt den Schneier kritisiert ist, dass nur negative Ergebnisse bei ei-nem Hacking Contest herauskommen konnen. Wenn Sicherheitslucken entdecktwerden ist gezeigt, dass das System unsicher ist. Aus der Tatsache, dass niemandeine Sicherheitslucke gefunden hat, kann jedoch nicht der Schluss gezogen wer-den, dass das System sicher ist. Es gibt also keine positiven Ergebnisse. Dies isteine Problematik, die sich auch bei der Suche nach Sicherheitslucken zeigt.

Es bleibt zu sagen, dass Hacking Challenges sowie gezielte Suchen nach Sicher-heitslucken sehr wohl dem Ausbau von Sicherheit dienen. Dies gilt z. B. dann,wenn durch sie Sicherheitslucken aufgedeckt, bewertet und behoben werden. Au-ßerdem konnen Firmen mit ihrer Hilfe der Offentlichkeit zeigen, dass sie sich umdie Sicherheit ihrer Produkte kummern, indem sie Hacking Challenges veranstal-ten und nach Sicherheitslucken suchen lassen.

Generell bleibt der Gewinn an Sicherheit jedoch nicht quantifizierbar. Er kann nurdurch das Vertrauen in die Experten bewertet werden, die fur die Suche nach Si-cherheitslucken beauftragt werden. Dabei wird den Fahigkeiten, Erfahrungen undVorgehensweisen der Experten vertraut. Die Experten wiederum konnen das Ver-trauen aufbauen und pflegen, indem sie sich aktiv im Bereich der IT-Sicherheitbemuhen, Security Advisories veroffentlichen und vergangene Erfolge bei derAufdeckung von Sicherheitslucken vorweisen.


Der Abschnitt diskutierte die Anwendung einer Cost-to-break-Metrik auf die Su-che nach Sicherheitslucken durch Fuzzing-Techniken. Es sollte bewertet werden,wie sicher oder unsicher das Betriebssystem Windows Mobile 5.0 ist. Kritisiertwurde die Metrik, da nicht klar ist, inwieweit die Ergebnisse einer Suche auf an-dere Suchen ubertragen werden kann. Verschiedene Faktoren wie Experten furdie Suche, Vorgehensweisen und Zeitbedarf legen nahe, dass die Bewertung derSicherheit durch eine solche Suche nicht objektiv genug ist.

73


Weiterhin wurden Hacking Challenges erwahnt, bei denen in Bezug auf Bewer-tung von Sicherheit eine ahnliche Problematik existiert. Zum Schluss wurde dar-auf hingewiesen, dass gezielte Suchen nach Sicherheitslucken genau wie HackingChallenges auch, fur den Ausbau von Sicherheit verwendet werden kann. Die Be-wertung von Sicherheit bleibt jedoch Vertrauenssache.

4.5 Zusammenfassung

Dieses Kapitel zeigte die Ergebnisse auf, die bei der Suche nach Sicherheitsluckenin Windows Mobile 5.0 mit Fuzzing-Techniken gesammelt werden konnten. Eswar in der aufgewendeten Zeit nicht moglich eine Sicherheitslucke aufzudecken.Die Probleme bei der Suche waren zum Teil technischer aber auch prinzipiellerNatur und wurden genannt. Der letzte Abschnitt diskutierte die Anwendbarkeiteiner Sicherheitsmetrik fur die Bestimmung der Cost-to-break durch eine Suchenach Sicherheitslucken. Die Ubertragbarkeit der Ergebnisse bei dieser Metrik wur-de kritisiert. Zum Schluss wurde gefolgert, dass die Bewertung von Sicherheitdurch eine Suche nach Sicherheitslucken nicht sinnvoll ist. Sicherheitslucken sindeine Voraussetzung fur Computerwurmer. Der Aufwand fur die Schaffung die-ser Voraussetzung kann jedoch nicht mit einer Suche nach Sicherheitslucken be-stimmt werden.

74

5 Verbesserung der Sicherheit inWindows Mobile 5.0

5.1 Einleitung

Das letzte Kapitel dieser Arbeit beschaftigt sich jetzt mit diversen Sicherheitspro-blemen in Windows Mobile 5.0, die wahrend dieser Arbeit aufgedeckt wurden.Die Probleme sind teils technischer und teils konzeptioneller Natur und schaffenVoraussetzungen fur die Verbreitung von Computerwurmern. Es werden Maß-nahmen vorgeschlagen, welche diese Voraussetzungen bekampfen. Insbesonderegeht es dabei um Maßnahmen, die der Betriebssystemhersteller, die Gerateherstel-ler, Entwickler und die Benutzer ergreifen konnen, um die Sicherheit bezuglichWindows Mobile 5.0 zu erhohen.

5.2 Sicherheitsmaßnahmen fur Betriebssystem- undGeratehersteller

5.2.1 Einleitung

Dieser Abschnitt behandelt Maßnahmen, die der Betriebssystemhersteller Micro-soft und die Hersteller der mobilen Gerate anwenden konnen. Teilweise konnendie Maßnahmen des Betriebssystemherstellers auch von den Gerateherstellern ge-troffen werden, da diese das Betriebssystem fur ihre Gerate sowieso nachtraglichanpassen mussen.

5.2.2 Unnotige Netzwerkdienste

Wahrend der Arbeit mit Windows Mobile 5.0 wurde festgestellt, dass diverseNetzwerkdienste auf den Testgeraten aktiviert sind. Diese sind uber die UDP-Ports 137, 138, 1034 und 2948 erreichbar. Wenn nun ein Windows Mobile-Gerat

75

5 Verbesserung der Sicherheit in Windows Mobile 5.0

ein WLAN-Netzwerk betritt, stehen diese Dienste im gesamten Netzwerk zurVerfugung.

Die Ports 137 und 138 implementieren Funktionalitaten der NetBIOS-Protokoll-familie. Sie gewahrleisten die Bekanntmachung aller Netzwerkteilnehmer uberdie NetBIOS-Namen. Zudem konnen uber NetBIOS Daten verbindungslos ver-sendet und empfangen werden, wobei die Adressierung der Netzwerkteilneh-mer uber die NetBIOS-Namen geschieht (s. [RFC87a]). NetBIOS-Dienste werdenjedoch nicht in jedem Netzwerk benotigt, so dass eine generelle Aktivierung nichtnotwendig ist.

Der Port 2948, der fur die MMS-Benachrichtigungen uber WAP Push verwendetwird, ist ebenfalls von Werk her aktiviert. Die Verbreitung von MMS-Benachrichti-gungen uber WLAN ist jedoch nur in speziellen Umgebungen moglich. Ublicher-weise werden sie uber SMS-Kurzmitteilungen verschickt und nicht uber UDP-Datagramme. [Mul06c, Mul06b] und das Fuzzing in Abschnitt 4.2.6 zeigen, dasshier sogar Fehler in der Implementation vorhanden sind. Unabhangig davon kon-nen fehlerhafte MMS-Benachrichtigungen sehr einfach fur eine DoS-Attacke miss-braucht werden.

Das selbe gilt fur den Port 1034, bei dem vermutet wird, dass er fur den Versandvon E-Mail-Benachrichtigungen verwendet werden kann. Auch hier ist wieder einspezielles Netzwerk-Setup notwendig, damit der Dienst seinen Zweck erfullenkann. Im Allgemeinen sind Netzwerke jedoch nicht fur diesen Dienst ausgelegt,so dass die Aktivierung vom Werk her auch hier nicht sinnvoll ist.

Es wurde keine Moglichkeit gefunden die Dienste zu deaktivieren, außer durchdie Trennung der WLAN-Verbindung. In Windows Mobile 5.0 existiert auch kei-ne integrierte Firewall mit der die Dienste maskiert werden konnten. ZusatzlicheDienste stellen immer eine großere Angriffsflache und somit auch hohere Risi-ken fur ein System dar. Da die Dienste im Allgemeinen nicht verwendet werdenist es ratsam, diese standardmaßig zu deaktivieren und nur durch den Benutzeraktivieren zu lassen. Diese Modifikation sollte vom Betriebssystemhersteller Mi-crosoft vorgenommen werden.

5.2.3 Trusted Environment

Fur Pocket PCs ist das in Abschnitt 2.2.9 erwahnte Trusted Environment nichtrestriktiv genug. Auf ihnen steht jedem Prozess die Trusted API zur Verfugung,unabhangig davon, ob er diese fur seine eigentliche Aufgabe benotigt oder nicht.Alle Prozesse werden als OEM_CERTIFY_TRUST ausgefuhrt.

Ein Problem entsteht nun, wenn ein Prozess uber eine Sicherheitslucke ausge-

76

5.2 Sicherheitsmaßnahmen fur Betriebssystem- und Geratehersteller

nutzt werden kann. Dies ist z. B. fur das Testprogramm vuln_stack.exe die-ser Arbeit demonstriert worden. Es lasst sich beliebiger Code einschleusen, derdann uber Zugriff auf die komplette Trusted API verfugt. Damit ist es beispiels-weise moglich in den Kernel Mode zu wechseln, Systemdateien zu verandernund Registry-Eintrage zu manipulieren. Außerdem kann das Trusted Environ-ment nun auch nachtraglich noch umgangen werden, um unsignierte Programmeohne Interaktion des Benutzers zu starten. Dies wurde in Abschnitt 3.3.12 fur dasStarten des Computerwurmprogramms in der separaten Datei ausgenutzt. Auchauf Pocket PCs sollten Prozesse deswegen nur als OEM_CERTIFY_RUN ausgefuhrtwerden, sofern sie keine Signatur besitzen, die ihnen die Verwendung der TrustedAPI explizit erlaubt. Dies ist von Microsoft bislang nur fur Smartphones vorge-sehen gewesen und nicht fur Pocket PCs. Die Geratehersteller sind jedoch in derLage dieses Verhalten im Platform Builder zu verandern (vgl. [MS:06] unter ”Co-designing for Windows Mobile-based Smartphones and Pocket PCs“). Microsoftsollte die Restriktion auch in Pocket PCs verwenden. Im Zweifelsfall sollten dieGeratehersteller selbst aktiv werden und die Restriktion fur ihre Gerate erzwin-gen.

Weiterhin konnte die Ausfuhrung unsignierter Anwendung auf den Geraten kom-plett untersagt werden. Dies ist jedoch nicht immer sinnvoll. Ublicherweise moch-ten Benutzer auch Drittanbietersoftware einsetzen, deren Entwickler sich den Si-gnierungsprozess nicht leisten konnen. VeriSign ist neben Geotrust eine der bei-den Firmen, die Entwickler mit Zertifikaten fur das Mobile2Market-Programmausstatten. Fur zehn Signierungen verlangt VeriSign einen Preis von 400 $. Miteiner einzigen Signierung kommen jedoch die wenigsten Anwendungen aus. Siebestehen meist aus mehreren Dateien, die jeweils einzeln signiert werden mussen.Nicht alle Entwickler konnen sich diese Kosten leisten. Vor allem Open Source-Anwendungen sind aus diesem Grund oft vom Mobile2Market-Programm aus-geschlossen. Aus diesem Grund werden die meisten Gerate so ausgeliefert, dassdie Benutzer die Ausfuhrung unsignierter Anwendungen uber eine Benutzerab-frage erlauben konnen. Fur Firmen, bei denen die Mitarbeiter nur Zugriff aufausgewahlte Anwendungen benotigen, ist die vollstandige Untersagung der Aus-fuhrung von unsignierten Anwendungen jedoch sinnvoll und praktikabel. Da dieGerate den Firmen und nicht den Mitarbeitern gehoren, sind derartige Richtlinienauch einfacher durchzusetzen.

Es ist wichtig zu erkennen, dass das Trusted Environment generell nicht vor derKompromittierung eines privilegierten Prozesses schutzen kann. Auch Anwen-dungen, denen im Rahmen des Trusted Environments vertraut wird, konnen Si-cherheitslucken enthalten und Angreifern moglicherweise Zugang zum Systemverschaffen. Der durch den Angreifer eingeschleuste Code ist dann auch privile-giert und kann das Trusted Environment sogar komplett deaktivieren. Dazu mussdie Security Policy fur privilegierte Applikationen (Privileged Apps Policy) in derRegistry des Gerates verandert werden. Der Eintrag lautet:

77


; Privileged Apps Policy[HKEY_LOCAL_MACHINE\Security\Policies\Policies]

"0000101b"=dword:1%

Der Wert 1 ist die Standardkonfiguration fur PocketPCs, auf denen jeder Prozessprivilegiert ausgefuhrt wird. Auf Smartphones ist dieser Wert entweder nicht vor-handen oder es ist ein Wert ungleich 1 angegeben. In den Fallen wird eine unsi-gnierte Anwendung (z. B. das Computerwurmprogramm) immer nur unprivile-giert (OEM_CERTIFY_RUN) ausgefuhrt werden (von [MS:06] unter ”Security Poli-cy Settings“ und ”Default Security Policy Settings for Windows Mobile-Based De-vices“). Wenn der Angreifer diesen Schlussel jedoch manipuliert oder hinzufugt,kann er weitere Prozesse mit der API CreateProcess privilegiert starten. Die-se Prozesse benotigen dann auch keine gultige Signatur. Auf die Art und Weiselasst sich auch die Ausfuhrung des Computerwurmprogramms aus Kapitel 3 un-ter Smartphones bewerkstelligen.

Die Tatsache, dass unprivilegierte Anwendungen das Computerwurmprogrammnicht nachladen konnen, stellt auch keine zusatzliche Sicherheit dar. Die Funk-tionalitat des Computerwurmprogramms kann auch direkt im Shellcode imple-mentiert werden. Fur die Arbeit war es lediglich komfortabler in einer hoher-en Programmiersprache zu entwickeln und das Computerwurmprogramm uberdie Windows-API nachzuladen. Das Trusted Environment dient vor allem demSchutz vor nicht vertrauenswurdigen Anwendungen und solchen Anwendungen,die nachtraglich verandert wurden. Beispiele dafur sind Computerviren oder Tro-janische Pferde, die von unachtsamen Benutzern ausgefuhrt werden konnten.

5.2.4 Trennung von Anwendungsdaten

In Windows Mobile 5.0 existiert kein Konzept fur die Trennung von Anwendungs-daten verschiedener Programme auf dem Dateisystem und in der Registry. JedeAnwendung kann auf alle Dateien und samtliche Registry-Schlussel zugreifen.Lediglich auf Smartphones findet eine Unterscheidung zwischen normalen undprivilegierten Anwendungen statt. Normale Anwendungen konnen dabei nichtauf Systemdateien und wichtige Registry-Schlussel zugreifen. Eine Trennung derDaten von normalen Programmen findet jedoch auch hier nicht statt.

Dies kann zu einem Problem werden, wenn eine Anwendung uber eine Sicher-heitslucke kompromittiert wird. Der zugehorige Prozess wird dann von einemAngreifer kontrolliert, der nun auf Daten anderer Anwendungen zugreifen kann.Dies konnen kritische Informationen wie Passworter, E-Mails, Adressen oder Te-lefonnummern sein. Security Advisories der Firma Airscanner haben in der Ver-

78


gangenheit aufgezeigt, dass Anwendungen fur Windows Mobile-Gerate ihre Pass-worter und andere sensible Informationen im Klartext auf den mobilen Geratenspeichern (vgl. [Fog06, Air05b, Air05c, Air05d]). Diese Daten konnen durch einenkompromittierten Prozess ausgelesen werden.

Um derartigen Ubergriffen zu begegnen, sollten die Daten einer Anwendung voranderen Anwendungen geschutzt werden. Dies kann z. B. uber getrennte Benut-zer fur verschiedene Anwendungen geschehen. Jede Anwendung hatte damit nurdie Rechte des eigenen Benutzers und konnte nur auf die eigenen Daten zugreifen.Windows Mobile 5.0 musste dazu um ein restriktives Benutzersystem erweitertwerden. Eine generelle Verschlusselung von Anwendungsdaten auf Betriebssyste-mebene ware ebenso eine mogliche Losung. Diese Anderungen musste Microsoftals Betriebssystemhersteller vornehmen. Windows Mobile 5.0 stellt die ProtectedStore API bereit, die Anwendungen nutzen konnen, um ihre sensiblen Daten zuverschlusseln. Die Verwendung ist jedoch optional, so dass jedes Anwendungs-programm diese API explizit nutzen muss (s. ”Protected Store API“ auf [MS:06]und Abschnitt 5.3.3).

5.2.5 Zugriff auf andere Prozesse

Unter Windows CE 4.2 ist es moglich, auf die Speicherbereiche eines anderen Pro-zesses zuzugreifen (s. [san05b, Mur03b]). Auch dies ermoglicht einem kompromit-tierten Prozess kritische Daten anderer Prozesse auszulesen. Selbst Daten, die nurverschlusselt auf das Dateisystem geschrieben werden, konnen so im Klartext imArbeitsspeicher der Anwendung gefunden werden.

Fur Windows Mobile 5.0 konnte der Angriff auch bestatigt werden. Hier wirdvorausgesetzt, dass der angreifende Prozess privilegiert ist und die Trusted APIverwenden darf (OEM_CERTIFY_TRUST). Auf Pocket PCs ist dies jedoch gege-ben. Die API SetProcPermissions kann fur den Zugriff den Speicher andererProzesse verwendet werden. Mit dem Funktionsaufruf

SetProcPermissions(0xFFFFFFFF); // Aufruf unter C/C++

wird dem aktuellen Prozess der Zugriff auf den gesamten Speicher des Systemerlaubt (s. [MS:06] unter ”SetProcPermissions“).

SetProcPermissionswird in Prozessen von Geratetreibern verwendet, um zu-satzlich Zugriff auf die Speicherbereiche der aufrufenden Prozesse zu erlangen.Zudem kann mit der Funktion eine einfache Interprozesskommunikation ubereinen gemeinsam verwendeten Speicherbereich (Shared Memory) zwischen ver-schiedenen Prozessen durchgefuhrt werden. Es ist jedoch nicht bekannt, ob an-

79


dere Prozesse außerhalb der Geratetreiber diese API zwingend benotigen. Fallsnicht, ist Microsoft anzuraten, diese API nur fur Geratetreiber zur Verfugung zustellen.

5.2.6 Verschleierung der Syscalls

In Abschnitt 3.3.10 wurde gezeigt, wie mit Hilfe von Syscalls Zugriff auf die ge-samte Windows-API erlangt werden kann. Damit konnen alle Funktionen aus-gefuhrt werden, die auch eine regulare Anwendung benutzen kann. Der Vorteilvon Syscalls gegenuber der direkten Verwendung von Windows-API-Funktionenist, dass sie immer uber die selben Adressen erreicht werden konnen, unabhangigvom Gerat oder der Version des Betriebssystems. Diese Tatsache erleichtert einemAngreifer die Entwicklung von Shellcode, der auf beliebigen Windows Mobile-Geraten funktioniert. Portabler Shellcode ist eine wichtige Voraussetzung fur dieVerbreitung von Computerwurmern.

Ein Ansatz, um einem Computerwurm den Zugriff auf die Windows-API zu er-schweren, ist die Veranderung der Adressen fur die Syscalls. Dabei reicht es schonaus, wenn jedes Gerat einmalig die Adressen der Syscall zufallig festlegt. Zwarkann so immer noch ein Exploit geschrieben werden, wenn die Adressen der Sys-calls fur ein spezielles Gerat bekannt sind, doch ein außenstehender Angreiferoder ein Computerwurm kann diese Adressen nicht direkt bestimmen.

Die vorgeschlagene Verschleierung der Syscalls muss nur auf der Seite des Be-triebssystems implementiert werden. Fur Anwendungsprogramme ist diese Ver-anderung transparent. Dies liegt daran, dass Anwendungsprogramme nie direktauf Syscalls zuruckgreifen, sondern immer die gekapselten Windows-API-Funkti-onen verwenden. Es mussen also lediglich die Windows-API modifiziert werden.Die Bibliotheken der Windows-API werden dynamisch zur Laufzeit und nie sta-tisch in die Anwendungen eingebunden. Sie sind immer schon auf den Geratenvorinstalliert und werden nicht von Anwendungsprogrammen nachtraglich hin-zugefugt. Die Verschleierung kann beispielsweise durch eine einfache Permuta-tion samtlicher Syscall-Adressen umgesetzt werden (s. Abb. 5.1). Die Adressenmussen dann in einer Permutationstabelle nachgeschlagen werden, bevor sie auf-gerufen werden konnen. Jedes Gerat erhalt dabei seine eigene Permutationsta-belle. Wichtig ist, dass die Tabelle nicht durch die Anwendungsprozesse direkterreicht werden kann, da die Permutation ansonsten nutzlos ist.

In [SPP+04] kritisieren die Autoren den Nutzen von PaX ASLR . PaX ist ein Patchfur den Linux-Kernel, der erweiterten Schutz in Bezug auf Speicherzugriffe be-reitstellt (s. [PaXa]). Address Space Layout Randomization (ASLR) ist eine zusatzli-che Technik von PaX, mit der wichtige Adressen eines Prozesses zufallig veran-dert werden (s. [PaXb]). Der Effekt ist der selbe wie bei der vorgestellten Syscall-

80


Abbildung 5.1: Permutation der Syscall-Adressen

Permutation. Beim Ausnutzen einer Sicherheitslucke, wie einem Pufferuberlauf,konnen notwendige Ressourcen mit hoher Wahrscheinlichkeit nicht verwendetwerden, da ihre Lage unbekannt ist. Die Autoren stellen einen Algorithmus vor,der mittels Brute Force alle moglichen Adressen durchprobiert. Sie gehen da-von aus, dass die auszunutzende Anwendung (ein Apache-Webserver mit Oracle-Datenbankmodul) einen absturzenden Server-Thread immer wieder neu startenwird. Damit lasst sich eine obere Grenze fur die Anzahl der Versuche angeben,die der Angriff fur das Eindringen in das System benotigt. Spatestens wenn al-le Adressen ausprobiert worden sind, ist der Exploit gelungen. Fur die Bedro-hung durch einen Computerwurm argumentieren sie, dass seine Verbreitungsge-schwindigkeit durch PaX ASLR lediglich leicht gehemmt wurde.

Die Argumente sind schlussig fur das gewahlte Szenario in dem eine kompromit-tierbare Server-Anwendung mehrere Threads verwendet. Die Versuche zum Aus-nutzen der Sicherheitslucke konnen hier beliebig oft wiederholt werden. Fur Win-dows Mobile 5.0-Gerate ist das Szenario jedoch schlecht ubertragbar, da Exploit-Versuche oft nur zum Absturz der jeweiligen Anwendung fuhren oder sogar daskomplette Gerat bis zu einem Reset unbrauchbar machen. Die Anzahl der mogli-chen Versuche fur einen Angriff ist im einstelligen Bereich zu vermuten. Ein Erfolgist damit sehr unwahrscheinlich.

Weiterhin sind fur einen Angriff auf Windows Mobile-Gerate zumindest zwei Sys-calls (GetModuleHandle und GetProcAddress) notwendig, um die kompletteWindows-API zu verwenden (s. Abschnitt 3.3.10). In dem fur Syscall-Adressen re-servierten Speicherbereich (0xf0000000-0xf0010000) mit einer Große von 64Kilobytes konnen 16.384 Adressen mit je 4 Byte abgelegt werden. Diese Adressenseien nun permutiert. Die Wahrscheinlichkeit, dass die Lage der beiden Syscall-Adressen beim ersten Versuch erraten wird, betragt dann

p =1

16.384· 1

16.383=

1

268.419.072< 4 · 10−9.

81


Dies ist also sehr unwahrscheinlich. Zudem ist fur ein erfolgreiches Ausprobierender Syscall-Adressen per Brute Force die folgende Anzahl von Versuchen notwen-dig:

V = 16.384 · 16.383 = 268.419.072.

Unter der Annahme, dass 1000 Versuche pro Sekunde durchgefuhrt werden kon-nen, wurde der gesamte Angriff im schlimmsten Fall

268.419.072

1000s = 268.419, 072s > 74 Tage

lang dauern. Im Durchschnitt waren das mehr als 37 Tage. Dies ist nicht praktika-bel.

Die Permutation der Syscall-Adressen erschwert die Verwendung der Windows-API. Ein Shellcode, der sich Syscalls zunutze macht, ist somit nicht mehr fur einenComputerwurm geeignet, da er nicht mehr generell fur jedes Gerat funktioniert.

5.2.7 Portstealing

Wahrend der Untersuchung der Testgerate wurde festgestellt, dass reservierteNetzwerkports durch einen anderen Prozess ubernommen werden konnen. DieMethode wurde als Portstealing bezeichnet und war bei der Entdeckung von mo-bilen Windows-Geraten im WLAN-Netzwerk hilfreich (s. Abschnitt 3.4.4).

Das Verhalten bezuglich der Portbindung ist bedenklich, hat aber nur geringeAuswirkungen, da unter Windows Mobile 5.0 die Prozesse generell unzureichendvoreinander geschutzt werden. Trotzdem sollte gewahrleistet werden, dass ge-bundene Ports nicht von anderen Prozessen ubernommen werden konnen. Micro-soft ist deshalb anzuraten, diese Unzulanglichkeit zu beheben. Dies kann gesche-hen, indem die Socket-Option SO_EXCLUSIVEADDRUSE wie in Windows XP im-plementiert wird (s. ”Using SO_REUSEADDR and SO_EXCLUSIVEADDRUSE“ auf[MS:06]). Der Prozess device.exe konnte mit Hilfe dieser Option den NetBIOS-Port 137 an sich binden, ohne dass dieser von anderen Prozessen ubernommenwerden kann.


Dieser Abschnitt beschaftigte sich mit verschiedenen Maßnahmen, die der Be-triebssystemhersteller und die Geratehersteller ergreifen konnen, um die Sicher-heit in Windows Mobile 5.0 zu erhohen. Es wurde empfohlen nicht benutzte Netz-werkdienste zu deaktivieren, das Trusted Environment auch fur Pocket PCs voll-standig zu erzwingen, eine Trennung von Anwendungsdaten zu gewahrleisten,

82

5.3 Sicherheitsmaßnahmen fur Entwickler

Zugriffe auf fremden Prozessspeicher zu verbieten, Syscall-Adressen zu permu-tieren und das unzulangliche Verhalten bzgl. der Ubernahme von Netzwerkportszu verbessern. Als nachste werden Maßnahmen fur Entwickler betrachtet.

5.3 Sicherheitsmaßnahmen fur Entwickler

5.3.1 Einleitung

Auch Entwickler haben die Moglichkeit bei der Erstellung von Software die Si-cherheit in Windows Mobile 5.0 zu verbessern. Diese werden nun vorgestellt.

5.3.2 Security Cookies aktivieren

Bei der Anwendungsentwicklung in Microsofts Entwicklungsumgebungen wieVisual Studio sollte darauf geachtet werden, dass die Compileroption /GS stetsaktiviert ist. Der Stack-Schutz, der dadurch bei der Ubersetzung verwendet wird,macht es Angreifern schwerer, Stack-basierte Pufferuberlaufe auszunutzen. In Ab-schnitt 4.3.2 konnte festgestellt werden, dass unter Windows Mobile 5.0 auf ARM-Architekturen dieser Schutz besonders gut funktioniert, da die bekannten Angrif-fe mit Hilfe des Structured Exception Handlings (aus [Lit03]) dort nicht verwendetwerden konnen.

Die Compileroption /GS ist standardmaßig aktiviert, wenn man in den Entwick-lungsumgebungen von Microsoft ein Projekt startet. Es gibt jedoch Entwickler, dieihre Programme optimieren mochten und die Option aus diesem Grund deakti-vieren. Microsoft gibt an, dass der Leistungsverlust durch die Aktivierung desStack-Schutzes in der Regel nicht mehr als 2% betragt. Insbesondere kommt derVerlust oft gar nicht zustande, da der Stack-Schutz nur an den Stellen in die Pro-gramme eingebaut wird, wo Puffer auf dem Stack verwendet werden (vgl. ”Com-piler Security Checks In Depth“ auf [MS:06]). Die geringen Leistungseinbruchesollten zu Gunsten von zusatzlicher Sicherheit in Kauf genommen und der Stack-Schutz aktiviert werden.

5.3.3 Verwendung der Protected Store API

Daten auf dem Dateisystem und in der Registry konnen, wie schon erwahnt, vonsamtlichen Prozessen ausgelesen werden. Die einzige Beschrankung ist, dass aufSmartphones unprivilegierte Anwendungen keine Systemdateien offnen konnen.

83


Ansonsten existiert hier keine Zugriffsbeschrankung. Entwickler von Anwendun-gen, die mit sensiblen Daten wie Passwortern, E-Mails oder Telefonummern um-gehen mussen, sollten deswegen zusatzliche Maßnahmen ergreifen, um Diebstahlvon Daten durch Entwendung des Gerates oder durch das Ausnutzen einer Si-cherheitslucke zu verhindern.

Windows Mobile 5.0 stellt dafur die Protected Store API zur Verfugung, mit derAnwendungen ihre Daten verschlusseln konnen. Die wesentlichen API-Funktion-en dafur sind CryptProtectData und CryptUnprotectData (s. [MS:06]). Furdie Verschlusselung mit CryptProtectData wird ein so genannter Master Keyverwendet. Dieser wird in der Systemdatei \windows\System.mky hinterlegt,nachdem er mit dem Logon-Passwort des Benutzers verschlusselt wurde. Wirddas Logon-Passwort geandert, so wird auch der Master Key neu verschlusselt(”Master Key Storage“ auf [MS:06]).

Entwickler sollten von der Protected Store API Gebrauch machen und wichtigeDaten mit ihrer Hilfe verschlusseln. Die Zuverlassigkeit des Schutzes hangt je-doch auch von der Sicherheit des gewahlten Benutzerpassworts ab. Wenn vomBenutzer kein Passwort zum Sperren des Gerats angegeben wurde, so ist auchder Master Key nicht durch ein Passwort geschutzt. In diesem Fall kann jeder (aufSmartphones nur ein privilegierter) Prozess auf den Master Key zugreifen und ihnfur die Entschlusselung von Daten verwenden.

5.3.4 Codesignierung von Anwendungen

Im Rahmen der Entwicklung von Anwendungen fur Windows Mobile wird meistauch eine Signierung der verschiedenen Anwendungsdateien vorgenommen. DieSignierung gewahrleistet, dass die mobilen Gerate entscheiden konnen, ob An-wendungen vertrauenswurdig sind oder nicht. Hierbei kann entweder eine Signa-tur fur normale (OEM_CERTIFY_RUN) oder privilegierte (OEM_CERTIFY_TRUST)Anwendungen ausgestellt werden. Dies geschieht uber die Signierung durch ver-schiedene Zertifikate (s. Abschnitt 2.2.9). Entwickler sollten die Signierung fur pri-vilegierte Ausfuhrung nur dann durchfuhren, wenn die Anwendung die erweiter-ten Privilegien fur die Ausfuhrung zwingend benotigt. Auf Geraten, die zwischennormaler und privilegierter Ausfuhrung unterscheiden, ware es fur einen Angrei-fer ansonsten einfacher, eine Sicherheitslucke im System auszunutzen. Durch dieTrusted API stehen ihm dann Funktionen zur Verfugung, mit denen er beispiels-weise Programme nachladen kann (wie in Abschnitt 3.3.12 gezeigt).

Auf Pocket PCs werden alle Anwendungen privilegiert ausgefuhrt. In diesem spe-ziellen Fall ist die beschriebene Maßnahme fur Entwickler unglucklicherweise oh-ne Konsequenz. Fur Smartphones ist die Maßnahme jedoch hilfreich, da Smart-phones eine Unterteilung bezuglich normalen und privilegierten Anwendungen

84

5.4 Sicherheitsmaßnahmen fur Benutzer

vornehmen.


Fur Entwickler wurden drei Maßnahmen fur die Verbesserung der Sicherheit vor-geschlagen. Zum einen die generelle Aktivierung des Stack-Schutzes durch Secu-rity Cookies, zweitens die Verschlusselung von sensiblen Informationen mit derProtected Store API und drittens die Verwendung von Codesignaturen fur Appli-kationen. Als nachstes werden Sicherheitsmaßnahmen beschrieben, die ein Benut-zer von Windows Mobile 5.0 treffen kann.

5.4 Sicherheitsmaßnahmen fur Benutzer

5.4.1 Einleitung

Der Benutzer ist die letzte Instanz, die in Bezug auf Sicherheit Maßnahmen ergrei-fen kann. Mogliche Maßnahmen werden nun diskutiert.

5.4.2 Benutzerpasswort setzen

Benutzer von Windows Mobile 5.0 sollten fur ihr Gerat ein Logon-Passwort ver-wenden. Ohne dieses Passwort konnen wichtige Daten des Gerats sehr leicht aus-gelesen werden.

Daten, die im Klartext vorhanden sind, konnen mit etwas mehr Aufwand selbstohne Kenntnis des Passworts ausgelesen werden. Dies kann z. B. durch einen Aus-bau des internen Speichers des Gerats erfolgen. Ein solcher Ausbau ist aufwandig,aber nicht unmoglich. Kritischer noch ist, dass selbst Daten, die mit der Protec-ted Storage API verschlusselt worden sind, durch eine andere Person wieder ent-schlusselt werden konnen. Dies ist deshalb moglich, weil der Master Key fur dieVerschlusselung praktisch unverschlusselt gespeichert wird. Nach ”Master KeyStorage“ auf [MS:06] wird der Master Key mit dem Algorithmus 3DES und ei-nem von dem Benutzerpasswort abgeleiteten Schlussel verschlusselt. Ohne einBenutzerpasswort fehlt jedoch eine geheime Information in diesem Schlussel. Diesist fur eine vertrauliche Speicherung des Master Keys notwendig. Aus diesemGrund wird nahegelegt, ein Benutzerpasswort zu setzen. Der Master Key wirdunter Berucksichtigung dieses Passwortes verschlusselt und kann nicht mehr vonfremden Personen entschlusselt werden.

85


5.4.3 WLAN und Bluetooth

Auch Benutzer konnen die Angriffsflache der Gerate gering halten. Dies gilt z. B.fur Bluetooth und WLAN, die haufig auf Pocket PCs zum Einsatz kommen. BeideSchnittstellen sollten nur dann aktiviert werden, wenn sie auch wirklich benotigtwerden. Zu jedem anderen Zeitpunkt stellen sie nur einen weiteren Angriffsvek-tor dar, fur den in Zukunft eine Sicherheitslucke entdeckt werden konnte. Weiter-hin wird durch eine Deaktivierung der Akku des Gerates geschont, da wenigerStrom verbraucht wird.

5.4.4 Unnotige Anwendungen

Ein weiterer Punkt ist die Installation unnotiger Anwendungen. Benutzer solltenkeine Software auf den Geraten installiert lassen, die sie nicht oder nicht mehrbenotigen. Insbesondere gilt dies fur netzwerkfahige Software, die unter Umstan-den den Zugang auf das Gerat gewahrleistet.

Ein Beispiel fur eine Bedrohung, die in der Vergangenheit existierte, ist der FTP-Server vxFtpSrv 0.9.7 (s. [vxF]) fur Windows Mobile Pocket PC 2003 (Windows CE4.2). Dort wurde von der Firma Airscanner ein Pufferuberlauf entdeckt, der zumAusfuhren von beliebigem Code benutzt werden kann (s. [Air05a]).

Derartige Anwendungen sollten nur dann ausgefuhrt werden, wenn sie auch ver-wendet werden. Im Falle eines FTP-Servers reicht es, diesen nur fur den Zeitraumdes erwunschten Zugriffs zu aktivieren und anschließend zu deaktivieren. Wirder nicht mehr verwendet, so sollte er komplett deinstalliert werden. Dies verhin-dert, dass der Server vergessen wird und in Zukunft eine Sicherheitslucke auf demGerat darstellt.

Es soll noch erwahnt werden, dass es unter Windows Mobile 5.0 keinen Task-manager gibt, der alle laufenden Prozesse anzeigt. Es existiert lediglich ein Pro-gramm, welches eine ”Liste ausgefuhrter Programme“ (s. Abb. 5.2) anzeigt. Hier-bei werden jedoch nur die Programme angezeigt, deren Prozesse die graphischeOberflache verwenden. Ein normaler Benutzer kann also gar nicht entscheiden,ob ein Programm wirklich beendet worden ist oder ob es nur seine graphischeOberflache deaktiviert hat. An dieser Stelle ist es sinnvoll einen zusatzlichen Task-manager zu installieren.

86

5.5 Zusammenfassung

Abbildung 5.2: Nicht alle Prozesse werden angezeigt


Ein genereller Rat fur Benutzer lautet: Anwendungen und Funktionen deaktivie-ren, die nicht zwingend benotigt werden. Dies gilt fur Netzwerkschnittstellen wieBluetooth und WLAN, aber auch fur unnotige Anwendungen. Diese vergroßernnur die Angriffsflache des Gerates. Zusatzlich sollte ein Benutzerpasswort gesetztwerden, um wichtige Informationen auf dem Gerat zu schutzen.

5.5 Zusammenfassung

Das Kapitel erarbeitete Sicherheitsmaßnahmen, die vom Betriebssystemhersteller,den Gerateherstellern, Entwicklern und Benutzern getroffen werden konnen, umVoraussetzungen fur die Verbreitung von Computerwurmern zu bekampfen. DieSicherheit von Windows Mobile 5.0 kann mit den angegebenen Maßnahmen ver-bessert werden.

87


88

6 Fazit

6.1 Ergebnisse dieser Arbeit

Diese Diplomarbeit erforschte die Voraussetzungen fur die Entwicklung einesComputerwurms, der sich auf mobilen Geraten mit dem Betriebssystem WindowsMobile 5.0 verbreiten kann. In Kapitel 3 wurde dazu ein Baukasten fur einen Com-puterwurm entwickelt. Dieser wurde in die verschiedenen Komponenten Infizie-rung, Verbreitung und Schadensfunktion aufgeteilt. Abschnitt 3.3 zeigte, wie dieverschiedenen Probleme beim Ausnutzen eines Stack-basierten Pufferuberlaufsgelost werden konnen, um die Kontrolle uber ein Windows Mobile 5.0-Gerat zuerlangen. Die hohe Zuverlassigkeit der Infizierung wurde anhand mehrerer Test-gerate bestatigt. Damit setzen sich die Ergebnisse von denen aus [Hur05b] und[san05b] ab.

Es wurde weiterhin eine Verbreitungsfunktion entwickelt, mit der sich ein Com-puterwurm sehr einfach von Gerat zu Gerat verbreiten kann. Dafur wurde in Ab-schnitt 3.4.4 ein Algorithmus implementiert, der anhand des Netzwerkverkehrsin einem WLAN-Netzwerk die zu infizierenden Gerate auswahlt. Auch die Zu-verlassigkeit der Verbreitungsfunktion konnte anhand der verschiedenen Test-gerate demonstriert werden. In Abschnitt 3.5 wurden dann noch mogliche Scha-densfunktionen fur einen Computerwurm erforscht. Dabei wurde herausgefun-den, dass ein Computerwurm unentdeckt hohe Telefonkosten generieren kann.Dies kann z. B. uber einen Anruf oder dem Versenden von SMS-Kurzmitteilungengeschehen. Ein Benutzer kann die Ausfuhrung dieser Schadensfunktionen nichterkennen, da sie im Hintergrund ohne graphisches Ruckmeldung ablaufen.

Kapitel 4 der Arbeit beschaftigte sich mit der Suche nach Sicherheitslucken inWindows Mobile 5.0. Da der Quellcode des Betriebssystems nicht zur Verfugungstand, wurden Fuzzing-Techniken fur die Suche verwendet (vgl. Abschnitt 4.2).Das Ergebnis der Suche ergab, dass keine Sicherheitslucken gefunden werdenkonnten. Bei der Suche wurde zudem festgestellt, dass die verwendeten TestgerateAnwendungen enthalten, die mit dem Stack-Schutz durch Security Cookies ver-sehen wurden. Wie in Abschnitt 4.3.2 herausgefunden werden konnte, lasst sichder Schutz nicht mit den bekannten Angriffen aus [Lit03] umgehen. Die Angriffenutzen Voraussetzungen der x86-Architektur aus. Diese sind unter Windows 2003

89

6 Fazit

Server gegeben, jedoch nicht auf mobilen Geraten der ARM-Architektur.

Eine ausnutzbare Sicherheitslucke ist eine Voraussetzung fur die Verbreitung ei-nes Computerwurms. Deswegen wurde in Abschnitt 4.4 untersucht, ob mit denErgebnissen einer Suche nach Sicherheitslucken eine Aussage uber den Erfolg an-derer, moglicherweise krimineller, Personen gemacht werden kann. Dazu wurdedie Suche als Metrik fur die Sicherheit von Windows Mobile 5.0 betrachtet, mitder die Cost-to-break fur das Betriebssystem bestimmt werden konnen. Die Un-tersuchung ergab, dass eine Suche nach Sicherheitslucken nicht als Metrik zu ge-brauchen ist. Die Ergebnisse einer derartigen Suche sind nicht ausreichend ubert-ragbar. Es wurde argumentiert, dass andere Experten mit anderen Voraussetzun-gen und Vorgehensweisen durchaus andere Ergebnisse erzielen konnen. Die Si-cherheit des Betriebssystems kann daher nicht auf diese Weise bestimmt werden.Die Aussagen konnten auch auf Hacking Challenges ubertragen werden. HackingChallenges und Suchen nach Sicherheitslucken konnen fur die Verbesserung vonSicherheit beitragen, wenn Sicherheitslucken aufgedeckt und behoben werden. Ei-ne Bewertung der Sicherheit beruht jedoch immer auf dem Vertrauen gegenuberden suchenden Experten.

In Kapitel 5 wurden diverse Unzulanglichkeiten in Windows Mobile 5.0 aufge-zeigt, die Entwicklung von Computerwurmern begunstigen konnen. Die man-gelnde Trennung von Anwendungsdaten beispielsweise oder die Moglichkeit aufden Speicher anderer Prozesse zuzugreifen sind konzeptionelle Probleme in Win-dows Mobile 5.0. Aus diesem Grund wurden Maßnahmen aufgezeigt, die der-artige Voraussetzungen fur einen Computerwurm beseitigen. Zudem wurde ei-ne Verschleierung der Syscall-Adressen vorgeschlagen, die verhindern soll, dassComputerwurmer Zugriff auf die Windows-API erhalten. Die Verbreitung vonComputerwurmern wurde damit eingeschrankt werden. Die aufgezeigten Maß-nahmen wurden aufgeteilt fur den Betriebssystemhersteller, die Geratehersteller,die Entwickler und die Benutzer.

6.2 Ausblick

Bei der Entwicklung des Computerwurmbaukastens in Kapitel 3 wurde die Infi-zierung speziell fur einen Stack-basierten Pufferuberlauf implementiert. Wie imweiteren Verlauf der Arbeit herausgefunden wurde, ist der Stack bei WindowsMobile 5.0 in der Regel jedoch ausreichend vor Stack-basierten Pufferuberlau-fen geschutzt (vgl. Abschnitt 4.3.2). Es existieren allerdings noch andere typischeProgrammierfehler, die moglicherweise fur die Injektion von beliebigem Codemissbraucht werden konnten, z. B. die Heap-basierten Pufferuberlaufe. Ein Heapist ein Speicherbereich, aus dem Anwendungen zusatzlichen Speicher anfordernkonnen. Fur die Reservierung und Freigabe von Speicherblocken wird ein Heap-

90

6.2 Ausblick

Management benotigt. Die Implementation der Heap-Managements variiert vonBetriebssystem zu Betriebssystem. Beim Ausnutzen von Heap-basierten Puffer-uberlaufen unter Linux muss deswegen z. B. anders vorgegangen werden als un-ter Windows XP. Bislang gibt es noch keine Untersuchungen daruber, ob Heap-basierte Pufferuberlaufe unter Windows Mobile 5.0 ausgenutzt werden konnenoder nicht. Dies ware jedoch ein interessantes Forschungsgebiet.

Ende des Jahres 2006 hat Microsoft Windows Embedded CE 6.0 auf Basis des neu-en Windows CE 6.0-Kernels angekundigt. Windows Embedded CE 6.0 enthalt imGegensatz zu Windows Mobile 5.0 eine veranderte Prozess- und Speicherarchitek-tur (vgl. [Yao06]), so dass die Ergebnisse dieser Arbeit nicht auf das neue Betriebs-system ubertragbar sein werden. Bislang werden noch keine Gerate ausgeliefert,die mit Windows Embedded CE 6.0 ausgestattet sind. In Zukunft konnen jedochauch dort Untersuchungen in Bezug auf Sicherheit und Malware vorgenommenwerden. Bis dahin wird es vermutlich noch einige Zeit dauern, da altere Geratemit Windows Mobile 5.0 auch in Zukunft noch weiter eingesetzt werden.

91

6 Fazit

92

A Werkzeuge

Dies ist eine Liste der Werkzeuge, die fur die Entwicklung samtlicher Bauteile desWurmbaukastens verwendet wurden. Einige von ihnen sind fur die Ubersetzungdes Quellcodes notwendig.

• GNU C-Compiler GCC 4.1.0Fur die Entwicklung des Wurmprogramms und anderer Tools. Muss fur dasZielsystem arm-wince-pe und x86 ubersetzt werden.

• GNU BinutilsEnthalten den GNU ARM Assembler und andere Tools fur die Ubersetzungdes Shellcodes. Muss fur das Zielsystem arm-wince-pe ubersetzt werden.Verwendete Version: 2.17.50 20060823 aus dem CVS.http://sources.redhat.com/binutils/

• Microsoft Visual Studio 2005Entwicklungsumgebung fur diverse ProgrammiersprachenVerwendete Version: 8.0.50727.42

• Microsoft Windows Mobile 5.0 SDKFur die Entwicklung von Windows Mobile-Applikationen in Visual Studio2005 notwendig.http://msdn.microsoft.com/windowsmobile/

• ActiveSync 4.2Stellt Verbindungen zwischen Desktop-Rechner und Windows Mobile-Gerather.http://www.microsoft.com/windowsmobile/activesync/activesync42.

mspx

• IDA Pro 5.0.0.879Disassembler und Debuggerhttp://www.datarescue.com

• SPIKE Fuzzer Creation Kit 2.9Fuzzing-Frameworkhttp://www.immunitysec.com/downloads/SPIKE2.9.tgz

93

http://sources.redhat.com/binutils/

http://msdn.microsoft.com/windowsmobile/

http://www.microsoft.com/windowsmobile/activesync/activesync42.mspx

http://www.microsoft.com/windowsmobile/activesync/activesync42.mspx

http://www.datarescue.com

http://www.immunitysec.com/downloads/SPIKE2.9.tgz

A Werkzeuge

• nmap 4.11Portscannerhttp://www.insecure.org/nmap/

• GNU Debugger 6.4Ubersetzt fur das Zielsystem arm-wince-pe.http://sourceware.org/gdb/

• SynCEActiveSync-Ersatz fur Linux (in Entwicklung)http://synce.sourceforge.net

• WireSharkWerkzeug fur Netzwerkprotokollanalysehttp://www.wireshark.org

94

http://www.insecure.org/nmap/

http://sourceware.org/gdb/

http://synce.sourceforge.net

http://www.wireshark.org

C Fuzzing

Hier konnen die Anhange gefunden werden, die fur das Fuzzing in 4 benotigtwerden. Dies sind die Portscan-Ergebnisse und SPK-Dateien fur den Einsatz inSPIKE.

C.1 Portscans

Dies sind die Ergebnisse der Portscans aus 4.2.3.

C.1.1 TCP Syn Scan

$ nmap -sS 192.168.254.140 -p 0-65535

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ )at 2006-10-01 12:42 CETInteresting ports on 192.168.254.140:Not shown: 65532 closed portsPORT STATE SERVICE14728/tcp filtered unknown20233/tcp filtered unknown34087/tcp filtered unknown55343/tcp filtered unknownMAC Address: 00:09:2D:98:32:AF (High Tech Computer)

Nmap finished: 1 IP address (1 host up) scanned in 146.542seconds

C.1.2 UDP Scan

$ nmap -sU 192.168.254.140 -p 0-65535

97

C Fuzzing

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ )at 2006-10-01 12:48 CETInteresting ports on 192.168.254.140:Not shown: 65532 closed portsPORT STATE SERVICE137/udp open|filtered netbios-ns138/udp open|filtered netbios-dgm1034/udp open|filtered activesync-notify2948/udp open|filtered wap-pushMAC Address: 00:09:2D:98:32:AF (High Tech Computer)

Nmap finished: 1 IP address (1 host up) scanned in 252.710seconds

C.2 SPK-Dateien

Hier sind die SPK-Dateien aufgelistet, die im Abschnitt 4.2 fur das Fuzzing ver-wendet werden.

C.2.1 NetBIOS Name Registration Request

// NetBios Name Service Registration Datagram

s_int_variable(0x0001, 4); // Transaction IDs_int_variable(0x1029, 4); // Flagss_int_variable(0x0100, 4); // Questionss_int_variable(0x00, 4); // Answer RRss_int_variable(0x00, 4); // Authority RRss_int_variable(0x0100, 4); // Additional RRs// Querys_string_variable(" ENEEEBFPFGEBFCEJEPCACACACACACAAA");

// Names_int_variable(0x00, 3); // Zeros_int_variable(0x2000, 4); // Types_int_variable(0x0100, 4); // Class// Additional recordss_int_variable(0x0cc0, 4); // Names_int_variable(0x2000, 4); // Types_int_variable(0x0100, 4); // Class

98

C.2 SPK-Dateien

s_int_variable(0xe0930400, 9); // TTLs_int_variable(0x0600, 4); // Data lengths_int_variable(0x0060, 4); // Flagss_bigword(0xc0a8fe8c); // Addr

C.2.2 MMS-Benachrichtigung

// MMS Notification

// Wireless Session Protocol (WSP)s_binary("00"); // Transaction IDs_binary("06"); // PDU Type: Pushs_binary("22"); // Header Length// Content Types_string_variable("application/vnd.wap.mms-message");s_binary("00"); // -

// Headerss_binary("af 84"); // X-Wap-Application-Id:x-wap-application:mms.ua

// MMS Message Encapsulation// X-Mms-Message-Type: m-notification-inds_binary("8c 82");s_binary("98"); // X-Mms-Transaction-ID:0000000001s_string_variable("0000000001"); // -s_binary("00"); // -s_binary("8d 90"); // X-Mms-MMS-Version: 1.0s_binary("89 12 80"); // From: [email protected]_string_variable("[email protected]");s_binary("00"); // -s_binary("96"); // Subject: Dies ist ein Tests_string_variable("Dies ist ein Test");s_binary("00"); // -s_binary("8a 82"); // X-Mms-Message-Class:Informationals_binary("8e 01 78"); // X-Mms-Message-Size: 120s_binary("88 06 80 04 7a a7 7d 64");

// X-Mms-Expiry: 03/18/2035s_binary("83"); // X-Mms-Content-Locations_string_variable("http://192.168.254.101/test2");

99

C Fuzzing

s_binary("00");

C.2.3 DHCP ACK-Nachricht

// DHCP ACK-Nachricht

s_binary("02 01 06 00");s_binary("1b da cb f8"); // Transaction IDs_int_variable("00000000", 9);s_int_variable("00000000", 9);s_binary("c0 a8 fe 8c"); // bestatigte IP-Adresses_int_variable("00000000", 9);s_int_variable("00000000", 9);s_binary("00 09 2d 98 32 af");s_binary_repeat("00", 10);s_binary_repeat("00",64);s_binary_repeat("00",128);s_binary("63 82 53 63"); // Magic Cookies_binary("35 01 05"); // Message Type=DHCP ACKs_binary("36 04 c0 a8 00 01"); // Server IP

// weitere Optionens_binary("33 04 00 00 17 70");s_binary("01 04 ff ff ff 00");s_binary("1c 04 c0 a8 fe ff");s_binary("03 04 c0 a8 fe 65");s_binary("0f 0b");s_string_variable("example.com"); // Domains_binary("06 04");s_binary("c0 a8 fe 65");s_binary("ff");s_binary_repeat("00", 8);

C.3 Logbuch

Dies ist das Logbuch, welches wahrend der Suche nach Sicherheitslucken gefuhrtwurde.

1.10.06:

100

C.3 Logbuch

2h Portscans durchgefuhrt:TCP Syn Scan:$ nmap -sS 192.168.254.140 -p 0-65535

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ )at 2006-10-01 12:42 CETInteresting ports on 192.168.254.140:Not shown: 65532 closed portsPORT STATE SERVICE14728/tcp filtered unknown20233/tcp filtered unknown34087/tcp filtered unknown55343/tcp filtered unknownMAC Address: 00:09:2D:98:32:AF (High Tech Computer)

Nmap finished: 1 IP address (1 host up) scanned in146.542 seconds

UDP:$ nmap -sU 192.168.254.140 -p 0-65535

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ )at 2006-10-01 12:48 CETInteresting ports on 192.168.254.140:Not shown: 65532 closed portsPORT STATE SERVICE137/udp open|filtered netbios-ns138/udp open|filtered netbios-dgm1034/udp open|filtered activesync-notify2948/udp open|filtered wap-pushMAC Address: 00:09:2D:98:32:AF (High Tech Computer)

Nmap finished: 1 IP address (1 host up) scanned in252.710 seconds

Portscans lieferten 4 offene UDP-Ports (137,138,1034und 2948).

Netbios Name Service Protocol angeschaut.NBNS Registration Request, den ein Testgeratversendet, mitgeschnitten.

SPIKE-Datei aus Mitschnitt erstellt und samtlicheFelder (s. SPK-Datei) gefuzzt.

101

C Fuzzing

$ generic_send_udp 192.168.254.140 137 nbnrr.spk0 0 0

System blieb jedoch stabil.

02.10.06:4h WAP-Push Protocol und MMS Notifications angeschaut

(WAP-Spezifikation, Vortrag von Mulliner, Mullinersnotiflood).

3h Spike-Datei erstellt und gefuzzt (Zeichenketten,sowie Langenangaben (size-Felder)).


System blieb stabil, viele Notifications wurdennicht angenommen (tauchten nicht im Messenger auf),manchmal kam auch die Popup-Box"Medienbenachrichtung konnte nicht dekodiert werden"

16.10.06:2h MMS Notifications gebaut und gefuzzt. Die neue

SPIKE-Datei beschrankt sich auf das Fuzzen vonStrings.

$ generic_send_udp 192.168.2.1 2948 mms.spk 0 0 0

Nachricht wird im Posteingang angezeigt. Bei langemSubjekt hangt tmail.exe. tmail.exe lasst sich nichtrunterladen und offline debuggen.

17.10.06:4h MMS-Transaction-ID Uberlauf. Crash nach vielen

Nachrichten. Gilt im Prinzip fur alle Strings.Vielleicht generell bei langen Nachrichten. Problem:Ich kann nicht debuggen.

18.10.06:2h UDP-Port 1034 ist fur Activesynce Up-To-Date-

Notifications gedacht. Exchange kannEmail-Benachrichtigungen verschicken. Leider weissich noch nicht welche Protokolle da verwendet werdenmussen. WDP (oder sowas) ist auf jeden Fall an

102

C.3 Logbuch

oberster Stelle.

22.10.06:4h+4h Exchange Server unter Windows Server 2003 aufsetzen

um UpToDate-Notifications zu erforschen. Ich mochteeine Notification mitschneiden, wenn diese vomServer an das mobile Gerat gesendet wird. Ich findejedoch keine Moglichkeit dies uber das IP-Netzwerkzu realisieren. Ublicherweise lauft dies uber SMS.

20.11.06:5h Port 2948: tmail.exe hangt nicht, sondert schmiert

ab. Mit IDA Pro kann ich den Prozess nun debuggen,allerdings nur auf dem MDA Pro.

Content-Type wird gefuzzt:


Target is <Gerate-IP>Total Number of Strings is 681fd=3Fuzzing Variable 0:1Variablesize= 5004

Reached maximum packets to send (1).

System blieb stabil.

Fur die anderen Variablen gab es ab und zuExceptions:Fehler 1:Variable X-Mms-Transaction-ID wird gefuzzt:


IDA Pro: The instruction at 0xD67EFC referencedmemory at 0x2409435A. The memory could not be read(0x00D67EFC -> 2409435A)

00D67ECC loc_D67ECC00D67ECC LDR R3, [R1]00D67ED0 LDRB R3, [R3,R4]00D67ED4 CMP R3, #0x20

103

C Fuzzing

00D67ED8 BCC loc_D67F0800D67EDC CMP R3, #0x7E00D67EE0 BHI loc_D67F0800D67EE4 STRB R3, [LR,R5]00D67EE8 LDR R3, [R1]00D67EEC ADD LR, LR, #100D67EF0 ADD R3, R3, #100D67EF4 STR R3, [R1]00D67EF8 LDR R4, [R0,#4]

PC -> 00D67EFC LDRB R3, [R3,R4]00D67F00 CMP R3, #000D67F04 BNE loc_D67ECC

PC kann nicht uberschrieben werden.

Fehler 2:From-Feld wird gefuzzt:


IDA Pro : The instruction at 0xD87F3C referencedmemory at 0x1E00435A. The memory could not be read(0x00D87F3C -> 1E00435A)

00D87F38 DCB 100D87F39 DCB 000D87F3A DCB 0xA0 ; a00D87F3B DCB 0xE3 ; O

PC -> 00D87F3C LDRB R3, [R3,R2]00D87F40 CMP R3, #000D87F44 ADDEQ R3, R2, #100D87F48 STREQ R3, [R1]00D87F4C LDMFD SP!, {R4,R5,PC}


Fehler 3:Subject wird gefuzzt:


IDA Pro : A datatype misalignment error wasdetected in a load or store instruction (0x03F8131C)

104

C.3 Logbuch

coredll.dll:03F8131C loc_3F8131PC -> coredll.dll:03F8131C LDR R3, [LR,R3]!

coredll.dll:03F81320coredll.dll:03F81320 loc_3F81320coredll.dll:03F81320 CMP R3, #0coredll.dll:03F81324 BGT loc_3F8131Ccoredll.dll:03F81328 MOV R1, LRcoredll.dll:03F8132C MOV R0, R5coredll.dll:03F81330 MOV R4, LRcoredll.dll:03F81334 BL unk_3F81038


21.11.06:3h Weiter Exchange Server aufsetzen fur

Up-to-Date-Notifications. Erweist sich schwierigerals gedacht. Ich finde keine hilfreicheDokumentation.

29.10.06:3h Neue Erkenntnis: Security Cookies wurden fur die

Ubersetzung von Windows Mobile verwendet!Beispiel mit IDA Pro im MMS Composer tmail.exe zufinden:

tmail.exe:00014658 LDR R3, =0x4D714tmail.exe:0001465C LDR R3, [R3]tmail.exe:00014660 STR R3, [SP,#0x2A8][...]tmail.exe:00014678 LDR R0, [SP,#0x2A8]tmail.exe:0001467C BL loc_418A4

Dies sind eindeutig Prolog und Epilog desStack-Schutzes.

30.10.06:4h WM5-Gerate verwenden DHCP -> Fuzzing der

DHCP-ClientsDHCP RFC 2131 angelesen,DHCP-Kommunikation uber Port 68 mitgeschnitten,SPK-Datei aus dem Mittschnitt erstellt und Wertefestgelegt

01.11.06:

105

C Fuzzing

2h SPK-Datei weiter angepasst, RFC 2131 gelesesen,Fuzzinglauf:

$ generic_send_udp <Gerate-IP> 68 dhcp.spk 0 0 0

Ergebnis: Hohe Belastung wahrend des Laufs, keineAbsturze

25.11.06:2h Security Cookie-Implementation auf ARM angeschaut:

SEH aug RISC-Architekuren ist anders implementiert(s. MSDN). Security Cookies konnen aufRISC-Architekturennicht wie bei Litchfield ausgenutzt werden. Erstmalkein Ansatz mehr um den Schutz zu umgehen.

106

Literaturverzeichnis

[Air05a] Airscanner Mobile Security Advisory 05081102: vxFtpSrv 0.9.7 Remote Co-de Execution Buffer Overflow Vulnerability. August 2005. – URL: http://www.airscanner.com/security/05081102 vxftpsrv.htm

[Air05b] Airscanner Mobile Security Advisory 05081201: PDAapps Verichat v1.30bhLocal Password Disclosure. Januar 2005. – URL: http://airscanner.com/security/05081201 verichat.htm

[Air05c] Airscanner Mobile Security Advisory 05081701: IM+ v3.10 Local PasswordPlaintext Exposure. Januar 2005. – URL: http://airscanner.com/security/05081701 implus.htm

[Air05d] Airscanner Mobile Security Advisory 05082201: File Transfer Anywherev3.01 Local Server Password Disclosure. Januar 2005. – URL: http://airscanner.com/security/05082201 fta.htm

[Ait02] AITEL, Dave: The Advantages of Block-Based Protocol Analysis for SecurityTesting. Februar 2002. – URL: http://www.immunitysec.com/downloads/advantages of block based analysis.pdf

[Ait06] AITEL, Dave: “The organization I belong to doesn’t have initals”(that evil dude in Heroes). In: Dailydave Mailinglist (2006), No-vember. – URL: http://lists.immunitysec.com/pipermail/dailydave/2006-November/003739.html

[Arc06] ArcSoft.com : Mobile Solutions : MMS (multimedia messaging). No-vember 2006. – URL: http://www.arcsoft.com/products/mobiledevicesolution/multimediamessaging.asp

[Ass06] ASSELINEAU, Roderick: Bewertung der Sicherheit von mobilen End-geraten unter Windows CE. In: MISC 2 (2006), Januar

[Ayc06] AYCOCK, John: Computer Viruses and Malware. Bd. 22. Springer, 2006.– ISBN 978–0–387–30236–2

[BDR+96] BLAZE, Matt ; DIFFIE, Whitfield ; RIVEST, Ronald L. ; SCHNEIER, Bruce; SHIMOMURA, Tsutomu ; THOMPSON, Eric ; WIENER, Michael: Mi-nimal Key Lengths for Symmetric Ciphers to Provide Adequate Commerci-

107

http://www.airscanner.com/security/05081102_vxftpsrv.htm

http://www.airscanner.com/security/05081102_vxftpsrv.htm

http://airscanner.com/security/05081201_verichat.htm

http://airscanner.com/security/05081201_verichat.htm

http://airscanner.com/security/05081701_implus.htm

http://airscanner.com/security/05081701_implus.htm

http://airscanner.com/security/05082201_fta.htm

http://airscanner.com/security/05082201_fta.htm

http://www.immunitysec.com/downloads/advantages_of_block_based_analysis.pdf

http://www.immunitysec.com/downloads/advantages_of_block_based_analysis.pdf

http://lists.immunitysec.com/pipermail/dailydave/2006-November/003739.html

http://lists.immunitysec.com/pipermail/dailydave/2006-November/003739.html

http://www.arcsoft.com/products/mobiledevicesolution/multimediamessaging .asp

http://www.arcsoft.com/products/mobiledevicesolution/multimediamessaging .asp


al Security. Januar 1996. – URL: http://theory.lcs.mit.edu/∼rivest/bsa-final-report.ps

[Bee06] BEER, Stan: Mobile phone botnets are poised to co-me calling. In: The Sydney Morning Herald (2006).– URL: http://www.smh.com.au/news/security/mobile-phone-botnets-are-poised-to-strike/2006/06/12/1149964442180.html

[Bra04] BRAY, Brandon: Compiler-Sicherheitsprufungen im De-tail. November 2004. – URL: http://www.microsoft.com/germany/msdn/library/security/CompilerSicherheitspruefungenImDetail.mspx?mfr=true

[Bre04] BRENNER, Bill: New Trojan targets PDAs. SearchSecurity.com, Au-gust 2004. – URL: http://searchsecurity.techtarget.com/originalContent/0,289142,sid14 gci998724,00.html

[Can06] EMEA Q3 2006 – highlights from the Canalys research. Oktober 2006. –URL: http://www.canalys.com/pr/2006/r2006102.htm

[CEG] CeGCC’s web page. – URL: http://cegcc.berlios.de/

[Chi04] CHIEN, Eric: Symantec Security Response: Backdoor.Brador.A. August2004. – URL: http://www.symantec.com/security response/writeup.jsp?docid=2004-080516-3455-99

[CP05] CYRUS PEIKARI, M.D.: PDA attacks, part 2: airborne viruses evolutionof the latest threats. In: (IN)SECURE Issue 1.4 (2005), October. – URL:http://www.insecuremagazine.com/INSECURE-Mag-4.pdf

[Del01] DELIO, Michelle: Hackers Win Security Challenge. In: Wi-red News (2001), April. – URL: http://www.wired.com/news/technology/0,43234-0.html

[DeM06] DEMOTT, Jared: The Evolving Art of Fuzzing. Juni 2006.– URL: http://www.appliedsec.com/files/The EvolvingArt of Fuzzing.doc

[dia06] Premium SMS - Bezahlung per Handy und SMS. November 2006. – URL:http://www.dialerschutz.de/premium-sms.php

[Dro97] DROMS, Ralph: Dynamic Host Configuration Protocol, RFC 2131. In:Request for Comments, Network Working Group, Marz 1997. – URL:http://www.faqs.org/rfcs/rfc2131.html

[Ear06] EARNSHAW, Richard: Procedure Call Standard for the ARM Architecture.Mai 2006. – URL: http://www.arm.com/miscPDFs/8031.pdf

108

http://theory.lcs.mit.edu/~rivest/bsa-final-report.ps

http://theory.lcs.mit.edu/~rivest/bsa-final-report.ps

http://www.smh.com.au/news/security/mobile-phone-botnets-are-poised-to-strike/2006/06/12/1149964442180.html



http://www.microsoft.com/germany/msdn/library/security/CompilerSicherheitspruefungenImDetail.mspx?mfr=true



http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci998724,00.html

http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci998724,00.html

http://www.canalys.com/pr/2006/r2006102.htm

http://cegcc.berlios.de/

http://www.symantec.com/security_response/writeup.jsp?docid=2004-080516-3455-99


http://www.insecuremagazine.com/INSECURE-Mag-4.pdf

http://www.wired.com/news/technology/0,43234-0.html

http://www.wired.com/news/technology/0,43234-0.html

http://www.appliedsec.com/files/The_Evolving_Art_of_Fuzzing.doc

http://www.appliedsec.com/files/The_Evolving_Art_of_Fuzzing.doc

http://www.dialerschutz.de/premium-sms.php

http://www.faqs.org/rfcs/rfc2131.html

http://www.arm.com/miscPDFs/8031.pdf


[Fog03] FOGIE, Seth: Reverse Engineering Mobile Binaries. DefConn 11, Las Ve-gas, USA, August 2003. – Folien auf http://www.airscanner.com/pubs/fogieDC11.pdf

[Fog04] FOGIE, Seth: PocketPC Abuse. Blackhat USA 2004, Las Vegas, USA, Juli2004. – Folien auf http://www.blackhat.com/presentations/bh-usa-04/bh-us-04-fogie/bh-us-04-fogie-up.pdf

[Fog05] FOGIE, Seth: PDA attacks: palm sized devices - PC sized threats.In: (IN)SECURE Issue 1.3 (2005), August. – URL: http://www.insecuremagazine.com/INSECURE-Mag-3.pdf

[Fog06] FOGIE, Seth: Airscanner vulnerability summary: Windows Mo-bile security software fails the test. In: (IN)SECURE Issue 1.8(2006), September. – URL: http://www.insecuremagazine.com/INSECURE-Mag-8.pdf

[GNU] GNU.org Homepage. – URL: http://www.gnu.org

[Hei05] Microsoft legt mit “Feature Pack” fur Windows Mobile 5.0 nach. Heise, Ju-ni 2005. – URL: http://www.heise.de/newsticker/meldung/60313

[Hel06] HELL, Matthias: Kraftige Zuwachse bei Smartphonesund PDAs. In: InformationWeek (2006), Oktober. – URL:http://www.informationweek.de/showArticle.jhtml?articleID=193200553

[Hen06] HENGEVELD, Willem J.: Windows CE 4.2 System Calls. August2006. – URL: http://www.xs4all.nl/∼itsme/projects/xda/wince-systemcalls.html

[Hil06] HILL, Jurgen: Verdrangt Windows den Blackberry? TecChannel, Au-gust 2006. – URL: http://www.tecchannel.de/news/themen/client/579744/index3.html

[HN05] HYPPONEN, Mikko ; NIEMELA, Jarno: F-Secure Virus Descriptions :Commwarrior.A. Marz 2005. – URL: http://www.f-secure.com/v-descs/commwarrior.shtml

[HPC06] The History of Windows CE - HPC Factor. Januar 2006. – URL: http://www.hpcfactor.com/support/windowsce/

[Hur05a] HURMAN, Tim: ARMed Combat: The Fight For Personal Security. EU-SecWest 2005, London, GB, 2005. – Folien auf http://eusecwest.com/esw06/esw06-hurman.pdf

109

http://www.airscanner.com/pubs/fogieDC11.pdf

http://www.airscanner.com/pubs/fogieDC11.pdf

http://www.blackhat.com/presentations/bh-usa-04/bh-us-04-fogie/bh-us-04-fogie-up.pdf

http://www.blackhat.com/presentations/bh-usa-04/bh-us-04-fogie/bh-us-04-fogie-up.pdf





http://www.gnu.org

http://www.heise.de/newsticker/meldung/60313

http://www.heise.de/newsticker/meldung/60313

http://www.informationweek.de/showArticle.jhtml?articleID=193200553

http://www.informationweek.de/showArticle.jhtml?articleID=193200553

http://www.xs4all.nl/~itsme/projects/xda/wince-systemcalls.html

http://www.xs4all.nl/~itsme/projects/xda/wince-systemcalls.html

http://www.tecchannel.de/news/themen/client/579744/index3.html

http://www.tecchannel.de/news/themen/client/579744/index3.html

http://www.f-secure.com/v-descs/commwarrior.shtml

http://www.f-secure.com/v-descs/commwarrior.shtml

http://www.hpcfactor.com/support/windowsce/

http://www.hpcfactor.com/support/windowsce/

http://eusecwest.com/esw06/esw06-hurman.pdf

http://eusecwest.com/esw06/esw06-hurman.pdf


[Hur05b] HURMAN, Tim: Exploring Windows CE Shellcode. Juni 2005. – URL:http://www.pentest.co.uk/documents/exploringwce/exploring wce shellcode.html

[HWF05] ActiveSync Protocol Documentation. Computer Hardware Fo-rum, November 2005. – URL: http://hardware.mcse.ms/message257702.html

[IAN06] Internet Assigned Numbers Authority (IANA) - Port numbers. No-vember 2006. – URL: http://www.iana.org/assignments/port-numbers

[Int04] Intel XScale R© Core Developer’s Manual. Januar 2004. – URL: http://www.intel.com/design/intelxscale/273473.htm

[Int06] Intel R© PXA27x Processor Family Developer’s Manual. Janu-ar 2006. – URL: http://www.intel.com/design/pca/applicationsprocessors/manuals/280000.htm

[Jur06] JURANIC, Lenon: Using fuzzing to detect security vulnerabili-ties. April 2006. – URL: http://www.infigo.hr/files/INFIGO-TD-2006-04-01-Fuzzing-eng.pdf

[Koz04] KOZIOL, Jack: The Shellcoder’s Handbook. First edition. Wiley Publis-hing, 2004. – ISBN 3893194622

[Koz05] KOZIOL, Jack: Ethical Hacking and Penetration Testing:Fuzzers - The ultimate list. Dezember 2005. – URL:http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html

[Lem06] LEMOS, Robert: Antivirus groups fight over Crossover sharing. Securi-tyFocus, Marz 2006. – URL: http://www.securityfocus.com/news/11379

[Lit03] LITCHFIELD, David: Defeating the Stack Based Buffer Overflow Pre-vention Mechanism of Microsoft Windows 2003 Server. Septem-ber 2003. – URL: http://www.ngssoftware.com/papers/defeating-w2k3-stack-protection.pdf

[Loh06] LOH, Sue: Inside Windows CE API Calls. Published onWindows CE Base Team Blog, Februar 2006. – URL:http://blogs.msdn.com/ce base/archive/2006/02/02/Inside Windows CE API Calls.aspx

[Met] Metasploit Linux Shellcode. – URL: http://www.metasploit.com/shellcode linux.html

110

http://www.pentest.co.uk/documents/exploringwce/exploring_wce_shellcode.html

http://www.pentest.co.uk/documents/exploringwce/exploring_wce_shellcode.html

http://hardware.mcse.ms/message257702.html

http://hardware.mcse.ms/message257702.html

http://www.iana.org/assignments/port-numbers

http://www.iana.org/assignments/port-numbers

http://www.intel.com/design/intelxscale/273473.htm

http://www.intel.com/design/intelxscale/273473.htm

http://www.intel.com/design/pca/applicationsprocessors/manuals/280000.htm

http://www.intel.com/design/pca/applicationsprocessors/manuals/280000.htm

http://www.infigo.hr/files/INFIGO-TD-2006-04-01-Fuzzing-eng.pdf

http://www.infigo.hr/files/INFIGO-TD-2006-04-01-Fuzzing-eng.pdf

http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html

http://www.infosecinstitute.com/blog/2005/12/fuzzers-ultimate-list.html

http://www.securityfocus.com/news/11379


http://www.ngssoftware.com/papers/defeating-w2k3-stack-protection.pdf

http://www.ngssoftware.com/papers/defeating-w2k3-stack-protection.pdf

http://blogs.msdn.com/ce_base/archive/2006/02/02/Inside_Windows_CE_API_Calls.aspx

http://blogs.msdn.com/ce_base/archive/2006/02/02/Inside_Windows_CE_API_Calls.aspx

http://www.metasploit.com/shellcode_linux.html

http://www.metasploit.com/shellcode_linux.html


[Mic] MICROSOFT: Frequently Asked Questions about Windows Mobile Software.– URL: http://www.microsoft.com/windowsmobile/about/faq.mspx

[Mic06] MICROSOFT: Platform Builder for Microsoft Windows CE 5.0: MemoryArchitecture. MSDN Library, Februar 2006. – URL: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcecoreos5/html/wce50conMemoryArchitecture.asp

[Mil05] MILLER, James A.: Mobile Malware: The Brief History. Januar2005. – URL: http://www.pdastreet.com/articles/2005/1/2005-1-13-Mobile-Malware-The.html

[MS:06] Microsoft Developer Network Library. August 2006. – URL: http://msdn.microsoft.com/library

[MSK03] MCCLURE, Stuat ; SCAMBRAY, Joel ; KURTZ, George: Hacking Expo-sed: Network Security Secrets & Solutions. Fourth edition. McGraw-HillOsborne Media, 2003. – ISBN 0–07222–742–7

[Mul05] MULLINER, Collin: Exploiting PocketPC. What The Hack 2005,Netherlands, Juli 2005. – Slides at http://wiki.whatthehack.org/images/c/c0/Collinmulliner wth2005 exploitingpocketpc.pdf

[Mul06a] MULLINER, Collin: Advanced Attacks Against PocketPC Phones (23c3 ver-sion). 23C3, Berlin, Dezember 2006. – URL: http://www.mulliner.org/pocketpc/feed/pocketpcmms collinmulliner 23c3.pdf

[Mul06b] MULLINER, Collin: Advanced Attacks Against PocketPC Phonesor getting 0wnd by MMS. Defcon 14, Las Vegas, USA, Au-gust 2006. – Slides at http://www.mulliner.org/pocketpc/CollinMulliner defcon14 pocketpcphones.pdf

[Mul06c] MULLINER, Collin: Security of Smart Phones, Department of Com-puter Science, University of California Santa Barbara, Diplomarbeit,Juni 2006. – URL: http://www.cs.ucsb.edu/∼rsg/projects/smartphones/2006 mulliner MSThesis.pdf

[Mur03a] MURIEL, Diana: Threat of mobile virus attack real. CNN, Oktober2003. – URL: http://www.cnn.com/2003/TECH/10/15/itu.security/index.html

[Mur03b] MURMANN, Tobias: Sicherheitsanalyse von Betriebssystemen fur MobileEndgerate. Frankfurt am Main, Johann Wolfgang Goethe-Universitat,Diplomarbeit, 2003

111

http://www.microsoft.com/windowsmobile/about/faq.mspx

http://www.microsoft.com/windowsmobile/about/faq.mspx

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcecoreos5/html/wce50conMemoryArchitecture.asp




http://www.pdastreet.com/articles/2005/1/2005-1-13-Mobile-Malware-The.html

http://www.pdastreet.com/articles/2005/1/2005-1-13-Mobile-Malware-The.html

http://msdn.microsoft.com/library

http://msdn.microsoft.com/library

http://wiki.whatthehack.org/images/c/c0/Collinmulliner_wth2005_exploiting_pocketpc.pdf



http://www.mulliner.org/pocketpc/feed/pocketpcmms_collinmulliner_23c3.pdf



http://www.mulliner.org/pocketpc/CollinMulliner_defcon14_pocketpcphones.pdf

http://www.mulliner.org/pocketpc/CollinMulliner_defcon14_pocketpcphones.pdf

http://www.cs.ucsb.edu/~rsg/projects/smartphones/2006_mulliner_MSThesis.pdf

http://www.cs.ucsb.edu/~rsg/projects/smartphones/2006_mulliner_MSThesis.pdf

http://www.cnn.com/2003/TECH/10/15/itu.security/index.html

http://www.cnn.com/2003/TECH/10/15/itu.security/index.html


[MVDL06] MULLINER, Collin ; VIGNA, Giovanni ; DAGON, David ; LEE, Wen-ke: Using Labeling to Prevent Cross-Service Attacks Against SmartPhones. In: BUSCHKES, R. (Hrsg.) ; LASKOV, P. (Hrsg.): Detection ofIntrusions and Malware, and Vulnerability Assessment, Springer-VerlagGmbH, Juli 2006 (Lecture Notes in Computer Science, 4064). – ISBN3–540–36014–X, pp. 91–108

[NRT04] NIEMELA, Jarno ; RAUTIAINEN, Sami ; TOCHEVA, Katrin: F-Secure Vi-rendefinition: Cabir. Juni 2004. – URL: http://www.f-secure.de/v-desk/cabir.shtml

[One96] ONE, Aleph: Smashing The Stack For Fun And Profit. In: Phrack Maga-zin 7 (1996), November, Nr. 49. – URL: http://www.phrack.org/archives/63/p63-0x06 Hacking WindowsCE.txt

[PaXa] Homepage of The PaX Team. – URL: http://pax.grsecurity.net/

[PaXb] PaX Address Space Layout Randomization. – URL: http://pax.grsecurity.net/docs/aslr.txt

[Pei06] PEIKARI, Cyrus: Analyzing the Crossover Virus: The First PC to WindowsHandheld Cross-infector. Marz 2006. – URL: http://www.informit.com/articles/article.asp?p=458169\&seqNum=2\&rl=1

[PF04] PEIKARI, Cyrus ; FOGIE, Seth: Introducing the First Virus for WindowsMobile Pocket PC. Juli 2004. – URL: http://www.airscanner.com/pr/dust0715.html

[PFR04a] PEIKARI, Cyrus ; FOGIE, Seth ; RATTER/29A: Details Emerge onthe First Windows Mobile Virus (Part 1 of 3). September 2004. –URL: http://www.informit.com/articles/article.asp?p=337069\&rl=1

[PFR04b] PEIKARI, Cyrus ; FOGIE, Seth ; RATTER/29A: Details Emerge onthe First Windows Mobile Virus (Part 2 of 3). September 2004. –URL: http://www.informit.com/articles/article.asp?p=337070\&seqNum=1\&rl=1

[PFR04c] PEIKARI, Cyrus ; FOGIE, Seth ; RATTER/29A: Details Emerge onthe First Windows Mobile Virus (Part 3 of 3). September 2004. –URL: http://www.informit.com/articles/article.asp?p=337071\&rl=1

[Pie97] PIETREK, Matt: A Crash Course on the Depths of Win32 Structured Excep-tion Handling. Januar 1997. – URL: http://www.microsoft.com/msj/0197/Exception/Exception.aspx

112

http://www.f-secure.de/v-desk/cabir.shtml

http://www.f-secure.de/v-desk/cabir.shtml

http://www.phrack.org/archives/63/p63-0x06_Hacking_WindowsCE.txt


http://pax.grsecurity.net/

http://pax.grsecurity.net/docs/aslr.txt

http://pax.grsecurity.net/docs/aslr.txt

http://www.informit.com/articles/article.asp?p=458169&seqNum=2&rl=1


http://www.airscanner.com/pr/dust0715.html

http://www.airscanner.com/pr/dust0715.html

http://www.informit.com/articles/article.asp?p=337069&rl=1






http://www.microsoft.com/msj/0197/Exception/Exception.aspx

http://www.microsoft.com/msj/0197/Exception/Exception.aspx


[Poß05] POSSNECK, Lutz: Handy-Viren: Die Geschichte des PCs wiederholt sich.December 2005. – URL: http://www.silicon.de/enid/mobilewireless/15593

[Pou02] POULSEN, Kevin: ’Hacking Challenge’ Winners Allege $43,000 Con-test Rip-Off. In: SecurityFocus (2002), November. – URL: http://www.securityfocus.com/news/1717

[RFC87a] Protocol Standard for a NetBIOS Service on a TCP/UDP Transport:Concepts and Methods, RFC 1001. In: Request for Comments, NetworkWorking Group, Marz 1987. – URL: http://www.faqs.org/rfcs/rfc1001.html

[RFC87b] Protocol Standard for a NetBIOS Service on a TCP/UDP Transport:Detailed Specifications, RFC 1002. In: Request for Comments, NetworkWorking Group, Marz 1987. – URL: http://www.faqs.org/rfcs/rfc1002.html

[RSA06a] RSA Laboratories: The RSA Factoring Challenge. 2006. – URL: http://www.rsasecurity.com/rsalabs/node.asp?id=2092

[RSA06b] RSA Security - Cryptographic Challenges. 2006. – URL: http://www.rsasecurity.com/rsalabs/node.asp?id=2091

[san05a] SAN: Hacking Windows CE. Xcon 2005, Beijing, China, August 2005.– URL: http://xcon.xfocus.org/xcon2005/archives/2005/Xcon2005 San.pdf#search=%22wince%20stack%20overflow%22

[san05b] [email protected]: Hacking Windows CE. In: Phrack Magazin 6(2005), Juli, Nr. 63. – URL: http://www.phrack.org/archives/63/p63-0x06 Hacking WindowsCE.txt

[Sch00] Kapitel 22. In: SCHNEIER, Bruce: Secrets & Lies - Digital Security in aNetworked World. John Wiley & Sons, Inc., 2000. – ISBN 0–471–25311–1,S. 346–349

[Sch02] SCHECHTER, Stuart E.: Quantitatively Differentiating System Secu-rity. Mai 2002. – URL: http://www2.sims.berkeley.edu/resources/affiliates/workshops/econsecurity/econws/31.pdf

[Sch04] SCHECHTER, Stuart E.: Computer Security Strength & Risk: A Quantitati-ve Approach, Harvard, Diss., 2004. – URL: http://citeseer.ist.psu.edu/schechter04computer.html

[Sea00] SEAL, David: ARM Architecture Reference Manual. Second Edition.Addison-Wesley Professional, 2000. – ISBN 0–201–73719–1

113

http://www.silicon.de/enid/mobile_wireless/15593

http://www.silicon.de/enid/mobile_wireless/15593







http://www.rsasecurity.com/rsalabs/node.asp?id=2092




http://xcon.xfocus.org/xcon2005/archives/2005/Xcon2005_San.pdf#search=%22wince%20stack%20overflow%22





http://www2.sims.berkeley.edu/resources/affiliates/workshops/econsecurity/econws/31.pdf



http://citeseer.ist.psu.edu/schechter04computer.html

http://citeseer.ist.psu.edu/schechter04computer.html


[SPP+04] SHACHAM, Hovav ; PAGE, Matthew ; PFAFF, Ben ; GOH, Eu-Jin ; MO-DADUGU, Nagendra ; BONEH, Dan: On the Effectiveness of Address-Space Randomization. In: ACM CCS 2004, 2004. – URL: http://crypto.stanford.edu/∼nagendra/papers/asrandom.pdf

[Spr05] SPRUNDEL, Ilja van: Fuzzing: Breaking software in an automated fashi-on. Dezember 2005. – URL: http://events.ccc.de/congress/2005/fahrplan/attachments/582-paper fuzzing.pdf

[Spr06] SPRUNDEL, Ilja van: Dave on finding vulnerabilities. In: ilja’s blog(2006), November. – URL: http://blogs.23.nu/ilja/stories/13345/

[Syn07] SynCE Project Homepage. Januar 2007. – URL: http://synce.sourceforge.net/

[vxF] Homepageof vxFtpSrv for Windows CE and Pocket PC. – URL: http://www.cam.com/vxftpsrv.html

[Wan05] WANG, Robert X.: Symantec Securiy Response: SymbOS.Cardtrp.A.September 2005. – URL: http://www.symantec.com/securityresponse/writeup.jsp?docid=2005-092215-2634-99

[WAP02] Wireless Application Protocol MMS Encapsulation Protocol. WAP Forum,Januar 2002. – URL: http://www.openmobilealliance.org/tech/affiliates/LicenseAgreement.asp?DocName=/wap/wap-209-mmsencapsulation-20020105-a.pdf

[WG06] WELLS, Joe ; GORDON, Sarah: The WildList Organization International.Oktober 2006. – URL: http://www.wildlist.org/WildList/

[Win06] WinPcap, The Packet Capture and Network Monitoring Library for Win-dows. 2006. – URL: http://www.winpcap.org

[Yao06] YAO, Paul: Entdecken Sie die neuen Features in WindowsEmbedded CE 6.0. In: MSDN Magazin (2006), Dezember. –URL: http://msdn.microsoft.com/msdnmag/issues/06/12/WindowsCE/Default.aspx

114

http://crypto.stanford.edu/~nagendra/papers/asrandom.pdf

http://crypto.stanford.edu/~nagendra/papers/asrandom.pdf

http://events.ccc.de/congress/2005/fahrplan/attachments/582-paper_fuzzing.pdf

http://events.ccc.de/congress/2005/fahrplan/attachments/582-paper_fuzzing.pdf

http://blogs.23.nu/ilja/stories/13345/

http://blogs.23.nu/ilja/stories/13345/

http://synce.sourceforge.net/

http://synce.sourceforge.net/

http://www.cam.com/vxftpsrv.html

http://www.cam.com/vxftpsrv.html



http://www.openmobilealliance.org/tech/affiliates/LicenseAgreement.asp?DocName=/wap/wap-209-mmsencapsulation-20020105-a.pdf



http://www.wildlist.org/WildList/

http://www.winpcap.org

http://msdn.microsoft.com/msdnmag/issues/06/12/WindowsCE/Default.aspx

http://msdn.microsoft.com/msdnmag/issues/06/12/WindowsCE/Default.aspx

Voraussetzungen für die Entwicklung von Malware unter ... · PDF...

Documents

Transcript of Voraussetzungen für die Entwicklung von Malware unter ... · PDF...