60378-2 Titelei_X 22.12.15 11:15 Seite 4

Bibliografische Information der Deutschen Bibliothek

Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte Daten sind im Internet über http://dnb.ddb.de abrufbar.

Alle Angaben in diesem Buch wurden vom Autor mit größter Sorgfalt erarbeitet bzw. zusammengestellt und unter Einschaltung wirksamer Kontrollmaßnahmen reproduziert. Trotzdem sind Fehler nicht ganz auszuschließen. Der Verlag und der Autor sehen sich deshalb gezwungen, darauf hinzuweisen, dass sie weder eine Garantie noch die juristische Verantwortung oder irgendeine Haftung für Folgen, die auf fehlerhafte Angaben zurückgehen, über- nehmen können. Für die Mitteilung etwaiger Fehler sind Verlag und Autor jederzeit dankbar. Internetadressen oder Versionsnummern stellen den bei Redaktionsschluss verfügbaren Informationsstand dar. Verlag und Autor übernehmen keinerlei Verantwortung oder Haftung für Veränderungen, die sich aus nicht von ihnen zu vertreten- den Umständen ergeben. Evtl. beigefügte oder zum Download angebotene Dateien und Informationen dienen aus- schließlich der nicht gewerblichen Nutzung. Eine gewerbliche Nutzung ist nur mit Zustimmung des Lizenzinha- bers möglich.

© 2016 Franzis Verlag GmbH, 85540 Haar bei München

Alle Rechte vorbehalten, auch die der fotomechanischen Wiedergabe und der Speicherung in elektronischen Medien. Das Erstellen und Verbreiten von Kopien auf Papier, auf Datenträgern oder im Internet, insbesondere als PDF, ist nur mit ausdrücklicher Genehmigung des Verlags gestattet und wird widrigenfalls strafrechtlich verfolgt.

Die meisten Produktbezeichnungen von Hard- und Software sowie Firmennamen und Firmenlogos, die in diesem Werk genannt werden, sind in der Regel gleichzeitig auch eingetragene Warenzeichen und sollten als solche betrachtet werden. Der Verlag folgt bei den Produktbezeichnungen im Wesentlichen den Schreibweisen der Hersteller.

Autoren: Christian Immler, Justin Clarke, Tim Philipp Schäfers, Dr. Patrick Engebretson, Julie J. . H. Ryan, Cade Kamachi, T. J. O’Connor, Peter Loshin, Dr. Peter Kraft, Andreas Weyert

ISBN 978-3-645-39074-3 INHALTSÜBERSICHT

1.. Teil: Android Hacking ...... PDF-S. 4

2.. Teil: SQL-Hacking ...... PDF-S. 537

3.. Teil: Hacking im Web ...... PDF-S. 1196

4.. Teil: Hacking Handbuch ...... PDF-S. 1693

5.. Teil: E-Mail Hacking ...... PDF-S. 2018

6.. Teil: Python Hacking ...... PDF-S. 2170

7.. Teil: Anonym im Internet mit Tor und ...... PDF-S. 2534

8.. Teil: Network Hacking ...... PDF-S. 2723 60378-2 Titelei_X 22.12.15 11:15 Seite 3

Christian Immler Android Hacking

Ihr kann mehr, als Sie denken: Hacken Sie Ihr Gerät, bevor es andere tun. 60378-2 Titelei_X 22.12.15 11:15 Seite 2

Christian Immler, Jahrgang 1964, war bis 1998 als Dozent für Computer Aided Design an der Fachhochschule Nienburg und an der University of Brighton tätig. Einen Namen hat er sich mit diversen Veröffentlichungen zu Spezialthemen wie 3-D-Visualisierung, PDA-Betriebssystemen, und Windows gemacht. Seit mehr als 20 Jahren arbeitet er als erfolgreicher Autor mit mehr als 200 veröffentlichten Computerbüchern. Vorwort

Android kann nach gerade einmal sieben Jahren Marktpräsenz – die erste Version erschien am 21.10.2008 – stolz von sich behaupten, das erfolgreichste mobile Betriebssystem aller Zeiten zu sein. Android hat mit etwa 84 % Marktanteil alle anderen mobilen Plattformen weit hinter sich gelassen. Selbst in der Statistik aller Betriebssysteme, nicht nur der mobilen, spielt Android eine wesentliche Rolle. Nach einer Statistik von Statcounter war im September 2015 Windows 7 mit 28,8 % das meistverbreitete Betriebssystem, dicht gefolgt von Android mit 27,5 %. Alle anderen Betriebssysteme erreichten nicht einmal die 10-%-Marke. Android läuft zurzeit auf über 24.000 verschiedenen Gerätemodellen. Das ursprüng- lich quelloffen als Android Open Source Project AOSP (source.android.com) angebotene Betriebssystem wird von den Geräteherstellern mit eigenen Erweiterungen, Ober- flächen und Hardwaretreibern angepasst und auch eingeschränkt. Hacken Sie Ihr Smartphone und machen Sie mehr möglich, als der Hersteller zulässt! Inhaltsverzeichnis

I Geheimnisse rund ums »Rooten«...... 13 1.1 Rooten – so geht’s...... 17 1.2 Rooten – Vorbereitung und Grundlagen ...... 18 1.2.1 Das Android-SDK...... 18 1.2.2 Minimal ADB and Fastboot ...... 19 1.2.3 Smartphone mit USB-Debugging verbinden...... 21 1.3 Der Bootloader...... 24 1.3.1 Bootloader auf Nexus-Geräten entsperren ...... 26 1.3.2 Bootloader entsperren – Besonderheiten bei HTC- und Motorola- ...... 27 1.4 Der Recovery-Modus ...... 32 1.4.1 ClockworkMod Recovery ...... 32 1.4.2 TeamWin Recovery Project (TWRP)...... 34 1.4.3 Besonderheiten bei Samsung-Smartphones...... 40 1.5 Apps zum Rooten ...... 44 1.5.1 Framaroot ...... 45 1.5.2 KingRoot...... 46 1.5.3 Root Genius...... 51 1.5.4 Universal Androot...... 52 1.5.5 Towelroot...... 52 1.6 Superuser-Utilities...... 52 1.6.1 SuperSU...... 54 1.6.2 ClockworkMod Superuser...... 55 1.6.3 KingUser...... 56 1.7 Tools zum Rooten vom PC ...... 57 1.7.1 Nexus Root Toolkit ...... 58 1.7.2 Bacon Root Toolkit für OnePlus One...... 69 1.7.3 SRSRoot...... 69 1.7.4 Wondershare MobileGo...... 71 1.7.5 Root_with_Restore_by_Bin4ry...... 72 1.7.6 Cydia Impactor...... 73 1.7.7 Root Genius...... 74 2 Apps jenseits des Mainstreams...... 77 2.1 Alternative Softwarearchive und Repositories...... 77 2.1.1 Play Store-Fehler beheben...... 79 2.1.2 Amazon App-Shop...... 86 2.1.3 F-Droid...... 87 2.1.4 APKMirror ...... 88 2.2 Alternative Launcher ...... 91 2.2.1 Launcher...... 93 2.2.2 KK Launcher...... 94 2.2.3 GO Launcher Z...... 95 8 Inhaltsverzeichnis

2.2.4 Yahoo! Aviate...... 97 2.2.5 Nokia Z Launcher Beta ...... 101 2.2.6 Smart Launcher 3 ...... 103 2.2.7 Everything Me ...... 105 2.2.8 Yandex.Shell...... 107 2.2.9 Launcher 8...... 108 2.2.10 Microsoft Arrow Launcher – Übersicht ...... 109 2.2.11 Hangar ...... 112 2.2.12 Home Switcher ...... 114 2.3 Dateimanager...... 115 2.3.1 File Expert HD ...... 115 2.3.2 Total Commander...... 118 2.3.3 X-plore File Manager ...... 119 2.4 Nützliche System-Apps...... 120 2.4.1 AppMonster...... 121 2.4.2 APK Extractor...... 123 2.4.3 CCleaner...... 124 2.4.4 Wondershare MobileGo...... 125 2.4.5 Wifi Analyzer...... 127 2.4.6 Connection List...... 128 2.4.7 OS Monitor...... 129 2.5 Alltägliche Aufgaben automatisieren...... 130 2.5.1 Llama...... 132 2.5.2 IFTTT ...... 134 2.6 Spezielle Apps für root...... 138 2.6.1 Autostarts...... 139 2.6.2 SD Maid...... 140 2.6.3 Titanium Backup...... 142 2.6.4 No-frills CPU Control...... 143 2.6.5 Recovery Reboot...... 143 2.6.6 ROM Toolbox...... 144 2.6.7 Terminal Emulator ...... 147 2.6.8 NetCut ...... 148 2.7 Systemmodifikationen mit dem Xposed Framework...... 149 2.7.1 Nützliche Xposed-Module...... 152 2.8 App-Berechtigungen...... 158 2.8.1 App-Berechtigungen einschränken...... 161 2.8.2 Verschlüsselte Nachrichten mit TextSecure...... 168 2.9 Werbung entdecken und blockieren ...... 169 2.9.1 Ad Network Scanner...... 173 2.9.2 Adblock Plus ...... 174 2.9.3 Block it! ...... 177 2.9.4 AdAway...... 178 2.9.5 Adblock Browser ...... 180 2.10 Debloat – überflüssige vorinstallierte Software entfernen...... 186 2.10.1 Root Browser ...... 187 2.10.2 System-App-Entferner...... 188 2.10.3 Debloater by Gatesjunior...... 189 Inhaltsverzeichnis 9

2.11 Sicherheitsalarme ...... 191 2.11.1 Die Schnüffelsoftware Carrier IQ...... 191 2.11.2 Der sogenannte WhatsApp-Virus ...... 192 2.11.3 Exploit...... 193 2.11.4 Der Trojaner Android.LockerPin.A ...... 196 2.11.5 Die Erpressersoftware PornDroid Android.Lockdroid.E...... 197 2.12 Gestohlene Smartphones orten oder unbrauchbar machen ...... 198 3 CustomROMs ...... 203 3.1 Warum CustomROMs? ...... 206 3.2 Der klassische Weg – CustomROMs auf das Smartphone flashen...... 208 3.2.1 Passende CyanogenMod-Dateien finden ...... 208 3.2.2 Download überprüfen...... 219 3.2.3 Originalbetriebssystem sichern...... 220 3.2.4 CustomROM auf das Smartphone flashen...... 220 3.3 JRummy ROM Installer für CustomROMs...... 222 3.4 Google Apps für CustomROM finden...... 223 3.4.1 Open GApps ...... 224 3.4.2 Minimal Edition Gapps und Debloat-Skript ...... 228 3.5 CyanogenMod – das bessere Android...... 230 3.5.1 Die wichtigsten Zusatzfunktionen in Kürze ...... 231 3.5.2 Die unterschiedlichen CyanogenMod-Versionen...... 233 3.5.3 CyanogenMod auf aktuellen Smartphones installieren ...... 235 3.5.4 Vorinstallierte Apps ...... 244 3.5.5 Die Einstellungen in CyanogenMod...... 263 3.5.6 Datenschutz...... 281 3.5.7 App-Zugriffe verfolgen...... 282 3.5.8 App-Berechtigungen einschränken...... 283 3.5.9 Smartphone über- und untertakten ...... 287 3.5.10 I/O-Scheduler verwalten Prozesse und Dateizugriffe...... 290 3.5.11 Root-Funktionen...... 291 3.5.12 Automatische Updates in CyanogenMod ...... 295 3.5.13 CM-Apps auch für »normales« Android...... 296 3.5.14 Inoffizielle CyanogenMod-Varianten und Nightlys...... 297 3.5.15 CyanogenMod für »historische« Smartphones ...... 303 3.6 BlissROM...... 311 3.6.1 BlissROM installieren...... 312 3.6.2 Google Apps nachinstallieren...... 312 3.6.3 Der Launcher im BlissROM ...... 313 3.6.4 Vorinstallierte Apps ...... 315 3.6.5 Design anpassen ...... 318 3.6.6 Navigationsoptionen...... 320 3.6.7 Apps in Fenstern öffnen...... 332 3.6.8 Sperrbildschirm-Optionen ...... 333 3.6.9 Benachrichtigungen anpassen...... 334 3.6.10 Erweiterter Ausschaltbildschirm...... 337 3.6.11 Erweiterte Statusleiste...... 339 3.6.12 Systemprofile nutzen ...... 342 3.6.13 Datenschutzoptionen ...... 344 10 Inhaltsverzeichnis

3.6.14 Eingebaute Root-Funktionen...... 347 3.7 AOKP ...... 349 3.7.1 AOKP installieren...... 350 3.7.2 ROM-Steuerung – die erweiterten Einstellungen...... 352 3.7.3 Erweiterte Geräteoptionen...... 367 3.7.4 CyanogenMod-Funktionen in AOKP...... 367 3.8 OmniROM...... 370 3.8.1 OmniROM installieren...... 370 3.8.2 Superuser-Funktionen in OmniROM...... 372 3.8.3 Benutzeroberfläche anpassen...... 373 3.8.4 Vollbildmodus ...... 375 3.8.5 OmniSwitch ...... 376 3.8.6 Sperrbildschirm anpassen...... 379 3.8.7 Active display ...... 381 3.8.8 LED-Benachrichtigungen anpassen ...... 382 3.8.9 Datenschutzoptionen ...... 383 3.8.10 DSP-Manager – systemweiter Equalizer...... 384 3.8.11 Neustartmenü erweitern ...... 385 3.8.12 Unbekannte Anrufer blockieren ...... 386 3.8.13 Intelligente automatische Updates ...... 387 3.9 PAC ROM...... 388 3.9.1 PAC ROM installieren...... 388 3.9.2 Die PAC-Einstellungen...... 391 3.9.3 Aus anderen CustomROMs bekannte Funktionen...... 398 3.9.4 Superuser-Funktionen in PAC ROM...... 404 3.10 SlimRom...... 404 3.10.1 SlimRom installieren...... 404 3.10.2 Neue Einstellungen zur Benutzeroberfläche ...... 405 3.10.3 Einstellungen zur Navigation...... 410 3.10.4 SlimCenter...... 414 3.10.5 Root-Zugriffe in SlimRom...... 415 3.10.6 App-Berechtigungen und Datenschutz ...... 416 3.10.7 Erweiterte Geräteeinstellungen...... 417 3.11 Nameless ROM ...... 419 3.11.1 Nameless ROM installieren...... 419 3.11.2 Die wichtigsten Einstellungen...... 421 3.11.3 Device Control ...... 423 3.12 MIUI ...... 427 3.12.1 Die Benutzeroberfläche...... 428 3.12.2 Vorinstallierte Apps ...... 431 3.12.3 Die wichtigsten Einstellungen...... 436 3.12.4 Bloatware entfernen...... 439 3.12.5 Apps verstecken und Gastmodus ...... 440 3.12.6 Die eingebaute Sicherheitsüberprüfung...... 441 4 Android ohne Google ...... 449 4.1 FreeYourAndroid...... 450 4.1.1 Was ist freie Software?...... 451 4.1.2 Freie Software auf Android-Smartphones nutzen ...... 452 Inhaltsverzeichnis 11

4.1.3 Freie App-Alternativen...... 452 4.1.4 Launcher...... 454 4.1.5 Kalender ...... 456 4.1.6 E-Mail...... 457 4.1.7 Browser...... 457 4.1.8 Landkarten...... 460 4.1.9 Office-Apps...... 463 4.2 Replicant ...... 466 4.2.1 Replicant installieren...... 468 4.2.2 Vorinstallierte Apps ...... 469 4.2.3 Die wichtigsten Einstellungen...... 469 5 GSM- und USSD-Codes...... 475 5.1 So werden GSM- und USSD-Codes eingegeben ...... 475 5.1.1 Gefahr durch USSD-Codes ...... 476 5.1.2 IMEI anzeigen...... 477 5.1.3 Prepaid-Guthaben anzeigen...... 478 5.1.4 Rufnummer unterdrücken ...... 478 5.1.5 Anklopfen...... 478 5.1.6 Rufumleitung ...... 479 5.1.7 PIN ändern...... 479 5.2 Diagnosecodes für spezielle Geräte ...... 480 6 Smartphone für Maker...... 485 6.1 Android-Smartphones vom PC aus steuern...... 485 6.1.1 Der Gerätemonitor im Android-SDK...... 485 6.1.2 TeamViewer ...... 487 6.1.3 Web PC Suite ...... 491 6.1.4 Wondershare MobileGo...... 494 6.1.5 Desktop-Tastatur/Remote Keyboard ...... 497 6.2 PC vom Smartphone aus steuern...... 500 6.2.1 TeamViewer ...... 500 6.2.2 Chrome Remote Desktop...... 503 6.2.3 VNC...... 505 6.3 Smartphone zur Steuerung von Hardware...... 507 6.3.1 Kodi Media Center...... 507 6.3.2 RasPi Check...... 510 6.3.3 Arduino mit dem Smartphone steuern...... 511 6.3.4 Haustechnik über IFTTT steuern ...... 514 6.3.5 TV Kill...... 515 6.3.6 Smartphone als Webcam...... 516 6.4 Android auf dem PC...... 522 6.4.1 Der Android-Emulator aus dem SDK ...... 522 6.4.2 Android als virtuelle Maschine unter Windows...... 527

Apps jenseits des Mainstreams

Zahlreiche Apps richten sich speziell an ambitionierte Nutzer und Hacker von And- roid-Smartphones. Die meisten derartigen Apps tauchen in den klassischen App- Empfehlungen in Zeitschriften und Medien nicht auf. Einige der in diesem Kapitel erwähnten Apps sind nicht einmal im Store verfügbar, sondern können nur aus alternativen Quellen installiert werden.

2.1 Alternative Softwarearchive und Repositories

Der Google Play Store ist die bekannteste Quelle zum Download von Apps, es gibt aber andere, die zum Teil Apps anbieten, die bei Google Play nicht lieferbar sind. Einige Entwickler bieten ihre Apps zusätzlich über ihre eigenen Webseiten oder unabhängige Downloadportale an. Hobbyprogrammierer und Open-Source-Projekte können auch nicht immer für jede Betaversion oder Neuentwicklung die Gebühr bezahlen, die Google für das Einstellen in den Play Store verlangt. Außerdem sperrt Google hin und wieder bestimmte Apps, die sich dann auf alternativen Wegen weiterhin installieren lassen. Apps werden außerhalb des Google Play Store meist als APK-Dateien zum Download angeboten. Diese können direkt über den Browser oder aus einem Dateianhang einer E-Mail auf dem Smartphone installiert werden. Die heruntergeladenen Dateien sind 78 2 Apps jenseits des Mainstreams

im Ordner Downloads auf dem Smartphone oder direkt nach dem Herunterladen über die Benachrichtigungen zu finden.

Bild 2.1: Heruntergeladene Apps installieren.

Je nach Einstellung des Smartphones kann bei der ersten Installation einer APK-Datei ein Hinweis erscheinen, der Ihnen mitteilt, dass Installationen aus unbekannten Quellen nicht zulässig sind. Direkt aus dieser Meldung heraus besteht Zugriff auf die zugehörige Systemeinstellung, mit der man die Installation aus unbekannten Quellen zulassen kann. Nicht zuletzt gibt es auch Smartphones ohne Google Play Store. Dies kann daran liegen, dass der Gerätehersteller die Google-Lizenz nicht bezahlen wollte oder ein CustomROM genutzt wird, dessen Entwickler sich bewusst gegen Google Play ent- schieden haben. 2.1 Alternative Softwarearchive und Repositories 79

Bild 2.2: Installation aus unbekannten Quellen zulassen.

Ist die Installation wirklich so gefährlich wie beschrieben? Die Installation einer App aus einer APK-Datei aus einer anderen vertrauenswürdigen Quelle ist technisch gleichermaßen sicher wie die Installation aus dem Google Play Store. Die Warnungen innerhalb des Betriebssystems sind eine Marketingmaßnahme von Google für seinen Play Store. Auch dort haben es Entwickler immer wieder geschafft, bösartige Software zu verbreiten. Letztlich ist jeder Anwender selbst dafür verantwortlich, welche Apps er auf seinem Smartphone installiert. Diese Verantwortung kann einem kein App-Shop-Betreiber abnehmen, egal ob Google Play oder ein anderer. Apps von unbekannten chinesischen Downloadseiten oder gar über ein Werbebanner zu installieren ist wirklich leichtsinnig.

2.1.1 Google Play Store-Fehler beheben Beim Versuch, Apps aus dem Google Play Store zu installieren, kommt es immer wieder zu den verschiedensten Fehlermeldungen, beispielsweise dass der Download nicht möglich sei oder der Gerätespeicher nicht ausreiche. Im letzteren Fall sollte man natürlich einmal in den Einstellungen unter Speicher nachsehen – meistens ist das aber nicht der wirkliche Grund, besonders dann nicht, wenn die Installation von Apps aus anderen Quellen funktioniert. Bei den meisten Fehlern – egal wie die Meldung lautet – sind fehlerhafte Updates des Google Play Store selbst oder der Google Play-Dienste die Ursache.

80 2 Apps jenseits des Mainstreams

Öffnen Sie die Einstellungen, tippen Sie dort auf Apps und suchen Sie in der Liste den Google Play Store.

Bild 2.3: App- Informationen für den Google Play Store.

Tippen Sie hier auf Daten löschen und weiter unten auf Cache leeren. Tippen Sie danach auf Updates deinstallieren, um den Google Play Store auf den Auslieferungszustand zurückzusetzen. Öffnen Sie danach auch die App-Informationen der Google Play-Dienste, löschen Sie hier ebenfalls den Cache und tippen Sie auf Speicherplatz verwalten. Tippen Sie im nächsten Bildschirm unten auf Alle Daten löschen. 2.1 Alternative Softwarearchive und Repositories 81

Bild 2.4: App- Informationen für die Google Play- Dienste.

Bei einigen Fehlern hilft es auch, in den App-Informationen der Google Play-Dienste und des Google Play Store auf Beenden erzwingen zu tippen, bevor das Gerät neu gestartet wird. Starten Sie danach das Gerät neu und öffnen Sie den Google Play Store. Dieser wird automatisch ein Update installieren. Nach Abschluss des Updates wird die Installa- tion von Apps in den meisten Fällen wieder funktionieren.

82 2 Apps jenseits des Mainstreams

Google Play-Fehler 413 Dieser Fehler tritt bei Internetverbindungen über Proxys auf. Wählen Sie in den Ein- stellungen unter Mehr/Mobilfunknetze den verwendeten Zugangspunkt und sehen Sie dort nach, ob ein Proxy eingetragen ist. Nur sehr wenige Mobilfunkanbieter benötigen tatsächlich Proxys. Viel öfter werden diese durch bösartige Dialersoftware eingetra- gen. Gegen den Google Play-Fehler 413 hilft es daher häufig, den Proxy einfach zu löschen.

Bild 2.5: Proxy- Einstellungen für Mobilfunkver- bindungen.

Sollte der Proxy vom Mobilfunknetzbetreiber wirklich benötigt werden, laden Sie Apps im Google Play Store über WLAN herunter. Tritt der Fehler auch bei WLAN auf, ist möglicherweise dort ebenfalls ein Proxy eingetragen. Tippen Sie in den Einstellungen unter WLAN länger auf die verwendete Verbindung und wählen im Kontextmenü Netzwerk ändern. Schalten Sie das Kontrollkästchen Erweiterte Optionen ein, erscheinen die Proxy-Einstellungen. Auch hier kann das Umstellen auf Kein Proxy helfen, den Google Play-Fehler zu verhindern. 2.1 Alternative Softwarearchive und Repositories 83

Bild 2.6: Proxy- Einstellungen für WLAN- Verbindungen.

Google Play-Fehler 492 Dieser Fehler deutet auf einen Fehler im -Cache hin. Booten Sie in diesem Fall das Smartphone im Recovery-Modus. Die meisten Recoverys haben einen Menü- punkt Wipe Dalvik Cache. Bestätigen Sie diesen und booten Sie das Smartphone neu. Bietet das Recovery-Menü keine Option zum Löschen des Dalvik-Cache, kann man entweder ein anderes Recovery-Tool installieren, wie zum Beispiel ClockworkMod Recovery, oder das Smartphone in den Werkzustand zurücksetzen, wobei allerdings zuvor alle Daten gespeichert werden müssen, da sie beim Zurücksetzen verloren gehen.

Was ist der Dalvik-Cache? Andoid-Apps sind in Java programmiert. Diese Programmiersprache wird, direkt bevor das Pro- gramm läuft, kompiliert. Seit Android 5 erfolgt das Kompilieren bereits bei der Installation einer App, sodass diese später schneller gestartet wird. Die kompilierten Daten werden im Dalvik- Cache unter /data/dalvik-cache abgelegt. Nach dem Bereinigen des Dalvik-Cache werden Apps beim ersten Starten wieder neu kompiliert. Ein Bereinigen des Dalvik-Cache gibt keinen Speicher frei, der für andere Zwecke genutzt werden kann.

84 2 Apps jenseits des Mainstreams

Google Play-Fehler 498 Dieser Fehler beruht in den meisten Fällen auf einem fehlerhaften App-Cache. Tippen Sie in den Einstellungen auf Speicher und warten Sie ab, bis die Datenmengen berech- net sind. Tippen Sie dann auf die Zeile Daten im Cache und bestätigen Sie die Meldung, den Cache zu löschen.

Bild 2.7: Cache löschen. 2.1 Alternative Softwarearchive und Repositories 85

Google Play-Fehler 923 Auch dieser Fehler kann durch einen fehlerhaften App-Cache verursacht werden, sodass ein Löschen des Cache bereits helfen kann. Eine weitere mögliche Ursache sind ungültige App-Einstellungen, die zum Beispiel bei der Installation eines alternati- ven Launchers oder Standardbrowsers entstehen können. Tippen Sie in den Einstellungen auf Apps und dann in der Apps-Liste oben rechts auf das Menüsymbol mit den drei Punkten. Wählen Sie hier App-Einstellungen zurückset- zen und bestätigen Sie anschließend die Sicherheitsabfrage.

Bild 2.8: App- Einstellungen zurücksetzen.

86 2 Apps jenseits des Mainstreams

2.1.2 Amazon App-Shop Der Amazon App-Shop ist wahrscheinlich der bekann- teste der alternativen Downloadshops für Android- Apps. Dieser App-Shop läuft über eine eigene App, die zunächst auf dem Smartphone installiert werden muss und zur Nutzung ein Amazon-Kundenkonto erfordert. Dort wird bei der Anmeldung im App-Shop das 1-Click-Kaufen automatisch aktiviert. Auf der Startseite des Amazon App-Shops für den PC sehen Sie alle Apps und können sich eine E-Mail oder SMS mit dem Downloadlink aufs Handy schicken lassen: amzn.to/1e5lWnF. Oder Sie nutzen den QR-Code zum Download des Amazon App-Shops.

Bild 2.9: Der Amazon App-Shop.

Amazon hat alle im App-Shop angebotenen Apps so modifiziert, dass sie nur auf dem Smartphone laufen, wenn dort auch die Amazon-App installiert ist und mit dem beim Download der App verwendeten Kundenkonto läuft.

2.1 Alternative Softwarearchive und Repositories 87

2.1.3 F-Droid F-Droid (f-droid.org) bietet ausschließlich Freeware aus der Open-Source-Szene an. Es sind auch einige interessante Systemtools dabei, die es nicht in den Google Play Store geschafft haben. F-Droid verwendet, wie die anderen Shops auch, eine eigene App zum Blättern durch den Katalog und zur Installation der Apps. Im Gegensatz zu den großen App-Stores ist keinerlei Anmeldung oder Kundenkonto nötig.

Bild 2.10: Der App- Store F-Droid.

Bei jeder App und auch bei möglichen Updates wird die genaue Versionsnummer angezeigt, was Google Play leider nicht tut. Im Gegensatz zu anderen App-Shops bietet F-Droid bei vielen Apps verschiedene Versionen an. So kann man auch ältere Versionen von Apps testen. In den Einstellungen lassen sich neben dem Standard-F- Droid-Katalog auch andere Paketquellen für Apps festlegen.

88 2 Apps jenseits des Mainstreams

2.1.4 APKMirror Die Webseite www.apkmirror.com bietet beliebte Apps als APK-Dateien zum Down- load an, um sie auch ohne Google Play Store installieren zu können.

Bild 2.11: APKMirror benötigt keine Store-App, sondern kann direkt im Browser auf dem Smartphone genutzt werden.

APKMirror liefert neben der aktuellen Version auch diverse ältere Versionen der Apps. Diese lassen sich zum Testen installieren oder für den Fall, dass in der aktuellen Version eine beliebte Funktion verloren gegangen ist oder sie eine ältere Betriebs- systemversion auf dem Smartphone nicht mehr unterstützt. 2.1 Alternative Softwarearchive und Repositories 89

Google Play Store über APKMirror nachinstallieren Auf Geräten mit CustomROMs oder auf China-Smartphones ohne Google Play Store lässt sich dieser über APKMirror nachinstallieren. Suchen Sie einfach nach Google Play Store und installieren Sie die aktuelle Version. Sollte sie nicht funktionieren, können Sie immer noch auf eine ältere Version zurückgehen. Zusätzlich müssen die Google Play-Dienste installiert werden. Sie finden sie unter dem Suchbegriff . Hier ist die Auswahl nicht ganz so einfach, da zu jeder Versionsnummer unterschiedliche Dateien angeboten werden.

Bild 2.12: Google Play Store und Google Play services bei APKMirror.

90 2 Apps jenseits des Mainstreams

Hinter der Versionsnummer der Google Play-Dienste hat jede Datei eine Datei- versionsnummer mit einem dreistelligen Ziffernblock am Ende nach dem Bindestrich. Dieser bezeichnet Android-Version, CPU-Architektur und Bildschirmauflösung, für die die Datei geeignet ist.

1. Ziffer bezeichnet die Android-Version

0 Android <5.0

4 oder 7 Android >=5.0

8 Android TV

2. Ziffer bezeichnet die CPU-Architektur

0 armeabi

3 armeabi-v7a

4 arm64-v8a

7 x86

3. Ziffer bezeichnet die Bildschirmauflösung in DPI

0 universal

2 160 DPI

4 240 DPI

6 320 DPI

8 480 DPI

Achten Sie darauf, immer die passende Variante der Google Play-Dienste herunter- zuladen und zu installieren.

60466-6 Titelei_X 05.04.16 10:47 Seite 1

Justin Clarke SQL-Hacking

SQL-Injektion auf relationale Datenbanken im Detail verstehen und abwehren. 5

Inhaltsverzeichnis

Danksagung...... 21

Die Autoren der Beiträge...... 23

Chefautor und Fachgutachter...... 26

1. Was ist SQL-Injection?...... 27 1.1 Einführung...... 27 1.2 Wie funktionieren Webanwendungen?...... 28 1.2.1 Eine einfache Anwendungsarchitektur...... 30 1.2.2 Eine kompliziertere Architektur...... 31 1.3 Wie funktioniert SQL-Injection?...... 32 1.3.1 Aufsehenerregende Beispiele...... 36 1.4 Wie kann das passieren?...... 40 1.4.1 Dynamische Stringerstellung...... 40 1.4.2 Falsche Behandlung von numerischen Typen...... 43 1.4.3 Falsche Behandlung von Mehrfachübertragungen...... 48 1.4.4 Unsichere Datenbankkonfiguration...... 50 1.5 Zusammenfassung...... 52 1.6 Schneller Überblick...... 53 1.6.1 Wie funktionieren Webanwendungen?...... 53 1.6.2 Wie funktioniert SQL-Injection?...... 53 1.6.3 Wie kann das passieren?...... 54 1.7 Häufig gestellte ragenF ...... 54 6 Inhaltsverzeichnis

2. Anwendungen auf Anfälligkeit für SQL-Injection prüfen...... 57 2.1 Einführung...... 57 2.2 Anfälligkeiten für SQL-Injection finden...... 58 2.2.1 Deduktives Testen...... 59 2.2.2 Datenbankfehler...... 69 2.2.3 Antworten der Anwendung...... 84 2.2.4 Blinde Injektion...... 90 2.3 Das Vorhandensein von Schwachstellen bestätigen...... 95 2.3.1 Zahlen und Strings unterscheiden...... 95 2.3.2 Inline-SQL-Injection...... 96 2.3.3 Die SQL-Injection abschließen...... 105 2.3.4 Zeitverzögerungen...... 116 2.4 Das Aufspüren von Schwachstellen automatisieren...... 118 2.4.1 Werkzeuge zum automatischen Aufspüren von Schwachstellen...... 119 2.5 Zusammenfassung...... 129 2.6 Schneller Überblick...... 130 2.6.1 Anfälligkeiten für SQL-Injection finden...... 130 2.6.2 Das Vorhandensein von Schwachstellen bestätigen...... 131 2.6.3 Das Aufspüren von Schwachstellen automatisieren...... 131 2.7 Häufig gestellte ragenF ...... 132

3. Quellcode untersuchen...... 135 3.1 Einführung...... 135 3.2 Quellcode auf Anfälligkeiten für SQL-Injection untersuchen...... 136 3.2.1 Gefährliche Programmiertechniken...... 138 3.2.2 Gefährliche Funktionen...... 146 3.2.3 Daten verfolgen...... 150 3.2.4 Code von Android-Anwendungen untersuchen...... 159 3.2.5 PL/SQL- und T-SQL-Code überprüfen...... 166 Inhaltsverzeichnis 7

3.3 Automatisierte Quellcodeprüfung...... 173 3.3.1 Graudit...... 175 3.3.2 Yet Another Source Code Analyzer (YASCA)...... 176 3.3.3 Pixy...... 176 3.3.4 AppCodeScan...... 177 3.3.5 OWASP LAPSE+...... 178 3.3.6 Microsoft Source Code Analyzer for SQL Injection...... 179 3.3.7 Microsoft Code Analysis Tool .NET (CAT.NET)...... 179 3.3.8 RIPS – Statischer Quellcodeanalysator für Schwachstellen in PHP-Skripten..180 3.3.9 CodePro AnalytiX...... 180 3.3.10 Teachable Static Analysis Workbench...... 181 3.3.11 Kommerzielle Tools zur Quellcodeuntersuchung...... 181 3.3.12 Fortify...... 182 3.3.13 Rational AppScan Source Edition...... 184 3.3.14 CodeSecure...... 184 3.3.15 Klocwork Solo...... 185 3.4 Zusammenfassung...... 185 3.5 Schneller Überblick...... 186 3.5.1 Quellcode auf Anfälligkeiten für SQL-Injection untersuchen...... 186 3.5.2 Automatisierte Quellcodeprüfung...... 187 3.6 Häufig gestellte Fragen...... 187

4. Anfälligkeiten für SQL-Injection ausnutzen...... 191 4.1 Einführung...... 191 4.2 Gebräuchliche Exploit-Techniken...... 193 4.2.1 Stapelabfragen...... 195 4.3 Das Datenbanksystem ermitteln...... 196 4.3.1 Identifizierung mit Rückmeldungen...... 197 4.3.2 Blinde Identifizierung...... 202 8 Inhaltsverzeichnis

4.4 Daten mithilfe von UNION-Anweisungen abrufen...... 204 4.4.1 Übereinstimmende Spalten...... 205 4.4.2 Übereinstimmende Datentypen...... 208 4.5 Bedingte Anweisungen...... 213 4.5.1 Variante 1: Zeitgestützte Vorgehensweise...... 214 4.5.2 Variante 2: Fehlergestützte Vorgehensweise...... 219 4.5.3 Variante 3: Inhaltsgestützte Vorgehensweise...... 221 4.5.4 Strings...... 222 4.5.5 Die Technik erweitern...... 224 4.5.6 Fehlermeldungen zur SQL-Injection nutzen...... 225 4.5.7 Fehlermeldungen in Oracle...... 228 4.6 Das Datenbankschema auflisten...... 232 4.6.1 SQL Server...... 233 4.6.2 MySQL...... 238 4.6.3 PostgreSQL...... 243 4.6.4 Oracle...... 244 4.7 Injektion in INSERT-Abfragen...... 248 4.7.1 Szenario 1: Vom Benutzer ausgewählte Daten einfügen...... 249 4.7.2 Szenario 2: INSERT-Fehler auslösen...... 252 4.7.3 Weitere Szenarien...... 255 4.8 Rechte erhöhen...... 255 4.8.1 SQL Server...... 256 4.8.2 Oracle...... 263 4.8.3 Das Erfordernis für CREATE PROCEDURE überwinden...... 266 4.9 Passworthashes stehlen...... 268 4.9.1 SQL Server...... 268 4.9.2 MySQL...... 270 4.9.3 PostgreSQL...... 271 4.9.4 Oracle...... 272 4.10 Out-of-band-Kommunikation...... 276 Inhaltsverzeichnis 9

4.10.1 E-Mail...... 277 4.10.2 HTTP/DNS...... 281 4.10.3 Dateisystem...... 282 4.11 SQL-Injection auf Mobilgeräten...... 286 4.12 SQL-Injektionsangriffe automatisieren...... 291 4.12.1 Sqlmap...... 291 4.12.2 Bobcat...... 293 4.12.3 BSQL...... 294 4.12.4 Weitere Programme...... 296 4.13 Zusammenfassung...... 297 4.14 Schneller Überblick...... 298 4.14.1 Gebräuchliche Exploit-Techniken...... 298 4.14.2 Das Datenbanksystem ermitteln...... 299 4.14.3 Daten mithilfe von UNION-Anweisungen abrufen...... 299 4.14.4 Bedingte Anweisungen...... 299 4.14.5 Das Datenbankschema auflisten...... 300 4.14.6 Injektion in INSERT-Abfragen...... 300 4.14.7 Rechte erhöhen...... 300 4.14.8 Passworthashes stehlen...... 301 4.14.9 Out-of-band-Kommunikation...... 301 4.14.10 SQL-Injection auf Mobilgeräten...... 301 4.14.11 SQL-Injektionsangriffe automatisieren...... 301 4.15 Häufig gestellte ragenF ...... 302

5. Blinde SQL-Injection...... 303 5.1 Einführung...... 303 5.2 Anfälligkeiten für blinde SQL-Injection finden und bestätigen...... 305 5.2.1 Allgemeine Fehlermeldungen provozieren...... 305 5.2.2 Abfragen mit Nebenwirkungen einschleusen...... 306 10 Inhaltsverzeichnis

5.2.3 Aufteilen und Ausgleichen...... 306 5.2.4 Häufige Situationen bei der blinden SQL-Injektion...... 309 5.2.5 Techniken zur blinden SQL-Injektion...... 310 5.3 Zeitgestützte Techniken...... 322 5.3.1 Datenbankabfragen verzögern...... 323 5.3.2 Überlegungen zur zeitgestützten Deduktion...... 334 5.4 Antwortgestützte Techniken...... 334 5.4.1 Antworttechniken in MySQL...... 335 5.4.2 Antworttechniken in PostgreSQL...... 337 5.4.3 Antworttechniken in SQL Server...... 338 5.4.4 Antworttechniken in Oracle...... 341 5.4.5 Mehr als ein Bit an Informationen abrufen...... 342 5.5 Alternative Kanäle...... 345 5.5.1 Datenbankverbindungen...... 346 5.5.2 Datenschleusung über DNS...... 348 5.5.3 Datenschleusung per E-Mail...... 353 5.5.4 Datenschleusung über HTTP...... 354 5.5.5 Datenschleusung durch ICMP...... 357 5.6 Automatisieren der blinden SQL-Injektion...... 357 5.6.1 Absinthe...... 357 5.6.2 BSQL Hacker...... 359 5.6.3 SQLBrute...... 362 5.6.4 Sqlmap...... 364 5.6.5 Sqlninja...... 366 5.6.6 Squeeza...... 368 5.7 Zusammenfassung...... 369 5.8 Schneller Überblick...... 370 5.8.1 Anfälligkeiten für blinde SQL-Injection finden und bestätigen...... 370 5.8.2 Zeitgestützte Techniken...... 371 5.8.3 Antwortgestützte Techniken...... 371 Inhaltsverzeichnis 11

5.8.4 Alternative Kanäle...... 371 5.8.5 Automatisieren der blinden SQL-Injektion...... 372 5.9 Häufig gestellte Fragen...... 372

6. Das Betriebssystem angreifen...... 375 6.1 Einführung...... 375 6.2 Zugriff auf das Dateisystem...... 377 6.2.1 Dateien lesen...... 377 6.2.2 Dateien schreiben...... 395 6.3 Befehle des Betriebssystems ausführen...... 407 6.3.1 MySQL...... 408 6.3.2 Microsoft SQL Server...... 409 6.3.3 Oracle...... 412 6.3.4 PostgreSQL...... 421 6.4 Den Zugriff sichern...... 423 6.5 Zusammenfassung...... 426 6.6 Schneller Überblick...... 426 6.6.1 Zugriff auf das Dateisystem...... 426 6.6.2 Befehle des Betriebssystems ausführen...... 427 6.6.3 Den Zugriff sichern...... 427 6.7 Quellen...... 428 6.8 Häufig gestellte Fragen...... 428

7. Themen für Fortgeschrittene...... 431 7.1 Einführung...... 431 7.2 Eingabefilter umgehen...... 432 7.2.1 Groß- und Kleinschreibung...... 432 7.2.2 SQL-Kommentare...... 433 12 Inhaltsverzeichnis

7.2.3 URL-Codierung...... 434 7.2.4 Dynamische Ausführung von Abfragen...... 437 7.2.5 NULL-Bytes...... 438 7.2.6 Verschachtelung von Ausdrücken, die entfernt werden...... 439 7.2.7 Abschneiden von Zeichen ausnutzen...... 439 7.2.8 Anwendungseigene Filter umgehen...... 442 7.2.9 Nicht standardmäßige Eintrittspunkte...... 443 7.3 SQL-Injection zweiter Ordnung...... 445 7.3.1 Anfälligkeiten für SQL-Injection zweiter Ordnung finden...... 448 7.4 Clientseitige SQL-Injektion...... 451 7.4.1 Zugriff auf lokale Datenbanken...... 451 7.4.2 Clientseitige Datenbanken angreifen...... 452 7.5 Kombinierte Angriffe...... 454 7.5.1 Erbeutete Daten nutzen...... 454 7.5.2 Cross-Site Scripting...... 455 7.5.3 Betriebssystembefehle in Oracle ausführen...... 456 7.5.4 Schwachstellen in Bereichen für authentifizierte Benutzer ausnutzen...... 456 7.6 Zusammenfassung...... 458 7.7 Schneller Überblick...... 459 7.7.1 Eingabefilter umgehen...... 459 7.7.2 SQL-Injection zweiter Ordnung...... 459 7.7.3 Clientseitige SQL-Injektion...... 460 7.7.4 Kombinierte Angriffe...... 460 7.8 Häufig gestellte Fragen...... 461

8. Schutzmaßnahmen auf Codeebene...... 463 8.1 Einführung...... 463 8.2 Domain-Driven Security...... 464 8.3 Parametrisierte Anweisungen...... 470 Inhaltsverzeichnis 13

8.3.1 Parametrisierte Anweisungen in Java...... 471 8.3.2 Parametrisierte Anweisungen in .NET (C#)...... 473 8.3.3 Parametrisierte Anweisungen in PHP...... 475 8.3.4 Parametrisierte Anweisungen in PL/SQL...... 476 8.3.5 Parametrisierte Anweisungen in Mobilanwendungen...... 477 8.3.6 Parametrisierte Anweisungen in HTML5...... 478 8.4 Eingaben validieren...... 479 8.4.1 Whitelists...... 479 8.4.2 Blacklists...... 484 8.4.3 Eingabevalidierung in Java...... 485 8.4.4 Eingabevalidierung in .NET...... 486 8.4.5 Eingabevalidierung in PHP...... 487 8.4.6 Eingabevalidierung in Mobilanwendungen...... 488 8.4.7 Eingabevalidierung in HTML5...... 488 8.5 Ausgaben codieren...... 488 8.5.1 Codierung bei der Übermittlung an die Datenbank...... 489 8.5.2 NoSQL-Injection verhindern...... 498 8.6 Kanonisierung...... 499 8.6.1 Vorgehensweisen zur Kanonisierung...... 500 8.7 Designtechniken zur Vermeidung der Gefahren von SQL-Injektion...... 502 8.7.1 Gespeicherte Prozeduren verwenden...... 502 8.7.2 Abstraktionsschichten verwenden...... 504 8.7.3 Umgang mit sensiblen Daten...... 505 8.7.4 Offensichtliche Objektnamen vermeiden...... 506 8.7.5 Datenbank-Honeypots einrichten...... 507 8.7.6 Weitere Quellen zur sicheren Entwicklung...... 508 8.8 Zusammenfassung...... 509 8.9 Schneller Überblick...... 510 8.9.1 Domain-Driven Security...... 510 8.9.2 Parametrisierte Anweisungen...... 510 14 Inhaltsverzeichnis

8.9.3 Eingaben validieren...... 510 8.9.4 Ausgaben codieren...... 511 8.9.5 Kanonisierung...... 511 8.9.6 Designtechniken zur Vermeidung der Gefahren von SQL-Injektion...... 511 8.10 Häufig gestellte ragenF ...... 512

9. Schutzmaßnahmen auf Plattformebene...... 515 9.1 Einführung...... 515 9.2 Laufzeitschutz...... 516 9.2.1 Firewalls von Webanwendungen...... 517 9.2.2 Abfangfilter...... 524 9.2.3 Bearbeitbare und nicht bearbeitbare Eingaben...... 530 9.2.4 Strategien auf URL- und Seitenebene...... 531 9.2.5 Aspektorientierte Programmierung (AOP)...... 532 9.2.6 Intrusion-Detection-Systeme (IDS)...... 533 9.2.7 Datenbankfirewall...... 533 9.3 Die Datenbank absichern...... 534 9.3.1 Den Zugriff auf die Anwendungsdaten einschränken...... 534 9.3.2 Den Zugriff auf den Datenbankserver einschränken...... 540 9.4 Weitere Überlegungen zur Bereitstellung...... 543 9.4.1 Unnötige Informationen unterdrücken...... 543 9.4.2 Ausführlichere Webserverprotokolle...... 549 9.4.3 Den Web- und den Datenbankserver auf getrennten Computern unterbringen...... 549 9.4.4 Netzwerkzugriffssteuerung einrichten...... 550 9.5 Zusammenfassung...... 550 9.6 Schneller Überblick...... 551 9.6.1 Laufzeitschutz...... 551 9.6.2 Die Datenbank absichern...... 551 Inhaltsverzeichnis 15

9.6.3 Weitere Überlegungen zur Bereitstellung...... 551 9.7 Häufig gestellte ragenF ...... 552

10. SQL-Injektionsangriffe erkennen und sich von den Auswirkungen erholen...... 555 10.1 Einführung...... 555 10.2 Einen vermuteten SQL-Injektionsangriff untersuchen...... 556 10.2.1 Sinnvolle Ermittlungspraktiken...... 556 10.2.2 Digitale Artefakte analysieren...... 559 10.3 Was tun nach einem Angriff?...... 588 10.3.1 Die Auswirkungen eindämmen...... 588 10.3.2 Die betroffenen Daten ermitteln...... 589 10.3.3 Zuständige Personen informieren...... 590 10.3.4 Die Aktionen des Angreifers auf dem System ermitteln...... 591 10.3.5 Erholung von einem SQL-Injektionsangriff...... 593 10.4 Zusammenfassung...... 599 10.5 Schneller Überblick...... 599 10.5.1 Einen vermuteten SQL-Injektionsangriff untersuchen...... 599 10.5.2 Sinnvolle Ermittlungspraktiken...... 599 10.5.3 Digitale Artefakte analysieren...... 600 10.5.4 Durch SQL-Injektionsangriffe verursachte Aktivitäten erkennen...... 600 10.5.5 Das Vorliegen eines erfolgreichen Angriffs bestätigen...... 601 10.5.6 Die Auswirkungen eindämmen...... 601 10.5.7 Die betroffenen Daten ermitteln...... 601 10.5.8 Zuständige Personen informieren...... 601 10.5.9 Die Aktionen des Angreifers auf dem System ermitteln...... 601 10.5.10 Die Payload eines Angriffs bestimmen...... 602 10.5.11 Erholung von einem SQL-Injektionsangriff...... 602 10.6 Häufig gestellte ragenF ...... 602 16 Inhaltsverzeichnis

11. Referenz...... 605 11.1 Einführung...... 605 11.2 Grundlagen von SQL...... 606 11.2.1 SQL-Abfragen...... 606 11.2.2 Die Menge der Ergebnisse einschränken...... 612 11.3 Schnellreferenz zur SQL-Injection...... 613 11.3.1 Anfälligkeiten für SQL-Injection aufspüren...... 614 11.3.2 Die Datenbankplattform ermitteln...... 618 11.3.3 Spickzettel für Microsoft SQL Server...... 622 11.3.4 Spickzettel für MySQL...... 632 11.3.5 Spickzettel für Oracle...... 636 11.3.6 Spickzettel für PostgreSQL...... 642 11.4 Filter zur Eingabevalidierung umgehen...... 645 11.4.1 Filter für Anführungszeichen...... 645 11.4.2 HTTP-Codierung...... 647 11.5 Fehlerbehebung bei SQL-Injektionsangriffen...... 648 11.6 SQL-Injection auf anderen Plattformen...... 651 11.6.1 Spickzettel für DB2...... 651 11.6.2 Spickzettel für #...... 652 11.6.3 Spickzettel für Ingres...... 654 11.6.4 Spickzettel für Sybase...... 655 11.6.5 Microsoft Access...... 657 11.7 Literatur...... 657 11.7.1 Whitepaper zur SQL-Injection...... 657 11.7.2 Spickzettel zur SQL-Injection...... 657 11.7.3 SQL-Injektionswerkzeuge...... 658 11.7.4 Passwortknacker...... 659 11.8 Schneller Überblick...... 659 11.8.1 Grundlagen von SQL...... 659 Inhaltsverzeichnis 17

11.8.2 Schnellreferenz zur SQL-Injection...... 660 11.8.3 Filter zur Eingabevalidierung umgehen...... 660 11.8.4 Fehlerbehebung bei SQL-Injektionsangriffen...... 660 11.8.5 SQL-Injection auf anderen Plattformen...... 661

Justin möchte dieses Buch seiner Tochter Adena widmen, weil sie ihm ständig eine große Freude ist.

Dave möchte seiner wunderschönen Frau Nicole und seiner Tochter Rose, die ihn bei all seinen Unternehmungen unterstützen und inspirieren, seinen von Herzen kommenden Dank aussprechen.

Sumit »sid« Siddharth möchte seiner schönen Frau Supriya und seiner hinreißenden Tochter Shriya für ihre Unterstützung danken. Außerdem möchte er den Penetrationstestern bei 7Safe dafür danken, dass sie es mit ihm aushalten.

Alberto möchte allen Hackern auf der Welt danken, die den in diesem Buch beschriebenen Stoff erforscht und die erwähnten Tools geschrieben haben. Außerdem möchte er es der Franziskaner Weissbier-Brauerei in München widmen, ohne die sein Beitrag nicht möglich gewesen wäre.

21

Danksagung

Justin möchte der Redaktion von Syngress (und insbesondere Chris Katsoropoulous und ­Heather Scherer) dafür danken, dass sie erneut bereit war, ein Buch anzunehmen, an dem eine (für die Verlagsbranche) absurde Anzahl von Autoren beteiligt war. In seiner Rolle als leitender Katzenhüter möchte er auch den Mitgliedern seines Autorenteams dafür danken, dass sie alle an einem Strang gezogen haben, um das Projekt auf die Beine zu stellen.

23

Die Autoren der Beiträge

Rodrigo Marcos Alvarez (CREST-Berater, MSc, BSc, CISSP, CNNA, OPST, MCP) ist technischer Direktor von SECFORCE, einer führenden Beratungsfirma für Penetrationstests. Neben der Führung seines technischen Teams hat Rodrigo Spaß daran, sich selbst an Sicherheitsüberprü- fungen zu beteiligen und sich die Hände schmutzig zu machen, indem er Tools schreibt und an interessanten neuen Hackingtechniken arbeitet.

Rodrigo ist Mitarbeiter des OWASP-Projekts und Sicherheitsforscher. Sein besonderes Interesse gilt der Netzwerkprotokollanalyse durch Fuzzing-Tests. Neben anderen Projekten hat er TAOF, einen protokollunabhängigen GUI-Fuzzer, und Proxyfuzz veröffentlicht, einen TCP/UDP- Proxy, der Netzwerkdatenverkehr im laufenden Verkehr einem Fuzzing-Test unterzieht. Weitere seiner Beiträge zum Gebiet der Websicherheit sind Bsishell, eine interaktive Python-Shell zur blinden SQL-Injektion, und die Entwicklung eines TCP-Sockets unter Wiederverwendung von Angriffstechniken.

Kevvie Fowler (GCFA Gold, CISSP, MCTS, MCDBA, MCSD, MCSE) leitet die TELUS Security Intelligence Analysis, wo er anspruchsvolle Ereignisanalyse und vorausschauende Aufklärung bietet, um Kunden vor aktuellen und neu aufkommenden Gefahren zu schützen.

Darüber hinaus ist er Gründer und Hauptberater von Ringzero, einer Firma für Sicherheits- forschung und Forensik. Der Schwerpunkt seiner aktuellen Forschungen liegt auf Datenbank- forensik, Rootkits und Mängeln in der nativen Verschlüsselung. Seine Ergebnisse stellt er auf Branchenkonferenzen wie Black Hat, SecTor und OWASP AppSec Asia vor.

Kevvie ist Autor von SQL Server Forensic Analysis und hat an weiteren Büchern über Informati- onssicherheit und Forensik mitgewirkt. Als anerkannter SANS-Forensikexperte und Mitglied des GIAC-Beratungsausschusses ist er daran beteiligt, die Richtung neuer Sicherheits- und Forensikforschungen zu bestimmen. Kevvie dient als vertrauenswürdiger Berater für Kunden aus dem öffentlichen und dem privaten Sektor. Seine Rolle als Vordenker wurde schon in In- formation Security Magazine, Dark Reading und Kaspersky Threatpost herausgestellt.

Dave Hartley ist leitender Sicherheitsberater von MWR InfoSecurity und zertifizierter CHECK- und CREST-Berater (Anwendung und Infrastruktur). Die Firma MWR InfoSecurity unter- stützt ihre Kunden dabei, Risiken für die Informationssicherheit zu erkennen, handzuhaben und abzuschwächen.

Dave hat schon viele unterschiedliche Sicherheitsüberprüfungen durchgeführt und bietet eine Unzahl von Beratungsdienstleistungen für Kunden aus verschiedensten Bereichen, darunter Finanzinstitute, Unternehmen aus den Branchen Unterhaltung, Medien, Telekommunikation und Softwareentwicklung sowie Behörden aus aller Welt. 24 Die Autoren der Beiträge

Des Weiteren ist Dave Mitglied der Beratungsgremien für CREST-Gutachter und NBISE, wo er Untersuchungen beaufsichtigt und gemeinsam mit anderen neue CREST-Untersuchungs- module entwickelt. CREST ist eine an Standards orientierte Organisation für Anbieter von Pe- netrationstests, die ein technisches Best-Practices-Zertifizierungsprogramm für Berater durch- führt. Außerdem war Dave daran beteiligt, zusammen mit NBISE einen für die USA ausgelegten Untersuchungsprozess zu entwickeln.

Dave arbeitet seit 1998 in der IT-Branche und hat Erfahrungen auf verschiedenen Gebieten der IT-Sicherheit gesammelt. Er ist als Autor tätig und leistet regelmäßig Beiträge zu vielen Magazi- nen über Informationssicherheit. Außerdem hat er das SQL-Injektionstool Bobcat geschrieben.

Alexander Kornbrust ist Gründer des Unternehmens Red--Security,­ das sich auf Da- tenbanksicherheit spezialisiert hat. Er bietet Audits zur Datenbanksicherheit, Sicherheitsschulung und Beratung für Kunden in aller Welt an. Des Weiteren war er an der Gestaltung und Ent- wicklung von ­McAfee Security Scanner for beteiligt, dem führenden Werkzeug für Datenbanksicherheit. Mit Oracle-Produkten arbeitet er seit 1992. Seine Spezialgebiete sind die Sicherheit von Oracle-Datenbanken und Architekturen. Er hat mehr als 1200 Sicherheitsmängel in Oracle gemeldet und hat an der Universität Passau seinen Abschluss als Diplom-Informatiker gemacht.

Erlend Oftedal arbeitet als Berater bei der Bekk Consulting AS in Oslo, wo er schon seit einigen Jahren die Sicherheitskompetenzgruppe leitet. Seine Zeit verbringt er als Sicherheitsberater und Entwickler für die Kunden von Bekk. Außerdem führt er Codeüberprüfungen und Sicherheits- tests durch.

Sowohl auf Softwareentwicklungs- als auch auf Sicherheitskonferenzen wie Javazone und OWASP AppSec Europa sowie in Usergroups und Universitäten in Norwegen und im Ausland hat er Reden über Webanwendungs­sicherheit gehalten. Als Sicherheitsforscher ist er stark für die norwegische Abteilung von OWASP engagiert. Außerdem ist er Mitglied des Norwegian Honeynet Project.

Erlend hat einen Mastergrad in Informatik von der Technisch-Naturwissenschaftlichen Univer- sität Norwegen (NTNU).

Gary O'Leary-Steele (CREST-Berater) ist technischer Direktor der Sec-1 Ltd. in Großbritanni- en. Zurzeit ist er leitender Penetrationstester und Sicherheitsberater für eine Vielzahl von Kun- den, darunter einige große Onlinehändler und Finanzorganisationen. Seine Spezialgebiete sind Sicherheitsüberprüfungen von Webanwendungen, Netzwerkpenetrationstests und Schwach- stellenforschung. Außerdem ist Gary Chefautor und Ausbilder des Sec-1-Schulungsprogramms CNSP (Certified Network Security Professional), das bereits mehr als 3000 Teilnehmer absol- viert haben. Microsoft, RSA, GFI, Splunk, IBM und Marshal Software haben Gary ihre Aner- kennung für die Entdeckung von Sicherheitsmängeln in ihren kommerziellen Anwendungen ausgesprochen. Die Autoren der Beiträge 25

Alberto Revelli ist Sicherheitsforscher und Urheber von Sqlninja, einem Open-Source-Toolkit, das zu einer beliebten Waffe für SQL-Injection in Webanwendungen mit Microsoft SQL Server geworden ist. Im Brotberuf arbeitet er für ein großes Handelsunternehmen, wo er meistens alles kaputt macht, was seine Neugier weckt, und es anschließend repariert.

In seiner Karriere hat er schon vielen Unternehmen geholfen, darunter großen Finanzinsti- tuten, Telekommunikationsanbietern, Medien- und Produktionsfirmen. Als Redner ist er zu mehreren Sicherheitskonferenzen wie EuSecWest, SOURCE, RSA, CONFidence, Shakacon ­und AthCon eingeladen worden.

Er lebt in London, wo er zusammen mit seiner Freundin das scheußliche Wetter und das ver- rückte Nachtleben genießt.

Sumit »sid« Siddharth arbeitet als Leiter der Abteilung für Penetrationstests bei der 7Safe Li- mited in Großbritannien, wo er sich auf Anwendungs- und Datenbanksicherheit spezialisiert hat und mehr als sechs Jahre Erfahrung mit Penetrationstests einbringt. Er hat eine Reihe von Whitepapers und Tools geschrieben und war als Redner bzw. Schulungsleiter an vielen Sicher- heitskonferenzen wie Black Hat, DEFCON, Troopers, OWASP AppSEc, ­Sec-T usw. beteiligt. Außerdem führt er den beliebten IT-Sicherheitsblog www.notsosecure.com.

Marco Slaviero ist Mitarbeiter bei SensePost, wo er die SensePost Labs leitet (derzeitige Be- legschaft: 1,5). Auf Branchenkonferenzen wie BlackHat USA und DefCon hat er Reden über verschiedene Sicherheitsthemen gehalten, darunter auch über SQL-Injection. Sein Fachgebiet sind Anwendungstests, wobei er sich auch für Netzwerke interessiert. Er ist als leitender Berater für Kunden auf vier Kontinenten tätig.

Marco lebt zusammen mit seiner wundervollen Frau Juliette.

Vor einigen Jahren hat Marco einen Mastergrad von der Universität von Pretoria erhalten, aber das ist jetzt Vergangenheit. Feigen hasst er immer noch.

Dafydd Stuttard ist unabhängiger Sicherheitsberater, Autor und Softwareentwickler mit dem Spezialgebiet Penetrationstests von Webanwendungen und kompilierter Software. Er ist Autor des Bestsellers Web Application Hacker's Handbook. Unter dem Pseudonym PortSwigger hat er die beliebte Burp Suite geschrieben, eine Sammlung von Tools zum Hacking von Webanwen- dungen. Dafydd hat auch Schulungskurse entwickelt und auf Sicherheitskonferenzen und bei anderen Gelegenheiten in aller Welt abgehalten. Er hat einen Master- und einen Doktorgrad in Philosophie von der Universität Oxford. 26 Chefautor und Fachgutachter

Chefautor und Fachgutachter

Justin Clarke ist Mitbegründer und Direktor von Gotham Digital Science, einer Beratungsfir- ma für Informationssicherheit, die mit ihren Kunden zusammenarbeitet, um Sicherheitsrisiken zu erkennen, zu verhindern und zu handhaben. Er hat mehr als 15 Jahre Erfahrung mit Sicher- heitstests von Netzwerken und Software für große Finanz-, Einzelhandels- und Technologieun- ternehmen in den USA, Großbritannien und Neuseeland.

Darüber hinaus hat Justin als Coautor zu einer Reihe von Computersicherheitsbüchern beige- tragen und ist als Redner bei vielen Konferenzen und Veranstaltungen zu Sicherheitsthemen aufgetreten, darunter Black Hat, ­EuSecWest, OSCON, ISACA, RSA, SANS, OWASP und der British Computer Society. Er ist Autor des Open-Source-Tools SQLBrute für blinde SQL-In- jection und Leiter der Londoner OWASP-Abteilung.

Justin hat einen Bachelorgrad in Informatik von der University of Canterbury in Neuseeland und Diplome in strategischem Personalmanagement und Buchhaltung. Was sich davon als praktischer erwiesen hat, kann er immer noch nicht sagen. 1

Was ist SQL-Injection?

Dave Hartley

1.1 Einführung

Viele Menschen, die behaupten, sie wüssten, was SQL-Injection sei, haben in Wirklichkeit nur einige triviale Beispiele kennengelernt. SQL-Injection ist eine der verheerendsten Angriffstech- niken, die ein Unternehmen treffen können. Sie kann zur Offenlegung der sensiblen Informati- onen führen, die in den Datenbanken einer Anwendung gespeichert sind, darunter so brauch- bare Informationen wie Benutzernamen, Passwörter, Namen, Adressen, Telefonnummern­ und Kreditkartenangaben.

Was aber ist SQL-Injection genau? Es handelt sich um eine Angriffstechnik, bei der ein Angreifer SQL-Anfragen (Structured Query Language) manipuliert, die eine Anwendung an ihre Back- End-Datenbank übergibt. Dabei nutzt der Angreifer die Syntax und die Möglichkeiten von SQL sowie die Leistungsfähigkeit und Flexibilität aus, die die unterstützende Datenbank und das Betriebssystem bieten. Nicht nur Webanwendungen sind anfällig für SQL-Injection. Jeglicher Code, der Eingaben aus nicht vertrauenswürdigen Quellen annimmt und daraus dynamische SQL-Anweisungen gestaltet, ist angreifbar (beispielsweise auch »Fat-Client-Anwendungen« in 28 1 Was ist SQL-Injection?

Client/Server-Architekturen). Früher wurde SQL-Injection hauptsächlich gegen serverseitige Datenbanken eingesetzt, doch angesichts der jetzigen HTML5-Spezifikation können Angreifer genauso gut auch JavaScript oder anderen Code ausführen, und damit auf clientseitige Da- tenbanken zugreifen und von dort Daten stehlen. Auch bei Mobilanwendungen (z. B. auf der ­Android-Plattform) können Schadanwendungen und clientseitige Skripte auf ähnliche Weise eingesetzt werden (siehe labs.mwrinfosecurity.com/notices/webcontentresolver/­ ).

SQL-Injection gibt es wahrscheinlich schon, seit zum ersten Mal SQL-­Datenbanken mit Web- anwendungen verbunden wurden. Meistens wird die Ent­deckung jedoch Rain Forest Puppy zugeschrieben. Zumindest war er es, der das Problem an die Öffentlichkeit brachte. Weih- nachten 1998 schrieb er in Phrack, einem E-Zine von und für Hacker, den Artikel »NT Web Technology Vulnerabilities« (www.phrack.com/issues.html?issue=54&id=8#article). Außerdem veröffentlichte er Anfang 2001 einen Ratgeber über SQL-Injection (»How I hacked Packet- Storm« auf www.wiretrip.net/rfp/txt/rfp2k01.txt), in dem er ausführlich beschrieb, wie mithilfe von SQL-Injection eine populäre Website angegriffen wurde. Seitdem haben viele Forscher Techniken zur Ausnutzung der entsprechenden Schwachstellen entwickelt und verfeinert. Den- noch wird das Problem bis heute von vielen Entwicklern und Sicherheitsexperten nicht richtig verstanden.

In diesem Kapitel sehen wir uns die Gründe für die Schwachstellen an, die eine SQL-Injection ermöglichen. Als Erstes sehen wir uns an, wie Webanwendungen gewöhnlich aufgebaut sind, um den Zusammenhang zu klären, in dem SQL-Injection auftritt. Danach beschäftigen wir uns damit, was im Code einer Anwendung zu Anfälligkeiten für SQL-Injection führt und wie Entwicklungspraktiken und Verhaltensweisen dazu beitragen.

1.2 Wie funktionieren Webanwendungen?

Die meisten von uns nutzen täglich Webanwendungen, entweder in der Ausübung unseres Berufs oder um auf unsere E-Mails zurückzugreifen, Reisen zu buchen, bei Onlinehändlern einzukaufen oder Newsbeiträge zu lesen usw. Es gibt Webanwendungen aller Art.

Unabhängig von der Sprache, in der sie geschrieben sind, haben Webanwendungen jedoch eines gemeinsam: Sie sind interaktiv und stützen sich meistens auf eine Datenbank. In der heutigen vernetzten Welt sind datenbankgestützte Webanwendungen gang und gäbe. Normalerweise be- stehen sie aus einer Back-End-Datenbank und Webseiten. Letztere enthalten serverseitige Skrip- te in einer Programmiersprache, die in der Lage ist, aufgrund der dynamischen Interaktion mit den Benutzern gezielt Informationen aus der Datenbank abzurufen. Einer der gebräuchlichsten Verwendungs­zwecke für datenbankgestützte Webanwendungen sind E-Commerce-Websites, bei denen eine Vielzahl von Informationen in einer Datenbank gespeichert sind, z. B. Produktin- formationen, Warenbestände, Preise, Porto- und Verpackungskosten usw. Wahrscheinlich sind Sie mit dieser Art von Anwendung, mit der Sie Produkte bei Onlinehändlern beziehen, vertraut. Eine datenbankgestützte Webanwendung besteht gewöhnlich aus drei Schichten: einer Präsenta- 1.2 Wie funktionieren Webanwendungen? 29

tionsschicht (ein Webbrowser oder Rendering-Engine), einer logischen Schicht (eine Program- miersprache wie C#, ASP, .NET, PHP, JSP o. Ä.) und einer Speicherschicht (ein Datenbanksystem wie Microsoft SQL Server, MySQL, Oracle o. Ä.). Der Webbrowser (die Präsentationsschicht, z. B. Internet Explorer, Safari, Firefox) sendet Anforderungen an die mittlere Schicht (die Lo- gikschicht), die diese Anforderungen bedient, indem sie die Datenbank (die Speicherschicht) abfragt oder aktualisiert.

Betrachten Sie als Beispiel einen Onlinehändler. Das Suchformular, das er anzeigt, ermöglicht es den Kunden, in den Produkten zu stöbern, gezielt nach bestimmten Produkten zu suchen und die Auswahl noch weiter zu verfeinern, beispielsweise nach Preis. Um beispielsweise alle Produk- te dieses Anbieters einzusehen, die weniger als 100 $ kosten, können wir folgenden URL angeben:

http://www.victim.com/products.php?val=100

Das folgende PHP-Skript zeigt, wie die Benutzereingabe (val) an eine ­dynamisch erstellte SQL- Anweisung übergeben wird. Bei der Anforderung des URLs wird der folgende Abschnitt des PHP-Codes ausgeführt:

// Stellt Verbindung mit der Datenbank her $conn = mysql_connect("localhost","username","password"); // Baut die SQL-Anweisung dynamisch aus den Eingaben auf $query = "SELECT * FROM Products WHERE Price < '$_GET["val"]' " . "ORDER BY ProductDescription"; // Führt die Abfrage an der Datenbank aus $result = mysql_query($query); // Durchläuft die Menge der Datensätze while($row = mysql_fetch_array($result, MYSQL_ASSOC)) { // Zeigt die Ergebnisse im Browser an echo "Description : {$row['ProductDescription']}
". "Product ID : {$row['ProductID']}
". "Price : {$row['Price']}

"; }

Die SQL-Anweisung, die das PHP-Skript zusammenstellt und ausführt, sehen­ Sie im folgenden Codebeispiel. Diese Anweidung gibt alle Produkte in der Datenbank zurück, die weniger als 100 $ kosten. Diese Produktauswahl wird im Webbrowser angezeigt, dass die Kunden den Einkauf im Rahmen ihres Budgets fortsetzen können. Im Prinzip funktionieren alle datenbankgestütz- ten Webanwendungen so oder ähnlich.

SELECT * FROM Products WHERE Price <'100.00' ORDER BY ProductDescription; 30 1 Was ist SQL-Injection?

1.2.1 Eine einfache Anwendungsarchitektur

Wie bereits erwähnt, bestehen datenbankgestützte Webanwendungen gewöhnlich aus drei Schichten, der Präsentations-, der Logik- und der Speicherschicht. Abbildung 1.1 zeigt ein ein- faches Beispiel für diese Schichtung, um deutlich zu machen, wie Webtechnologien zusammen- wirken, um die vertraute Webumgebung mit ihrem großen Funktionsumfang zu bilden.

Die oberste Ebene der Anwendung ist die Präsentationsschicht. Sie zeigt die üblichen Informa- tionen zu Diensten wie der Suche in Produkten, dem Kauf oder dem Einkaufswagen an. Zur Kommunikation mit anderen Schichten gibt sie Ergebnisse an die Browser/Client-Schicht und alle anderen Schichten im Netzwerk aus. Davon zu unterscheiden ist die Logikschicht. Als eine eigene Schicht steuert sie die Funktionen der Anwendung, indem sie die eigentliche Verarbei- tung durchführt. Die Datenschicht wiederum besteht aus den Datenbankservern. Hier werden die Informationen gespeichert und abgerufen. Die Daten in dieser Schicht sind von den Anwen- dungsservern und der Geschäftslogik getrennt. Die Verwendung einer eigenen Schicht für die Daten verbessert auch die Skalierbarkeit und Leistung. In Abbildung 1.1 sendet der Webbrowser (Präsentation) Anforderungen an die mittlere Schicht (Logik), die darauf reagiert, indem sie Abfragen und Aktualisierungen an der Datenbank (Speicherung) vornimmt. Als eine grund- legende Regel in einer dreischichtigen Architektur kommuniziert die Präsentationsschicht nie- mals direkt mit der Datenschicht. Die gesamte Kommunikation muss über die mittlere Schicht erfolgen. Die dreischichtige Architektur ist prinzipiell linear aufgebaut.

Präsentationsschicht Logikschicht Speicherung index.asp laden, kompilieren http://www.victim.com und ausführen abrufen Skript- SQL ausführen Engine

RDBMS

Skripte Daten zurückgeben

HTML darstellen Sendet HTML

Webbrowser/Render-Engine Programmiersprachen: C#, ASP, Datenbanken: MS SQL, .NET, PHP, JSP usw. MySQL, Oracle usw. Abbildung 1.1: Einfache dreischichtige Architektur

In Abbildung 1.1 startet der Benutzer seinen Webbrowser und stellt eine Verbindung mit http:// www.victim.com her. Der Webserver in der Logikschicht lädt das Skript aus dem Dateisystem und übergibt es an seine Skript-Engine, wo es analysiert und ausgeführt wird. Das Skript baut mithilfe eines Datenbankkonnektors eine Verbindung mit der Speicherschicht auf und führt eine SQL-Anweisung an der Datenbank aus. Die Datenbank wiederum gibt die Daten an den Konnektor zurück, der dann an die Skript-Engine in der Logikschicht übergeben wird. Die Lo- gikschicht wiederum wendet eventuell vorhandene Regeln der Anwendungs- oder Geschäftslo- gik an, bevor sie schließlich eine Webseite im HTML-Format an den Webbrowser des Benutzers 1.2 Wie funktionieren Webanwendungen? 31

in der Präsentationsschicht zurückgibt. Der Browser stellt das HTML dar und präsentiert dem Benutzer eine grafische Darstellung des Codes. All dies geschieht in Sekunden und für den Be- nutzer unsichtbar.

1.2.2 Eine kompliziertere Architektur

Dreischichtige Lösungen sind nicht skalierbar, weshalb dieses Modell in den letzten Jahren überdacht und ein neues Konzept eingeführt wurde, bei dem der Schwerpunkt auf Skalier- barkeit und Wartungsfreundlichkeit liegt: das Entwicklungsprinzip n-schichtiger Anwendun- gen. In diesem Rahmen wurde eine vierschichtige Lösung entworfen, bei der eine Middleware, meistens ein so genannter Anwendungsserver, zwischen Webserver und Datenbank geschaltet ist. Anwendungsserver in n-schichtigen Architekturen beherbergen eine Anwendungsprogram- mierschnittstelle (Application Programming Interface, API), um die Geschäftslogik und die Geschäftsprozesse für die Verwendung durch Anwendungen offenzulegen. Zusätzliche Webser- ver können nach Bedarf hinzugefügt werden. Außerdem kann der Anwendungsserver mit ver- schiedenen Datenquellen kommunizieren, z. B. mit Datenbanken, Mainframecomputern und anderen veralteten Sytemen.

Abbildung 1.2 zeigt eine einfache vierschichtige Architektur. Hier sendet der Webbrowser (Prä- sentation) eine Anforderung an die mittlere Schicht (Logik), die wiederum die offengelegten des Anwendungsservers in der Anwendungsschicht aufruft. Diese APIs reagieren auf die Anforderungen, indem sie Abfragen und Aktualisierungen an der Datenbank (Speicherung) ausführen.

In Abbildung 1.2 startet der Benutzer seinen Webbrowser und stellt eine Verbindung mit http:// www.victim.com her. Der Webserver in der Logikschicht lädt das Skript aus dem Dateisystem und übergibt es an seine Skript-Engine, wo es analysiert und ausgeführt wird. Das Skript ruft eine offengelegte API des Anwendungsservers in der Anwendungsschicht auf. Dieser Server baut mithilfe eines Datenbankkonnektors eine Verbindung mit der Speicherschicht auf und führt eine SQL-Anweisung an der Datenbank aus. Die Datenbank wiederum gibt die Daten an den Konnektor zurück. Der Anwendungsserver wendet eventuell vorhandene Regeln der An- wendungs- oder Geschäftslogik an, bevor er die Daten an den Webserver zurückgibt. Der Web- server führt ggf. eine abschließende Logik aus und übergibt die Daten dann im HTML-Format an den Webbrowser des Benutzers in der Präsentationsschicht. Der Browser stellt das HTML dar und präsentiert dem Benutzer eine grafische Darstellung des Codes. All dies geschieht in Sekunden und für den Benutzer unsichtbar.

Das Grundprinzip geschichteter Architekturen besteht darin, eine Anwendung in logische Abschnitte oder Schichten zu zerlegen, denen allgemeine oder besondere Rollen zugewiesen werden. Die Schichten können dabei auf mehrere Computer verteilt oder auf ein und demsel- ben Rechner untergebracht werden, wobei sie jedoch praktisch oder prinzipiell voneinander getrennt sind. Je mehr Schichten Sie verwenden, umso spezifischer sind die Aufgaben der ein- 32 1 Was ist SQL-Injection?

zelnen Schichten. Die Aufteilung der Aufgaben einer Anwendung auf mehrere Schichten ver- einfacht die Skalierung, erlaubt eine bessere Verteilung der Entwicklungsaufgaben auf mehrere Entwickler, macht die Anwendung leichter lesbar und fördert die Wiederverwendbarkeit ihrer Bestandteile. Durch diese Vorgehensweise werden auch kritische Fehlerpunkte ausgeschlossen, was die Anwendung robuster macht. Wird beispielsweise entschieden, den Datenbankanbieter zu wechseln, ist dazu nicht mehr nötig, als einige Änderungen in den entsprechenden Teilen der Anwendungsschicht vorzunehmen. Präsentations- und Logikschicht bleiben davon unberührt. Im Internet werden heutzutage am meisten drei- und vierschichtige Architekturen verwendet. Das n-schichtige Modell ist jedoch äußerst flexibel und ermöglicht es, viele Schichten und Ebe- nen logisch zu trennen und auf unzählige Art und Weise einzurichten.

Präsentationsschicht Logikschicht Anwendungsschicht Speicherung index.asp laden, kompilieren Interagiert mit dem Datenspeicher http://www.victim.com SQL ausführen und ausführen und setzt Anwendungs- und abrufen Skript- Geschäftslogik durch Engine

RDBMS

Skripte

HTML darstellen Sendet HTML Übergibt Daten an Webserver Daten zurückgeben

Webbrowser/ Programmiersprachen: C#, ASP, CFC-, EJB-, SOAP-, RMI- Datenbanken: MS SQL, Render-Engine .NET, PHP, JSP usw. Webdienst usw. MySQL, Oracle usw.

Abbildung 1.2: Einfache vierschichtige Architektur

1.3 Wie funktioniert SQL-Injection?

Webanwendungen werden immer anspruchsvoller und technisch komplizierter. Die Skala reicht von dynamischen Internet- und Intranetportalen wie E-Commerce-Websites und Partner-­ Extranets zu HTTP-Unternehmensanwendungen wie Dokumentmanagementsystemen und ERP-Anwendungen. Die Verfügbarkeit dieser Systeme und die Sensibilität der darin ­gespeicherten und verarbeiteten Daten ist für fast alle größeren Unternehmen von entscheidender Bedeutung, nicht nur für Firmen mit Online-Stores. Webanwendungen und die Infrastrukturen und Um- gebungen zu ihrer Unterstützung nutzen diverse Technologien und können erhebliche Mengen an verändertem und angepasstem Code enthalten. Die Natur dieser funktionsreichen Designs und ihre Möglichkeit, Informationen über das Internet oder in einem Intranet zu erfassen, zu verarbeiten und zu verbreiten, machen sie zu beliebten Zielen für Angreifer. Außerdem sind ­Sicherheitstechnologien für Netzwerke ausgereift, weshalb es weniger Gelegenheiten gibt, Netz- werkschwachstellen auszunutzen, um in Informationssysteme einzubrechen. Hacker richten ihre Aufmerksamkeit jetzt daher verstärkt darauf, Anwendungen anzugreifen.

Bei der SQL-Injection wird SQL-Code in Anwendungs- oder Benutzereingabeparameter einge- fügt oder daran angehängt, die zur Ausführung an den SQL-Back-End-Server übergeben wer- 1.3 Wie funktioniert SQL-Injection? 33

den. Jegliche Prozeduren, die SQL-Anweisungen zusammenstellen, sind prinzipiell anfällig für einen solchen Angriff, da die Vielfalt von SQL und der Methoden zur Konstruktion von SQL- Anweisungen reichhaltige Gelegenheit zur Programmierung gibt. Die Hauptform der SQL-In- jection besteht darin, Code direkt in die Parameter einzufügen, die mit SQL-Befehlen verkettet und ausgeführt werden. Bei einer weniger unmittelbaren Vorgehensweise wird Schadcode in Strings eingebaut, die zur Speicherung in einer Tabelle oder als Metadaten vorgesehen sind. Werden diese gespeicherten Strings später zu dynamischen SQL-Befehlen verkettet, so wird der Schadcode ausgeführt. Wenn eine Webanwendung die ihr übergebenen Parameter nicht ordentlich bereinigt (selbst bei der Verwendung von Parametrisierungstechniken), dann kann ein Angreifer die Zusammenstellung der SQL-Anweisungen für das Back-End manipulieren. Diese Anweisungen werden dann mit den Rechten ausgeführt, die der Benutzer der Anwen- dung hat. Befehle, die mit dem Betriebssystem interagieren, laufen mit den Berechtigungen der Komponenten, die die Befehle ausführen (also z. B. mit den Berechtigungen des Datenbank-, des Anwendungs- oder des Webservers). Diese Berechtigungen können sehr hoch sein.

Um dies zu veranschaulichen, sehen wir uns wieder unser Beispiel des Onlinehändlers an. Um alle Produkte einzusehen, die weniger als 100 $ kosten, konnten wir bekanntlich folgenden URL verwenden:

http://www.victim.com/products.php?val=100

Der Anschaulichkeit halber werden in den URL-Beispielen in diesem Kapitel GET- statt POST-­ Parameter verwendet. POST-Parameter lassen sich genauso einfach verändern, allerdings muss dazu ein zusätzliches Instrument eingesetzt werden, z. B. ein Tool zur Manipulation des Daten- verkehrs, ein Webbrowser-Plug-In oder eine Inline-Proxyanwendung.

Hier versuchen wir jedoch, unsere SQL-Befehle einzufügen, indem wir sie an den Eingabepa- rameter val anhängen. Das können Sie einfach dadurch tun, dass Sie den URL um den String ' OR '1'='1 ergänzen.

http://www.victim.com/products.php?val=100' OR '1'='1

Die SQL-Anweisung, die das PHP-Skript diesmal zusammenstellt und ausführt, gibt sämtliche Produkte in der Datenbank unabhängig von ihrem Preis zurück. Das liegt daran, dass Sie die Logik der Abfrage verändert haben: Die zweite mit OR angehängte Aussage ist immer wahr, da 1 schließlich immer gleich 1 ist. Die zusammengestellte und ausgeführte Abfrage sieht wie folgt aus:

SELECT * FROM ProductsTbl WHERE Price < '100.00' OR '1' = '1' ORDER BY ProductDescription; 34 1 Was ist SQL-Injection?

Es gibt viele Möglichkeiten, wie sich Schwachstellen gegenüber SQL-Injektionsangriffen ausnut- zen lassen, um eine breite Palette von Zielen zu erreichen. Ob der Angriff Erfolg hat, hängt zum größten Teil von der Datenbank und den miteinander verbundenen Systemen ab. Manchmal kann es sehr viel Können und Ausdauer erfordern, eine Schwachstelle vollständig auszunutzen.

Das vorstehende kleine Beispiel hat gezeigt, wie ein Angreifer eine dynamisch aus nicht validier- ten oder codierten Eingaben zusammengestellte SQL-Anweisung gestalten kann, um Aktionen auszuführen, die die Entwickler der Anwendung weder beabsichtigt noch vorausgesehen ha- ben. Wie effektiv ein solcher Angriff sein kann, wurde in diesem Beispiel jedoch nicht deutlich. Schließlich haben wir die Schwachstelle nur ausgenutzt, um uns alle Produkte in der Datenbank anzusehen, und das hätten wir auch ganz legal mit den dafür vorgesehenen Funktionen der An- wendung tun können. Nehmen wir jetzt aber an, dass die Anwendung über ein CMS (Content Management System) über das Netzwerk verwaltet werden kann. Ein CMS ist eine Webanwen- dung, mit der sich Inhalte einer Website ohne HMTL-Kenntnisse erstellen, bearbeiten, verwal- ten und veröffentlichen lassen. Um auf das CMS für unsere Beispielwebsite zuzugreifen, müssen Sie einen URL wie den folgenden eingeben:

http://www.victim.com/cms/login.php?username=foo&password=bar

Um auf die Funktionen der CMS-Anwendung zugreifen zu können, müssen Sie einen gültigen Benutzernamen und ein Kennwort angeben. Wenn Sie den vorstehenden URL eingeben, er- halten Sie allerdings die Fehlermeldung: »Falscher Benutzername oder falsches Passwort. Bitte versuchen Sie es erneut.« Der Code für das Skript login.php sieht wie folgt aus:

// Stellt die Verbindung zur Datenbank her $conn = mysql_connect("localhost","username","password"); // Stellt aus den Einhaben dynamisch die SQL-Anweisung zusammen $query = "SELECT userid FROM CMSUsers WHERE user = '$_GET["user"]' " . "AND password = '$_GET["password"]'"; // Führt die Abfrage an der Datenbank aus $result = mysql_query($query); // Prüft, wie viele Zeilen die Datenbank zurückgegeben hat $rowcount = mysql_num_rows($result); // Wird eine Zeile zurückgegeben, müssen die Anmeldeinformationen gültig // sein, weshalb der Benutzer zu den admin-Seiten weitergeleitet wird if ($rowcount ! = 0){header("Location: admin.php");} // Wird keine Zeile zurückgegeben, sind die Anmeldeinformationen falsch else {die('Incorrect username or password, please try again.')}

Das Skript login.php stellt dynamisch eine SQL-Anweisung zusammen und gibt einen Datensatz zurück, wenn ein Benutzername und ein zugehöriges Passwort eingegeben wurden. In dem folgenden Codeausschnitt ist diese SQL-Anweisung genauer zu erkennen. Die Abfrage gibt die ID des Benutzers (userid) zurück, wenn die für user und password eingegebenen Werte einem gespeicherten Wert in der Tabelle CMSUsers entsprechen: 1.3 Wie funktioniert SQL-Injection? 35

SELECT userid FROM CMSUsers WHERE user = 'foo' AND password = 'bar';

Das Problem bei diesem Code besteht darin, dass der Entwickler der Ansicht war, die Anzahl der zurückgegebenen Datensätze sei zwangsläufig entweder null oder eins. In dem vorherigen Injektionsbeispiel haben wir eine Schwachstelle ausgenutzt, die es erlaubt, die Bedeutung der SQL-Abfrage zu ändern, sodass sie stets true zurückgibt. Dieselbe Technik können wir auch bei der CMS-Anwendung einsetzen und damit die Anwendungslogik aushebeln. Durch Anhängen des Strings 'OR '1'='1 im folgenden URL gibt die SQL-Anweisung, die das PHP-Skript zusam- menstellt und ausführt, die userids sämtlicher Benutzer in der Tabelle CMSUsers zurück:

http://www.victim.com/cms/login.php?username=foo&password=bar' OR '1'='1

Sämtliche Benutzer-IDs werden zurückgegeben, da wir die Logik der Abfrage geändert haben. Die zweite mit OR angehängte Aussage ist immer wahr, da 1 schließlich immer gleich 1 ist. Die zusammengestellte und ausgeführte Abfrage sieht wie folgt aus:

SELECT userid FROM CMSUsers WHERE user = 'foo' AND password = 'password' OR '1' = '1';

Die Logik der Anwendung besagt, dass die Anmeldeinformationen richtig gewesen sein müs- sen, wenn die Datenbank mehr als null Datensätze zurückgibt, weshalb wir zu dem geschütz- ten Skript admin.php weitergeleitet werden und Zugriff darauf bekommen sollen. Wir würden dann als der erste Benutzer angemeldet, der in der Tabelle CMSUsers aufgeführt ist. Eine Anfäl- ligkeit für SQL-Injection hat es uns erlaubt, die Anwendungslogik zu unterlaufen.

Versuchen Sie nicht, diese Beispiele bei fremden Webanwendungen oder Systemen auszupro- bieren, sofern Sie dazu nicht die ausdrückliche Erlaubnis (vorzugsweise in schriftlicher Form) des Besitzers haben. In den Vereinigten Staaten können Sie dafür nach dem »Computer Fraud and Abuse Act« von 1986 (www.cio.energy.gov/documents/ComputerFraud-AbuseAct.pdf) oder dem »USA Patriot Act« von 2001 strafrechtlich verfolgt werden. In Großbritannien kommen das »Computer Misuse Act« von 1990 (www.opsi.gov.uk/acts/acts1990/Ukpga_19900018_ en_1) und das »Police and Justice Act« von 2006 (www.opsi.gov.uk/Acts/ acts2006/ukpga_20060048_ en_1) zur Anwendung. Wenn Anklage erhoben wird, können Sie mit einer hohen Geldstrafe oder sogar einer Haftstraße belangt werden. 36 1 Was ist SQL-Injection?

1.3.1 Aufsehenerregende Beispiele

Genaue Daten darüber, wie viele Organisationen für SQL-Injection anfällig sind oder gar schon erfolgreich angegriffen wurden, lassen sich nur schwer beschaffen. Anders als Firmen in den USA sind Unternehmen in vielen anderen Ländern nicht verpflichtet, ernsthafte Sicherheits- verletzungen öffentlich bekannt zu geben. Solche Einbrüche und erfolgreichen Angriffe sind jedoch ein beliebtes Thema für die Medien. Selbst kleinere Vorfälle, die früher unbemerkt vom breiten Publikum geblieben wären, werden heute in großem Maßstab an die Öffentlichkeit ge- bracht.

Einige der öffentlich verfügbaren Quellen helfen, zu erkennen, wie schwerwiegend das Problem der SQL-Injection ist. Beispielsweise führt die »Liste der 25 gefährlichsten Softwarefehler« von CWE/SANS (Common Weakness Enumeration) die am weitesten verbreiteten kritischen Fehler auf, die zu erheblichen Schwachstellen in Software führen. Die 25 Einträge wurden nach Einga- ben von über 20 verschiedenen Organisationen geordnet. Die einzelnen Schwachstellen wurden nach Häufigkeit, Wichtigkeit und Wahrscheinlichkeit der Ausnutzung bewertet. Zu dieser Be- wertung und zur Aufstellung der endgültigen Rangliste wurde das CWSS (Common Weakness Scoring System) verwendet. An der Spitze der Liste für das Jahr 2011 steht die Anfälligkeit für SQL-Injektionsangriffe (siehe http://cwe.mitre.org/top25/index.html).

Auch das OWASP (Open Web Application Security Project) führt die Anfälligkeit für Injekti- onsangriffe (darunter auch SQL-Injection) in seiner Top-10-Liste von 2010 als eine der erns- testen Sicherheitsbedrohungen für Webanwendungen auf. Der Hauptzweck dieser Liste besteht darin, Entwickler, Designer, Architekten und Organisationen über die Folgen der am weitesten verbreiteten Schwachstellen von Webanwendungen aufzuklären. In der vorherigen Liste aus dem Jahr 2007 stand die SQL-Injection noch auf dem zweiten Platz. Für 2010 hatte die OWASP die Methodik zur Bestimmung der Rangfolge geändert, um sie nicht allein auf die Häufigkeit der jeweiligen Schwachstellen zu stützen, sondern auch das Risiko zu ermitteln. Früher wurde die Top-10-Liste der OWASP aus Daten der CVE-Liste (Common Vulnerabilities and Exposu- res) öffentlich bekannter Schwachstellen und Gefahren im Bereich der Informationssicherheit, die von der MITRE Corporation veröffentlicht wird (http://cve.mitre.org/). Das Problem bei der Verwendung der CVE-Zahlen als Indikator dafür, wie viele Websites für SQL-Injectionen anfäl- lig sind, besteht darin, dass diese Daten keinen Einblick in die Schwachstellen von Websites ge- ben, die von Unternehmen selbst erstellt wurden. Die CVE-Einträge stellen nur die aufgespür- ten Schwachstellen in kommerziellen und Open-Source-Anwendungen dar, zeigen aber nicht, wie weit diese Schwachstellen in der Praxis verbreitet sind. In Wirklichkeit ist die Situation noch viel, viel schlimmer. Dennoch ist der Trendbericht aus dem Jahr 2007 eine interessante Lektüre (http://cve.mitre.org/ docs/vuln-trends/vuln-trends.pdf).

Es gibt noch weitere Quellen, die Informationen über angegriffene Websites sammeln. Bei- spielsweise hält Zone-H Verunstaltungen von Websites fest. Sie zeigt eine große Zahl von pro- minenten Websites und Webanwendungen, die im Laufe der Jahre aufgrund von Schwachstel- len gegenüber SQL-Injektionsangriffen gehackt wurden. Seit 2001 wurden Websites innerhalb der Domäne Microsoft mindestens 46 Mal verunstaltet. Eine umfassende Liste der betroffenen Microsoft-Websites finden Sie online auf Zone-H (www.zone-h.org/content/view/14980/1/). 1.3 Wie funktioniert SQL-Injection? 37

Auch die traditionelle Presse bringt erfolgreiche Ausnutzungen von Sicherheitslücken an die Öffentlichkeit, insbesondere, wenn sie bekannte und angesehene Unternehmen betreffen. Die folgende Liste nennt eine Auswahl solcher Fälle:

•• Im Februar 2002 stellte Jeremiah Jacks (www.securityfocus.com/news/346) fest, dass Guess. com durch SQL-Injection angreifbar war. Er verschaffte sich Zugriff auf die Kreditkarten­ informationen von mindestens 200.000 Kunden. •• Im Juni 2003 schlug Jeremiah Jacks erneut zu, dieses Mal bei PetCo.com (www.securityfocus. com/news/6194), wo er über die Ausnutzung einer Schwachstelle gegenüber SQL-Injection Zugriff auf die Angaben von 500.000 Kreditkarten erhielt. •• Am 17. Juni 2005 warnte MasterCard einige der Kunden wegen einer Unterwandung des Sicherheitssystems von Card Systems Solutions. Das war damals der bekannteste Einbruch dieser Art. Durch die Ausnutzung einer Anfälligkeit für SQL-Injection erhielt ein Hacker Zugriff auf Angaben zu 40 Millionen Kreditkarten (www.ftc.gov/os/caselist/0523148/05231 48complaint.pdf). •• Im Dezember 2005 entdeckte Guidance Software, Entwickler von EnCase, dass ein Hacker die Datenbank mithilfe einer Schwachstelle gegenüber SQL-Injection geknackt hatte. Da- durch waren die Finanzunterlagen von 3800 Kunden offengelegt worden (www. ftc.gov/os/ caselist/0623057/0623057complaint.pdf­ ). •• Etwa im Dezember 2006 wurde der US-Discounter TJX gehackt. Die Angreifer stahlen die Daten von Millionen von Bezahlkarten aus den TJX-Datenbanken. •• Im August 2007 wurde die Website der Vereinten Nationen (www.un.org) durch einen SQL- Injektionsangriff verunstaltet, bei dem die Angreifer antiamerikanische Parolen veröffent- lichten (http://news.cnet.com/8301-10784_3-9758843-7.html). •• 2008 nutzte das Botnetz Asprox Anfälligkeiten für SQL-Injection für Drive-by-Masseninfi- zierungen mit Schadsoftware, um selbst zu wachsen (http://en.wikipedia.org/wiki/Asprox). Die Anzahl der ausgenutzten Webseiten wird auf 500.000 geschätzt. •• Im Februar 2009 gelang es einer Gruppe rumänischer Hacker angeblich, bei mehreren ge- trennten Aktionen mithilfe von SQL-Injektionsangriffen in die Websites von Kaspersky, F-Secure­ und Bit Defender einzubrechen. Danach sollen sie noch viele weitere angesehene Websites wie RBS WorldPay, CNET.com, BT.com, Tiscali.co.uk und national-lottery.co.uk gehackt haben. •• Am 17. August 2009 hat das US-Justizministerium den amerikanischen Staatsbürger Albert Gonzalez und zwei nicht namentlich genannte Russen beschuldigt, mithilfe eines SQL- Injektionsangriffs 130 Millionen Kreditkartennummern gestohlen zu haben. Unter den be- troffenen Unternehmen war das Kreditkartenzahlungssystem Heartland Payment Systems, die Einzelhandelskette 7-Eleven und die Supermarktkette Hannaford Brothers. •• Im Februar 2011 fand Anonymous heraus, dass hbgaryfederal.com aufgrund einer Sicher- heitslücke gegenüber SQL-Injection in seinem CMS angreifbar war. 38 1 Was ist SQL-Injection?

•• Im April 2011 stellte sich heraus, dass die Website von Barracuda Networks (barracudanet- works.com) für SQL-Injection anfällig war. Der Hacker, der den Angriff durchführte, stellte Kopien des Datenbankinhalts online – einschließlich der Anmeldeinformationen und Pass- worthashes der CMS-Benutzer! •• Im Mai 2011 drang LulzSec in mehrere Websites von Sony ein (sonypictures.com­ , Sony- Music.gr und SonyMusic.co.jp) und stellte die Inhalte der Datenbank »aus Spaß« online. LulzSec sagte aus, die Passwörter, E-Mail-Adressen, Postanschriften und Geburtsdaten von einer Million Benutzer gefunden und alle Administratorinformationen von Sony Pictures gestohlen zu haben, einschließlich der Passwörter. Nach einer Pressemitteilung konnte die Gruppe auch auf 75.000 Musiktitel und 3,5 Millionen Musikcoupons zugreifen. •• Im Mai 2011 knackte LulzSec auch die Website des Public Broadcast Service (PBS). Dabei hat die Gruppe mithilfe eines SQL-Angriffs nicht nur zahlreiche SQL-Datenbanken herun- tergeladen, sondern auch eine neue Seite in die PBS-Website eingefügt. LulzSec hat die Be- nutzernamen und Passworthashes der Datenbankadministratoren und Benutzer sowie die Anmeldedaten aller lokalen PBS-Partner einschließlich Klartextpasswörtern veröffentlicht. •• Im Juni 2011 wurde die Fanwebsite von Lady Gaga gehackt. In einer damaligen Meldung hieß es: »Die Hacker bezogen eine Kopie der Inhaltsdatenbank von www.ladygaga.co.uk und griffen auf einen Teil der Datensätze mit E-Mail-Adressen, Vor- und Nachnamen zu. Pass- wörter und Finanzinformationen wurden nicht gestohlen.« (http:// www.mirror.co.uk/ce- lebs/news/2011/07/16/lady-gaga-website-hacked-and-fans-details-stolen-115875-23274356)

Früher haben Hacker eine Website oder Webanwendung hauptsächlich angegriffen, um sich Ansehen bei anderen Hackergruppen zu verschaffen, um ihre politischen Ansichten und Bot- schaften zu verbreiten, um ihre Fähigkeiten (oder »mad skillz« im Jackerjargon) unter Beweis zu stellen oder um sich gegen eine vermeintliche Beleidigung oder Ungerechtigkeit zu wehren. Heute nutzen Angreifer Webanwendungen jedoch eher aus, um sich finanziell zu bereichern. Im Internet sind heute viele Arten von Angreifern mit sehr unterschiedlichen Motiven unter- wegs (ich bin mir sicher, dass jeder, der dieses Buch liest, eine Vorstellung von LulzSec und Anonymous hat!). Die Palette umfasst Personen, die einfach nur durch Interesse an Technik und eine »Hackermentalität« angetrieben werden, in fremde Systeme einzusteigen, aber auch kriminelle Organisationen, die bewusst mögliche Ziele ausspähen, um sich finanziell zu be- reichern, politische Aktivisten, die durch ihre persönlichen Ansichten oder die einer Gruppe motiviert sind, und vergrätzte Systemadministratoren und Angestellte, die ihre Rechte und Möglichkeiten für unterschiedlichste Ziele missbrauchen. Oft ist eine Verwundbarkeit gegen- über SQL-Injection in einer Website oder Webanwendung alles, was ein Angreifer braucht, um sein Ziel zu erreichen.

Seit Anfang 2008 wurden Hunderttausende von Websites durch automatisierte SQL-Injek- tionsangriffe geschädigt (Asprox). Dabei suchte ein Tool im Internet nach Anwendungen mit Schwachstellen und nutzte sie automatisch aus. Der Schadcode bei diesem Exploit führte eine iterative SQL-Schleife aus, die jede von Benutzern erstellte Tabelle in der Datenbank suchte und in allen­ Textspalten darin ein clientseitiges Schadskript anhängte. Da die meisten datenbank- gestützten Webanwendungen die Inhalte der Datenbanken dazu nutzen, um Webinhalte dyna- 1.3 Wie funktioniert SQL-Injection? 39

misch aufzubauen, wurde den Benutzern der betroffenen Website oder -anwendung über kurz oder lang das Skript präsentiert. Alle Browser, die die infizierte Webseite luden, wurden durch das Tag angewiesen, ein Schadskript auszuführen, das auf einem Remoteserver untergebracht war. Der Zweck bestand darin, so viele Hosts wie möglich mit Schadsoftware zu infizieren. Die- ser Angriff erwies sich als sehr wirkungsvoll. Wichtige Websites wie die von Regierungsstellen, der Vereinten Nationen und großer Unternehmen wurden durch diesen Massenangriff infiziert. Es lässt sich nur schwer ermitteln, wie viele Clientcomputer und Besucher dieser Websites wiede- rum infiziert wurden, insbesondere da der Schadcode für jeden individuellen Angriff angepasst werden konnte.

Sind Sie schon übernommen worden? Mir könnte das nicht passieren, oder? Mit den Jahren habe ich schon viele Webanwendungen untersucht, und dabei musste ich feststellen, dass jede dritte durch SQL-Injektionsangriffe verwundbar war. Das gilt teilweise auch heute noch, allerdings habe ich das Gefühl, dass ich für mein Geld heute viel härter arbeiten muss. Das kann an einer Reihe von Variablen liegen, die sich nur schwer quantifizieren lassen. Meiner Meinung nach aber haben die Verbesserungen bei der allgemeinen Sicherheit gängiger Entwicklungsframeworks und Maßnahmen zur Fortbildung von Entwicklern dazu beigetragen, dass sich Entwickler sehr anstren- gen, um solche Schwachstellen in ihren Anwendungen zu vermeiden. Zurzeit finde ich Anfälligkeiten für SQL-Injection in Anwendungen, die von unerfahrenen Entwick- lern für neue Technologien und Plattformen geschrieben werden. Das Asprox-Botnet wächst aber nach wie vor! Die Auswirkungen der Schwachstellen unterscheiden sich sehr stark zwischen den Anwendungen und Plattformen, aber die Schwachstellen sind auch heute noch in vielen Anwendungen vorhanden. Viele Anwendungen werden in ungeschützten Umgebungen wie dem Internet eingerichtet, ohne auf Schwachstellen untersucht zu werden. Die Verunstaltung einer Website ist eine sehr auffällige Aktion, die gewöhnlich von »Skript Kiddies« durchgeführt wird, um Punkte zu sammeln und die Anerkennung anderer Hackergruppen zu finden. Ernster zu nehmende Hacker mit einer stärkeren Motivation wollen die Aufmerksamkeit nicht auf sich ziehen. Es ist durchaus möglich, dass solche anspruchsvollen und fähigen Angreifer eine Schwach­ stelle gegenüber SQL-Injection ausnutzen, um Zugriff auf verbundene Systeme zu be- kommen und sie zu missbrauchen. Ich musste meine Kunden mehr als einmal darüber informieren, dass ihre Systeme bereits geknackt wurden und von Hackern aktiv für illegale Tätigkeiten ­genutzt wurden. Manche Organisationen und Websitebenutzer er- fahren vielleicht niemals, dass ihre Systeme ausgenutzt wurden oder dass Hacker eine Hintertür zu ihren Systemen eingebaut haben. 1.6 Schneller Überblick 53

1.6 Schneller Überblick

1.6.1 Wie funktionieren Webanwendungen?

•• Webanwendungen zeichnen sich dadurch aus, dass die Benutzer mithilfe eines Webbrow- sers über ein Netzwerk wie das Internet oder ein Intranet darauf zugreifen. Es handelt sich um Softwareanwendungen, die in einer vom Browser unterstützten Sprache (wie HTML, ­JavaScript, Java usw.) geschrieben sind und in einem Webbrowser dargestellt werden. •• Einfache dynamische, datenbankgestützte Webanwendungen bestehen gewöhnlich aus einer Back-End-Datenbank sowie Webseiten, die ein serverseitiges Skript enthalten. Geschrieben ist dieses Skript in einer Programmiersprache, mit der aufgrund verschiedener dynamischer Interaktionen bestimmte Informationen aus der Datenbank abgerufen werden können. •• Einfache dynamische, datenbankgestützte Webanwendungen bestehen gewöhnlich aus drei Schichten: der Präsentationsschicht (ein Webbrowser oder eine Render-Engine), die Logik- schicht (eine Programmiersprache wie C#, ASP, .NET, PHP, JSP usw.) und eine Speicher- schicht (eine Datenbank wie Microsoft SQL Server, MySQL, Oracle usw.). Der Webbrowser (die Präsentationsschicht, z. B. Internet Explorer, Safari, Firefox usw.) sendet Anforderungen an die mittlere Schicht (Logikschicht), die wiederum zur Erfüllung dieser Anforderungen Abfragen und Aktualisierungen an der Datenbank (Speicherschicht) vornimmt.

1.6.2 Wie funktioniert SQL-Injection?

•• SQL-Injection ist ein Angriff, bei dem SQL-Code in Eingabeparameter der Anwendung oder des Benutzers eingefügt oder daran angehängt und dann an den SQL-Back-End-Server übergeben wird, wo er geparst und ausgeführt wird. •• Bei der häufigsten Form der SQL-Injection wird Code direkt in die Parameter eingefügt, die mit SQL-Befehlen verkettet und ausgeführt werden. •• Wenn ein Angreifer eine SQL-Anweisung ändern kann, so läuft der Vorgang mit den Be- rechtigungen der Komponente ab, die den Befehl ausführt (z. B. mit den Berechtigungen des Datenbank-, Anwendungs- oder Webservers). Diese Komponenten haben häufig hohe Berechtigungen. 54 1 Was ist SQL-Injection?

1.6.3 Wie kann das passieren?

•• Schwachstellen, die durch SQL-Injection ausgenutzt werden können, treten­ meistens auf, wenn die Entwickler der Webanwendung versäumen, die von einem Webformular, einem Cookie, einem Eingabeparamter usw. empfangenen Werte zu validieren oder zu codieren, bevor sie an die auf dem Datenbankserver auszuführenden SQL-Abfragen übergeben wer- den. •• Wenn ein Angreifer die Eingaben, die an eine SQL-Abfrage gesendet werden, so manipulie- ren kann, dass die Daten nicht mehr als Daten interpretiert werden, sondern als Code, dann kann er möglicherweise auch Code in der Back-End-Datenbank ausführen lassen. •• Wenn Entwickler keine gründlichen Kenntnisse der zugrundeliegenden Datenbank und kein Bewusstsein für die möglichen Gefahren haben, die der von ihnen geschriebene Code bietet, produzieren sie oft unsichere Anwendungen, die anfällig für SQL-Injection sind.

1.7 Häufig gestellte Fragen

F: Was ist SQL-Injection?

A: SQL-Injection ist eine Angriffstechnik, bei der Schwachstellen im Code ausgenutzt werden, um Eingaben zu manipulieren und damit an das Back-End gesendete SQL-Anweisungen zu ändern.

F: Sind alle Datenbanken anfällig für SQL-Injection?

A: Die meisten Datenbanken sind anfällig, allerdings in sehr unterschiedlichem Grade.

F: Welche Auswirkungen hat eine Anfälligkeit für SQL-Injection?

A: Das hängt von vielen Faktoren ab. Im Allgemeinen kann ein Angreifer Daten in der Daten- bank manipulieren, weit mehr Daten abrufen, als die Anwendung normalerweise zulässt, und möglicherweise sogar Betriebssystembefehle auf dem Datenbankserver ausführen.

F: Ist SQL-Injection ein neues Phänomen?

A: Nein, wahrscheinlich hat es das schon gegeben, seit zum ersten Mal SQL-Datenbanken mit Webanwendungen verbunden wurden. An die Öffentlichkeit gebracht wurde dieses Prob- lem jedoch erstmals Weihnachten 1998. 1.7 Häufig gestellte Fragen 55

F: Wie ist es möglich, dass Code ausgeführt wird, nur weil jemand seinen Eingaben ein einfa- ches Anführungszeichen voranstellt?

A: SQL-Datenbanken interpretieren das Anführungszeichen als Trennzeichen zwischen Code und Daten. Daher gehen sie davon aus, dass alles, was innerhalb der Anführungszeichen steht, Daten sind, und alles, was darauf folgt, Code ist.

F: Sind Websites sicher vor SQL-Injection, wenn die Eingabe des Anführungszeichens unter- sagt wird?

A: Nein. Es gibt unzählige Möglichkeiten, das Anführungszeichen so zu codieren, dass es trotz- dem als Eingabe akzeptiert wird, und bei manchen SQL-Injection-Techniken wird dieses Zeichen überhaupt nicht verwendet. Angreifern stehen neben dem Anführungszeichen auch mehrere andere Zeichen zur Verfügung, beispielsweise der doppelte senkrechte Strich (||) und das doppelte Anführungszeichen (").

F: Sind Websites sicher vor SQL-Injection, wenn die GET-Methode nicht verwendet wird?

A: Nein, POST-Parameter lassen sich genauso einfach manipulieren.

F: Meine Anwendung ist in HPH/ASP/Perl/.NET/Java/usw. geschrieben. Ist diese Sprache immun?

A: Nein. Alle Programmiersprachen, bei denen die Eingaben vor der Übergabe an dynamisch erstellte SQL-Anweisungen nicht validiert werden, ist potenziell gefährdet, zumindest sofern keine parametrisierten Abfragen und gebundene Variablen verwendet werden.

60376-8 Titelei_X 17.03.16 14:15 Seite 1

Tim Philipp Schäfers Hacking im Web

Denken Sie wie ein Hacker und schließen Sie die Lücken in Ihrer Webapplikation, bevor diese zum Einfallstor für Angreifer wird. 60376-8 Titelei_X 17.03.16 14:15 Seite 2

Tim Philipp Schäfers , Jahrgang 1995, ist seit seinem Abitur als Security-Consultant tätig und berät Firmen im Bereich Websicherheit/Webhacking. Schäfers deckte gravierende Sicherheitslücken bei Unternehmen wie PayPal, Facebook, Google, der deutschen Telekom und vielen weiteren Unternehmen verantwortlich auf. Er ist Mitgründer und Mitbetreiber des Webprojekts „Internetwache.org“, das sich ebenfalls mit der Sicherheit von Webapplikatio - nen und Webhacking beschäftigt. Seit Ende 2015 schreibt Schäfers zudem auf dem Web-Portal golem.de über die Themen IT-Sicherheit und Privatsphäre. Vorwort

Kaum ein Monat vergeht, in dem wir nicht hören, dass ein Unternehmen Opfer eines Hackerangriffs geworden ist. Oftmals wird die Webseite verunstaltet, Social-Media- Accounts geraten unter die Kontrolle von unbekannten Angreifern, oder es wird gar die gesamte Onlinedatenbank eines Unternehmens geklaut. Als Einstiegspunkt für Angreifer dient oft das Web, genauer die Webapplikationen, die auf Servern im Internet betrieben werden. Im Handumdrehen kann die Webseite eines Unternehmens zum Einfallstor werden oder der Webshop zur Goldgrube für Onlinekriminelle, während das Geschäft darunter leidet. Die (Un-)Sicherheit Ihrer Webapplikationen entscheidet letztlich auch über den Erfolg oder Misserfolg Ihres Unternehmens, denn oftmals findet über diese Anwen- dungen die Abwicklung ganzer Geschäfts(teil)prozesse statt. Genau um diese Thematik soll es in diesem Buch gehen: die Sicherheit von Web- anwendungen mithilfe eines sicheren Programmcodes. Längst wird für eine sichere Webapplikation mehr benötigt als Standardlösungen oder Firewalls, vielmehr ist ein hohes Maß an Wissen nötig, um überhaupt nachvoll- ziehen zu können, was mögliche Angreifer auf Applikationsebene alles versuchen, um Systeme zu hacken. Angreifer nutzen verschiedene Arten des Angriffs. In dem vorliegenden Buch werden die gängigsten Angriffsvektoren im Bereich Webhacking betrachtet und es wird erklärt, wie man diese beheben kann. Die Komplexität und das schnelle Wachstum des Webs und seiner Technologien haben seit seiner Entstehung für einiges Durcheinander gesorgt. Dieser Wirrwarr schlägt sich auch auf die Sicherheit von Systemen und Webapplikationen nieder. Es gibt im Web Standards, die nicht eingehalten werden, gelebte Regeln (die eigentlich nur Vorschläge waren) und sicherlich auch eine Menge verzweifelter Entwickler, die sich fragen, wie sie da den Durchblick behalten können. Das Buch »Hacking im Web« soll an dieser Stelle weiterhelfen: Hier werden Angriffs- möglichkeiten aufgezeigt, zahlreiche Tipps gegeben und Vorschläge zur Behebung von Lücken gemacht. Ziel ist, dass Sie wissen, wie auf mögliche Gefahren reagiert werden kann. Dadurch können Angriffsflächen bereits während der Entwicklung minimiert werden. 6 Danksagung

Danksagung

Dieses Buch liegt nur in dieser Form vor Ihnen, da einige Personen mich in meinem Vorhaben, einiges über die Sicherheit von Webapplikationen zu Papier zu bringen, unterstützt haben und stets mit Rat und Tat zur Seite standen. Ein großes Dankeschön für geniale Ideen, geistreiche Einfälle und alle sonstigen Formen der Unterstützung geht an: Franzi, Heide, Dennis, Merlin, Laurenz, Joel, Vanessa, Kevin, Dome, Maria, Saghana, Hans und meine gesamte Familie. Des Weiteren gilt mein ganz besonderer Dank Rico Walde und Sebastian Neef. Beide haben durch ihre umfassenden Rückmeldungen zu einzelnen Kapiteln und ihr fun- diertes IT-Fachwissen maßgeblich dazu beigetragen, dass dieses Fachbuch hoffent- lich ausgeglichene Anteile an Theorie und Praxis aufweist und noch dazu angenehm zu lesen ist. Zudem möchte ich Dr. Markus Stäuble, dem Lektor und Programmleiter »Professional Series« beim Franzis Verlag, danken. Seine Ausdauer, seine Anregungen und Tipps und nicht zuletzt auch die Begeisterung für das Thema haben mich als recht jungen Erstautor motiviert, das Buchprojekt durchzuführen und mit dem Buch Teil der Serie zum Thema Hacking im Franzis Verlag zu werden. Abschließend möchte ich Ihnen, liebe Leser, stellvertretend für eine ganze Reihe von anderen Menschen aus dem Web danken! Das moderne Web würde nicht existieren, wenn es keine neugierigen Entwickler, mutigen Gestalter, gewieften Blogger, cleveren Hacker oder skeptischen Mitleser gäbe. In der bisherigen menschlichen Evolution gab es wohl kaum eine andere Kommunikations- und Verbindungsart, die so vielfältig, umfassend und allgegenwärtig war oder ist wie das Web — deshalb: Danke, dass Sie alle es täglich nutzen und es so zu dem machen, was es ist!

Inhaltsverzeichnis

I Einleitung...... 15 1.1 Der Ansatz...... 16 1.2 Das Ziel...... 16 1.3 Der Aufbau ...... 16 1.4 Die Grenzen...... 19 1.5 Das (Kern-)Problem ...... 20

2 Evolution des Webs...... 23 2.1 Die Anfänge des Webs...... 23 2.2 Die Boomphase des Webs...... 25 2.3 Webapplikationen heute ...... 26 2.4 Webapplikationen in der Zukunft...... 28 2.5 Entwicklung der Websicherheit ...... 28

3 Basiswissen...... 33 3.1 HTTP ...... 33 3.1.1 HTTP-Anfrage...... 35 3.1.2 HTTP-Antwort...... 36 3.1.3 HTTP-Headerfelder...... 37 3.1.4 HTTP-Methoden...... 39 3.1.5 Statuscode und Reason Phrase...... 40 3.1.6 Cookies...... 41 3.2 Sprachen des Webs...... 44 3.2.1 Clientseitige Sprachen...... 44 3.2.2 Serverseitige Sprachen ...... 58 3.3 URL...... 74 3.4 Webbrowser ...... 77 3.4.1 Document Object Model (DOM)...... 80 3.4.2 Browsersicherheit ...... 80 3.4.3 Same-Origin-Policy (SOP)...... 81 3.5 Codierung...... 82 3.5.1 HTML-Codierung...... 83 3.5.2 URL-Codierung ...... 84 3.5.3 Unicode-Codierung...... 85 3.5.4 UTF-8 ...... 86 3.5.5 base64-Codierung...... 87 3.5.6 Hexadezimale Codierung ...... 88 3.5.7 Zusammenfassung...... 88 8 Inhaltsverzeichnis

4 Session-Angriffe...... 89 4.1 Man-in-the-Middle-Angriff...... 91 4.2 Cookie-Replay-Angriff ...... 92 4.3 Session-Hijacking ...... 93 4.4 Session-Fixation...... 97 4.5 Session-Riding bzw. CSRF (Cross Site Request Forgery)...... 98 4.6 Zusammenfassung: Abhilfe aus Entwicklersicht ...... 101 4.6.1 Verschlüsselung...... 101 4.6.2 Sichere Generierung von Session-IDs...... 102 4.6.3 Sonstige Maßnahmen ...... 103 4.6.4 Hinweise zu Session-Riding bzw. CSRF ...... 106

5 Cross-Site-Scripting (XSS)...... 109 5.1 Reflexives XSS ...... 110 5.2 Persistentes XSS ...... 118 5.3 DOM-based XSS ...... 121 5.4 self-XSS ...... 123 5.5 Social-engineered XSS ...... 123 5.6 uXSS ...... 125 5.7 Flash-based XSS ...... 126 5.8 Abhilfe aus Entwicklersicht...... 127 5.8.1 Sonstige Hinweise/Umgehen von Filtern...... 128 5.8.2 Schutz vor reflexivem und persistentem XSS...... 131 5.8.3 Schutz vor DOM-XSS...... 143 5.8.4 Schutz vor self-XSS ...... 144 5.8.5 Hinweise zu Social-engineered XSS...... 144 5.8.6 Hinweise zu uXSS...... 145 5.8.7 Schutz vor Flash-based XSS ...... 146 5.9 Sonstige Maßnahmen gegen XSS ...... 149 5.9.1 CSP (Content-Security-Policy)...... 149 5.9.2 XSS-Filter im Browser...... 153 5.9.3 http-only-Flags ...... 154 5.10 Zusammenfassung der Maßnahmen ...... 154 5.11 Wissenswertes über XSS...... 155 5.12 Scriptless Attacks...... 157

6 Angriffe auf nachgelagerte Datenbanksysteme...... 159 6.1 SQL-Injections...... 160 6.1.1 Login Bypass mit SQL-Injection...... 161 6.1.2 Basisangriffe durch SQL-Injection...... 163 6.1.3 Blind-SQL-Injection...... 181 6.1.4 Wesentliche Erkenntnisse: Angreifersicht...... 188 6.1.5 Sicherung von SQL-Datenbanken...... 188 Inhaltsverzeichnis 9

6.1.6 Wesentliche Erkenntnisse: Entwicklersicht...... 195 6.1.7 Wissenswertes über SQL-Injections...... 195 6.2 Grundlagen von LDAP...... 197 6.2.1 Operatoren innerhalb von LDAP ...... 200 6.2.2 Verknüpfung von Operatoren ...... 201 6.2.3 LDAP-Injection ...... 202 6.2.4 Blind-LDAP-Injection...... 203 6.2.5 Sicherung von LDAP-Systemen...... 204 6.3 XPath...... 205 6.3.1 XPath-Injection...... 206 6.3.2 Blind-XPath-Injection...... 208 6.3.3 Sicherung von XPath...... 208 6.3.4 Zusammenfassung: Sicherung nachgelagerter Dateisysteme ...... 208

7 Sicherheit von Authentifizierungsmechanismen...... 211 7.1 Verschiedene Angriffsvektoren...... 211 7.1.1 Simple Angriffe gegen Authentifizierungsmechanismen...... 212 7.1.2 Wörterbuchangriff...... 212 7.1.3 Brute-Force-Methode...... 212 7.2 Grundlagen zum Passworthashing...... 213 7.3 Kryptografische Hashfunktionen ...... 216 7.4 Passwortcracking...... 217 7.4.1 Lookup-Tabellen mittels Brute-Force-Methode oder Wörterbuchangriff...... 218 7.4.2 Rainbow Tables ...... 218 7.4.3 Google-Suche...... 219 7.4.4 Tools ...... 219 7.5 Typenunsicherer Vergleich...... 219 7.6 Abhilfe aus Entwicklersicht...... 223 7.6.1 Salt hinzufügen ...... 223 7.6.2 Sicheres Passworthashing...... 225 7.6.3 Passwort-Policy...... 226 7.6.4 Passwortvalidierung...... 226 7.6.5 Sicherer Vergleich...... 228 7.6.6 Weitere Authentifizierungsarten ...... 228 7.6.7 Hinweise zur Log-in-Änderung...... 230 7.6.8 Hinweise zur »Passwort vergessen?«-Funktion...... 230 7.6.9 Protokollierung (Logging)...... 231 7.6.10 Zusammenfassung...... 232

10 Inhaltsverzeichnis

8 File Inclusion...... 235 8.1 Path Traversal...... 235 8.1.1 Abhilfe aus Entwicklersicht...... 237 8.2 Local File Inclusion (LFI)...... 239 8.2.1 Abhilfe aus Entwicklersicht...... 241 8.3 Nullbyte-Injection...... 241 8.3.1 Abhilfe zur Nullbyte-Injection...... 242 8.4 Uneingeschränkte Dateiuploads...... 243 8.4.1 Hinweis zum Upload von Dateien...... 246 8.5 Remote File Inclusion (RFI)...... 247 8.5.1 Abhilfe aus Entwicklersicht...... 248 8.6 XML-External-Entities-Injection (XXE) ...... 248 8.6.1 Abhilfe aus Entwicklersicht ...... 251 8.7 Code-Injection...... 252 8.7.1 Abhilfe aus Entwicklersicht...... 253 8.8 HTTP-Header-Injection ...... 254 8.8.1 Cookie-Injection...... 254 8.8.2 SMTP-Header-Injection...... 255 8.8.3 Abhilfe aus Entwicklersicht...... 260 8.9 Zusammenfassung...... 261

9 Logische Fehler...... 263 9.1 Zugriffsrechte ...... 263 9.1.1 Rechteausweitungen...... 264 9.1.2 Ungeschützte Funktionen...... 267 9.1.3 Kontextabhängige Zugriffe...... 268 9.1.4 Parametrisierte Zugriffskontrollen ...... 269 9.1.5 Referrer-basierte Zugriffskontrolle ...... 270 9.1.6 Schrittweise Zugriffskontrolle...... 270 9.2 Ungeprüfte Um- und Weiterleitungen...... 270 9.2.1 Abhilfe aus Entwicklersicht...... 271 9.3 Namenskonflikte...... 272 9.3.1 Namenskonflikte in URLs...... 272 9.3.2 Namenskonflikte in Nutzernamen ...... 273 9.3.3 Namenskonflikte bei Uploads ...... 274 9.4 Cookie-Manipulation...... 275 9.4.1 Abhilfe aus Entwicklersicht ...... 275 9.5 Zusammenfassung...... 275

10 Informationspreisgabe...... 277 10.1 Fehlermeldungen ...... 277 10.2 Directory Listing...... 280 10.3 Öffentlich zugängliche Informationen...... 281 Inhaltsverzeichnis 11

10.3.1 Versteckte Subdomains...... 281 10.3.2 »Versteckte« Pfade/Standardpfade...... 282 10.3.3 Informationen aus dem Quelltext ...... 283 10.3.4 Öffentliche Dateien ...... 284 10.3.5 Öffentliche Logdateien ...... 285 10.3.6 Sonstige Konfigurationsdateien...... 286 10.3.7 Sonstige Informationen...... 291 10.3.8 Unsichere direkte Objektreferenzen...... 291 10.3.9 Standardwerte ...... 291 10.3.10 Suchmaschinen ...... 292 10.3.11 Soziale Manipulation (Social Engineering)...... 303 10.4 Abhilfe: Informationspreisgabe ...... 312 10.4.1 Abhilfe: Fehlermeldungen ...... 313 10.4.2 Abhilfe: Directory Listing...... 313 10.4.3 Abhilfe: öffentlich zugängliche Informationen ...... 314 10.4.4 Abhilfe: Standardwerte ...... 316 10.4.5 Abhilfe: Suchmaschinen ...... 316 10.4.6 Abhilfe: Phishing-Angriffe ...... 319 10.4.7 Abhilfe: Social Hacking...... 320 10.4.8 Abhilfe: Social Hacking gegen Plattformbetreiber ...... 320 10.4.9 Abhilfe: Social Hacking innerhalb von Plattformen...... 321

11 UI-Redressing ...... 323 11.1 Die Methoden der Angreifer ...... 323 11.1.1 Clickjacking...... 324 11.1.2 Cursorjacking...... 327 11.1.3 Fortgeschrittene UI-Redressing-Angriffe...... 330 11.2 Abhilfe aus Entwicklersicht...... 332 11.2.1 CSP (Content-Security-Policy) ...... 332 11.2.2 X-Frame-Options (XFO) ...... 333 11.2.3 Frame-Busting mittels JavaScript...... 334 11.2.4 Zusammenfassung...... 335

12 Weitere Angriffsarten...... 337 12.1 SQL-Injections zu XSS...... 337 12.2 XSS zu SQL-Injection...... 338 12.3 Domain- bzw. Typosquatting ...... 339 12.4 Google-Bombing...... 343 12.5 Exploits ...... 345 12.6 Rent a Hacker/Untergrundforen...... 347

13 Die 10 wichtigsten Regeln für Entwickler und Sicherheitsverantwortliche.... 349

12 Inhaltsverzeichnis

A Tools...... 353 A.1 Toolübersicht...... 354 A.2 Mozilla Firefox-Erweiterungen ...... 356 A.2.1 Tamper Data...... 357 A.2.2 Hackbar...... 358 A.2.3 Live HTTP headers...... 360 A.2.4 User Agent Switcher...... 362 A.2.5 Wappalyser ...... 364 A.2.6 XSS ME ...... 366 A.2.7 SQL Inject ME ...... 368 A.3 HTTP-Proxy-Tools ...... 369 A.3.1 Burp Suite...... 369 A.3.2 OWASP Zed Attack Proxy (ZAP) ...... 383 A.4 Tools zu Session-Angriffen...... 391 A.4.1 Wireshark...... 392 A.4.2 CSRFGenerator...... 395 A.5 Angriffstools zu XSS ...... 395 A.5.1 XSSer...... 396 A.5.2 Xenotix XSS Exploit Framework ...... 398 A.5.3 Adobe SWF Investigator...... 402 A.6 Tools zu nachgelagerten Datenbanksystemen...... 404 A.6.1 SQL-Ninja...... 404 A.6.2 sqlmap...... 407 A.6.3 Havij...... 409 A.6.4 LDAP Blind Explorer...... 413 A.6.5 XPath Blind Explorer...... 414 A.7 Angriffe gegen Authentifizierungsmechanismen ...... 415 A.7.1 Brutus...... 416 A.7.2 Cintruder...... 419 A.8 Passwortcracking...... 419 A.8.1 Hash Identifier...... 419 A.8.2 findmyhash ...... 421 A.8.3 John the Ripper...... 423 A.9 Tools zur Informationspreisgabe ...... 424 A.9.1 Subbrute ...... 424 A.9.2 Knock Subdomain Scan...... 426 A.9.3 WFuzz ...... 427 A.9.4 DirBuster...... 430 A.9.5 WPScan ...... 431 A.9.6 joomscan ...... 433 A.9.7 GitTools (Finder, Dumper, Extractor)...... 435 A.9.8 theHarvester...... 438 A.9.9 Social Engineering Toolkit (SET) ...... 439 Inhaltsverzeichnis 13

A.10 Tools zu UI-Redressing...... 444 A.10.1 Clickjacking Tester...... 444 A.10.2 Clickjacking Tool ...... 445 A.11 Kommentar zu automatischen Schwachstellenscannern ...... 446

B Bug-Bounty-Programme...... 447

C Legal Webhacking durchführen ...... 451 C.1.1 HackITs...... 451 C.1.2 Capture the Flag...... 453 C.1.3 Responsible-Disclosure-Programme/Bug-Bounty- Programme ...... 453 C.1.4 Zusammenfassung ...... 454

D SCADA-Hacking ...... 457 D.1.1 Ich sehe was, was du nicht siehst, und das bist … DU — öffentlich zugängliche Kameras...... 458 D.1.2 Zugriff auf elektronische Geräte ...... 462 D.1.3 Öffentlich zugängliche Human Machine Interfaces (HMI)...... 466 D.1.4 Öffentlich zugängliche PLCs (Programmable Logic Controller)...... 476 D.1.5 Shodan — das dunkle Google...... 477 D.1.6 Fazit...... 479

Epilog...... 481

Abkürzungsverzeichnis...... 483

Literaturempfehlungen ...... 487

Quellenverzeichnis ...... 491 Session-Angriffe

Wir haben in dem Kapitel zuvor gelernt, dass HTTP ein zustandsloses Protokoll ist und dass es dadurch per se nicht möglich ist, verschiedene Anfragen eines Nutzers zusammenfassend zu sehen, sondern dass diese unabhängig voneinander betrachtet werden (siehe Kapitel 3.1.6, »Cookies«). IPs allein sind in puncto Identifizierung nicht zuverlässig, da hinter einer IP-Adresse mehrere Clients stehen können (etwa bei Proxys oder VPNs). Session-Management bietet die Möglichkeit, einzelne Anfragen zu verbinden, und ist deshalb gewissermaßen als Herzstück einer modernen Webanwendung mit Benutzerfunktion anzusehen. Wenn bei diesem fundamentalen Mechanismus eine fehlerhafte Implementierung vorliegt, hat das in jedem Fall Auswirkungen auf die gesamte Sicherheit der Anwendung. Oftmals werden gerade über diese Komponente Identifikation und Autorisierung gegenüber der Anwendung vorgenommen, insoweit sind Schwächen in diesem Bereich zwingend auszuschließen. Bevor wir auf tatsächliche Angriffsmöglichkeiten zu sprechen kommen, schauen wir uns zunächst die technische Umsetzung genauer an: Mittels einer sogenannten Session ist es möglich, Anfragen eindeutig einem Nutzer zuzuordnen, erst dadurch werden dynamische und interaktive Webapplikationen nutzbar, etwa da nutzerbezo- gener Inhalt angezeigt werden kann. 90 4 Session-Angriffe

Bei einer Session handelt es sich um eine Sitzung. Durch die Session-ID (Sitzungs-ID, SID), die beim Start einer Sitzung zufällig erzeugt wird und eindeutig ist, kann man Anfragen einem Nutzer zuordnen. Bei jeder Anfrage, bei der bereits eine Authentifi- zierung mittels Log-in stattgefunden hat, wird an die Applikation die Session-ID zur Prüfung (meist in einem HTTP-Headerfeld) übergeben. Damit gibt sich der Nutzer der Applikation gegenüber zu erkennen, und vorangegangene Anfragen können mit der aktuellen in Verbindung gebracht werden. Das ist äußerst nützlich, etwa bei dem Ablegen eines Artikels im Warenkorb oder um sich die Daten eines Nutzers zu merken und sie im Nutzerbezug zu verarbeiten. Außerdem ist es uns als Anwendern möglich, dadurch die Webapplikation über längere Dauer zu verwenden, ohne sich jedes Mal (nach erneuter Anfrage) identifizieren zu müssen. Nahezu jedes bekannte Framework verfügt über einen Mechanismus zum Session- Management, es ergibt Sinn, diesen zu verwenden und nicht unbedingt einen eigenen, möglicherweise unsicheren zu erstellen. Die »Session-ID-Names« der bekanntesten Webframeworks sind nachfolgend aufge- listet:

Webapplikation-Framework Session-ID-Name PHP PHPSESSID Microsoft IIS Server ASPSESSIONID Cold Fusion CFID/CFTOKEN J2EE (Java) JSESSIONID ASP.NET ASP.NET_SessionId

Sessions werden mit einer Laufzeit versehen; sie laufen nach einer gewissen Zeit ab und fungieren somit gewissermaßen als Kurzzeitpasswort. Ihre Laufzeit sollte so lang sein, wie die Sitzung aufrechterhalten werden soll. Das »Abmelden« oder ein »Log- out« in einer Webapplikation durch den Nutzer bedeutet, dass die zuvor gültige Session-ID als abgelaufen deklariert wird. Die Session-ID kann allerdings auch von der Applikation aus als abgelaufen gekennzeichnet werden (automatisches Log-out), etwa wenn der Benutzer sehr lange keine Eingabe oder Interaktion mehr durchgeführt hat. Es gibt verschiedene Möglichkeiten, die Session-ID zu übertragen, die bekanntesten sind nachfolgend aufgeführt und uns in Teilen bereits aus den Grundlagen bekannt: ] Die gängigste Vorgehensweise ist, ein Cookie (Textwert) zu setzen, mit dem sich der Client fortan identifiziert (Übertragung durch HTTP-Headerfelder). 4.1 Man-in-the-Middle-Angriff 91

] Eine weitere Möglichkeit ist, in Formularen ein verstecktes Feld zu nutzen und mit dem HTML-Tag (Inhalte in diesem Tag werden nicht angezeigt) und der POST-Methode die Session-ID zu übertragen. ] Zudem kann die Session-ID als URL-Parameter mit der GET-Methode übertragen werden (davon ist allerdings abzuraten). Zur Übertragung zwischen Client und Server kann stets das HTTP-Protokoll genutzt werden, eine Verschlüsselung ist auch möglich und ausdrücklich zu empfehlen. Die Session-ID wird zu Beginn einer Session serverseitig festgelegt (HTTP-Header- feld: Set-Cookie) und bei jeder neuen Anfrage vom Client mitgesendet (HTTP- Headerfeld: Cookie), damit dieser sich gegenüber der Webapplikation als bereits bekannt ausgeben kann. Sendet der Client keine Session-ID, ist keine anhaltende Session möglich. Wie deutlich wird, vertraut der gesamte Mechanismus darauf, dass der Client stets die eigene Session-ID zurücksendet, jene, die er zu Beginn seiner Sitzung erhalten hat. Solange diese Regel eingehalten wird und zudem sichergestellt ist, dass nicht zwei Nutzer die gleiche Session-ID haben, funktioniert alles wie gewünscht. Wir möchten uns aber einmal damit beschäftigen, was passiert, wenn sich einige Clients nicht an die Regeln halten, also herausfinden, wie es möglich ist, dem System des Session- Managements habhaft zu werden. Dazu betrachten wir nachfolgend die Angriffs- vektoren »Man-in-the-Middle-Angriff«, »Cookie-Replay-Angriff«, »Session-Hijacking« und »Session-Fixation«. Anschließend schauen wir uns die Empfehlungen und Abhilfen aus Entwicklersicht an.

4.1 Man-in-the-Middle-Angriff

Zunächst sei gesagt, dass ein sogenannter »Man-in-the-Middle-Angriff« (MitM- Angriff) das Auslesen der Session-ID grundsätzlich ermöglicht, da die Kommunika- tion (falls unverschlüsselt — HTTP) abgehört werden kann. Das Vorgehen ist aller- dings mit gewissem Aufwand verbunden, da der Angreifer den Zugang zu den Netzen haben muss, um mithilfe eines Packet-Sniffers (zum Beispiel »Wireshark«, siehe »Tools«) die entsprechenden Informationen mitzuschneiden.

92 4 Session-Angriffe

Bild 4.1: Skizzierung eines Man-in-the-Middle-Angriffs.

Die konkrete Angriffsmethodik dahinter wird hier nicht weiter ausgeführt, da sie sich eher auf die Sicherheit von Netzen bezieht als auf die von Webapplikationen selbst. Wichtig ist an dieser Stelle nur, dass dadurch die Session-ID ausgelesen werden kann, und was die Kenntnis der Session-ID bedeutet, betrachten wir im nächsten Angriffs- vektor.

4.2 Cookie-Replay-Angriff

Bei einem Cookie-Replay-Angriff wird die zuvor erlangte Information der Session-ID verwendet, um sich gegenüber der Anwendung auszuweisen. Die Problematik beginnt, wenn es gelingt, eine gültige Session-ID eines anderen Nutzers zu senden, denn so kann man sich gegenüber der Applikation als dieser Benutzer ausweisen und womöglich auf sämtliche Inhalte und Funktionen des Nutzers zugreifen. Dem Angreifer kann zum Vorteil gereichen, dass die Time-out-Zeiten recht großzü- gig sind. Vergisst dann ein Nutzer das Log-out oder schließt der Browser unbeab- sichtigt (Absturz etc.), kann das dazu führen, dass die Sitzung gültig bleibt. Wenn 4.3 Session-Hijacking 93

überdies die Abmeldefunktion oder das Session-Management generell falsch imple- mentiert ist, kann es sogar sein, dass die Session-ID nie abläuft. Findet ein Angreifer diese fälschlicherweise noch gültigen Session-IDs, etwa durch Ausprobieren oder Sniffing, kann er mit dem »Cookie-Replay-Angriff« die alte (aber noch nicht abge- laufene) Sitzung erneut nutzen. Es gibt sogar Applikationen, die bewusst persistente Cookies einsetzen, damit der Nutzer sich nicht bei jedem Besuch der Webseite neu anmelden muss. Diese »Pass- wort merken«- oder »Erinnere dich an mich«-Checkboxen sind ein Risiko, denn wenn einmal eine Session-ID bekannt geworden ist, ist sie möglicherweise dauerhaft ver- wendbar, es sei denn, sie wird in bestimmten Zeitintervallen erneuert.

4.3 Session-Hijacking

Beim Session-Hijacking (Sitzungsübernahme) geht es ebenfalls darum, Kenntnis über die gültige Session-ID anderer Nutzer zu erhalten und sie in einem Request an die Webapplikation zu senden, um sich als die entsprechenden Nutzer auszugeben. Im Unterschied zum »Cookie-Replay-Angriff« geschieht das allerdings nicht zwingend im Nachhinein und unter Ausnutzung zu großzügiger Ablaufzeiten der Sitzungen, sondern während ein Nutzer die Applikation noch in Gebrauch hat. Doch wie kommen wir am besten an die Session-ID eines Nutzers? Eine naheliegende und simple Idee ist es, sie zu klauen. Dieses Vorgehen ist für Angreifer ein lohnender Ansatz, allerdings beschäftigen wir uns damit erst einige Kapitel später (siehe Kapitel 5, »Cross-Site-Scripting (XSS)«). Ein weiterer Ansatz wäre, Session-IDs zu erraten (»Brute-Forcing«), das wäre aller- dings ebenfalls mit viel Aufwand verbunden, da die meisten Session-IDs standard- mäßig recht lang sind. Statt mühsamen Ausprobierens ergibt es mehr Sinn, die Session-IDs (etwa die eigene) zu analysieren und mögliche Muster darin zu erkennen, um letztlich die Session-ID anderer Nutzer hervorsehen oder berechnen zu können. Teilweise wiegen sich Programmierer, denen es vorrangig um die Lauffähigkeit der Applikation geht, in Sicherheit, wenn eine ausreichend lange Session-ID vorliegt, beispielsweise 32-stellig (in PHP ist das ein gängiger Standard). Sie gehen davon aus, dass bei einer solchen Länge keine Gefahr von »Session-Hijacking« ausgehen kann. Das ist jedoch weit gefehlt, denn es kommt nicht nur auf die Länge dieser Werte an, sondern vielmehr auf die Art, wie diese generiert werden. Würden Sie ein Passwort als sicher bezeichnen, das aus den ersten zehn Stellen der Fibonacci-Folge (11235813213455) besteht? Wohl kaum, da ihre Bildung nicht geheim ist, sondern allseits bekannt: Die folgende Zahl ist immer die Summe der zwei vorherigen. Selbst bei einer Länge von über 100 Stellen wäre ein solcher Code zu

94 4 Session-Angriffe

knacken, da man das Muster wiedererkennt und allgemeine Regeln in der Zahlenfolge ausmachen kann. Ähnlich kann das bei Session-IDs sein, die Länge sagt also nichts über den Grad der Sicherheit bzw. Vorhersehbarkeit aus. Einem potenziellen Angreifer spielt an dieser Stelle noch etwas anderes in die Hände. Die meisten Webapplikationen sind öffentlich zugänglich, was bedeutet, dass er sich selbst bei der Anwendung anmelden und seine eigene Session-ID auslesen könnte. Hat er sie, kann er sie möglicherweise zerlegen oder sogar rekonstruieren, wie sie gebildet worden ist. In Quellcodes von Webapplikationen finden sich zum Beispiel immer wieder Metho- den, die den Zeitstempel zur Erzeugung einer Session-ID oder eines eigentlich gehei- men Schlüssels benutzen. Genau das war auch der Fall bei einem sehr verbreiteten Plug-in für das Content- Management-System WordPress. Die Mitarbeiter der Firma Sucuri Inc. entdeckten Anfang 2015 in dem Plug-in folgende Codezeile [22]:

'secret' => md5(time())

Konkret sorgt diese Zeile dafür, dass der Parameter secret den Wert der Zeit (Unix- Timestamp) in gehashter Form (MD5-Algorithmus, mehr dazu im Kapitel über Passworthashing) erhält. Das Fatale daran ist, dass diese Generierung vorhersehbar ist. Konkret: Ein Angreifer kann dieses Wissen nutzen, um sich den Parameter secret selbst zu generieren. In diesem Fall wurde der Parameter bei der Installation des Plug- ins erzeugt, jeder, der also Kenntnis über den ungefähren Zeitraum der Installation hat (das Installationsdatum lässt sich häufig leicht ermitteln, etwa indem man auf andere Systemdateien prüft), ist in der Lage, den Parameter secret nachzuvollziehen. Mit diesem berechenbaren Wert war es schließlich sogar möglich, das gesamte Content-Management-System zu übernehmen. Das WordPress-Plug-in wurde zuvor rund 1,3 Millionen Mal heruntergeladen, von einem Augenblick auf den anderen waren also Millionen von Webseiten unsicher. Das Beispiel zeigt eindrucksvoll, was es bedeuten kann, wenn man auch nur einen sensiblen Wert mit vorhersehbaren Elementen generiert. Bezogen auf die zuvor behandelte Generierung von Session-IDs bedeutet das, dass wir es tunlichst vermeiden sollten, uns an Werten zu bedienen, die für andere leicht zu erraten oder vorhersehbar sind. Das Bild zeigt eine Webapplikation, bei der die Entwickler offensichtlich sehr einfalls- los waren, als es darum ging, zufällige Werte zu erzeugen. Ein erfahrenes Auge sieht sofort: Sie haben einfach den Timestamp des Unix-Systems genommen, um die Parameter id und secureToken zu generieren — also genau das gemacht, wovon gründlich abzuraten ist, denn einem Angreifer ist es damit möglich, diese Daten aus- zuprobieren und eventuell Sessions zu übernehmen. 4.3 Session-Hijacking 95

Bild 4.2: Webanwendung mit voraussagbaren GET-Parametern.

Nachfolgend finden Sie eine Liste, die häufig genutzte Werte zur Generierung von Session-IDs aufzeigt. Von deren alleiniger Verwendung soll jedoch ausdrücklich abgesehen werden (Tipps zur korrekten Generierung von Session-IDs erfolgen am Ende des Kapitels): ] IP-Adresse des Nutzers ] Referrer ] Hostname ] Zeitstempel ] simple Zahlenfolgen ] statische Werte ] User-Agent ] Nutzername oder weitere Daten des Nutzers Der Grund dafür, dass solche Werte häufig zum Einsatz kommen, ist, dass sie zufällig erscheinen und leicht im Quellcode aufrufbar sind. In der Praxis kommen häufig auch Kombinationen aus diesen Werten vor — etwa Zeitstempel + gehashter Benutzer- name. Trotz der scheinbaren Komplexität bleiben diese Werte vorhersehbar, und findige Angreifer können eventuell nur durch Betrachten der IDs bereits auf die Idee zur Generierung kommen.

96 4 Session-Angriffe

Wurde die Methodik hinter der Generierung der Session-IDs unserer Applikation einmal durch einen Angreifer unbemerkt geknackt, ist letztlich unsere gesamte Nutzerauthentifizierung umgehbar, da die Session-ID jedes Nutzers unbemerkt generiert und auch verwendet werden kann.

Bild 4.3: Skizzierung einer Sessionübernahme.

Das Praktische für den Angreifer an den beiden ersten Angriffsarten ist, dass keine Notwendigkeit besteht, das eigentliche (möglicherweise starke) Passwort eines Nutzers zu knacken, es genügt, seine Session-ID zu kennen, um seine Berechtigungen zu erhalten. 4.6 Zusammenfassung: Abhilfe aus Entwicklersicht 101

Bild 4.6: Skizzierung: Session-Riding.

4.6 Zusammenfassung: Abhilfe aus Entwicklersicht

Es scheint offensichtlich, dass beim Session-Management eine ganze Reihe von Maßnahmen getroffen werden müssen, um Session-Angriffe zu unterbinden. Sonst haben Angreifer nahezu freie Hand, unsere Webapplikation in Gefahr zu bringen. Im Folgenden sind die wichtigsten Abhilfen und Tipps aus Entwicklersicht zusam- mengefasst.

4.6.1 Verschlüsselung Grundsätzlich sollte bei Webanwendungen immer eine Verschlüsselung im Einsatz sein, um die Möglichkeit eines Man-in-the-Middle-Angriffs auszuschließen bzw. auf ein Minimum zu senken.

102 4 Session-Angriffe

Bei Webapplikationen, bei denen persönliche Daten oder Log-in-Daten verarbeitet werden, sollte immer eine Verschlüsselung zum Einsatz kommen (HTTPS). Es ist stets darauf zu achten, moderne Verschlüsselungen zu verwenden, aktuell bedeutet das im Idealfall die Verschlüsselung TLS 1.2 oder, falls nicht anders möglich, TLS 1.1. Die Nutzung von TLS 1.0 in neuen Systemen sollte vermieden werden, da es mittler- weile als veraltet gilt. Des Weiteren sollte »HTTP Strict Transport Security« (HSTS)21 genutzt werden. Dabei handelt es sich um ein Vorgehen, bei dem dem Nutzer direkt eine ver- schlüsselte Verbindung angeboten wird, auch wenn dieser eine unverschlüsselte Verbindung anfragt. Die Anwendung dieser Technologie ergibt Sinn, da heutzutage nahezu alle Endgeräte und Browser verschlüsselte Verbindungen unterstützen und die Sicherheit vor Man-in-the-Middle-Angriffen und Session-Übernahmen dadurch verbessert werden kann. Das entsprechende Cookie kann so gesetzt werden und wird von allen modernen Browsern unterstützt:

Strict-Transport-Security: -age=16070400; includeSubDomains

Bei Verschlüsselung handelt es sich eher um eine unterstützende Maßnahme, sie verhindert aus- schließlich das Auslesen der Session-ID durch Dritte während der Übermittlung — Schutz vor vorhersagbaren Session-IDs oder anderen Angriffsvektoren ist dadurch noch nicht gegeben.

Auf verschlüsselten Webseiten sollten ausschließlich Inhalte eingebettet sein, die ebenfalls über verschlüsselte Verbindungen abgerufen werden können. Wird die Einbettung über eine unverschlüsselte Verbindung vorgenommen, gefährdet das möglicherweise die Geheimhaltung der Session-ID. Um sicherzugehen, dass die Session-IDs vom Client immer über einen verschlüssel- ten Kanal gesendet werden, bietet es sich an, bei Setzen des Cookies eine Secure- Flag zu platzieren.

Set-Cookie: auth=172d046067681c6a5f5b7039434b868; Path=/accounts; Expires=Wed, 15 Jan 2020 12:37:49 GMT; Comment=Testcookie; Secure; … Die meisten Plattformen oder Server lassen in ihrer Konfiguration zudem zu, dass man dieses Verhalten grundsätzlich einschalten kann.

4.6.2 Sichere Generierung von Session-IDs Kern des Session-Managements ist die Session-ID. Die Geheimhaltung und Zufällig- keit der ID bestimmt die Sicherheit in besonderem Maße. Deshalb sollte darauf

21 Früher hieß diese Technologie einmal STS (Strict Transport Security). 4.6 Zusammenfassung: Abhilfe aus Entwicklersicht 103

geachtet werden, dass die Session-IDs nicht aus Werten generiert werden, die vorhersagbar sind (siehe Übersicht in Kapitel 4.3, »Session-Hijacking«). Es ist sinnvoll, erprobte Funktionen zur Generierung von IDs aus Frameworks zu nutzen und nicht seine eigenen (möglicherweise unsicheren) Methoden zu erstellen. Die oben genannten Session-ID-Names (siehe Tabelle in Kapitel 4, »Session- Angriffe«) und Verfahren zu Generierung gelten allesamt als sicher.

Falls es doch notwendig ist, ist es wichtig zu wissen, dass die random()-Funktionen einiger Programmiersprachen nur bedingt zufällig ist. Für Computer ist es schwer, »zufällige« Werte zu generieren, und es kommt immer wieder vor, dass Sicherheits- experten nachweisen können, dass manche Zufallsgeneratoren nicht so sicher bzw. zufällig sind wie angenommen. Insoweit empfiehlt sich bei der Generierung einer eigenen Session-ID die Nutzung eines nicht zufälligen Werts, etwa des Zeitstempels und einer zufälligen Zahl. Durch die Kombination aus zufälligem und nicht zufälligem Wert in der Session-ID wird Vorhersehbarkeit weitestgehend verhindert. Es sollte also keine voraussagbare Session-ID vorliegen und erst recht keine im Quelltext statisch codierte. Die Länge der Session-IDs ist ebenfalls wichtig — je länger ein ID ist, desto schwerer ist sie zu erraten (Mittel gegen Brute-Forcing). In der Praxis hat sich eine Länge von etwa 128 Bit (16 Byte) bewährt (je nach System und Anwendung).

4.6.3 Sonstige Maßnahmen Bei jeder neuen Anmeldung an eine Webapplikation (Autorisierung mittels Nutzer- name/Passwort) sollte eine neue Session-ID vergeben werden. Wie bereits erwähnt, sollte das Log-in mit einer verschlüsselten Seite stattfinden und nicht erst nach dem Log-in auf den verschlüsselten Bereich weitergeleitet werden. Es muss durch eine Vorabüberprüfung ausgeschlossen werden, dass bereits ein Nutzer die generierte Session-ID nutzt, um Session-Fixation vorzubeugen und um Kollisionen bei der Vergabe der IDs zu vermeiden. Es sollte keine Übertragung der Session-ID über die URL geben, besser ist die Ver- wendung von POST-Anfragen oder die Übertragung mittels Cookie. Die Übertragung sollte nicht über die URL stattfinden, da das zum einen die Session- Fixation erheblich erleichtert. Zum anderen gibt es sehr viele Systeme, die die ent- sprechenden URLs in ihre Listings übernehmen. So lassen sich in Google mit den richtigen Suchparametern unzählige Webseiten mit Session-IDs in der URL finden (siehe Abschnitt »Google-Dorking«), und es gibt vereinzelt Sitemaps oder Analyse- tools, in denen URLs versehentlich mit Session-ID gelistet werden.

Quellenverzeichnis

[1] W. Stuflesser, »MDR Nachrichten«, 5. Februar 2015. [Online]. Available: http://www.mdr.de/nachrichten/sony-hack-schaden100_zc-e9a9d57e_zs-6c4417e7.html. [Zugriff im November 2015] [2] T. Berners-Lee, »Information Management: A Proposal«, März 1989. [Online]. Available: http://www.w3.org/History/1989/proposal.html. [Zugriff im November 2015] [3] W. (CERN), »World Wide Web«, Dezember 1990. [Online]. Available: http://info.cern.ch/hypertext/WWW/TheProject.html. [Zugriff im November 2015] [4] S. S. N. A. Laboratory, »First U.S. Website: Documentation of the Early Web at SLAC (1991–1994)«, [Online]. Available: http://www.slac.stanford.edu/history/earlyweb/index.shtml. [Zugriff im November 2015] [5] Netcraft, »October 2015 Web Server Survey«, [Online]. Available: http://news.netcraft.com/archives/2015/10/16/october-2015-web-server-survey.html. [Zugriff im November 2015] [6] OWASP, »OWASP Top Ten Project«, 12. Juni 2013. [Online]. Available: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project. [Zugriff im November 2015] [7] Google, »Google Vulnerability Reward Program (VRP) Rules«, November 2010. [Online]. Available: https://www.google.com/about/appsecurity/reward-program/. [Zugriff im November 2015] [8] Facebook, Bug Bount Program von Facebook, [Online]. Available: https://www.facebook.com/whitehat/. [Zugriff im November 2015] [9] T. Berners-Lee, R. Fielding und H. Frystyk, »RFC 1945: Hypertext Transfer Protocol — HTTP/1.0«, Mai 1996. [Online]. Available: https://tools.ietf.org/pdf/rfc1945.pdf. [Zugriff im November 2015] [10] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L. Masinter, P. Leach und T. Berners-Lee, »RFC 2616: Hypertext Transfer Protocol — HTTP/1.1«, Juni 1999. [Online]. Available: https://tools.ietf.org/pdf/rfc2616.pdf. [Zugriff im November 2015] [11] M. Belshe, R. Peon und M. Thomson, Ed., »RFC 7540: Hypertext Transfer Protocol Version 2 (HTTP/2)«, Mai 2015. [Online]. Available: https://tools.ietf.org/pdf/rfc7540.pdf. [Zugriff im November 2015] 492 Quellenverzeichnis

[12] »ISO 8879: Standard Generalized Markup Language (SGML)«, Oktober 1986. [Online]. Available: http://www.iso.org/iso/catalogue_detail.htm?csnumber=16387. [Zugriff im September 2015] [13] B. Bos, »Cascading Style Sheets w3.org«, 23. Oktober 2015. [Online]. Available: http://www.w3.org/Style/CSS/. [Zugriff im November 2015] [14] B. Bos, T. Çelik, I. Hickson und H. W. Lie, »Cascading Style Sheets Level 2 Revi- sion 1 (CSS 2.1) Specification«, 17. Dezember 2014. [Online]. Available: http://www.w3.org/TR/CSS21/. [Zugriff im November 2015] [15] »VBScript is no longer supported in IE11 edge mode«, Microsoft, 22. Oktober 2015. [Online]. Available: https://msdn.microsoft.com/en- us/library/dn384057(v=vs.85).aspx. [Zugriff im November 2015] [16] »Usage Statistics and Market Share of Server-side Programming Languages for Websites, November 2015«, w3techs, November 2015. [Online]. Available: http://w3techs.com/technologies/overview/programming_language/all. [Zugriff im November 2015] [17] J. Corbet, »Resetting PHP 6«, 24. März 2010. [Online]. Available: http://lwn.net/Articles/379909/. [Zugriff im November 2015] [18] A. Faulds, »php.internals: Re: Name of Next Release of PHP (again)«, 29. Juli 2014. [Online]. Available: http://news.php.net/php.internals/76254. [Zugriff im Novem- ber 2015] [19] T. Berners-Lee, R. Fielding und L. Masinter, »RFC 3986: Uniform Resource Identifier (URI): Generic Syntax«, Januar 2005. [Online]. Available: http://tools.ietf.org/pdf/rfc3986.pdf. [Zugriff im November 2015] [20] T. Berners-Lee, »The WorldWideWeb browser«, [Online]. Available: http://www.w3.org/People/Berners-Lee/WorldWideWeb.html. [Zugriff im November 2015] [21] »Usage of character encodings for websites«, W3Techs, November 2015. [Online]. Available: http://w3techs.com/technologies/overview/character_encoding/all. [Zugriff im November 2015] [22] M.-A. Montpas, »Security Advisory — WP-Slimstat 3.9.5 and Lower«, sucuri, 24. Februar 2015. [Online]. Available: https://blog.sucuri.net/2015/02/security- advisory-wp-slimstat-3-9-5-and-lower.html. [Zugriff im November 2015] [23] M. Kolšek, »Session Fixation Vulnerability in Web-based Applications«, ACROS Security, Dezember 2002. [Online]. Available: http://www.acros.si/papers/session_fixation.pdf. [Zugriff im November 2015] Quellenverzeichnis 493

[24] T. Schreiber, »SESSION RIDING: A Widespread Vulnerability in Today's Web Applications«, SecureNet GmbH, Dezember 2004. [Online]. Available: http://www.securenet.de/papers/Session_Riding.pdf. [Zugriff im November 2015] [25] C. Shiflett, »My Amazon Anniversary«, 15. März 2007. [Online]. Available: http://shiflett.org/blog/2007/mar/my-amazon-anniversary. [Zugriff im November 2015] [26] M. Mimoso, »CSRF Vulnerability patched in GoDaddy Domain Settings«, Threatpost, 20. Januar 2015. [Online]. Available: https://threatpost.com/csrf- vulnerability-patched-in-godaddy-domain-settings/110538/. [Zugriff im November 2015] [27] T. P. Schäfers und S. Neef, »Mozilla Foundation Security Advisory 2014-20«, 18. März 2014. [Online]. Available: https://www.mozilla.org/en- US/security/advisories/mfsa2014-20/. [Zugriff im November 2015] [28] S. Kamkar, »Technical explanation of The MySpace Worm«, [Online]. Available: http://samy.pl/popular/tech.html. [Zugriff im November 2015] [29] T. Perez, »Serious Cross Site Scripting Vulnerability in TweetDeck — Twitter«, 14. Juni 2014. [Online]. Available: https://blog.sucuri.net/2014/06/serious-cross-site- scripting-vulnerability-in-tweetdeck-twitter.html. [Zugriff im November 2015] [30] A. Klein, »DOM Based Cross Site Scripting or XSS of the Third Kind«, 4. Juli 2005. [Online]. Available: http://www.webappsec.org/projects/articles/071105.html. [Zugriff im November 2015] [31] B. Lincoln, »Major Internet Explorer Vulnerability — NOT Patched«, 31. Januar 2015. [Online]. Available: http://seclists.org/fulldisclosure/2015/Feb/0. [Zugriff im November 2015] [32] XSS Jigsaw, »Analysis on Internet Explorer's UXSS«, 4. Februar 2015. [Online]. Available: https://blog.innerht.ml/ie-uxss/. [Zugriff im November 2015] [33] M. Bynens, »In search of the perfect URL validation regex«, [Online]. Available: https://mathiasbynens.be/demo/url-regex. [Zugriff im November 2015] [34] hashbangcode, »filter_var() URL Validation«, [Online]. Available: http://www.hashbangcode.com/examples/filter_var_url_validate/. [Zugriff im November 2015] [35] Microsoft, »How To: Prevent Cross-Site Scripting in ASP.NET«, Mai 2005. [Online]. Available: https://msdn.microsoft.com/en-us/library/ff649310.aspx. [Zugriff im November 2015] [36] D. Cruz, »Bypassing asp.net request validation detection, but it is a vulnerability?«, Juni 2014. [Online]. Available: http://blog.diniscruz.com/2014/06/ bypassing-aspnet-request-validation.html. [Zugriff im November 2015]

494 Quellenverzeichnis

[37] Facebook, »Facebook Hilfebereich — Wie funktioniert ein Self-XSS-Betrug?«, Mai 2015. [Online]. Available: https://www.facebook.com/help/246962205475854. [Zugriff im November 2015] [38] P. Uhley, »Creating more secure SWF web applications«, 20. Dezember 2007. [Online]. Available: http://www.adobe.com/devnet/flashplayer/articles/secure_swf_apps.html. [Zugriff im November 2015] [39] J. Grossman, »What you need to know about the UXSS in the Acrobat Plugin«, 4. Januar 2007. [Online]. Available: http://jeremiahgrossman.blogspot.de/2007/01/what-you-need-to-know-about-uxss- in.html. [Zugriff im November 2015] [40] M. Heiderich, T. Frosch, J. Schwenk, J. Magazinius und E. Z. Yang, »mXSS: Attacks: Attaching well-secured Web-Applications by using innerHTML Mutations«, 4. November 2013. [Online]. Available: http://www.cse.chalmers.se/~d02pulse/thesis/innerhtml.pdf. [Zugriff im November 2015] [41] M. Heiderich, M. Niemietz, F. Schuster, T. Holz und J. Schwenk, »Scriptless Attacks — Stealing the Pie Without Touching the Sill«, Oktober 2012. [Online]. Available: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.469.7647&rep=rep1&type=pdf. [Zugriff im November 2015] [42] M. Heiderich, »Youtube: Wie Angreifer ganz ohne JavaScript an Deine wertvollen Daten kommen — Mario Heiderich beim MMT 29«, 24. März 2012. [Online]. Available: https://www.youtube.com/watch?v=22Ujc7hTcD0. [Zugriff im November 2015] [43] rain.forest.puppy, »Phrack Magazin: NT Web Technology Vulnerabilities«, 25. Dezember 1998. [Online]. Available: http://phrack.org/issues/54/8.html. [Zugriff im November 2015] [44] S. Kille, »RFC 1779: A String Representation of Distinguished Name«, März 1995. [Online]. Available: https://tools.ietf.org/pdf/rfc1779.pdf. [Zugriff im November 2015] [45] G. Good, »RFC 2849: The LDAP Data Interchange Format (LDIF) — Technical Specificati«, Juni 2000. [Online]. Available: https://tools.ietf.org/pdf/rfc2849.pdf. [Zugriff im November 2015] [46] K. Zeillenga, »RFC 4510: Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map«, Juni 2006. [Online]. Available: https://tools.ietf.org/pdf/rfc4510.pdf. [Zugriff im November 2015] Quellenverzeichnis 495

[47] C. Alonso, R. Bordó, A. Guzmán und M. Beltrán, »LDAP Injection & Blind LDAP Injection (In Web Applications)«, März 2008. [Online]. Available: https://www.blackhat.com/presentations/bh-europe-08/Alonso-Parada/Whitepaper/bh- eu-08-alonso-parada-WP.pdf. [Zugriff im November 2015] [48] T. Howes, »RFC 2254: The String Representation of LDAP Search Filters«, Dezember 1997. [Online]. Available: https://tools.ietf.org/pdf/rfc2254.pdf. [Zugriff im November 2015] [49] A. Berglund, S. Boag, D. Chamberlin, M. F. Fernández, M. Kay, J. Robie und J. Siméon, »XML Path Language (XPath) 2.0 (Second Edition)«, 14. Dezember 2010. [Online]. Available: http://www.w3.org/TR/xpath20/. [Zugriff im November 2015] [50] M. Chow, »Abusing NoSQL Databases«, August 2013. [Online]. Available: https://www.defcon.org/images/defcon-21/dc-21-presentations/Chow/DEFCON-21-Chow- Abusing-NoSQL-Databases.pdf. [Zugriff im November 2015] [51] R. Butturini, »Making Mongo Cry: NoSQL for Penetration Testers«, 2014. [Online]. Available: http://slideplayer.com/slide/2510942/. [Zugriff im November 2015] [52] P. Beuth, »golem.de — Keine Nacktfotos sind auch keine Lösung«, 2. September 2014. [Online]. Available: http://www.golem.de/news/datensicherheit-keine- nacktfotos-sind-auch-keine-loesung-1409-108966.html. [Zugriff im November 2015] [53] hackappcom, »Github: AppleID bruteforce«, September 2014. [Online]. Available: https://github.com/hackappcom/ibrute. [Zugriff im November 2015] [54] dbrgn, »Hackernews — PHP: md5('240610708') == md5('QNKCDZO')«, 5. Mai 2015. [Online]. Available: https://news.ycombinator.com/item?id=9484757. [Zugriff im November 2015] [55] The PHP Group, »PHP: strcmp — Manual«, [Online]. Available: http://php.net/manual/de/function.strcmp.php. [Zugriff im November 2015] [56] The PHP Group, »PHP: Tabelle zu Typenvergleichen in PHP — Manual«, [Online]. Available: http://php.net/manual/de/types.comparisons.php. [Zugriff im November 2015] [57] S. Neef und T. P. Schäfers, »Internetwache.org — Paypal behebt Path Traversal Lücke«, 10. September 2013. [Online]. Available: https://www.internetwache.org/paypal-behebt-path-traversal-lucke-10-09-2013/. [Zugriff im November 2015] [58] R. Silva, »XXE in OpenID: one bug to rule them all, or how I found a Remote Code Execution flaw affecting Facebook's servers«, Dezember 2013. [Online]. Available: http://www.ubercomp.com/posts/2014-01- 16_facebook_remote_code_execution. [Zugriff im November 2015]

496 Quellenverzeichnis

[59] J. Leyden, »The Register: Facebook coughs up $33.5k... its BIGGEST bug bounty EVER«, 24. Januar 2014. [Online]. Available: http://www.theregister.co.uk/2014/01/24/facebook_bug_bounty_payout/. [Zugriff im November 2015] [60] M. Ramadan, »How I Hacked Facebook with a Word Document«, 7. Oktober 2015. [Online]. Available: http://www.attack-secure.com/blog/hacked-facebook-word- document. [Zugriff im November 2015] [61] F. Almroth und M. Karlsson, »How we got read access on Google’s production servers«, 4. November 2014. [Online]. Available: http://blog.detectify.com/post/82370846588/how-we-got-read-access-on-- production. [Zugriff im November 2015] [62] P. Prasad, »Shopify: Remote Code Execution«, 16. Juli 2015. [Online]. Available: https://prakharprasad.com/shopify-remote-code-execution/. [Zugriff im November 2015] [63] The PHP Group, »PHP: exec — Manual«, [Online]. Available: http://php.net/manual/de/function.exec.php. [Zugriff im November 2015] [64] P. Prasad, »Hackerone — Attention! Remote Code Execution at http://wpt.ec2.shopify.com/«, Juli 2015. [Online]. Available: https://hackerone.com/reports/73567. [Zugriff im November 2015] [65] P. Meenan, »Added filtering to the testlog search string«, 15. Juli 2015. [Online]. Available: https://github.com/WPO-Foundation/webpagetest/ commit/225b429bc6d0f6e19f5f54fde525602132c748bf. [Zugriff im November 2015] [66] J. Postel, »RFC 821: Simple Mail Transfer Protocol«, August 1982. [Online]. Available: https://tools.ietf.org/pdf/rfc821.pdf. [Zugriff im November 2015] [67] P. Resnick, »RFC 5322: Internet Message Format«, Oktober 2008. [Online]. Available: https://tools.ietf.org/pdf/rfc5322.pdf. [Zugriff im November 2015] [68] P. Fehrenbach und B. Sadeghipour, »Email Spoofing via Google Admin Console«, 13. März 2015. [Online]. Available: http://nahamsec.com/lack-of-domain- verification-by-google/. [Zugriff im November 2015] [69] S. Brakhane, »Hackerone — A 'Full access' administrator is able to see the shop owners user details«, 31. Oktober 2015. [Online]. Available: https://hackerone.com/reports/96890. [Zugriff im November 2015] [70] S. Neef und T. P. Schäfers, »Internetwache.org — AXFR-Scan der Alexa Top 1 Million«, 29. März 2015. [Online]. Available: https://www.internetwache.org/axfr-scan- der-alexa-top-1-million-29-03-2015/. [Zugriff im November 2015] [71] S. Neef und T. P. Schäfers, »Internetwache.org — Wie ungeschützte .git Repositorys die Sicherheit Ihrer Webseite gefährden — Eine Analyse der Alexa 1M«, 28. Juli 2015. [Online]. Available: https://www.internetwache.org/wie-ungeschutzte-git- Quellenverzeichnis 497

repositorys-die-sicherheit-ihrer-webseite-gefahrden-eine-analyse-der-alexa-1m-28-07- 2015/. [Zugriff im November 2015] [72] Typo3 Documentation Team, »Typo3 — Install Tools«, 8. September 2015. [Online]. Available: https://docs.typo3.org/typo3cms/SecurityGuide/ GuidelinesIntegrators/InstallTool/Index.html. [Zugriff im November 2015] [73] S. Neef und T. P. Schäfers, »Internetwache.org — Den Paypal-Phishern auf der Spur«, 11. März 2013. [Online]. Available: https://www.internetwache.org/den-paypal- phishern-auf-der-spur-11-03-2013/. [Zugriff im November 2015] [74] A. Kannenberg, »Heise.de — Betrugsmasche aufgewärmt: Falsche Microsoft- Techniker am Telefon«, 19. Juni 2015. [Online]. Available: http://www.heise.de/ newsticker/meldung/Betrugsmasche-aufgewaermt-Falsche-Microsoft-Techniker-am- Telefon-2718299.html. [Zugriff im November 2015] [75] R. Lemos, »You don't know (click)jack«, 15. Oktober 2008. [Online]. Available: http://www.securityfocus.com/news/11535/. [Zugriff im November 2015] [76] K. Kotowicz, »Cursorjacking again«, 18. Januar 2012. [Online]. Available: http://blog.kotowicz.net/2012/01/cursorjacking-again.html. [Zugriff im November 2015] [77] E. Lawrence, »IEBlog — IE Security Part VII: ClickJacking Defenses«, 28. Januar 2009. [Online]. Available: http://blogs.msdn.com/b/ie/archive/2009/01/27/ie8- security-part-vii-clickjacking-defenses.aspx. [Zugriff im November 2015] [78] D. Ross und T. Gondrom, »RFC 7034: "HTTP Header Field X-Frame-Options"«, Oktober 2013. [Online]. Available: https://tools.ietf.org/pdf/rfc7034.pdf. [Zugriff im November 2015] [79] T. Melamed, »AppSec: X-Frame-Option is dead, long live Content Security Policy!«, 10. März 2014. [Online]. Available: https://appsec-labs.com/portal/anti- clickjacking/. [Zugriff im November 2015] [80] M. Weissbacher, T. Lauinger und W. Robertson, »Why is CSP Failing? Trends and Challenges in CSP Adoption«, September 2014. [Online]. Available: http://tobias.lauinger.name/papers/csp-raid2014.pdf. [Zugriff im November 2015] [81] G. Rydstedt, E. Bursztein und D. Boneh, »Busting Frame Busting: a Study of Clickjacking Vulnerabilities on Popular Sites«, 20. Juli 2010. [Online]. Available: http://seclab.stanford.edu/websec/framebusting/framebust.pdf. [Zugriff im November 2015] [82] T. Çelik, K. Marks, M. Cutts und J. Shellen, »microformats — rel="nofollow"«, 10. Januar 2015. [Online]. Available: http://microformats.org/wiki/rel-nofollow. [Zugriff im November 2015]

498 Quellenverzeichnis

[83] n-tv.de, »n-tv.de — Fehler bei : "Scheiße" führt zu Schalke«, 15. Juli 2011. [Online]. Available: http://www.n-tv.de/technik/Scheisse-fuehrt-zu-Schalke- article3824281.html. [Zugriff im November 2015] [84] B. Krebs, »Bidding for Breaches, Redefining Targeted Attacks«, 23. September 2015. [Online]. Available: http://krebsonsecurity.com/2015/09/bidding-for-breaches- redefining-targeted-attacks/. [Zugriff im November 2015] [85] spiegel.de, »spiegel.de — BND will Informationen über Software-Sicherheits- lücken einkaufen«, 9. November 2014. [Online]. Available: http://www.spiegel.de/ spiegel/vorab/bnd-will-informationen-ueber-software-sicherheitsluecken-einkaufen-a- 1001771.html. [Zugriff im November 2015]

60417-8 Titelei_X 07.07.15 13:57 Seite 1

Dr. Patrick Engebretson Hacking Handbuch

Penetrationstests planen und durchführen: Seien Sie schneller als die Hacker und nutzen Sie deren Techniken und Tools: , Metasploit, Armitage, Wireshark, JtR, Rootkits, Netcat, Meterpreter und mehr. 5

Inhaltsverzeichnis

Danksagung...... 11

Der Autor...... 13

Einleitung...... 15

1 Penetrationstests – was ist das?...... 25 1.1 Einführung...... 25 1.2 Vorbereitungen...... 26 1.3 Einführung in Kali Linux: »Werkzeuge. Jede Menge Werkzeuge.«...... 30 1.4 Arbeiten auf dem Angriffscomputer: Die Engine starten...... 36 1.5 Ein Hacker-Labor einrichten und nutzen...... 40 1.6 Die Phasen eines Penetrationstests...... 43 1.7 Wie geht es weiter?...... 50 1.8 Zusammenfassung...... 51

2 Aufklärung...... 53 2.1 Einführung...... 53 2.2 HTTrack: Ein Website-Kopierer...... 59 2.3 Google-Direktiven: Üben Sie sich in Google-Fu!...... 64 2.4 Harvester: E-Mail-Adressen aufspüren und ausnutzen...... 73 2.5 Whois...... 77 2.6 Der Befehl host...... 83 2.7 Informationen von DNS-Servern abrufen...... 84 6 Inhaltsverzeichnis

2.8 NSLookup...... 86 2.9 Dig...... 89 2.10 Fierce: Wenn eine Zonenübertragung nicht möglich ist...... 90 2.11 Informationen von E-Mail-Servern gewinnen...... 92 2.12 MetaGooFil...... 93 2.13 ThreatAgent: Drohnenangriff...... 95 2.14 Social Engineering...... 97 2.15 Die Informationen nach angreifbaren Zielen durchsuchen...... 99 2.16 Wie übe ich diesen Schritt?...... 101 2.17 Wie geht es weiter?...... 101 2.18 Zusammenfassung...... 103

3 Scan...... 105 3.1 Einführung...... 105 3.2 Pings und Ping-Folgen...... 111 3.3 Portscans...... 114 3.4 Der Drei-Wege-Handshake...... 117 3.5 TCP-Verbindungsscans mit Nmap...... 117 3.6 SYN-Scans mit Nmap...... 120 3.7 UDP-Scans mit Nmap...... 122 3.8 Weihnachtsbaumscans mit Nmap...... 126 3.9 NULL-Scans mit Nmap...... 128 3.10 Die Nmap-Script-Engine: Von der Raupe zum Schmetterling...... 129 3.11 Portscans: Zusammenfassung...... 132 3.12 Schwachstellen-Scan...... 133 3.13 Wie übe ich diesen Schritt?...... 141 3.14 Wie geht es weiter?...... 143 3.15 Zusammenfassung...... 144 Inhaltsverzeichnis 7

4 Eindringen...... 145 4.1 Einführung...... 145 4.2 Medusa: Zugriff auf Remotedienste gewinnen...... 148 4.3 Metasploit: Hacking im Hugh-Jackman-Stil...... 154 4.4 JtR: König der Passwortcracker...... 172 4.5 Lokales Passwortcracking...... 176 4.6 Knacken von Passwörtern über das Netzwerk...... 186 4.7 Knacken von Linux-Passwörtern...... 187 4.8 Passwörter zurücksetzen: Die Abrissbirnen-Technik...... 189 4.9 Sniffing: Netzwerkdatenverkehr ausspähen...... 193 4.9.1 Macof: Aus einem Switch einen Hub machen...... 196 4.9.2 Wireshark: Der Hai im Datenmeer...... 197 4.10 Armitage: Hacking wie mit dem Maschinengew­ ehr...... 201 4.11 Warum fünf Werkzeuge lernen, wenn doch eines reicht?...... 205 4.12 Wie übe ich diesen Schritt?...... 209 4.13 Wie geht es weiter?...... 213 4.14 Zusammenfassung...... 216

5 Social Engineering...... 219 5.1 Einführung...... 219 5.2 Die Grundlagen von SET...... 220 5.3 Websites als Angriffswege...... 224 5.4 Credential Harvester...... 232 5.5 Weitere Optionen in SET...... 234 5.6 Zusammenfassung...... 237

6 Webgestützte Eindringversuche...... 239 6.1 Einführung...... 239 6.2 Grundlagen des Webhackings...... 241 6.3 Nikto: Abfragen von Webservern...... 243 8 Inhaltsverzeichnis

6.4 W3af: Mehr als nur eine hübsche Oberfläche...... 245 6.5 Spider: Die Zielwebsite analysieren...... 249 6.6 Anforderungen mit WebScarab abfangen...... 254 6.7 Codeinjektion...... 257 6.8 XSS-Angriffe: Wenn Browser Websites vertrauen...... 263 6.9 Zed Attack Proxy: Alles unter einem Dach...... 267 6.10 Informationen mit ZAP abfangen...... 269 6.11 Spiderangriffe mit ZAP...... 271 6.12 Scannen mit ZAP...... 272 6.13 Wie übe ich diesen Schritt?...... 273 6.14 Wie geht es weiter?...... 275 6.15 Weitere Quellen...... 275 6.16 Zusammenfassung...... 276

7 Nacharbeiten und Erhaltung des Zugriffs mit Hintertüren, . Rootkits und Meterpreter...... 279 7.1 Einführung...... 279 7.2 Netcat: Das Schweizer Messer...... 281 7.3 Netcats kryptischer Vetter: Cryptcat...... 289 7.4 Rootkits...... 290 7.5 Hacker Defender: Nicht das, wofür Sie es halten...... 292 7.6 Rootkits erkennen und abwehren...... 298 7.7 Meterpreter: Der Hammer, der aus allem einen Nagel macht...... 300 Inhaltsverzeichnis 9

7.8 Wie übe ich diesen Schritt?...... 304 7.9 Wie geht es weiter?...... 306 7.10 Zusammenfassung...... 307

8 Der Abschluss eines Penetrationstests...... 309 8.1 Einführung...... 309 8.2 Den Testbericht schreiben...... 310 8.3 Die Zusammenfassung für die Geschäftsführung...... 312 8.4 Der ausführliche Bericht...... 312 8.5 Die Rohausgaben...... 315 8.6 Sie müssen nicht nach Hause gehen, aber hierbleiben können Sie auch nicht...... 320 8.7 Wie geht es weiter?...... 323 8.8 Schlusswort...... 325 8.9 Der Kreislauf des Lebens...... 326 8.10 Zusammenfassung...... 327

11

Dieses Buch ist Gott und meiner Familie gewidmet. Es ist an der Zeit, es wie Zac Brown zu halten und bis »an die Knie« im Wasser zu waten.

Danksagung

Ich möchte allen danken, die dazu beigetragen haben, dass diese Ausgabe möglich wurde. Ein Buch herauszugeben ist Teamarbeit, und ich fühle mich gesegnet, dass ich so großartigen Teamkameraden begegnet bin. Die folgende Liste ist leider unzureichend, wofür ich mich gleich im Voraus entschuldigen und allen danken möchte, die in irgendeiner Weise dazu beigetragen haben, dieses Buch zu verwirklichen. Mein besonderer Dank geht an:

Meine Frau Mein Fels, mein Leuchtturm, mein Stahlseil! Danke für deine Ermutigung, deinen Glauben, deine Unterstützung und deine Bereitschaft, wieder einmal zur »alleinerziehenden Mutter« zu werden, während ich mich für Stunden und Tage zurückzog, um an der zweiten Ausgabe zu arbeiten. Wie bei so vielen anderen Dingen im Leben bin ich mir auch bei diesem Buch sicher, dass es ohne dich nicht möglich gewesen wäre. Mehr als allen anderen verdanke ich dieses Werk dir. Ich liebe dich.

Meine Mädchen Ich weiß, dass diese Ausgabe für euch in vieler Hinsicht schwierig war, da ihr alt genug seid, um mich zu vermissen, wenn ich nicht da bin, aber noch zu jung, um zu verstehen, warum ich das tue. Ich hoffe, dass ihr eines Tages, wenn ihr alt genug seid, zu diesem Buch greifen und erkennen werdet, dass alles, was ich in meinem Lebe tue, für euch ist. 12 Danksagung

Meine Familie Ich möchte meinem weiteren Familienkreis für die Liebe und Unterstützung danken. Ein besonderer Dank geht an meine Mutter Joyce, die meine inoffizielle Lektorin gab und dieses Buch wahrscheinlich häufiger gelesen hat als irgendjemand sonst. Deine schnelle Rückmeldung und deine Einsichten waren von unschätzbarem Wert.

Dave Kennedy Es war für mich eine große Ehre, dass du dich an meinem Buch beteiligst hast. Ich weiß, wie sehr dich deine Familie, TrustedSec, DEFCON, SET und deine vielen anderen verrückten Projekte in Anspruch nehmen, aber du hast dir immer Zeit für dieses Buch genommen, und deine Einsichten haben es viel besser gemacht, als ich hoffen durfte. Danke, mein Freund. (Fühl dich geknuddelt.) Es wäre sehr nachlässig von mir, wenn ich Dave nicht noch die gebührende zusätzliche Anerkennung geben würde; er hat nämlich nicht nur als technischer Gutachter zu diesem Buch beigetragen, sondern auch unermüdlich daran gearbeitet, es Kali-konform zu machen, und (naturgemäß) das Kapitel 5 (über SET) komplett übernommen.

Jared Demott Was kann ich über den einzigen Menschen sagen, neben dem ich mir am Computer wie ein Vollidiot vorkomme? Vielen Dank dafür, dass du dir die Zeit genommen und meine Arbeit unterstützt hast. Du bist mir zu einem großartigen Freund geworden, und ich schätze deine Hilfe sehr.

Das Syngress-Team Danke für diese neue Gelegenheit! Danke an das Herausgeberteam. Ich schätze eure harte Arbeit und euren Einsatz für dieses Projekt. Ein besonderer Dank geht an Chris Katsaropoulos für all seine Mühen. 13

Der Autor

Dr. Patrick Engebretson hat seinen Doktor in Informationssicherheit an der Dakota State University erworben. Zurzeit arbeitet er als Privatdozent für Computer- und Netzwerksicherheit sowie als leitender Penetrationstester für ein Sicherheitsunternehmen im mittleren Westen der USA. Zu seinen Forschungsgebieten gehören Penetrationstests, Hacking, Ausnutzung von Schwachstellen und Malware. Dr. Engebretson ist als Redner sowohl bei der DEFCON als auch bei der Black-Hat-Konferenz in Las Vegas aufgetreten. Außerdem wurde er vom US-Ministerium für Heimatschutz eingeladen, seine Forschungsergebnisse im Software Assurance Forum in Washington vorzustellen. Er nimmt regelmäßig an Exploit- und Penetrationstestschulungen für Fortgeschrittene teil, die von anerkannten Experten der Branche abgehalten werden, und weist mehrere Zertifizierungen auf. Des Weiteren gibt er Vor- und Hauptstudiumskurse in Penetrationstests, Malware-Analyse und fortgeschrittener Ausnutzung von Schwachstellen.

15

Einleitung

Es ist kaum zu glauben, dass seit der ersten Ausgabe dieses Buches bereits zwei Jahre vergangen sind. Angesichts der Beliebtheit und der (größtenteils positiven) Rückmeldung, die ich zu dem ursprünglichen Manuskript erhalten habe, war ich sehr bestrebt, diese zweite Ausgabe auf den Weg zu bringen. Es ist nicht so, dass sich der Stoff sehr stark geändert hätte. Die Grundlagen von Hacking und Penetrationstests sind nach wie vor die Basis. Nachdem ich die erste Ausgabe fertig gestellt hatte, kam ich durch Kommunikation mit den Lesern und durch zahllose Verbesserungsvorschläge von Verwandten, Freunden und Kollegen zu der Überzeugung, dass diese neue Ausgabe das Original in jeder Hinsicht überflügeln würde. Einiges älteres (veraltetes) Material wurde entfernt, dafür kam etwas neuer Stoff hinzu, und das gesamte Buch wurde noch einmal kräftig aufpoliert. Wie die meisten Personen, die im Bereich der Sicherheit tätig sind, habe ich dazugelernt, meine Lehrmethoden haben sich weiterentwickelt, und meine Studenten fordern mich, sie immer wieder mit neuem Material zu versorgen. Daher verfüge ich über einige großartige neue Werkzeuge und Ergänzungen und freue mich sehr darauf, Ihnen dieses Mal etwas darüber mitzuteilen. Ich bin dankbar für all die Rückmeldungen, die ich zur ersten Ausgabe erhalten habe, und habe hart daran gearbeitet, die zweite Ausgabe noch besser zu machen.

Als ich begann, die zweite Ausgabe vorzubereiten, habe ich mir jedes Kapitel genau angesehen, um sicherzustellen, dass nur das beste und bedeutendste Material Eingang darin findet. Wie es oft bei solchen Zweitausgaben der Fall ist, finden Sie einige Stellen, bei denen der Stoff mit dem der Originalausgabe identisch ist, während er an anderen Stellen auf den neuesten Stand gebracht wurde, um neue Werkzeuge einzubeziehen und veraltete herauszunehmen. Für viele von Ihnen ist es aber wahrscheinlich am wichtigsten, dass ich viele neue Themen und Werkzeuge sowie Antworten auf die Fragen hinzugefügt habe, die mir am häufigsten gestellt wurden. Zur Qualitätssicherung haben sowohl Dave Kenney als auch ich selbst alle 16 Einleitung

Beispiele und Werkzeugbeschreibungen in diesem Buch durchgearbeitet und jeden einzelnen Screenshot auf den neuesten Stand gebracht. Das Buch wurde außerdem komplett auf Kali Linux ausgerichtet.

Ich möchte allen Lesern der Erstausgabe danken, die mir Fragen und Korrekturen gesandt haben, und ich habe dafür gesorgt, dass all diese Verbesserungen eingeflossen sind. Unabhängig davon, ob Sie zum ersten Mal zu diesem Buch greifen oder ob Sie die Neuausgabe nutzen, um sich über die neuen Werkzeuge zu informieren, bin ich mir sicher, dass Sie an dieser Ausgabe Ihre Freude haben werden.

Wie ich schon zu Beginn der ersten Ausgabe bemerkt habe, bin ich mir sicher, dass Ihnen verschiedene Fragen durch den Kopf gehen, wenn Sie überlegen, ob Sie dieses Buch lesen sollten: Wer ist das Zielpublikum für dieses Buch? Wie unterscheidet sich dieses Buch von X? (Setzen Sie hier den Titel Ihres Lieblingsbuchs zum Thema ein.) Warum sollte ich es kaufen? Was muss ich alles einrichten, um die Beispiele nachvollziehen zu können? All dies sind gerechtfertigte Fragen, und da ich von Ihnen verlange, Zeit und Geld für dieses Buch aufzuwenden, ist es wichtig, dass ich Ihnen darauf antworte.

Für Personen, die sich für Hacking und Penetrationstests interessieren, kann der Besuch einer gut sortierten Buchhandlung genauso verwirrend sein wie die Suche nach Hacking-Tutorials im Internet. Es scheint eine fast unbegrenzte Auswahl zu geben. Viele große Buchhandlungen haben mehrere Regale der Computersicherheit gewidmet. Dazu zählen Bücher über sicheres Programmieren, über Netzwerksicherheit, Sicherheit von Webanwendungen, Sicherheit von Mobilgeräten, Rootkits, Malware, Penetrationstests, Bewertung von Schwachstellen, Ausnutzung von Schwachstellen und natürlich Hacking. Allerdings finden Sie auch bei den Büchern über »Hacking« eine große Bandbreite an Inhalten und Themen. Manche Werke konzentrieren sich auf die Verwendung von Werkzeugen, sagen aber nichts darüber aus, wie diese Werkzeuge zusammenwirken. Andere wiederum sind besonderen Gebieten des Hackings gewidmet, ohne ein Gesamtbild zu vermitteln. Einleitung 17

Dieses Buch soll dazu beitragen, die Verwirrung zu lösen. Es ist als einfacher Ausgangspunkt für alle Personen gedacht, die sich für Hacking und Penetrationstests interessieren. Der Text, den Sie hier lesen werden, beschreibt nicht nur einzelne Werkzeuge und Themen, sondern zeigt auch, wie die Werkzeuge zusammenwirken und sich aufeinander stützen, um zum Erfolg beizutragen. Sie müssen sowohl die einzelnen Werkzeuge als auch die richtige Methodik (d. h. die »Reihenfolge«) Ihrer Anwendung meistern, um beim Erlernen der Grundlagen Erfolg zu haben. Das heißt, Sie müssen nicht nur wissen, wie Sie die verschiedenen Werkzeuge einsetzen, sondern auch, in welcher Beziehung sie zueinander stehen und was Sie tun müssen, wenn eines dieser Werkzeuge versagt.

Was ist neu in dieser Ausgabe?

Wie bereits erwähnt, habe ich viel Zeit aufgewendet, um alle berechtigten Kritikpunkte und Probleme anzugehen, auf die mich die Leser der ersten Ausgabe aufmerksam gemacht haben. Ich habe sämtliche Beispiele aller Kapitel durchgearbeitet, um sicherzustellen, dass sie konsistent sind und zum Thema passen. Insbesondere werden die einzelnen Angriffsmethoden und Werkzeuge in dieser Ausgabe viel besser strukturiert, geordnet, gegliedert und klassifiziert. Ich habe auch viel Zeit aufgewendet, um zwischen »lokalen« Angriffen und solchen zu unterscheiden, die »über das Netzwerk« ausgeführt werden, damit meine Leser den Zweck, den Blickwinkel und die Denkrichtung der einzelnen Themen besser verstehen können. Außerdem habe ich die Beispiele neu angeordnet, damit sich die besprochenen Angriffe gegen ein einzelnes Ziel (Metasploitable) leichter nachvollziehen lassen. Die einzige Ausnahme dabei bildet die Aufklärungsphase. Um sie wirkungsvoll durchführen zu können, sind meistens »aktive« Ziele erforderlich.

Neben den Änderungen im Aufbau habe ich mehrere in der ursprünglichen Ausgabe erwähnte Werkzeuge herausgenommen und durch neue ersetzt, z. B. ThreatAgent, DNS-Abfragewerkzeuge, die Nmap-Skript-Engine, das SET (Social Engineering Toolkit), Armitage, Meterpreter, W3af, ZAP usw. 18 Einleitung

Auch die Informationen zu einzelnen Werkzeugen wurden aktualisiert, und die Beispiele funktionieren jetzt in Kali Linux.

Zu guter Letzt habe ich auch die ZEH-Methodik (Zero Entry Hacking) um Tätigkeiten, Werkzeuge und Prozesse für die Nacharbeiten nach dem eigentlichen Eindringen erweitert.

An wen richtet sich dieses Buch?

Dieses Buch ist als sehr behutsame und doch gründliche Einführung in die Welt des Hackings und der Penetrationstests gedacht. Insbesondere soll es Ihnen helfen, die grundlegenden Schritte eines Penetrationstests zu meistern, ohne Sie zu überfordern. Wenn Sie dieses Buch durchgearbeitet haben, verfügen Sie über ein solides Verständnis von Penetrationstests und sind mit den grundlegenden Werkzeugen dafür vertraut.

Um es ganz deutlich zu sagen: Dieses Buch richtet sich an Personen, für die Hacking und Penetrationstests etwas Neues sind, die wenig oder gar keine Erfahrungen damit haben, die sich einen Gesamtüberblick verschaffen möchten (darüber, wie die einzelnen Werkzeuge und Phasen zusammenwirken), die schnell die grundlegenden Werkzeuge und Methoden für Penetrationstests beherrschen lernen wollen oder die einfach nur ihre Kenntnisse über offensive Sicherheit erweitern möchten.

Kurz gesagt eignet sich dieses Buch für alle, die an Computersicherheit, Hacking oder Penetrationstests interessiert sind, aber keine vorherigen Erfahrungen haben und nicht sicher sind, wo sie anfangen sollen. Ein Kollege und ich nennen dieses Konzept »Zero Entry Hacking« (ZEH), also etwa »Hacking angefangen bei null«. Es ähnelt ein bisschen den modernen Schwimmbecken, die sanft vom Rand zum tiefen Bereich abfallen und es damit den Schwimmern erlauben, langsam hineinzuwaten, ohne sich überfordert zu fühlen oder zu befürchten, dass sie ertrinken werden. Durch dieses Prinzip kann das Becken unabhängig vom Alter und den Einleitung 19

Schwimmkünsten von allen genutzt werden. Dieses Buch verfolgt einen ähnlichen Ansatz. ZEH soll Sie mit den Grundprinzipien vertraut machen, ohne Sie zu überfordern. Wenn Sie dieses Buch durchgearbeitet haben, sind Sie für Fortgeschrittenenkurse, weiterführende Themen und Bücher gewappnet.

Wie unterscheidet sich dieses Buch von anderen?

Davon abgesehen, Zeit mit meiner Familie zu verbringen, sind mir zwei Beschäftigungen am liebsten: Lesen und Hacking. Meistens kombiniere ich diese beiden Interessen, indem ich etwas über Hacking lese. Da ich Dozent und Penetrationstester bin, können Sie sich vorstellen, dass mein Bücherregal vollgestopft mit Büchern über Hacking, Sicherheit und Penetrationstests ist. Wie bei fast allen Dingen im Leben schwanken auch bei diesen Büchern die Qualität und der Wert sehr stark. Einige sind hervorragende Informationsquellen, die ich schon so oft zurate gezogen habe, dass sie buchstäblich auseinanderfallen, während andere nur wenig hilfreich sind und immer noch so gut wie neu aussehen. Ein Buch, das die Einzelheiten gut erklärt, ohne die Aufmerksamkeit des Lesers zu verlieren, ist Gold wert. Leider sind die meisten meiner Lieblingsbücher, also der völlig abgegriffenen und abgenutzten, entweder sehr lang (über 500 Seiten) oder sehr spezifisch (tiefschürfende Betrachtungen eines einzelnen Themas). Das ist beides nichts Schlechtes, im Gegenteil, es sind gerade diese Detailfülle und die Klarheit der Erklärungen, die diese Bücher so großartig machen. Allerdings werden Anfänger durch einen Riesenwälzer, der sich auf ein ganz bestimmtes Teilgebiet der Sicherheit konzentriert, leicht überfordert.

Für Neulinge, die versuchen, sich mit dem Gebiet der Sicherheit vertraut zu machen und die Grundlagen des Hackings zu erlernen, ist die Lektüre dieser Bücher eher abschreckend und verwirrend. Dieses Buch unterscheidet sich in zweierlei Hinsicht von anderen Publikationen: Erstens richtet es sich an Anfänger (wir fangen bei null an). Wenn Sie sich noch nie im Hacking 20 Einleitung

versucht haben oder nur wenige Werkzeuge kennen und nicht sicher sind, was Sie als Nächstes tun sollen (oder wie Sie die Ergebnisse dieser Werkzeuge deuten sollen), dann ist dieses Buch für Sie genau richtig. Hier werden Sie nicht mit Einzelheiten zugeschüttet, sondern erhalten einen breiten Überblick über das gesamte Themengebiet. Dieses Buch soll Sie nicht zu einem Experten für sämtliche Gesichtspunkte von Penetrationstests machen, sondern Ihnen einen Schnelleinstieg ermöglichen. Es deckt alles ab, was Sie wissen müssen, um sich danach anspruchsvollerem Stoff zuwenden zu können.

Daher werden in diesem Buch zwar nach wie vor die wichtigsten Werkzeuge beschrieben, die Sie zur Durchführung der einzelnen Schritte eines Penetrationstests benötigen, doch werden nicht alle Sonder- und Zusatzfunktionen erklärt, die darin zur Verfügung stehen. Dadurch können wir uns auf die Grundlagen konzentrieren, was auch dazu beiträgt, die Verwirrung zu vermeiden, die manchmal bei anspruchsvolleren Funktionen oder durch kleine Unterschiede zwischen den einzelnen Versionen eines Werkzeugs auftritt. Wenn Sie dieses Buch durchgearbeitet haben, verfügen Sie über genügend Kenntnisse, um sich die »erweiterten Funktionen« und die »neuen Versionen« der beschriebenen Werkzeuge selbst beizubringen.

Beispielsweise werden in dem Kapitel über Portscans verschiedene einfache Scans mit dem sehr beliebten Portscanner Nmap beschrieben. Da es in diesem Buch um die Grundlagen geht, ist es nicht so wichtig, welche Version von Nmap Sie benutzen. Ein SYN-Scan funktioniert in Nmap 2 genauso wie in Nmap 5. Dieses Prinzip habe ich so oft wie möglich angewandt, denn dadurch können Sie Nmap und alle anderen Werkzeuge kennenlernen, ohne sich um die Unterschiede zu kümmern, die bei anspruchsvolleren Funktionen zwischen den einzelnen Versionen gewöhnlich auftreten. Außerdem können Sie ein Buch, das nach diesem Prinzip geschrieben ist, viel länger sinnvoll nutzen. Einleitung 21

Denken Sie daran, dass dieses Buch Ihnen das allgemeine Wissen vermitteln soll, das Sie benötigen, um sich auch mit fortgeschrittenen Themen und weiterführenden Büchern zu beschäftigen. Wenn Sie erst einmal die Grundlagen beherrschen, können Sie immer noch die genauen Einzelheiten und anspruchsvolleren Funktionen eines Werkzeugs kennenlernen. Am Ende jedes Kapitels finden Sie außerdem eine Aufstellung der Werkzeuge und Themen, die in diesem Buch nicht behandelt werden können, die aber zum weiterführenden Studium empfohlen werden.

Dieses Buch ist aber nicht nur eigens für Neulinge geschrieben, sondern stellt die Informationen auch auf einzigartige Weise dar. Alle Werkzeuge und Techniken werden in einer bestimmten Reihenfolge an einer kleinen Anzahl von Zielen ausgeführt. (Alle diese Zielcomputer befinden sich im selben Subnetz, das sich auf einfache Weise nachbauen lässt, um die Beispiele nachzuvollziehen.) Dabei erfahren Sie jeweils, wie Sie die Ausgabe der Werkzeuge deuten und wie Sie sie für die Angriffsphase des nächsten Kapitels nutzen. In diesem Buch werden sowohl lokale Angriffe als auch solche beschrieben, die über das Netzwerk ausgeführt werden, und es wird gezeigt, wann welche Vorgehensweise angebracht ist.

Die Verwendung eines Beispiels, das Schritt für Schritt durchgearbeitet wird, hilft Ihnen, das Gesamtbild zu sehen, und das Ineinandergreifen der einzelnen Werkzeuge und Phasen besser zu verstehen. Das ist anders als in zahlreichen Büchern, die oft die verschiedenen Werkzeuge und Angriffe erklären, aber nichts darüber aussagen, wie diese Werkzeuge wirkungsvoll verkettet werden können. Die Darstellung der Informationen auf diese Weise zeigt deutlich, wie Sie von einer Phase zur nächsten übergehen. Das ist eine sehr wertvolle Erfahrung, denn Sie ermöglicht es Ihnen, einen gesamten Penetrationstest durchzuführen, indem Sie einfach den Beispielen in diesem Buch folgen. Durch dieses Konzept erhalten Sie einen klaren Eindruck der Grundlagen und lernen gleichzeitig, wie die verschiedenen Werkzeuge und Phasen zusammenhängen. 22 Einleitung

Warum sollten Sie dieses Buch kaufen?

Gründe dafür wurden schon in den vorherigen Abschnitten hervorgehoben, aber die folgende Liste führt sie noch einmal in konzentrierter Form auf:

•• Sie möchten etwas über Hacking und Penetrationstests lernen, wissen aber nicht, wo Sie anfangen sollen. •• Sie haben sich schon an Hacking und Penetrationstests versucht, sind sich aber nicht darüber im Klaren, wie die einzelnen Aspekte zusammenhängen. •• Sie möchten mehr über die Werkzeuge und Vorgehensweisen lernen, mit denen sich Hacker und Penetrationstester Zugang zu Netzwerken und Systemen verschaffen. •• Sie suchen nach einem guten Ausgangspunkt, um Kenntnisse über offensive Sicherheit zu erwerben. •• Sie sind beauftragt, eine Sicherheitsüberprüfung Ihrer Organisation durchzuführen. •• Sie lieben die Herausforderung.

Was brauche ich, um die Beispiele nachvollziehen zu können?

Es ist zwar durchaus möglich, dieses Buch von Anfang bis Ende zu lesen, ohne irgendeines der Beispiele nachzuvollziehen, aber ich möchte Ihnen wirklich ans Herz legen, sich die Ärmel hochzukrempeln und alle besprochenen Werkzeuge und Techniken auszuprobieren. Es gibt nichts Besseres als praktische Erfahrungen. Alle Beispiele können mit kostenlosen Werkzeugen und Software wie VMware Player und Linux durchgespielt werden. Nach Möglichkeiten sollten Sie sich jedoch auch Windows XP (vorzugsweise Einleitung 23

ohne Service Packs) beschaffen, um ein Windows-Ziel einzurichten. Zwar sind alle Versionen von Windows 2000 bis Windows 8 geeignet, aber für die ersten Versuche bilden ältere, nicht gepatchte Versionen die besten Ziele.

Falls Sie kein Windows auftreiben können, haben Sie immer noch die Möglichkeit, die einzelnen Phasen zu üben, indem Sie eine angreifbare Version von Linux einrichten oder herunterladen. In diesem Buch verwenden wir eine absichtlich mit Schwachstellen versehene Version von namens Metasploitable. Dies ist ein ideales Übungsziel und obendrein völlig kostenlos! Zurzeit können Sie Metasploitable bei Sourceforge auf http://sourceforge.net/projects/metasploitable/ herunterladen.

Achtung! In diesem Buch finden Sie immer wieder Weblinks wie den oben angegebenen. Da sich das Web ständig wandelt, sind Webadressen immer nur begrenzt gültig. Wenn einer der angegebenen Links nicht funktioniert, versuchen Sie bei Google nach der Quelle zu suchen. Wie Sie Ihr Hackinglabor im Einzelnen einrichten, wird in Kapitel 1 beschrieben. Die folgende kurze Liste zeigt Ihnen jedoch schon einmal, was Sie benötigen, um die Beispiele in diesem Buch durchzuarbeiten:

•• VMware Player oder irgendeine andere Software, mit der sich virtuelle Maschinen ausführen lassen •• Eine virtuelle Maschine mit Kali Linux (oder BackTrack) oder einer anderen Linux-Version, die als Angriffscomputer dient •• Eine virtuelle Maschine mit Metasploitable oder einer ungepatchten Version von Windows (vorzugsweise Windows XP) als Zielcomputer

219

5 Social Engineering

Aufklärung

Nacharbeiten und Scan Erhaltung des Zugriffs

Eindringen

5.1 Einführung

In diesem Kapitel bauen wir auf dem auf, was Sie in Kapitel 2 über Social Engineering gelernt haben. Außerdem lernen Sie hier, wie wichtig es ist, Ihren Angriff glaubhaft zu gestalten. Social Engineering gehört zu den einfachsten Techniken, um Zugang zu einer Organisation oder einem einzelnen Computer zu erlangen, aber auch zu den größten Herausforderungen, wenn Sie Ihre Hausaufgaben bezüglich des Ziels und Ihrer Opfer nicht richtig machen. Ein guter Social-Engineering-Experte wendet viel Zeit auf, um seinen Vorwand (Angriffsweg) zu gestalten, eine glaubhafte Geschichte zu konstruieren und dabei jede Einzelheit zu bedenken. Der Angriff muss so glaubhaft sein, dass die Opfer keinerlei Verdacht schöpfen und niemand Alarm schlägt, während Sie versuchen, Ihr Blendwerk als Realität auszugeben. 220 Kapitel 5: Social Engineering

Eine meiner liebsten Erfahrungen im Bereich des Social Engineering war ein Angriff auf eine Fortune-1000-Organisation. Dabei wurde ins Feld geführt, dass gegebene medizinische Leistungen ablaufen würden, wenn die Angestellten eine bestimmte Richtlinie nicht unterzeichneten. Dies war ein idealer Angriff, da er mit menschlichen Gefühlen spielt, dabei aber im Rahmen der üblichen Erwartungen eines Angestellten bleibt. Um keinen Alarm auszulösen, wurde der Angriff nur an vier Personen geschickt. Die Erfolgsquote lag bei 100 %. Der Erfolg hängt bei solchen Dingen jedoch ganz allein davon ab, wie viel Zeit und Anstrengung Sie investieren, um den Angriff glaubhaft zu machen.

Das SET (Social Engineering Toolkit) ist ein Werkzeug, das Ihnen dabei helfen kann, einige fürchterlich komplizierte Techniken zu automatisieren und Ihre Angriffe glaubhaft zu gestalten. Wie der Name schon sagt, ist es jedoch nur ein Werkzeug und nicht mehr. Stellen Sie sich SET als ein Schwert vor, das auch nur so gut ist wie die Fähigkeiten des Fechters, der es führt. Um Ihre Erfolgsquote bei Social-Engineering-Angriffen zu steigern, müssen Sie genau wissen, wie Sie SET auf Ihre Bedürfnisse anpassen und seine Möglichkeiten größtmöglich ausschöpfen.

Was also ist SET? Es handelt sich dabei um ein Grundgerüst für Angriffe, das einzig und allein dem Social Engineering gewidmet ist. Sie können damit ohne große Programmierkenntnisse und langjährige Erfahrung schnell eine Reihe anspruchsvoller Angriffsmöglichkeiten aufstellen. SET ist zu einem Standardwerkzeug für Penetrationstester und zu einer Methode geworden, um herauszufinden, wie gut Organisationen gezielten Social-Engineering- Angriffen widerstehen können.

5.2 Die Grundlagen von SET

Wie Sie bereits wissen, sind Binärdateien in der Ordnerstruktur von Kali unter /usr/bin/werkzeugname und die Dateien der Anwendung in /usr/share/name_des_werkzeugordners untergebracht. SET bildet da Die Grundlagen von SET 221

keine Ausnahme und wird in Kali im Verzeichnis /usr/share/setoolkit installiert. Aufrufen können Sie es an der Kommandozeile mit dem folgenden Befehl, wobei Sie sich in einem beliebigen Verzeichnis befinden können:

se-toolkit

Dadurch wird die Hauptoberfläche von SET aufgerufen, in der eine Reihe von Optionen zur Auswahl steht, wie Sie in Abbildung 5.1 sehen.

Abbildung 5.1: Das Menü in SET

SET ist ein menügesteuertes System, das es Ihnen erlaubt, Ihre Angriffe auf das gewünschte Ziel zuzuschneiden. Sie können übrigens auch die Konfigurationsdatei unter /usr/share/setoolkit/config/set_config bearbeiten, um die Funktionsweise von SET nach Ihren Vorstellungen anzupassen. Innerhalb des Menüs können Sie mit den Optionen 4 und 5 Metasploit bzw. SET aktualisieren. Option 1 führt zu den Social- Engineering-Angriffen, Option 2 zu den Werkzeugen für direkte Angriffe, die im Fast-Track-Menü (»Schnellspur«) zur Verfügung stehen. Wir konzentrieren uns hier auf Option 1, unter der Sie die meisten der Social- Engineering-Angriffe finden (siehe Abbildung 5.2). Geben Sie also 1 ein. 222 Kapitel 5: Social Engineering

Abbildung 5.2: Das Menü der Social-Engineering-Angriffe

Sehen wir uns die möglichen Angriffswege in diesem Menü kurz im Überblick an. Da wir uns hier mit den Grundlagen beschäftigen, werden wir uns nicht ausführlich um die Einzelheiten kümmern, aber ein Grundverständnis kann Ihnen auf dem weiteren Weg helfen. Die Spear- Phishing-Angriffe sind besonders gestaltete E-Mails mit schädlichen Anhängen. Das ist das, was Sie dauernd in den Nachrichten hören, allerdings lassen sich solche Angriffe nur sehr schwer durchführen. Die Mehrzahl der Exploits, die für Adobe, Office und andere Programme herauskommen, werden sehr schnell durch Patches zunichte gemacht und fast sofort von Antivirussoftware erkannt.

Als Angreifer haben Sie gewöhnlich nur eine Gelegenheit, um den Angriff auszuführen, und das gilt besonders für Penetrationstester. Die Exploits selbst hängen sehr stark von der Version der Zielsoftware ab. Um Ihnen ein Beispiel zu geben: 2013 hat Scott Bell ein Metasploit-Modul für eine Schwachstelle von Internet Explorer veröffentlicht, bei der es um die weitergehende Benutzung freigegebener Zeiger im Arbeitsspeicher ging. Bei der Verwendung dieses Exploits reichte es aus, wenn das Opfer mit Internet Explorer die schädliche Website besuchte, um seinen Computer Die Grundlagen von SET 223

zu knacken. Das war ein erstaunlicher Exploit und ein wirklich großartiges Beispiel für Präzision und Recherche. Das einzige Problem bei diesem Exploit bestand darin, dass er nur bei Internet Explorer 8 auf Windows XP SP3 funktionierte (siehe Abbildung 5.3).

Abbildung 5.3: Dieser Exploit funktioniert nur bei IE 8 auf Windows XP SP3

An dieser Stelle muss ich noch einmal betonen, dass Scotts Leistung einfach erstaunlich ist. Sie dürfen Arbeit und Genie, die nötig sind, um einen Exploit wie diesen zu entdecken und in eine Angriffswaffe umzuwandeln, niemals bagatellisieren oder unterschätzen. Wie bereits erwähnt, sind die meisten Exploits jedoch versionsspezifisch. Die Hauptgründe dafür sind die zusätzlichen Schutzmechanismen in späteren Versionen von Internet Explorer und die Verwendung von Speicheradressen in den Exploits. Jede Version von Internet Explorer und Windows (und das bezieht sich auch auf die installierten Service Packs) verwendet andere Speicheradressen. Damit ein Exploit funktionieren kann, muss er daher eigens auf das vorliegende Betriebssystem, die Service Packs und die Version von Internet Explorer zugeschnitten sein. Um einen Exploit so anzupassen, dass er 224 Kapitel 5: Social Engineering

mehrere Plattformen angreifen kann, müssen Sie erheblich viel Zeit und Forschungsarbeit investieren. Es gibt einige solcher »Universal-Exploits«, die gemeinsame Speicheradressen ausnutzen. Beispielsweise hat Chris »g11tch« Hodges im Jahr 2013 einen Zero-Day-Exploit für Microsoft Word veröffentlicht (http://www.exploit-db.com/exploits/24526/), der auf mehreren Plattformen funktioniert. Er mag daher für den Angriff auf eine Organisation geeignet erscheinen, aber wenn Sie ihn auf VirusTotal hochladen, werden Sie feststellen, dass er von sehr vielen Antivirusprodukten erkannt wird. Um auch nur die grundlegenden Schutzmaßnahmen zu umgehen, die Unternehmen haben, müssten wir den Code sehr stark verschleiern. Aufgrund all dieser Hürden kommt es beim Social Engineering oft darauf an, einen Weg zu verfolgen, der schon im Voraus erfolgversprechend ist. Gezieltes Spear-Phishing funktioniert nur dann, wenn Sie Ihr Opfer in- und auswendig kennen. Einfach nur vorgefertigte PDF- oder Word-Dokumente mit Exploits als Anhang zu senden, wirkt nur in den seltensten Fällen.

5.3 Websites als Angriffswege

Zu den Paradefunktionen von SET gehören die Website-Angriffswege. Die in dieser Gruppe versammelten Angriffsmöglichkeiten sind alle sehr erfolgreich und stützen sich sehr stark auf Glaubwürdigkeit (einen wichtigen Faktor beim Social Engineering). Wenn Sie im Social-Engineering-Menü von SET Option 2 wählen, gelangen Sie zu dem Menü aus Abbildung 5.4

Die beiden Hauptangriffsarten, auf die wir uns hier konzentrieren wollen, sind der Java-Applet-Angriff und das Abgreifen von Anmeldeinformationen (Credential Harvester). Der Java-Applet-Angriff stützt sich dabei nicht auf die allerneuesten raffinierten Exploits, sondern auf das Design der Sprache Java. In Java können Sie so genannte Applets schreiben, vollwertige Programme, die oft in Webanwendungen eingesetzt werden. Beispielsweise nutzt WebEx von Cisco Java-Applets zum Start von Online- Webkonferenzen. Applets gehören in Webanwendungen zur Tagesordnung Websites als Angriffswege 225

und wirken echt und glaubhaft, wenn sie den Opfern mit einem geschickten Vorwand untergeschoben werden. Wählen Sie im Menü Option 1 (Java Applet Attack Method) und in dem daraufhin angezeigten Menü Option 2 (Site Cloner). SET wechselt dann automatisch zu der angegebenen Webseite, klont sie, schreibt sie mit einem schädlichen Java-Applet neu, richtet einen Webserver ein und erstellt mehrere Payloads. Das alles geschieht innerhalb weniger Minuten.

Abbildung 5.4: Auswählen von Java-Applets als Angriffsmethode

Wenn Sie sich für Site Cloner entschieden haben, wählen Sie anschließend No für NAT (Network Address Translation) und Portweiterleitung. Diese Optionen brauchen Sie nur dann, wenn Sie sich hinter einem Router mit Portweiterleitung befinden. Geben Sie anschließend die IP-Adresse Ihres (Angriffs-) Computers ein (siehe Abbildung 5.5).

Als Nächstes geben Sie an, welche Seite Sie klonen wollen. In diesem Beispiel verwenden wir https://www.trustedsec.com. Nach dem Klonvorgang sehen Sie das Menü aus Abbildung 5.6, in dem Sie die gewünschte Payload auswählen können. 226 Kapitel 5: Social Engineering

Abbildung 5.5: Eingabe der IP-Adresse des Angriffscomputers

Abbildung 5.6: Auswählen der Payload in SET

60392-8 Titelei_X 07.07.15 13:56 Seite 1

Julie J. C. H. Ryan / Cade Kamachi E-Mail Hacking

Schützen Sie Ihr E-Mail-Postfach vor Trojanern, Viren und gefährlichen Anhängen. 5

Inhaltsverzeichnis

Vorwort...... 7

Die Autoren...... 9

Der Fachgutachter...... 9

1. Einleitung...... 11 1.1 Ein bisschen Geschichte...... 13 1.2 Schädliche elektronische Nachrichten – was ist das?...... 16

2. Arten von schädlichen Nachrichten...... 22 2.1 Arten von schädlichen Nachrichten...... 26 2.1.1 Ansprechen der Gefühle...... 26 2.1.2 Trickserei...... 27 2.1.3 Getarnte Links...... 27 2.1.4 Getarnte Anhänge...... 28 2.1.5 Eine zusätzliche Schwierigkeit...... 29 2.2 Beispiele für schädliche Nachrichten...... 30 2.2.1 Ansprechen der Gefühle...... 30 2.2.2 Die Einladung...... 37 2.2.3 Das Geldangebot...... 41 2.2.4 Die Warnung...... 45 2.2.5 Die Insidermeldung...... 50 2.2.6 Die maskierte E-Mail...... 52 2.2.7 Die große Lüge...... 52 2.2.8 Die kleine Lüge...... 56 6 Inhaltsverzeichnis

2.3 Der E-Mail-Exploit...... 59 2.3.1 Kategorien von E-Mail-Exploits...... 59 2.3.2 Schutz vor Exploits...... 64

3. Den Feind kennen...... 67

4. Die internen Mechanismen: Das Verborgene sichtbar machen...... 73 4.1 E-Mail-Grundlagen...... 74 4.2 Der Kopf (Header)...... 74 4.3 Der Nachrichtenrumpf...... 79 4.4 Anhänge...... 82 4.5 Senden und Empfangen von E-Mails...... 85 4.5.1 E-Mail-Protokolle...... 86 4.5.2 E-Mails synchronisieren...... 96 4.5.3 Alternative zum Verschicken von Daten...... 97 4.5.4 Passwortstruktur...... 99 4.5.5 Zweite E-Mail-Adresse...... 103 4.6 Zugriff auf verborgene Informationen...... 109

5. Schritte zum Erkennen schädlicher Nachrichten...... 112 5.1 Unterstützung durch die Technik...... 123 5.2 Es kommt auf die Konfiguration an...... 126

6. Ein gestaffeltes Schutzsystem gegen schädliche Nachrichten...... 130 6.1 Warum eine gestaffelte Vorgehensweise?...... 131

7. Schlusswort...... 142

8. Glossar...... 144 7

Vorwort

Dieses Buch ist für ganz normale Benutzer gedacht, die keine tief greifenden technischen Kenntnisse über Computer und Netzwerke haben. Es ist in ei- ner einfachen Sprache geschrieben und soll Ihnen das erforderliche Wissen vermitteln, um sich gegen Angreifer zu schützen, ohne Sie mit technischen Einzelheiten zu verwirren. Sie können es von vorn bis hinten durchlesen, aber auch gezielt die Kapitel aufschlagen, an denen Sie besonders interes- siert sind. Wenn Sie sich um die technischen Einzelheiten nicht kümmern wollen, können Sie Kapitel 4 getrost überschlagen. Leser, die keine Manage- mentverantwortung tragen, können Kapitel 6 auslassen.

In Kapitel 1 beschäftigen wir uns damit, was schädliche Nachrichten über- haupt sind, um das Feld für die ausführlichere Erörterung in den anschlie- ßenden Kapiteln abzustecken. Systeme zur Nachrichtenübermittlung für schädliche Zwecke einzusetzen, ist keine neue Erfindung: Beispiele für den Missbrauch der Post lassen sich bis 1838 zurückverfolgen. Da die Absender es darauf anlegen, die Empfänger von der Echtheit ihrer Nachrichten zu überzeugen, stellt es eine echte Herausforderung dar, schädliche Nachrich- ten als solche zu erkennen und ihnen nicht zum Opfer zu fallen.

Kapitel 2 erklärt ausführlich die verschiedenen Arten von schädlichen Nachrichten anhand von realen Beispielen. Hier lernen Sie die Elemente der Nachrichten kennen, die Hinweise auf die schädliche Natur geben. Das ist sehr nützlich, um einen Angriff zu erkennen und nicht auf ihn herein- zufallen.

In Kapitel 3 konzentrieren wir uns auf die Absichten der Absender. Zu wissen, welche psychologischen Tricks in schädlichen Nachrichten angewandt werden, kann ebenso zum Schutz beitragen wie technische Werkzeuge und Sicherheitsanalysen. Hier werden die beiden Hauptziele von Angreifern und ihre Vorgehensweisen zum Erreichen dieser Ziele beschrieben. 8 Vorwort

Kapitel 4 geht auf die technischen Aspekte ein. Hier lernen Sie den Aufbau von E-Mails kennen und erfahren, wie Sie diese Struktur nutzen, um zu bestimmen, ob eine empfangene E-Mail schädlich oder harmlos ist. Die Elemente im Kopf und Rumpf der Nachricht und die Anhänge werden besprochen.

In Kapitel 5 geht es um den Erkennungsprozess. Die beschriebene Vorge- hensweise lässt sich auf alle Problemstellungen anwenden, bei denen irgend­ etwas aufgespürt werden muss, wird hier aber im Zusammenhang mit dem Erkennen von schädlichen Nachrichten dargestellt. Außerdem erfahren Sie, wie Ihre Erfahrungen dazu beitragen, Ihre Fähigkeiten zum Erkennen von schädlichen Nachrichten zu verbessern.

Kapitel 6 richtet sich an Leser, die die Verantwortung für das Problem schäd- licher Nachrichten nicht nur für sich allein tragen. Hier wird ein Grund- gerüst für eine Schutzstruktur vorgestellt, die Unternehmen eine Abwehr mit Breiten- und Tiefenwirkung erlaubt. In diesem Grundgerüst werden sowohl die technischen Aspekte der Verteidigung als auch die betroffenen Menschen berücksichtigt.

Kapitel 7 bietet einige abschließende Gedanken und Empfehlungen. Zu wissen, was Sie tun müssen, wenn Sie das Opfer einer schädlichen Nach- richt geworden sind, ist ebenso wichtig wie die Kenntnisse zur Vorbeugung gegen diese Gefahren. Daher geht es in diesem Kapitel um die Reaktion auf Angriffe und um Maßnahmen zur Wiederherstellung.

Für Dozenten kann dieses Buch als Ausgangspunkt dienen, um das Bewusst- sein für die Gefahren zu schärfen, die in elektronischer Nachrichtenübermitt- lung lauern. Manager können es als Eckpfeiler eines Schulungsprogramms nutzen, mit dem die Sicherheit im Unternehmen verbessert und sichere Ver- haltensmuster im Umgang mit Computern etabliert werden sollen. Eltern können es heranziehen, um mit Ihren Kindern über die Gefahren im Zusam- menhang mit der Online-Kommunikation zu sprechen. 9

Die Autoren

Julie Ryan ist Privatdozentin an der George Washington University in Was- hington, D.C:, wo sie über Informationssicherheit, Systemdynamik und Mensch-Maschine-Interaktion forscht und lehrt. Dr. Ryan hat einen Grad als Bachelor of Science von der US Air Force Academy, einen Mastergrad in interdisziplinärer Technologie von der Eastern Michigan University und einen Doktorgrad in Naturwissenschaft von der George Washington Uni- versity. Sie ist Coautorin von »Defending Your Digital Assets Against Hac- kers, Crackers, Spies and Thieves« (2000) und Herausgeberin von »Leading Issues in Information Warfare and Security«.

Cade Kamachi hält einen akamedischen Grad in Computerinformations­ technologie von der Brigham Young University in Idaho sowie einen MBA-Grad der Idaho State University. Während seiner Zeit an der Idaho State University führte er im Rahmen des National Information Assurance Training and Education Center (NIATEC) Forschungen durch und ent- wickelte Schulungen. Cade hat auf den Gebieten Technologie und Infor- mationssicherheit sowohl für die Industrie als auch für staatliche Behör- den gearbeitet, wobei seine Pflichten von technischer Einrichtung bis zum Aufstellen von Richtlinien reichten. Außerdem hat er bei der Entwicklung und Umsetzung von IT-Sicherheitsübungen für akademische, wirtschaft- liche und staatliche Einrichtungen geholfen.

Der Fachgutachter

Corey Schou ist ein Fulbright-Stipendiat und aktiver Forscher, der häufig als öffentlicher Redner auftritt und als Autor auf über 300 Bücher, Forschungsarbeiten, Artikel und andere Veröffentlichungen zurückblicken kann. Zu seinen Interessen gehören Informationssicherheit, Risiko­ 10 Der Fachgutachter

management, Softwareentwicklung, Entwicklung sicherer Anwendungen, Sicherheit und Datenschutz und gemeinsame Entscheidungsfindung.

In der Presse wurde er als Vater des Wissensschatzes bezeichnet, der heute weltweit zur Einrichtung von Computer- und Informationssicherheit verwendet wird. Unter anderem war er für die Aufstellung und Bearbeitung der Normen für die Computersicherheitsschulung der US-Regierung zuständig.

2003 wurde er als erster Träger für den Ehrentitel des »University Professor« der Idaho State University ausgewählt. Er leitet das Informatics Research Institute und das National Information Assurance Training and Education Center. Sein Programm wurde von der US-Regierung als »Center of Academic Excellence in Information Assurance« ausgezeichnet und gehört zu den führenden Instituten des Programms »CyberCorps/Scholarship for Service«.

Neben seinen akademischen Leistungen hält er eine breite Palette an Zertifikaten, darunter als CCFP (Certified Cyber Forensics Professional), CSSLP (Certified Secure Software Lifecycle Professional), HCISPP (HealthCare Information Security and Privacy Practitioner), CISSP-ISSAP (CISSP Information Systems Security Architecture Professional) und CISSP- ISSMP (CISSP Information Systems Security Management Professional).

Im Laufe seiner Karriere wurde er von vielen Organisationen gewürdigt, unter anderem von der Federal Information Systems Security Educators Association, die ihn 1996 zum »Lehrer des Jahres« kürte. Seine Forschungs­ arbeiten und seine Schulungseinrichtung wurden von der Information System Security Association als herausragende Beiträge zum Berufsstand genannt. 1997 erhielt er den TechLearn-Preis für Beiträge zur Fernschulung.

Für sein Lebenswerk wurde er zum Ehren-CISSP (Certified Information Systems Security Professional) vorgeschlagen und gewählt. Im Jahr 2001 wählte ihn das Information Systems Security Certification Consortium [(ISC)2] für seine Beiträge zur Informationssicherheitsbranche zum zweiten Empfänger des Tipton-Preises. 2007 wurde er zum Mitglied des (ISC)2 ernannt. Der E-Mail-Exploit 65

Exploits und Bots erkennen

Mehrere Anzeichen deuten auf einen Bot-Befall Ihres Rechners hin. Etwa, wenn Sie feststellen, dass Ihre Internetverbindung langsamer läuft als frü- her. Des Weiteren sorgen Bots für das unerwünschte Aufrufen von Interne- tseiten, zumeist Werbeseiten. Sie können Ihren Browser sogar lahmlegen, wobei es unerheblich ist, ob Sie zum Beispiel Chrome, Firefox, den Internet Explorer oder Opera verwenden.

Solche Symptome können auftreten, müssen aber nicht! Häufig merken Anwender gar nicht, dass ihr Computer von Hackern an ein Bot-Netz an- geschlossen wurde.

Checkliste: So schützen Sie sich vor Exploits und Bots! Die folgende Checkliste zeigt Ihnen, dass für den Schutz vor Exploits und Botnet-Befall die gleichen Schutzvorkehrungen anzuwenden sind, wie wir sie Ihnen bereits für den allgemeinen E-Mail-Verkehr nahegelegt haben: 1. Öffnen Sie unter keinen Umständen einen Anhang, den Sie mit einer Mail von einem Ihnen unbekannten Absender erhalten haben. 2. Nutzen Sie sichere Passwörter. 3. Ändern Sie Ihre Passwörter regelmäßig in nicht zu großen Zeitabständen. 4. Erstellen Sie von Ihren wichtigen Daten in regelmäßigen Abständen Sicherungskopien auf einem externen Speichermedium, das nicht ständig mit Ihrem Computer verbunden ist. Nur so bleiben Ihre wertvollen Daten erhalten, sollten Sie einem Hacker-Angriff zum Opfer gefallen sein. 5. Wenn Sie WLAN oder VoIP nutzen, sollte die Übertragung ausschließlich verschlüsselt erfolgen. 66 Kapitel 2: Arten von schädlichen Nachrichten

6. Führen Sie alle Service-Packs und Sicherheitsupdates Ihres Betriebssystems, Ihrer Antiviren-Software usw. regelmäßig aus. Nur so bleibt Ihr PC vor aktuellen Bedrohungen geschützt. 7. Seien Sie beim Aufrufen Ihnen unbekannter Internetseiten vorsichtig. Sie können auf solche Seiten über Links in E-Mails aufmerksam gemacht werden. Denken Sie aber auch beim bloßen Internet-Surfen daran, dass unbekannte Seiten gefährlich sein können und auf Ihrem PC Schadsoftware installieren und ausführen können. 8. Hüten Sie sich davor, Software unbekannter oder fragwürdiger Herkunft zu installieren, insbesondere, wenn sie gratis angeboten wird. 9. Ein altes Sprichwort sagt: »Trau, schau wem!15« Halten Sie sich daran. Es ist bei E-Mail- und Internet-Anwendungen aktueller denn je! Ob Ihr Computer befallen ist, können Sie mit geeigneter Software ermitteln. Sie können die Empfehlungen auf www.botfrei.de befolgen und dafür bereitgestellte Programme downloaden oder sich selbst nach Alternativen umsehen. Wurden Schädlinge gefunden, löschen Sie sie. Ansonsten beherzigen Sie die bereits zuvor genannten neun Punkte.

15 Falls Sie dieses Sprichwort nicht kennen: Es bedeutet, dass Sie niemandem leichtfertig Ihr Vertrauen schen- ken sollen. 3 Den Feind kennen

Ein Verständnis der Psychologie von Phishing-Angriffen zu entwickeln, ist zu ihrer Unterbindung ebenso wertvoll wie technische Maßnahmen und Sicherheitsanalysen. Wer beide Seiten kennt, kann besser einschätzen, was seine Organisation verwundbar macht und wie weit ein Angreifer gehen würde, um eine solche Schwachstelle auszunutzen. Wenn man beispielswei- se davon ausgeht, dass eine bestimmte Klasse von Angreifern hauptsächlich von dem Gedanken an Ruhm getrieben sind, kann man davon ausgehen, dass sie nicht sehr geneigt sind, sich durch mehrere Schichten von Vertei- digungsmechanismen zu kämpfen, sondern schnell aufgeben, um sich ein leichteres Ziel zu suchen. Allerdings kann dieselbe Klasse von Angreifern entschlossener vorgehen, wenn sie weiß, dass das Ziel einen hohen Wert darstellt, da der Einbruch in ein so hochwertiges Ziel mehr Prestige und mehr Wertschätzung einbringt. Diese Zweiteilung gilt insbesondere auch für die Absender von Schad-E-Mails: Die Mehrzahl der Angriffe ist an je- den gerichtet, der antwortet, während einige wenige gezielt auf sehr wert- volle Ziele gerichtet sind. 68 Kapitel 3: Den Feind kennen

Die Absender von schädlichen E-Mails verfolgen zwei Hauptziele. Das er- ste besteht darin, dass Sie die E-Mail zu sehen bekommen. Dazu muss die Nachricht so gestaltet sein, dass sie automatische Überprüfungs- und Qua- rantäneprogramme unterläuft. Zweitens ist beabsichtigt, dass Sie auf die E- Mail reagieren. Das kann manchmal einfach nur heißen, dass Sie sie öffnen und lesen. In anderen Fällen jedoch wünscht der Absender, dass Sie einen Anhang öffnen oder etwas ähnliches tun.

Darin liegt eine große Herausforderung: Wie können Sie die Ziele und Ab- sichten der Absender von schädlichen E-Mails erkennen? Damit Sie die E- Mail überhaupt zu sehen bekommen, muss Sie sie erreichen. Das wiederum bedeutet, dass sie zielgerichtet sein muss, dass ihre Absenderadresse nicht sofort als böswillig erkannt werden darf und dass ihr Inhalt sämtliche Filter überwinden muss, die auf Ihrem System in Kraft sein mögen. Damit Sie auf die Nachricht reagieren – indem Sie auf etwas klicken, einen Anhang öff- nen, sie weiterleiten oder darauf antworten –, muss die Nachricht auf Ihre Bedürfnisse, Wünsche, Vorlieben und Abneigungen zugeschnitten sein.

•• Ausrichtung auf das Ziel: Schädliche E-Mails können eigens an Sie ge- richtet, aber auch wie ein Schrotschuss an so viele Empfänger wie mög- lich abgefeuert werden. E-Mails, die an eine große Menge möglicher Empfänger gesandt werden, lassen sich im Allgemeinen leichter als potenziell gefährlich erkennen als diejenigen, die auf eine bestimmte Person abzielen. Das liegt an der Kosten/Nutzen-Abwägung beim Ab- sender: Es ist billig und einfach, die gleiche E-Mail an Tausende von Empfängern zu schicken, aber ziemlich kostspielig, sich die erforder- lichen Informationen zu beschaffen, um eine Einzelperson glaubhaft anzusprechen. Diese beiden Formen werden als UTME (UnTargeted Malicious Email, »nicht zielgerichtete schädliche E-Mail«) bzw. TME (Targeted Malicious Email, »gezielte schädliche E-Mail«) bezeichnet. UTME wird laut Definition nicht zielgerichtet an so viele Menschen wie möglich geschickt. TME dagegen, auch »Spear-Phishing« genannt (eine Anspielung auf das Speerfischen), ist sehr viel genauer auf eine einzelne Person ausgerichtet und sehr persönlich gestaltet, um mög- lichst wirkungsvoll zu sein. Es ist sehr kostspielig, die Informationen über eine Einzelperson einzuholen, die für einen wirkungsvollen TME- 69 

Angriff erforderlich sind, z. B. ihre Arbeitsgewohnheiten, ihr Umgang, ihre Vorlieben und Abneigungen usw. So viel Aufwand ist gewöhnlich nur für äußerst lukrative Ziele reserviert. Ein Beispiel für ein Ziel, das einen solchen Aufwand rechtfertigen würde, ist beispielsweise jemand in einem High-Tech-Unternehmen, der leichten Zugang zu Marketing- plänen oder Ideen für neue Entwicklungen hat. Wenn ein Angreifer eine solche Person dazu verleitet, einen Anhang in einer E-Mail zu öffnen, kann er sich dadurch Zugang zum gesamten Netzwerk des Unterneh- mens und damit zu äußerst vertraulichen Daten verschaffen. •• Absenderadresse: Die Absender schädlicher E-Mails wollen ihre wahre Identität normalerweise verschleiern, weshalb sie verschiedene Techni- ken einsetzen, um die wirkliche Quelle der E-Mail zu maskieren. Der gefälschte Absender, der in der Mail angezeigt wird, kann dabei ein sehr gebräuchlicher Name, eine Person aus der Kontaktliste des Empfängers oder eine prominente Persönlichkeit sein. Eine der ersten Maßnahmen bei der Untersuchung möglicherweise schädlicher E-Mails besteht da- her darin, die unsichtbaren Teile der Absenderadresse zu betrachten, um herauszufinden, wie sie tatsächlich aussieht. Wie das im Einzelnen geht, erfahren Sie in Kapitel 4. •• Inhalt: Schädliche E-Mails können unterschiedliche Arten von gefähr- lichen Inhalten aufweisen. Zu den harmlosesten gehören noch die Ket- tennachrichten, die gewöhnlich viele Male weitergeleitet werden und Falschdarstellungen enthalten, mit denen die Empfänger zu einer emo- tionalen Reaktion angestachelt werden sollen. Der Zweck dieser Art von schädlichen E-Mails besteht darin, Glaubensnetze zu beeinflussen. Diese Mails werden auch als Mem-Propaganda oder memetische An- griffe bezeichnet. Die Beispiele in Kapitel 2 zeigen die breite Palette von verschiedenen Inhalten, die schädliche Nachrichten haben können. Be- achten Sie aber, dass die Fantasie der Angreifer keine Grenzen kennt. Es gab einmal eine E-Mail, die den Empfänger über einen vermeintlichen Leichenfund informierte und ihn bat, den Anhang zu öffnen, um den Toten zu identifizieren. Das zeigt, dass die Urheber solcher Nachrichten vor nichts zurückschrecken. Die Menschen, die schädliche Nachrichten senden, sei es zum Erschwindeln von Geld, zum Abschöpfen persönlicher Daten, zum Anknüpfen von Be- 70 Kapitel 3: Den Feind kennen

ziehungen, für Like-Farming oder aus irgendeinem anderen Grund, haben eines – und nur eines! – gemeinsam: Es sind Menschen. Darüber hinaus unterscheiden sie sich auf jede nur erdenkliche Weise. Manche sind sehr arm und arbeiten unter der Aufsicht von Bandenführern von Internetcafés aus. Andere sind gute situiert und werden von zu Hause oder im Café tätig. Wieder andere sind reich und schon so lange im Geschäft, dass sie damit ein Vermögen eingenommen haben. Die Geschichten von zwei dieser Per- sonen veranschaulichem, was für Menschen dies sind.

•• Adam Vitale: Herr Vitale bekannte sich 2008 schuldig, die US-Bun- desgesetzgebung gegen Spamming verletzt zu haben. Er sagte aus, dass er damit 40.000 $ pro Woche verdient hat. Dabei hatte er auf Aktien- schwindel spezialisiert. Insider profitierten vom Verkauf von Aktien, deren Preise durch ihre Tätigkeiten künstlich in die Höhe geschraubt worden waren. Allerdings war Vitale auch bereit, sich an vielen anderen Maschen zu beteiligen, unter anderem auch in Werbung für Computer- sicherheitssoftware.1 •• Zwei Nigeria-Schwindler: Die Reporterin Erika Eichelberger vom Nach- richtenmagazin Mother Jones schrieb über ein Treffen mit zwei jungen Männern, die sich an etwas beteiligt hatten, was sie als Tricksen be- zeichneten: »Sie beharrten darauf, dass es etwas anderes ist, jemanden mit Tricks zu überlisten, als ihn zu bestehlen.« Diese beiden Männer hatten mit Vorschussbetrügereien, dem sogenannten 419-Schwindel, nach eigenen Angaben je 60.000 $ eingenommen.2 Diese beiden Geschichten veranschaulichen die große Bandbreite. Schädli- che E-Mails können von Leuten kommen, die Geld stehlen wollen, Ihre Zeit oder Ihre Daten. Aufgrund dieses breiten Spektrums von Motiven ist es nicht möglich, einen bestimmten Tätertyp für solche Aktivitäten anzuge-

1 Zu den Quellen mit Berichten über Adam Vitale gehören u. a.: Reuters, »NY Man Pleads Guilty to Spamming AOL Subscribers«, 11. Juni, 2007, http://www.reuters.com/article/2007/06/11/us-crime-spam- idUSN1120537620070611. Tynan, Dan: »Will the Real Spam King Please Stand Up?« in PC World, 16. Okto- ber 2008; erneut veröffentlicht in der Washington Post, online verfügbar auf http://www.washingtonpost.com/ wp-dyn/content/article/2008/10/13/AR2008101302311.html. US-Staatsanwaltschaft, Bezirk New York/Süd, »Brooklyn Man Pleads Guilty in Participating in Massive AOL Spam Scheme«, 11. Juni 2007, http://www. justice.gov/usao/nys/pressreleases/June07/vitalepleapr.pdf. 2 Eichelberger, Erika: »What I Learned Hanging Out with Nigerian Email Scammers«, Mother Jones, 20. März 2014, online verfügbar auf http://www.motherjones.com/politics/2014/03/what-i-learned-from-nigerian-scammers 71 

ben. Tatsächlich kommen als Täter die verschiedensten Arten von Personen aus aller Welt und mit unterschiedlichen Moralvorstellungen in Frage.

Die grundlegende Motivation jedoch ist klar: Jemand möchte etwas haben, dass er auf andere Weise nicht bekommen kann. Manche wollen Sie dazu veranlassen, direkt Geld zu überweisen. In anderen Fällen wollen die Täter Sie dazu bringen, auf einen Link zu klicken, durch den schädliche Software auf Ihren Computer heruntergeladen wird. Wieder andere beabsichtigen, dass Sie einen Anhang öffnen, durch den auf Ihrem Computer Aktivitäten möglich werden, die Sie normalerweise niemals erlauben würden.

Dahinter kann die Absicht stehen, die Rechenleistung Ihres Computers als Zombiemitglied eines Botnetzes zu nutzen, das dann stundenweise für un- terschiedliche Zwecke eingesetzt werden kann, z. B. für Denial-of-Service- Angriffe auf bestimmte Systeme. Vielleicht will man auf Ihrem Computer auch Software installieren, die den Tätern Zugriff auf all Ihre Daten gibt, darunter auch vertrauliche Geschäftsdaten. Ein sehr häufig anzutreffendes Motiv besteht darin, Sie dazu zu verleiten, in einer Antwort-E-Mail oder auf einer Website persönliche Daten anzugeben, sodass die Täter dann Ihre Identität stehlen, Ihr Bankkonto ausplündern oder Ihre elektronische Iden- tität für böse Zwecke missbrauchen können.

Die Absichten, die mit den Nachrichten verfolgt werden, können ganz einfach sein – wie beim Stromzählerbetrug in Oregon –, aber auch teuf- lisch verschlagen, wie bei dem Phishing-Angriff auf Netflix-Kunden. Beim Stromzählerschwindel erhielten Stromkunden Forderungen über mehre- re hundert Dollar für die Reparatur ihrer Zähler, wobei Ihnen angedroht wurde, dass Ihre Stromversorgung abgeschnitten würde, falls sie nicht zahl- ten.3 Bei dem Phishing-Angriff wurden Netflix-Kunden in Webanzeigen, Popup-Fenstern und E-Mails dazu verleitet, sich auf eine gefälschte Website zu begeben, die so aussah wie die von Netflix. Dort wurden sie aufgefordert, den Mitgliederbereich zu öffnen, wo eine gebührenfreie Rufnummer ange- geben war, an die sie sich wenden sollten. Die Person am anderen Ende der Leitung brachte die Anrufer dann mit einer Schritt-für-Schritt-Erklärung

3 »PUD Warns Customers About Meter Repair Scam«, 30. April 2014. Verfügbar auf http://www.thechroni- cleonline.com/news/article_44926c5e-d07b-11e3-ad80-001a4bc f887a.html. 72 Kapitel 3: Den Feind kennen

dazu, eine Software herunterzuladen, die den Betrügern eine Hintertür auf dem Computer des Opfers öffnete.4

Diese große Bandbreite an möglichen Absichten bedeutet leider, dass es verlorene Liebesmüh ist, sich auf die Absicht zu konzentrieren, sich in die Personen hineinzudenken, die hinter schädlichen Nachrichten stehen. Ein- fach ausgedrückt, besteht die Absicht in einem Diebstahl, aber die Zahl der verschiedenen Wege, auf denen dieser Diebstahl versucht wird, ist erstaun- lich groß.

Da es den Menschen im Allgemeinen gegen den Strich geht, sich ihr Geld, ihre Identität oder ihre Daten stehlen zu lassen, gibt es gemeinsame An- strengungen von Providern und dem Gesetzgeber, die Tätigkeit der Absen- der schädlicher Nachrichten einzudämmen. Leider ist dabei ein Wettrüsten im Gange. Sobald eine Methode unterbunden oder ein Kanal dichtgemacht wird, kommt eine neue Methode auf. Die Angreifer studieren die Maßnah- men der Verteidiger und entwickeln Methoden, die von den gegenwärtigen Abwehreinrichtungen nicht mehr erkannt werden können. Das bedeutet, dass man ständig auf der Hut bleiben und auf die nächste Überraschung gefasst sein muss.

Für die Täter ist es bereits ein Erfolg, wenn jemand ihre Nachricht öffnet und darauf antwortet, einen Like-Farming-Post weiterleitet, auf einen ge- fährlichen Link klickt oder einen Anhang öffnet. Das ist für sie der erste Schritt, um Zugriff auf das zu bekommen, was sie wirklich haben wollen, aber es ist ein entscheidender Schritt, ohne den sie ihr eigentliches Ziel nicht erreichen können.

Unter dem Strich gilt daher: Klicken Sie auf keine Links, öffnen Sie keine Anhänge und betrachten Sie jede Nachricht mit Argwohn. Wenn Sie aber den Eindruck haben, dass Sie einem Link unbedingt folgen oder einen An- hang öffnen müssen, dann gehen Sie dabei vorsichtig vor.

4 Taylor hat darüber zwei Artikel geschrieben: »Phishing Scam Targeting Netflix May Trick You With Phony Customer Service Reps«, 3. März 2014, http://www.huffingtonpost.com/2014/03/03/netflix-phishing-scam- customer-support_n_4892048.html. »Scammers Are Targeting Netflix Users Again, Preying On The Most Trusting Among Us«, 17. April 2014. http://www.huffingtonpost.com/2014/04/17/netflix-comcast-phishing- _n_5161680.html.

60415-4 Titelei_X 08.09.15 13:29 Seite 1

T. J. O’Connor Python Hacking

Lernen Sie die Sprache der Hacker, testen Sie Ihr System mit Python und schließen Sie die Lücken!

Programmierwissen der Hacker mit Quellcode erklärt: Analyse von Netzwerkverkehr, WLANs angreifen, Passwörter knacken, Exploits schreiben, Daten von sozialen Netzwerken abgreifen 5

Inhaltsverzeichnis

Danksagung...... 15

Der Autor: T. J. O’Connor...... 17

Der Coautor: Rob Frost...... 19

Der Fachgutachter: Mark Baggett...... 21

Einleitung...... 23 Zielgruppe...... 23 Der Aufbau dieses Buches...... 23 Kapitel 1: Grundlagen...... 24 Kapitel 2: Penetrationstests mit Python...... 24 Kapitel 3: Forensische Untersuchungen mit Python...... 24 Kapitel 4: Analyse des Netzwerkverkehrs mit Python...... 25 Kapitel 5: Angriffe auf drahtlose Netzwerke mit Python...... 25 Kapitel 6: Webaufklärung mit Python...... 25 Kapitel 7: Umgehen von Antivirussoftware mit Python...... 25 Die Begleitwebsite...... 26

1. Grundlagen...... 27 1.1 Einführung: Ein Penetrationstest mit Python...... 27 1.2 Die Entwicklungsumgebung einrichten...... 29 1.2.1 Drittanbieterbibliotheken installieren...... 29 1.2.2 Interpretiertes und interaktives Python im Vergleich...... 33 6 Inhaltsverzeichnis

1.3 Die Sprache Python...... 34 1.3.1 Variablen...... 35 1.3.2 Strings...... 36 1.3.3 Listen...... 36 1.3.4 Dictionarys...... 37 1.3.5 Netzwerkverbindungen...... 38 1.3.6 Bedingte Anweisungen...... 39 1.3.7 Ausnahmebehandlung...... 40 1.3.8 Funktionen...... 42 1.3.9 Iteration...... 44 1.3.10 Datei-E/A...... 47 1.3.11 Das Modul sys...... 48 1.3.12 Das Modul os...... 49 1.4 Ihr erstes Python-Programm...... 52 1.4.1 Kuckucksei: Der Hintergrund für Ihr erstes Python- Programm...... 52 1.4.2 Ein UNIX-Passwortknacker...... 53 1.4.3 Böse Dinge für einen guten Zweck: Der Hintergrund für Ihr zweites Python-Programm...... 57 1.4.4 Ein Passwortknacker für Zip-Dateien...... 58 1.5 Zusammenfassung...... 64 1.6 Literatur...... 64

2. Penetrationstests mit Python...... 67 2.1 Einführung: Würde der Morris-Wurm heute noch funktionieren?...... 67 2.2 Einen Portscanner schreiben...... 68 2.2.1 Vollständiger TCP-Verbindungsscan...... 69 2.2.2 Das Anwendungsbanner abrufen...... 72 Inhaltsverzeichnis 7

2.2.3 Den Scan auf Threads aufteilen...... 74 2.2.4 Den Nmap-Portscanner aufnehmen...... 78 2.3 Ein SSH-Botnetz mit Python aufbauen...... 80 2.3.1 Interaktion mit SSH über Pexpect...... 82 2.3.2 SSH-Passwörter mit Pxssh knacken...... 86 2.3.3 SSH über schwache private Schlüssel angreifen...... 90 2.3.4 Ein SSH-Botnetz aufbauen...... 95 2.4 Kombinierter Massenangriff über FTP und das Web...... 99 2.4.1 Einen Scanner für den anonymen FTP-Zugriff mit Python erstellen...... 100 2.4.2 FTP-Anmeldeinformationen mit Ftplib ermitteln...... 102 2.4.3 Auf dem FTP-Server nach Webseiten suchen...... 104 2.4.4 Schadcode auf den Webseiten injizieren...... 105 2.4.5 Die Einzelteile zusammenfügen...... 107 2.5 Conficker...... 113 2.5.1 Den Windows-SMB-Dienst mit Metasploit angreifen...... 115 2.5.2 Python-Code zur interaktiven Nutzung von Metasploit schreiben...... 117 2.5.3 Eine Brute-Force-Methode zur Ausführung von Remoteprozessen...... 119 2.5.4 Endmontage: Einen eigenen Conficker schreiben...... 120 2.6 Eigenen Zero-Day-Angriffscode schreiben...... 124 2.6.1 Angriffe mithilfe von Stack-Pufferüberläufen...... 124 2.6.2 Die Kernelemente des Exploits...... 125 2.6.3 Den Exploit senden...... 127 2.6.4 Das Exploit-Skript fertigstellen...... 128 2.7 Zusammenfassung des Kapitels...... 131 2.8 Literatur...... 131 8 Inhaltsverzeichnis

3. Forensische Untersuchungen mit Python...... 135 3.1 Einführung: Wie die BTK-Morde durch forensische Untersuchungen aufgeklärt wurden...... 135 3.2 Wo bist du gewesen? – Drahtlose Zugriffspunkte in der Registrierung analysieren...... 137 3.2.1 Die Windows-Registrierung mit WinReg lesen...... 138 3.2.2 Die MAC-Adresse mit Mechanize an Wigle übertragen.... 140 3.3 Gelöschte Elemente im Papierkorb mit Python untersuchen...... 146 3.3.1 Gelöschte Elemente mithilfe des Moduls OS finden...... 146 3.3.2 SIDs Benutzern zuordnen...... 147 3.4 Metadaten...... 150 3.4.1 PDF-Metadaten mit PyPDF analysieren...... 151 3.4.2 Exif-Metadaten...... 154 3.4.3 Bilder mit Beautiful Soup herunterladen...... 155 3.4.4 Exif-Metadaten von Bildern mit der Python-Bibliothek Imaging lesen...... 157 3.5 Spuren von Anwendungen mit Python untersuchen ...... 161 3.5.1 Die SQLite-Datenbank von Skype...... 161 3.5.2 Skype-Datenbankabfragen mit Python und Sqlite3 automatisieren...... 163 3.5.3 SQLite-Datenbanken von Firefox mit Python untersuchen...... 171 3.6 iTunes-Backups mit Python untersuchen...... 181 3.7 Zusammenfassung des Kapitels...... 189 3.8 Literatur...... 189 Inhaltsverzeichnis 9

4. Analyse des Netzwerkverkehrs mit Python...... 191 4.1 Einführung: Operation Aurora – Das Offensichtliche übersehen...... 192 4.2 Wohin geht der Datenverkehr? Python antwortet!...... 193 4.2.1 IP-Adressen mit PyGeoIP physischen Standorten zuordnen...... 194 4.2.2 Pakete mit Dpkt analysieren...... 195 4.2.3 Google-Karten mit Python erstellen...... 200 4.3 Analyse des LOIC-Datenverkehrs: Ist Anonymous wirklich anonym?...... 204 4.3.1 LOIC-Downloads mit Dpkt finden...... 204 4.3.2 IRC-Befehle zum Hive analysieren...... 206 4.3.3 Laufende DDoS-Angriffe erkennen...... 209 4.4 Wie H. D. Moore das Problem des Pentagon löste...... 215 4.4.1 Das TTL-Feld...... 216 4.4.2 TTL-Felder mit Scapy analysieren...... 218 4.5 Die Fast-Flux- und Domain-Flux-Techniken von Storm und Conficker...... 223 4.5.1 Weiß Ihr DNS etwas, das Sie nicht wissen?...... 224 4.5.2 DNS-Datenverkehr mit Scapy analysieren...... 225 4.5.3 Fast-Flux-Datenverkehr mit Scapy aufspüren...... 226 4.5.4 Domain-Flux-Datenverkehr mit Scapy aufspüren...... 228 4.6 Kevin Mitnick: Vorhersage von TCP-Folgenummern...... 230 4.6.1 Vorhersage von TCP-Folgenummern selbst gemacht..... 231 4.6.2 Eine SYN-Flood mit Scapy hervorrufen...... 232 4.6.3 TCP-Folgenummern berechnen...... 233 4.6.4 Die TCP-Verbindung fälschen...... 236 4.7 Intrusion-Detection-Systeme mit Scapy unterlaufen.....240 4.8 Zusammenfassung des Kapitels...... 249 4.9 Literatur...... 249 10 Inhaltsverzeichnis

5. Angriffe auf drahtlose Netzwerke mit Python...... 251 5.1 Einführung: (Un-) Sicherheit von WLANs und der Eismann...... 252 5.2 Die Umgebung für WLAN-Angriffe einrichten...... 252 5.2.1 Die Erfassung von WLAN-Datenverkehr mit Scapy testen...... 253 5.2.2 Bluetooth-Pakete für Python installieren...... 255 5.3 Wall of Sheep – WLAN-Geheimnisse passiv belauschen...... 256 5.3.1 Kreditkarteninformationen mit regulären Ausdrücken ausspähen...... 256 5.3.2 Hotelgäste ausspionieren...... 261 5.3.3 Einen WLAN-Keylogger für Google-Abfragen schreiben...... 264 5.3.4 FTP-Anmeldeinformationen ausspionieren...... 269 5.4 Wo ist Ihr Laptop gewesen? Python antwortet!...... 271 5.4.1 Auf 802.11-Suchanfragen lauschen...... 272 5.4.2 802.11-Signal von verborgenen Netzwerken finden...... 273 5.4.3 Verborgene 802.11-Netzwerke enttarnen...... 274 5.5 Drohnen mit Python übernehmen und ausspionieren....275 5.5.1 Datenverkehr abfangen und das Protokoll analysieren...... 276 5.5.2 802.11-Pakete mit Scapy gestalten...... 279 5.5.3 Die Drohne zum Absturz bringen...... 283 5.6 Firesheep erkennen...... 285 5.6.1 Wordpress-Sitzungscookies...... 286 5.6.2 Schafe hüten: Die Wiederverwendung von Wordpress- Cookies erkennen...... 288 5.7 Spionieren mit Bluetooth und Python...... 291 5.7.1 Drahtlosen Datenverkehr zum Ermitteln von Bluetooth- Adressen abfangen...... 293 Inhaltsverzeichnis 11

5.7.2 RFCOMM-Kanäle suchen...... 297 5.7.3 Service Discovery Protocol...... 299 5.7.4 Einen Drucker mit Python ObexFTP übernehmen...... 300 5.7.5 BlueBug-Angriffe mit Python durchführen...... 301 5.8 Zusammenfassung des Kapitels...... 303 5.9 Literatur...... 304

6. Webaufklärung mit Python...... 307 6.1 Einführung: Social Engineering heute...... 307 6.1.1 Aufklärung vor dem Angriff...... 308 6.2 Mit der Bibliothek Mechanize im Internet surfen...... 309 6.2.1 Anonymität: Proxys, Benutzeragenten und Cookies...... 311 6.2.2 Eine Python-Klasse für den anonymen Browser schreiben...... 315 6.3 Webseiten mit anonBrowser untersuchen...... 318 6.3.1 HREF-Links mit Beautiful Soup abschöpfen...... 318 6.3.2 Bilder mit BeautifulSoup spiegeln...... 321 6.4 Recherche, Untersuchung und Aufdeckung...... 323 6.4.1 Mit Python auf die Google-API zugreifen...... 324 6.4.2 Tweets mit Python analysieren...... 328 6.4.3 Ortsangaben aus Tweets entnehmen...... 331 6.4.4 Interessen auf Twitter mithilfe regulärer Ausdrücke bestimmen...... 334 6.5 Anonyme E-Mail...... 340 6.6 Social Engineering als Massenangriff...... 341 6.6.1 E-Mails mit Smtplib verschicken...... 342 6.6.2 Spear Phishing mit Smtplib...... 344 6.7 Zusammenfassung des Kapitels...... 348 6.8 Literatur...... 349 12 Inhaltsverzeichnis

7. Umgehen von Antivirussoftware mit Python...... 351 7.1 Einführung: Flame...... 351 7.2 Antivirusprogrammen ausweichen...... 352 7.3 Die Umgehung der Antivirussoftware bestätigen...... 357 7.4 Zusammenfassung...... 365 7.5 Literatur...... 365 Für mein Äffchen und meine Ninja-Prinzessin: Alles ist möglich, wenn man sich nur stark genug bemüht. 15 

Danksagung

Die Wendung »pass auf deinen Rücken auf« im Militärjargon bedeutet, dass man stets auch hinter sich Ausschau halten muss. Bei einer Militärpa- trouille muss mindestens ein Mitglied rückwärts gehen, um das hinter den anderen liegende Gelände auf Gefahren abzusuchen, die die anderen nicht sehen können. Als ich meinen Mentor darauf ansprach, dass ich ein Buch schreiben wollte, gab er mir zu verstehen, dass dies nur möglich ist, wenn ich Teamkameraden habe, die bereitwillig auf meinen Rücken aufpassen. Ich dachte über die Menschen in meinem Leben nach, auf die sich meine Unternehmung auswirken würde, und wusste schon nach drei Sekunden, dass sie alle stark genug wären.

An meinen Fachgutachter Mark Baggett: Deine unablässigen technischen Korrekturen haben dieses Buch vor Fehlern bewahrt. An Dr. Reeves, Dr. Freeh, Dr. Jacoby und Dr. Blair: Vielen Dank, dass Sie vor vielen Jahren einen zornigen jungen Armeeoffizier aufgenommen und zu einem unge- wöhnlichen Akademiker gemacht haben, der in der Lage ist, ein Buch zu schreiben. An Dr. Fanelli: Danke, dass Sie mir nicht beigebracht haben, »unkonventionell« zu denken, sondern die Konventionen dazu zu nutzen, etwas Neues zu entwickeln. An Dr. Conti: Danke, dass Sie mich geschickt so manipuliert haben, dass ich Gesetz 28 folgte. An meine ehemaligen Studen- ten, insbesondere die Ninja-Gruppe von Alan, Alex, Arod, Chris, Christina, Duncan, Gremlin, Jim, James, Kevin, Rob, Steven, Sal und Topher: Eure Kreativität ist für mich weiterhin eine Quelle der Inspiration.

An Rob Frost: Danke, dass du ein viel aussagekräftigeres Kapitel über Webaufklärung geschrieben hast, als ich es jemals hätte tun können. An Matt, Ryan, Kirk, Mark, Bryan und Bill: Danke für euer Verständnis da- für, dass ich in der Nacht davor nicht schlafen konnte, und dafür, dass ihr nicht nur auf meinen Rücken, sondern auch rundherum aufgepasst habt. An meine liebende Frau, mein Äffchen und meine Ninja-Prinzessin: Danke für deine bedingungslose Liebe, dein Verständnis und deine Unterstützung während dieses Unternehmens. An meine Eltern: Danke, dass ihr mir bei- gebracht habt, Bildung zu schätzen. Und an Dr. Cook: Tank on, brother! 17 

Der Autor: T. J. O’Connor

T. J. O’Connor ist Experte für Informationssicherheit beim US-Verteidi- gungsministerium und Fallschirmjäger der US Army. Als Privatdozent an der US-Militärakademie gab er Kurse über Forensik, Exploits und Informa- tionsschutz. Zweimal betreute er als Co-Trainer Teams, die aus den jährli- chen Cyber-Defense-Übungen der NSA als Sieger hervorgingen. Außerdem gewann er den ersten jährlichen Cyber Challenge der National Defense University. Er hat schon in mehreren Red Teams gedient, unter anderem zweimal im Northeast Regional Team bei der National Collegiate Cyber Defense Competition.

O’Connor hat einen Mastergrad in Informatik von der North Carolina State University, einen Mastergrad in Informationssicherheit vom SANS Technical Institute sowie einen Bachelorgrad in Informatik von der US- Militärakademie. Er hat wissenschaftliche Forschungsergebnisse in USE- NIX-Arbeitskreisen, auf ACM- und Sicherheitskonferenzen, im SANS Rea- ding Room, beim Internet Storm Center, im Army Magazine und im Armed Forces Journal vorgestellt. Zu seinen Auszeichnungen als Experte auf dem Gebiet der Computersicherheit gehören das angesehene Zertifikat als GSE (GIAC Security Expert) und OSCE (Offensive Security Certified Expert). O’Connor ist Mitglied des SANS-Eliteteams Cyber Guardians. 19 

Der Coautor: Rob Frost

Robert Frost erlangte im Jahr 2011 seinen Abschluss an der US-Militäraka- demie und ging zur Fernmeldetruppe der US Army. Er hat einen Bachelor in Informatik mit Auszeichnung, wobei er sich in seiner Bachelorarbeit auf Informationsbeschaffung aus öffentlich zugänglichen Quellen konzentrier- te. Aufgrund seiner Fähigkeit, Regeln zu umgehen, wurde Rob als eines von zwei Mitgliedern des nationalen Meisterschaftsteams für die Cyber Defense Exercise 2011 ausgewählt. Rob hat mehrere Wettbewerbe in Computersi- cherheit gewonnen. 21 

Der Fachgutachter: Mark Baggett

Mark Baggett ist zertifizierter SANS-Ausbilder und gibt verschiedene Kurse im Rahmen des SANS-Lehrplans über Penetrationstests. Er ist Hauptbe- rater und Gründer der Firma In Depth Defence Inc., die Penetrationstests und Incident-Response-Dienste anbietet. In seiner Rolle als technischer SANS-Berater des US-Verteidigungsministeriums ist Baggett insbesondere mit der praktischen Anwendung von SANS-Ressourcen bei der Entwick- lung militärischer Fähigkeiten beschäftigt.

Baggett war in großen internationalen und Fortune-1000-Unternehmen auf verschiedenen Posten für Informationssicherheit verantwortlich. Er hat als Softwareentwickler, als Netzwerk- und Systemingenieur, als Sicherheits- manager und als CISO gearbeitet. In letzterer Stellung war er für Richtli- nien, Konformität, Reaktion auf Störungen und alle anderen Aspekte der Informationssicherheit verantwortlich. Damit kennt er die Herausforde- rungen, die sich Sicherheitsexperten heute beim Verkaufen, Umsetzen und Unterstützen von Maßnahmen zur Informationssicherheit stellen, aus erster Hand. Baggett ist aktives Mitglied der Informationssicherheit-Community und Gründungspräsident der Greater Augusta ISSA. Er besitzt verschiedene Zertifikate, darunter das angesehene GSE des SANS-Instituts. Sein Blog über verschiedene Sicherheitsthemen finden Sie auf http://www.pauldotcom.com. 23

Einleitung

Python ist eine Sprache für Hacker. Dank ihrer Unkompliziertheit und hohen Effizienz, dank der zahllosen Drittanbieterbibliotheken und der niedrigen Einstiegsschwelle stellt Python eine hervorragende Entwick- lungsplattform für offensive Werkzeuge dar. Wenn auf Ihrem Computer Mac OS X oder Linux läuft, ist die Sprache mit hoher Wahrscheinlichkeit schon auf Ihrem System installiert. Es gibt zwar schon eine große Men- ge an Offensivwerkzeugen, doch mit Python können Sie auch mit den schwierigen Fällen umgehen, in denen diese Werkzeuge versagen.

Zielgruppe

Jeder Mensch lernt auf seine eigene Weise. Doch unabhängig davon, ob Sie als Anfänger lernen wollen, Python-Skripts zu schreiben, oder als erfahrener Programmierer daran interessiert sind, Ihre Fähigkeiten auf Penetrations­ tests anzuwenden, ist dieses Buch etwas für Sie.

Der Aufbau dieses Buches

Mit diesem Buch wollten wir ein »Kochbuch des Bösen« schreiben und Beispiele für die dunklen Möglichkeiten von Python geben. Sie finden hier Python-Rezepte für Penetrationstests, Webanalyse, Netzwerkanalyse, foren- sische Analyse und zum Einbruch in drahtlose Geräte. Diese Beispiele sollen Sie dazu anregen, Ihre eigenen Python-Skripts zu schreiben. 24 Einleitung

Kapitel 1: Grundlagen

Für diejenigen, die noch nie in Python programmiert haben, gibt Kapitel 1 Hintergrundinformationen über die Sprache, ihre Variablen, Datentypen, Funktionen, über Iteration, Auswahl und die Arbeit mit Modulen. Sie er- halten hier anhand von einigen einfachen Programmen eine methodische Anleitung. Wenn Sie bereits mit Python vertraut sind, können Sie dieses Kapitel ruhig überschlagen. Die anschließenden Kapitel sind größtenteils in sich abgeschlossen, sodass Sie sie in jeder beliebigen Reihenfolge lesen können, je nachdem, was Sie am meisten interessiert.

Kapitel 2: Penetrationstests mit Python

In Kapitel 2 lernen Sie die Verwendung von Python zum Schreiben von Angriffsskripts für Penetrationstests kennen. Die Beispiele in diesem Ka- pitel umfassen einen Portscanner, den Aufbau eines SSH-Botnetzes, einen Massenangriff über FTP, einen Nachbau des Wurms Conficker und das Schreiben eines eigenen Exploits.

Kapitel 3: Forensische Untersuchungen mit Python

In Kapitel 3 verwenden wir Python für digitale forensische Untersuchungen. In den Beispielen lernen Sie, wie Sie den Standort von Personen heraus- finden, gelöschte Elemente wiederherstellen, Spuren in der Windows-Regis­ trierung sichern, Metadaten in Dokumenten und Bildern untersuchen und Spuren von Anwendungen und Mobilgeräten feststellen. Einleitung 25

Kapitel 4: Analyse des Netzwerkverkehrs mit Python

In Kapitel 4 wird Python zur Analyse des Netzwerkverkehrs eingesetzt. Die Skripts in diesem Kapitel ermitteln aus abgefangenen Paketen die IP-Adres- se und den physischen Standort, untersuchen ein weit verbreitetes DDoS- Angriffswerkzeug, decken Ablenkungsscans auf, analysieren Botnetz-Da- tenverkehr und unterlaufen Intrusion-Detection-Systeme.

Kapitel 5: Angriffe auf drahtlose Netzwerke mit Python

In Kapitel 5 geht es um Angriffe auf WLAN- und Bluetooth-Geräte. Die Beispiele in diesem Kapitel zeigen, wie Sie drahtlosen Datenverkehr abfan- gen und analysieren, einen Keylogger für drahtlose Verbindungen erstellen, versteckte drahtlose Netzwerke finden, Drohnen fernsteuern, Schadsoft- ware für drahtlose Netzwerke aufspüren, Bluetooth-Verbindungen abhö- ren und Schwachstellen von Bluetooth ausnutzen.

Kapitel 6: Webaufklärung mit Python

Kapitel 6 beschäftigt sich damit, wie Sie das Web mithilfe von Python nach Informationen absuchen. Zu den Beispielen gehören das anonyme Surfen mit Python, die Arbeit mit Entwickler-APIs, die Informationsgewinnung auf populären Social-Media-Websites und das Aufstellen einer maßge- schneiderten E-Mail für Spear-Phishing.

Kapitel 7: Umgehen von Antivirussoftware mit Python

Im letzten Kapitel schreiben wir eine Malware, die Antivirussystemen aus- weichen kann. Außerdem entwickeln wir ein Skript, das unsere Malware zu einem Online-Virenscanner hochlädt. 26 Einleitung

Die Begleitwebsite

Die Begleitwebsite enthält den gesamten in diesem Buch besprochenen Code. Um die Beispiele und Netzwerkaufzeichnungen herunterzuladen, be- suchen Sie http://www.buch.cd. Zum Download geben Sie den Code 60415-4 ein. 2 Penetrationstests mit Python

Ein Krieger wird man nicht einfach dadurch, dass man es sich wünscht. Es ist ein endloser Kampf, der bis zum allerletzten Augenblick unseres Lebens anhält. Niemand wird als Krieger geboren, genauso wenig, wie jemand als Durchschnittsmensch geboren wird. Wir machen uns selbst entweder zu dem einen oder zu dem anderen.

»Kokoro« von Natsume Soseki, Japan, 1914

2.1 Einführung: Würde der Morris-Wurm heute noch funktionieren?

22 Jahre, bevor der Wurm Stuxnet die iranischen Atomanlagen in Buschehr und Natanz lahmlegte (Albright, Brannan und Walrond, 2010), startete ein Student an der Cornell University die erste digitale Angriffswaffe. Robert 68 Kapitel 2: Penetrationstests mit Python

Tappan Morris Jr., dessen Vater das staatliche Computersicherheitszentrum der NSA leitete, infizierte 6000 Arbeitsstationen mit einem Wurm, der nach ihm Morris-Wurm benannt wurde (Elmer-Dewitt, McCarroll und Voorst, 1998). Nach heutigen Maßstäben mögen 6000 Arbeitsstationen vernach- lässigbar erscheinen, aber das war 1988 ein Zehntel aller Computer, die mit dem Internet verbunden waren. Nach groben Schätzungen des US-Rech- nungshofes lagen die Kosten für die Beseitigung der Schäden durch den Morris-Wurm zwischen 10 und 100 Millionen Dollar (GAO, 1989). Wie funktionierte dieser Wurm?

Der Morris-Wurm führte einen Drei-Seiten-Angriff aus. Er nutzte Schwach- stellen in Unix-Programmen aus, erstens in sendmail und zweitens im finger- Daemon. Drittens versuchte er mithilfe einer Liste gebräuchlicher Benutzer- namen und Passwörter, RSH-Verbindungen (Remote Shell) zu den Zielen aufzunehmen. Wenn er auf irgendeinem dieser Angriffswege Erfolg hatte, konnte der Wurm ein kleines Programm als eine Art Enterhaken benutzen, um sich vollständig zu dem Zielcomputer herüberzuziehen (Eichin und Rochlis, 1989).

Würde ein ähnlicher Angriff auch heute noch funktionieren? Können wir etwas Ähnliches schreiben? Diese Fragen bilden die Grundlage für die Er- örterung in diesem Kapitel. Morris schrieb den Großteil seines Wurms in C. Diese Sprache ist zwar sehr vielseitig, aber schwer zu lernen. Im Gegen- satz dazu weist Python eine benutzerfreundliche Syntax auf und bietet eine Fülle von Drittanbietermodulen. Dadurch steht eine viel solidere Grundla- ge zur Verfügung, was auch das Auslösen von Angriffen leichter macht. Auf den folgenden Seiten werden wir in Python Teile des Morris-Wurms nach- bauen, dabei aber auch einige neuzeitliche Angriffswege berücksichtigen.

2.2 Einen Portscanner schreiben

Der erste Schritt zu einem erfolgreichen Cyberangriff ist die Aufklärung. Ein Angreifer muss erst herausfinden, wo die Schwachstellen liegen, be- vor er Exploits auswählen kann. In diesem Abschnitt schreiben wir ein Einen Portscanner schreiben 69

kurzes Aufklärungsskript, das nach offenen TCP-Ports auf dem Zielhost sucht. Um aber mit TCP-Ports arbeiten zu können, müssen wir zunächst TCP-Sockets erstellen.

Wie die meisten modernen Sprachen bietet auch Python Zugriff auf die An- wendungsprogrammierschnittstelle (API) für BSD-Sockets. Damit lassen sich Anwendungen für die Netzwerkkommunikation zwischen Hostcom- putern schreiben. Es gibt API-Funktionen, um TCP/IP-Sockets zu erstellen, zu binden, an ihnen zu lauschen, Verbindung mit ihnen aufzunehmen und Datenverkehr an sie zu senden. Um unsere eigenen Angriffsprogramme bes- ser entwickeln zu können, müssen wir jedoch zunächst etwas mehr über TCP/IP und Sockets erfahren.

Die Mehrheit der über das Internet zugänglichen Anwendungen stützt sich auf TCP. Beispielsweise kann der Webserver einer Organisation TCP- Port 80 verwenden, der E-Mail-Server TCP-Port 25 und der FTP-Server TCP-Port 21. Um Verbindung mit irgendeinem dieser Dienste in der Ziel- organisation aufzunehmen, muss ein Angreifer sowohl die IP-Adresse als auch den mit dem Dienst verbundenen Port kennen. Wenn er mit der Zielorganisation vertraut ist, hat er diese Informationen womöglich, aber ein Angreifer kennt sie wahrscheinlich nicht.

Zur Eröffnung eines Cyberangriffs führen Angreifer routinemäßig einen Portscan durch. Eine Möglichkeit dazu besteht darin, ein TCP-SYN-Paket an eine Reihe von gängigen Ports zu senden und auf die TCP-ACK-Antwort zu warten, die auf einen offenen Port hindeutet. Bei einem TCP-Verbin- dungsscan dagegen wird ein vollständiger Drei-Wege-Handshake durchge- führt, um zu bestimmen, ob der Dienst oder Port zur Verfügung steht.

2.2.1 Vollständiger TCP-Verbindungsscan

Beginnen wir also damit, einen TCP-Portscanner zu schreiben, der zur Iden- tifizierung der Hosts einen vollständigen TCP-Verbindungsscan einsetzt. Als Erstes importieren wir die Python-Implementierung der BSD-Socket-API, 70 Kapitel 2: Penetrationstests mit Python

die uns mit einigen wichtigen Funktionen für unsere Zwecke versorgt. Wir wollen uns einige wenige davon kurz anschauen, bevor wir fortfahren. Um mehr zu erfahren, lesen Sie die Dokumentation der Python-Standardbiblio- thek auf http://docs.Python.org/library/socket.html.

•• socket.gethostbyname(hostname) – Diese Funktion nimmt einen Hostnamen wie www.syngress.com entgegen und gibt eine IPv4-Adres- se wie 69.163.177.2 zurück. •• socket.gethostbyaddr(ip address) – Diese Funktion nimmt eine IPv4- Adresse entgegen und gibt ein Tripel aus Hostname, Liste alternativer Hostnamen und Liste von IPv4/IPv6-Adressen für dieselbe Hostschnitt- stelle zurück. •• socket.socket([family[, type[, proto]]]) – Diese Funktion erstellt eine Socketinstanz der angegebenen Familie. Zur Auswahl stehen da- bei AF_INET, AF_INET6 und AF_UNIX. Außerdem kann SOCK_STREAM für TCP-Sockets oder SOCK_DGRAM für UDP-Sockets angegeben werden. Die Protokollnummer ist gewöhnlich 0 und wird in den meisten Fällen weggelassen. •• socket.create_connection(address[, timeout[, source_address]]) – Diese Funktion nimmt ein 2-Tupel (Host, Port) entgegen und gibt eine Instanz eines Netzwerksockets zurück. Außerdem können Sie einen Zeitüberschreitungswert und eine Quelladresse angeben. Um die Funktionsweise unseres TCP-Portscanners besser zu verstehen, teilen wir unser Skript in fünf einzelne Schritte auf. Als Erstes übergeben wir einen Hostnamen und eine durch Kommata getrennte Liste der zu scannenden Ports. Danach übersetzen wir den Hostnamen in eine IPv4- Adresse. Für jeden Port auf der Liste müssen wir dann eine Verbindung zu der Zieladresse und dem angegebenen Port herstellen. Um den Dienst zu ermitteln, der hinter dem Port läuft, senden wir schließlich sinnlose Daten und lesen das Banner, das von der Anwendung zurückgesendet wird.

Im ersten Schritt nehmen wir den Hostnamen und den Port vom Benut­ zer entgegen. Dazu erfasst unser Programm die Kommandozeilenop- tionen mithilfe der Bibliothek optparse. Der Aufruf optparse.Option- Einen Portscanner schreiben 71

Parser([usage message]) erstellt eine Instanz des Optionsparsers. Danach gibt parser.add_option die einzelnen Befehlszeilenoptionen für unser Skript an. Das folgende Beispiel zeigt eine schnelle Methode, um den Ziel- hostnamen und den zu scannenden Port zu bestimmen:

import optparse parser = optparse.OptionParser(‘usage %prog –H’+\ ‘ -p ’) parser.add_option(‘-H’, dest=’tgtHost’, type=’string’, \ help=’specify target host’) parser.add_option(‘-p’, dest=’tgtPort’, type=’int’, \ help=’specify target port’) (options, args) = parser.parse_args() tgtHost = options.tgtHost tgtPort = options.tgtPort if (tgtHost == None) | (tgtPort == None): print parser.usage exit(0)

Als Nächstes schreiben wir die beiden Funktionen connScan und port­ Scan. Letztere nimmt den Hostnamen und den Zielpunkt als Argumente entgegen. Sie versucht dann zunächst, die IP-Adresse mit der Funktion gethostbyname() zu einem Anzeigenamen aufzulösen. Danach gibt sie den Hostnamen (oder die IP-Adresse) aus und zählt die einzelnen Ports auf, zu denen die Funktion connScan eine Verbindung herzustellen ver- suchen soll. Diese Funktion wiederum nimmt als Argumente den Ziel- host und den Zielport (tgtHost und tgtPort) entgegen und versucht eine Verbindung dazu aufzubauen. Wenn das gelingt, meldet connScan einen offenen Port, anderenfalls einen geschlossenen. Zusammenfassung des Kapitels 131

2.7 Zusammenfassung des Kapitels

In diesem Kapitel haben wir eigene Werkzeuge geschrieben, die wir in einem Penetrationstest einsetzen können. Zu Anfang haben wir einen Portscanner erstellt. Danach haben wir uns Möglichkeiten für den Angriff auf die Protokolle SSH, FTP und SMB angesehen. Zum Schluss haben wir einen eigenen Zero-Day-Exploit in Python geschrieben.

Ich hoffe, dass Sie für Ihre Penetrationstests sehr viel Code schreiben ­werden. Um Ihnen zu helfen, Ihre Tests zu verbessern, habe ich Ihnen einige der Grundlagen von Python-Skripts vorgeführt. Nachdem Sie nun einen Ein- blick in die Möglichkeiten von Python gewonnen haben, wollen wir uns an- sehen, wie wir Skripts für forensische Untersuchungen schreiben können.

2.8 Literatur

Ahmad, D. (2008) »Two years of broken crypto: ’s dress rehearsal for a global PKI compromise«, IEEE Security & Privacy, S. 70–73.

Albright, D., Brannan, P., und Walrond, C. (2010). »Did Stuxnet Take Out 1,000 Centrifuges at the Natanz Enrichment Plant?«, ISIS REPORT, 22. November 2010. isis-online.org/uploads/isis-reports/documents/stuxnet_ FEP_22Dec2. Abgerufen am 31.10.2011.

Eichin, M., und Rochlis, J. (1989). »With Microscope and Tweezers: An Analysis of the Internet Virus of November 1988«, 9. Februar 1989. www. utdallas.edu/~edsha/UGsecurity/internet-worm-MIT.pdf. Abgerufen am 31.10.2011.

Elmer-Dewitt, P., McCarroll, T., und Voorst, B. V. (1988). »Technology: the kid put us out of action«, Time Magazine, 14. Oktober 1988. http://www. time.com/time/magazine/article/0,9171,968884,00.html. Abgerufen am 30.10.2011. 132 Kapitel 2: Penetrationstests mit Python

Freyman, C. (2011). »FreeFloat FTP 1.0 Any Non Implemented Command Buffer Overflow«, Packet Storm Full Disclosure Information Security, 18. Juli 2011. http://packetstormsecurity.org/files/view/103166/freefloat2-overflow. py.txt. Abgerufen am 31.10.2011.

GAO (1989). »Report to the Chairman, Subcommittee on Telecommunica- tions and Finance, Committee on Energy and Commerce House of Repre- sentatives. ‚Virus Highlights Need for Improved Internet Management.‘« United States General Accounting Office. tp.cerias.purdue.edu/pub/doc/mor- ris_worm/GAO-rpt.txt. Abgerufen am 31.10.2011.

Huang, W. (2011). »k985ytv mass compromise ongoing, spreads fake antivirus«, Armorize Malware Blog, 17. August 2011. http://blog.armo- rize.com/2011/08/k985ytvhtmfake-antivirus-mass.html. Abgerufen am 31.10.2011.

Markoff, J. (2009). »Defying experts, rogue computer code still lurks«, The New York Times, 27. August 2009. http://www.nytimes.com/2009/08/27/ technology/27compute.html. Abgerufen am 30.10.2011.

Moore, H. D. (2008). »Debian OpenSSL predictable PRNG toys«, Digi- tal Offense. http://digitaloffense.net/tools/debian-openssl/. Abgerufen am 30.10.2011.

Nahorney, B. (2009). »The Downadup Codex a comprehensive guide to the threat’s mechanics«, Symantec Security Response. www.symantec.com/ content/en/us/enterprise/media/security_response/whitepapers/the_downa- dup_codex_ed2.pdf. Abgerufen am 30.10.2011.

One, A. (1996). »Smashing the stack for fun and profit«, Phrack Magazine, 11. August 1996. http://www.phrack.org/issues.html?issue=49&id=14#article. Abgerufen am 30.10.2011.

US vs. Morris (1991). »928 F. 2d 504, (C. A. 2nd Circuit, 7. März 1991)«, Google Scholar. http://scholar.google.com/scholar_case?case=551386241451639668. Abgerufen am 31.10.2011. Literatur 133

Vaskovich, F. (1997). »The Art of Port Scanning«, Phrack Magazine, 1. Sep- tember 1997. http://www.phrack.org/issues.html?issue=51-id=11#article. Abgerufen am 31.10.2011.

60416-1 Titelei_X 06.08.15 11:10 Seite 3

Peter Loshin Anonym im Internet mit Tor und Tails

Nutze die Methoden von Snowden und hinterlasse keine Spuren im Internet. 60416-1 Titelei_X 06.08.15 11:10 Seite 2

Peter Loshin ist unabhängiger Berater zu Internetprotokollen und Open-Source-Netzwerktechnologien. Er schreibt auch zu diesen Themen. Seine Arbeiten erscheinen regelmäßig in führenden Fachzeit- schriften und auf Webseiten. Dazu gehören CPU, Computerworld, PC Magazine, EarthWeb, Internet.com und CNN. 5

Inhaltsverzeichnis

Vorwort...... 11

Danksagungen...... 13

1. Anonymität und Umgehung der Zensur...... 15 1.1 Was bedeutet Anonymität?...... 20 1.2 Was ist Tor?...... 21 1.3 Gründe für die Verwendung von Tor...... 26 1.4 Was Tor nicht leisten kann...... 30 1.5 So funktioniert Tor...... 32 1.5.1 Bestandteile des Tor-Protokolls...... 34 1.5.2 Sichere Tunnel mit den öffentlichen Schlüsseln der Tor-Knoten aufbauen...... 36 1.5.3 Der Austrittsknoten als Vertreter des Tor-Clients...... 37 1.6 Wer verwendet Tor?...... 38 1.6.1 Normalbürger...... 39 1.6.2 Militär...... 41 1.6.3 Journalisten und ihre Leser/Zuschauer...... 41 1.6.4 Strafverfolgungsbehörden...... 42 1.6.5 Informanten und Aktivisten...... 42 1.6.6 Personen mit und ohne große Öffentlichkeitswirkung.....42 1.6.7 Geschäftsleute und IT-Experten...... 43 1.6.8 Weitere Personen...... 43 1.6.9 Der Vorteil eines breiten Spektrums an Benutzern...... 44 1.7 Wie wird Tor verwendet?...... 46 1.7.1 Vorausplanen und Tor jetzt kennenlernen...... 47 1.7.2 TBB oder Tails?...... 48 6 Inhaltsverzeichnis

1.7.3 Tor Browser Bundle...... 48 1.7.4 Tails...... 49 1.7.5 Vertrauen ist gut ...... 49 1.8 Sichere Verwendung von Tor...... 51 1.8.1 Verwenden Sie den Tor-Browser...... 51 1.8.2 Öffnen Sie keine Dokumente...... 51 1.8.3 Installieren und aktivieren Sie keine Browser-Plug-Ins....52 1.8.4 Vermeiden Sie Websites ohne HTTPS...... 52 1.8.5 Verwenden Sie Bridges und suchen Sie Gesellschaft...... 52

2. Das Tor Browser Bundle...... 53 2.1 Der Inhalt des TBB...... 53 2.1.1 Vidalia...... 54 2.1.2 Tor...... 56 2.1.3 Mozilla Firefox ESR und Torbutton...... 56 2.1.4 Weitere Inhalte...... 58 2.2 Das TBB verwenden...... 59 2.2.1 Erste Schritte...... 60 2.2.2 Das TBB starten: Windows...... 60 2.2.3 Das TBB starten: Mac OS X...... 61 2.2.4 Das TBB starten: Linux...... 61 2.2.5 Installation auf Ubuntu: GUI...... 63 2.2.6 Installation auf Ubuntu: Kommandozeile...... 63 2.2.7 Vidalia...... 66 2.2.8 Schnellzugriff...... 67 2.2.9 Logbuch...... 67 2.2.10 Tor starten/stoppen...... 68 2.2.11 Weiterleitung einrichten...... 69 2.2.12 Netzwerk betrachten...... 71 2.2.13 Eine neue Identität verwenden...... 72 2.2.14 Bandbreitengraph...... 74 Inhaltsverzeichnis 7

2.3 Einstellungen...... 74 2.3.1 Allgemein ...... 75 2.3.2 Netzwerk...... 76 2.3.3 Beteiligung...... 77 2.3.4 Dienste...... 79 2.3.5 Aussehen...... 79 2.3.6 Fortgeschritten...... 80 2.4 Den Tor-Browser verwenden...... 80 2.5 Wenn Tor keine Verbindung herstellen kann...... 81 2.5.1 Grundlegende Störungssuche...... 81 2.5.2 Brauchen Sie einen Proxy?...... 81 2.5.3 Das Logbuch einsehen...... 82 2.5.4 Tor für Firewalls einstellen...... 83 2.5.5 Wenn Tor immer noch keine Verbindung herstellen will...83

3. Tails...... 85 3.1 Der Umfang von Tails...... 87 3.2 Tails einrichten...... 90 3.2.1 Tails beziehen...... 90 3.2.2 Das System zum Starten von Tails einrichten...... 91 3.3 Tails verwenden...... 92 3.3.1 Tails starten...... 93 3.3.2 Tails herunterfahren...... 94 3.3.3 Tails auf einem USB-Laufwerk installieren...... 95 3.3.4 Tails manuell auf einem USB-Gerät installieren...... 97 3.3.5 Tails aktualisieren (Clone & Upgrade)...... 98 3.3.6 Persistente Speicherbereiche auf dem Tails-Medium...... 99 3.3.7 Persistente Speicherbereiche einrichten...... 101 3.3.8 Whisperback...... 102 3.3.9 KeePassX...... 103 8 Inhaltsverzeichnis

3.3.10 Metadata Anonymization Toolkit...... 103 3.3.11 Claws Mail...... 105 3.3.12 GNU Privacy Guard...... 106

4. Tor-Relays, Bridges und Obfsproxy...... 107 4.1 Wenn das normale Tor nicht ausreicht...... 108 4.1.1 Wie China Tor blockiert hat...... 109 4.1.2 Ist Tor ausgefallen oder brauchen Sie eine Bridge?...... 110 4.2 Bridge-Relays...... 112 4.2.1 Bridge-Relays mithilfe der BridgeDB finden...... 114 4.2.2 Bridge-Relays per E-Mail finden...... 114 4.2.3 Andere Möglichkeiten Bridges zu finden...... 116 4.3 Tor zur Verwendung eines Bridge-Relays ­einrichten...... 116 4.4 Plug-In-Transportproxys und Obfsproxy...... 118 4.4.1 Plug-In-Transportproxys...... 119 4.4.2 Flash Proxy...... 120 4.4.3 Plug-In-Transportproxys verwenden...... 121

5. Tor-Ressourcen bereitstellen...... 123 5.1 Einen Beitrag zum Tor-Netzwerk leisten – wie und warum?...... 123 5.2 Welche Möglichkeiten haben Sie?...... 124 5.3 Welche Risiken gehen Sie ein?...... 127 5.4 Einrichtung eines Tor-Relays...... 128 5.5 Anforderungen und Konsequenzen...... 129 5.6 Nicht-Austrittsrelay...... 130 5.7 Austrittsknoten...... 131 5.8 Bridge-Relay...... 132 Inhaltsverzeichnis 9

6. Verborgene Tor-Dienste...... 135 6.1 Gründe für die Verwendung verborgener Dienste...... 136 6.2 Funktionsweise von verborgenen Tor-Diensten...... 137 6.2.1 Das Tor-Protokoll für verborgene Dienste...... 138 6.2.2 Pseudo-URLs...... 140 6.2.3 Web-Onion-Proxys...... 142 6.2.4 Was in den Schatten lauert...... 143 6.3 Verborgene Tor-Dienste einrichten...... 144 6.3.1 Tor zum Laufen bekommen...... 145 6.3.2 Den Server installieren...... 147 6.3.3 Den verborgenen Dienst einrichten...... 148 6.3.4 Tipps, Tricks und Fallgruben...... 150

7. E-Mail-Sicherheit und Vorgehensweisen zur Förderung der Anonymität...... 153 7.1 Einweg-Konten...... 155 7.1.1 10minutemail.com...... 156 7.1.2 Anonymous Email (http://www.5ymail.com/)...... 156 7.1.3 Vermeiden Sie diese Dienste...... 157 7.2 Anonyme Remailer-Dienste...... 158 7.3 Anonyme E-Mail-Kommunikation über Tor...... 159 7.4 Anonyme E-Mail-Kommunikation als verborgener Tor-Dienst...... 161 7.5 Anonymität und Pseudonymität...... 161 7.6 Tipps für die anonyme E-Mail-Kommunikation...... 162 7.6.1 Die Anonymität bei der E-Mail-Kommunikation wahren.163 7.6.2 Verwenden Sie immer Tor...... 164 7.6.3 Verwenden Sie stets HTTPS...... 165 7.7 Schritt für Schritt: Ein anonymes E-Mail-Konto einrichten...... 165 10 Inhaltsverzeichnis

A. Validierung der Tor-Software...... 167 A.1 Tor-Software mit GNU Privacy Guard validieren...... 167 A.2 Tails-Distributionen mit GnuPG validieren...... 171 A.3 Mit welchen PGP-Schlüsseln sind welche Pakete signiert?...... 174

B. Wenn Tor-Downloads gesperrt werden...... 181 B.1 Tor-Spiegel...... 182 B.2 Tor per E-Mail...... 183 B.3 Weitere Möglichkeiten...... 184

C. Hilfe suchen und Antworten erhalten...... 185 C.1 Tor...... 186 C.1.1 Bug-Tracker/Wiki...... 186 C.1.2 Tor-FAQ...... 187 C.1.3 Tor-Dokumentation...... 188 C.1.4 Verborgene Tor-Server...... 188 C.2 Das Tor-Projekt...... 189 C.2.1 Kontaktinformationen...... 189 C.2.2 Menschen und Organisationen hinter dem Tor-Projekt 190 11

Vorwort

Der Google-CEO Eric Schmidt löste 2009 einen Proteststurm aus, als er erklärte: »Datenschutz ist tot!« Er sagte:

Wenn Sie etwas tun, von dem niemand etwas wissen sollte, dann sollten Sie es am besten erst gar nicht tun. Wenn Sie aber wirklich einen Da- tenschutz brauchen, dann ist es in Wirklichkeit so, dass Suchmaschinen einschließlich Google diese Informationen eine Zeit lang aufbewahren, und es ist beispielsweise wichtig, dass wir in den Vereinigten Staaten alle dem Patriot Act unterliegen. Es ist möglich, dass diese Informationen den Behörden zugänglich gemacht werden.

Für diejenigen, die legitime Gründe haben, das Internet anonym zu nutzen – Diplomaten, Angehörige des Militärs und anderer staatlicher Organisa- tionen, Journalisten, politische Aktivisten, IT-Profis, Strafverfolgungsbe- amte, politisch Verfolgte und andere –, bilden Anonymisierungsnetzwerke ein wertvolles Instrument. Es gibt viele gute Zwecke, für die ­Anonymität sehr wichtig sein kann.

Die anonyme Nutzung des Internets wird durch die vielen Websites, die alles über uns wissen, durch Cookies und Werbenetzwerke und durch die Protokollierung von IP-Adressen bei den Providern erschwert, und auch neugierige Beamte können eine Rolle spielen. Es reicht nicht mehr aus, die Cookies im Browser auszuschalten, um online allein gelassen zu werden.

Für viele mag die Verwendung eines Open-Source-Werkzeugs zur Verbin- dung mit dem Internet über ein Anonymisierungsnetzwerk zu kompliziert sein (oder scheinen), da die meisten Informationen über Werkzeuge mit Beschreibungen ihrer Funktionsweise und Erörterungen darüber über- frachtet sind, wie sie die Sicherheit maximieren. Selbst für technisch ver- sierte Benutzer ist das manchmal zu viel des Guten. Die Verwendung dieser Werkzeuge kann jedoch in Wirklichkeit ganz einfach sein. 12 Vorwort

Für viele Benutzer kann die Möglichkeit, das Internet anonym zu nutzen, im wahrsten Sinne des Wortes über Leben und Tod entscheiden. Niemand sollte daher durch übermäßige Kompliziertheit daran gehindert werden, Anonymisierungswerkzeuge zu verwenden, insbesondere dann, wenn ein wirklich dringender Bedarf vorliegt. Dieses Buch bietet das Know-how, mit dem gefährdete Benutzer so schnell und sicher wie möglich anonym online gehen können.

Auf den folgenden Seiten erfahren Sie, wie Sie das wirkungsvollste und am häufigsten genutzte dieser Anonymisierungswerkzeuge einsetzen. Es schützt Diplomaten, Angehörige des Militärs und anderer staatlicher ­Organisationen, Journalisten, politische Aktivisten, Strafverfolgungs­ beamte, politisch Verfolgte und andere. Diese praktische Anleitung lässt die theoretischen Grundlagen und die technischen Einzelheiten außen vor. Der Schwerpunkt liegt stattdessen darauf, wie Sie so schnell wie möglich »von null auf anonym« kommen können. 13

Danksagungen

Ich möchte all denen, die zum Tor-Projekt beigetragen haben, für ihre Beteiligung an diesem wichtigen Unternehmen danken. Insbesondere möchte ich den Personen meinen Dank aussprechen, die mit dem Tor- Projekt verbunden sind und mir freundlicherweise geholfen haben, dieses Buch zu vollenden:

Karsten Loesing, Forscher und Leiter des Tor-Metrics-Projekts, der trotz seines vollen Terminkalenders freundlicherweise die Zeit fand, das Buch auf technische Richtigkeit durchzusehen.

Runa A. Sandvik, Entwicklerin, Sicherheitsforscherin und Übersetzungs- koordinatorin, die meine nervtötenden Fragen über Tor großzügig und hilfreich beantwortet und mir einige Einsichten in die Schwierigkeiten ge- geben hat, über Tor zu schreiben.

Roger Dingledine, Projektleiter und einer der ursprünglichen Tor-Entwick- ler, der mir sehr geduldig fast eine Stunde seiner Zeit geschenkt hat, um mir auf dem Tor Project Hack Day 2013 in Boston zu erklären, wie Tor funktioniert.

Andrew Lewman, geschäftsführender Direktor, ohne dessen Hilfe ich dieses Buch nicht hätte abschließen können.

Wie immer danke ich auch den erfahrenen Fachleuten bei Elsevier, ange- fangen bei Syngress-Herausgeber Steve Elliot, der mich dazu überredet hat, wieder mit dem Schreiben von Büchern anzufangen, Ben Rearick, dem redaktionellen Projektmanager, sowie Mohana Natarajan, Pro- duktmanagerin, die das gesamte Projekt bis zum Abschluss geleitet hat.

1 Anonymität und Umgehung der Zensur

Obwohl es so aussehen mag, ist das Internet kein anonymes Medium (und ist es auch nie gewesen). Die Leute verhalten sich jedoch, als ob es anonym wäre, indem sie etwa auf Websites widerliche Kommentare veröffentlichen oder im »Inkognito«- oder »Privat-Modus« ihres Browsers nach fragwür- digen Inhalten suchen.

Sobald Sie jedoch Verbindung mit dem Internet haben, geben Sie Ihre Identität über die IP-Adresse Ihres Computers bekannt. Damit lässt sich über Ihr Konto bei Ihrem Provider Ihre Anschrift ermitteln bzw. über Ihr Firmennetzwerk Ihr Arbeitsplatzrechner.

Selbst wenn Sie über eine fremde IP-Adresse auf das Internet zugreifen (z. B. über das WLAN in einem Hotel, in einem Internetcafé oder auf einem geborgten PC), können Sie von jedem, der die Sitzung überwacht, identi- fiziert werden, sobald Sie sich an Social-Networking-Websites anmelden oder nach Ihren E-Mails sehen. 16 Kapitel 1: Anonymität und Umgehung der Zensur

Immer wieder zeigt es sich, dass die Nutzung des Internets Spuren hinter- lässt – Spuren, die jemand, der daran interessiert ist, sammeln und mit Ihrer Person in Verbindung bringen kann. Angesichts des PRISM-Programms, das im Juni 2013 ruchbar wurde – eine Zusammenarbeit der NSA (Natio- nal Security Agency) mit neun der größten Anbieter von Internetdiensten, darunter Google, Microsoft, Apple und Facebook, um Daten zu erfassen und zu speichern –, sind Bedenken über Datenschutz alles andere als para- noide Vorstellungen.

Das wurde im Jahr 2012 auf eindrucksvolle Weise veranschaulicht, als die E-Mails des ehemaliges CIA-Direktors David Petraeus (& Co.) an die ­Öffentlichkeit gerieten. Wenn schon der Direktor der CIA nicht in der Lage ist, die digitalen Spuren seiner außerehelichen Affä- ren zu verwischen, welche Hoffnung besteht dann für andere? (Siehe »Don‘t be a Petraeus: A Tutorial on Anonymous Email Accounts« auf https://www.eff.org/deeplinks/2012/11/tutorial-how-create-anonymous- email-accounts.)

Das Beispiel von Petraeus zeigt, dass der typische Benutzer selbst bei der Verwendung geliehener Netzwerkverbindungen an unterschiedlichen Standorten so viel persönliche Informationen offenlegt, dass jegliche Vor- spiegelung von Anonymität online zu einer Farce wird.

Alles, was Sie online unternehmen, kann auf verschiedenen Wegen ausspio- niert werden, aber mit entsprechender Sorgfalt ist es möglich, die offen- sichtlichsten Spuren zu verwischen. Darum geht es in diesem Buch: wie Sie Kontakt mit dem Internet aufnehmen und dabei sicher sein können, dass jemand, der die Verbindung abhört, nicht herausfinden kann, was Sie tun (oder dass Sie es dieser Person zumindest sehr schwer machen).

Der zweite wichtige Aspekt der Anonymität im Internet betrifft die Umge- hung der Zensur. In Ländern wie China und dem Iran verhindern staatli- che Firewalls den Zugriff auf Websites, die von der Regierung als inakzepta- bel eingestuft werden. Benutzer in solchen Ländern würden wahrscheinlich gern die Belästigung durch zielgerichtetes Marketing ertragen (was in libe- ralen Ländern ein Grund für die Verwendung von Tor ist), wenn sie dafür 17 

die Möglichkeit hätten, die staatliche Zensur zu umgehen. Aber sie müssen nicht einmal diesen Kompromiss eingehen, denn wenn sie in der Lage sind, anonym Verbindung zum Internet aufzunehmen, können sie gewöhnlich auch die Zensur umgehen.

Wie können Bürger in Diktaturen unzensierte Nachrichten lesen, wenn die Regierung den gesamten Internetzugang filtert? Wie können Diplomaten, Spione, Geschäftsleute oder Journalisten die Wahrheit an Orten verbreiten, an denen der Internetzugriff aus politischen oder wirtschaftlichen Gründen zensiert wird oder unerwünschte Inhalte gefiltert werden? Wie können In- formanten über Missetaten berichten, ohne sich selbst Gefahr auszusetzen?

Für viele besteht die Antwort darin, Tor zu verwenden (https://www.tor- project.org), ein Open-Source-Projekt, das Benutzern überall die anonyme und durch keinerlei Zensur eingeschränkte Nutzung des Internets erlau- ben soll. Tor sorgt für Anonymität, indem es die Möglichkeiten der Gegner einschränkt, durch Analyse des Netzwerkdatenverkehrs personenbezogene Informationen zu gewinnen.

Mit »Gegner« meine ich hier jeden, der versucht, Ihre Identität und Ihren Standort herauszufinden, und zwar unabhängig davon, ob es eine Regie- rungsbehörde, ein korrupter Beamter, ein Manager oder ein Stalker ist. Was es mit der »Analyse des Netzwerkdatenverkehrs« auf sich hat, wird im Abschnitt »Why we need Tor« (»Warum wir Tor brauchen«) des Überblicks über das Tor-Projekt (http:s//www.torproject.org/about/overview.html) erklärt:

Die Verwendung von Tor schützt Sie vor einer gängigen Form der Inter- netüberwachung, die als »Analyse des Netzwerkdatenverkehrs« bezeich- net wird. Mithilfe einer solchen Analyse kann ermittelt werden, wer über ein öffentliches Netzwerk mit wem spricht. Wer die Quelle und das Ziel Ihres Internet-Datenverkehrs kennt, kann Ihr Verhalten und Ihre Interessen herausfinden. Das kann Auswirkungen auf Ihren Kontostand haben, wenn beispielsweise eine E-Commerce-Website die Preise auf der Grundlage des Landes oder Ihrer Organisation festlegt. Es kann sogar Ihren Arbeitsplatz und Ihre körperliche Unversehrtheit gefährden, wenn offengelegt wird, wer Sie sind und wo Sie sich befinden. Wenn Sie sich 18 Kapitel 1: Anonymität und Umgehung der Zensur

beispielsweise im Ausland befinden und Kontakt mit den Computern Ihres Arbeitsgebers aufnehmen, um E-Mails einzusehen oder zu lesen, können Sie dabei versehentlich Ihre Nationalität und Ihren Arbeitgeber gegenüber jedem aufdecken, der das Netzwerk beobachtet, selbst wenn die Verbindung verschlüsselt ist.

Wie funktioniert diese Analyse? Internet-Datenpakete bestehen aus zwei Teilen: den Nutzdaten und einem Header für die Weiterleitung. Bei den Nutzdaten handelt es sich um das, was gesendet wird, also z. B. eine E-Mail-Nachricht, eine Webseite oder eine Audiodatei. Selbst wenn Sie die Nutzdaten bei der Kommunikation verschlüsseln, kann die Analyse des Datenverkehrs eine Menge darüber zeigen, was Sie tun, und mögli- cherweise sogar, was Sie sagen. Das liegt daran, dass sich diese Analyse auf den Header konzentriert, der die Quelle, das Ziel, die Größe, die Zeit usw. angibt.

Ein grundlegendes Problem für den Datenschutz besteht darin, dass der Empfänger schon durch einen Blick auf den Header erkennen kann, dass die Nachricht von Ihnen stammt. Das können aber auch autorisierte Zwischenstationen wie die Provider und manchmal auch nicht autori- sierte Zwischenstationen. Eine einfache Form der Datenverkehrsanalyse kann darin bestehen, sich irgendwo zwischen Sender und Empfänger zu platzieren und die Header einzusehen.

Es gibt aber noch leistungsfähigere Arten der Analyse. Manche An- greifer spionieren in mehreren Teilen des Internets und verwenden anspruchsvolle statistische Techniken, um die Kommunikationsmuster vieler verschiedener Organisationen zu verfolgen. Dagegen hilft keine Verschlüsselung, da sie nur den Inhalt des Internetdatenverkehrs unles- bar bar, nicht aber die Header. 19 

Mehr über Tor: Wer steht hinter dem Tor-Projekt? »Gebührende Vorsicht« ist eine etwas geschwollene Formulierung für: »Mach deine Hausaufgaben, bevor du ein Risiko eingehst.« Immer, wenn Sie eine Software einsetzen, um Ihre Privatsphäre zu schützen oder Sicherheitsmaßnahmen zu ergreifen, vertrauen Sie den Autoren und Herausgebern dieser Software. Sie müssen überzeugt sein, dass die Personen, die die Software zur Verfügung stellen, sowohl fähig als auch vertrauenswürdig sind: Fähig, damit Sie sich keine Sorgen darüber machen müssen, dass die Produktionssoftware mit erheblichen Fehlern durchsetzt ist oder dass einfach zu behebende Fehler lange Zeit nicht behoben werden. Vertrauenswürdig, damit Sie nicht befürchten müssen, dass die Ent- wickler dem Druck von anderen Stellen nachgeben und die Software auf eine Weise ändern, die die Sicherheit verringert. Vertrauen in Menschen, die Sie nicht persönlich kennen, entspringt gewöhnlich dem Ruf dieser Personen. Das Tor-Projekt hat einen Ruf von Offenheit und Transparenz: Ein Großteil ihrer Tätigkeiten, von der Fehlersuche über die langfristige Projektentwicklung bis zur Dis- kussion darüber, wie die Funktionen am besten erfüllt werden kön- nen, erfolgt öffentlich, auf der Wiki-Seite, in den Diskussionslisten und auf der Website des Projekts. Der gesamte Quellcode der Soft- ware sowie der Quellcode der Website sind zur Untersuchung und Kommentierung zugänglich. Wenn Sie sich zum Schutz Ihrer Anonymität auf Tor verlassen wol- len, sollten Sie mehr über die Personen erfahren, die hinter Tor ste- hen. Das ist fast noch wichtiger, als zu lernen, wie das Tor-Protokoll funktioniert. Links zu Informationen über die Personen, die das Tor- Projekt tragen – finanziell sowie technisch – finden Sie in Anhang C, Abschnitt C.2. Ich möchte Ihnen jedoch ans Herz legen, auch eigene Nachforschungen anzustellen. 20 Kapitel 1: Anonymität und Umgehung der Zensur

1.1 Was bedeutet Anonymität?

Computer machen es viel schwieriger und komplizierter, anonym zu blei- ben. Bevor es Computer und das Internet gab, reichte es meistens aus, nicht aufzufallen – also so auszusehen und zu handeln wie alle anderen –, um unter dem Radar der Leute zu bleiben, die Ausschau nach Ihnen hielten, ob das nun »die Behörden« waren, jemand, der eine Rechnung eintreiben wollte, oder ein aufdringlicher Vertreter.

In der Welt der Computer gibt es jedoch viele verschiedene Möglichkeiten, Sie zu identifizieren – und sie alle können automatisiert werden, sodass nicht einmal die Möglichkeit besteht, an einem schlafenden Nachtwächter oder einer abgelenkten Sekretärin vorbeizuschlüpfen:

•• IP-Adressen. Alle Geräte, die mit dem Internet verbunden sind, kön- nen anhand ihrer IP-Adresse identifiziert werden. Diese Adresse wird vom Provider zugewiesen, sodass dieser das Konto und den Standort des verwendeten Systems aus einer IP-Adresse ermitteln kann. •• Browsercookies. Webserver, insbesondere solche, die Dienste bereitstel- len, legen auf Ihrem System »Cookies« mit identifizierenden Informa- tionen ab, wenn Sie auf den Dienst zugreifen. •• Systemprofile. Informationen über Ihr System, z. B. den verwendeten Browser, das Betriebssystem, die installierten Schriftarten, Plug-Ins und sonstige Software (und mehr) können dazu herangezogen werden, ein Profil Ihres Systems zu erstellen. Mehr darüber erfahren Sie auf Panop- ticlick (https://panopticlick.eff.org/), einem Forschungsprojekt der EFF (Electronic Frontier Foundation, https://www.eff.org/).

Sie können nicht einfach zu einer Website surfen, ohne Ihre Identität preis- zugeben, und wenn irgendjemand nach Ihnen sucht (oder nach Ihrem Computer), kann er Software einsetzen, die den Zugriff durch Sie sofort erkennt und meldet. Es ist nicht möglich, im Kielwasser einer Gruppe au- torisierter Benutzer hereinzuschleichen, die Türsteher auf irgendeine Weise zu überreden oder auszutricksen oder sich in einer Wolke von IP-Adressen zu verstecken. Was ist Tor? 21

1.2 Was ist Tor?

Tor ist ein Werkzeug zur Wahrung der Anonymität und zur Umgehung der Zensur. Es handelt sich um eine Softwaresuite, die Anonymisierungsproto- kolle für gewöhnliche IP-Adressen verwendet. Tor-Knoten (also Computer, auf denen die Tor-Netzwerksoftware läuft), bauen sichere Netzwerkverbin- dungen zwischen dem auf Anonymität bedachten Benutzer und den Web- sites auf, die er besuchen möchte. Tor-Clients nutzen Zwischensysteme, sogenannte »Relays«. Dabei handelt es sich um Computer, auf denen Tor- Software läuft und die so eingerichtet sind, dass sie diese Verbindungen für alle aufbauen, die sie benötigen.

Mehr über Tor: Einzelheiten über die Tor-Netzwerkprotokolle Dieses Buch gibt nur eine sehr allgemeine Beschreibung der Funk- tionsweise von Tor, ohne auf die Einzelheiten der Protokollimple- mentierung einzugehen. Wenn ich sage, dass ein Tor-Client eine Verbindung herstellt, dann können Sie davon ausgehen, dass das ein gerüttelt Maß an kryptografischer Kommunikation umfasst, um die Identitäten der Systeme zu bestätigen, die Netzwerkdaten ordnungs- gemäß zu verschlüsseln und alles zu vermeiden, was die Identität des Benutzers offenlegen könnte, sowie alles zu tun, was eine solche Of- fenlegung verhindert. Um ein genaueres Verständnis des Tor-Projekts zu gewinnen, soll- ten Sie sich als Erstes das Dokument »Tor: The Second-Generation Onion Router« über das Design des Protokolls ansehen (https://svn. torproject.org/svn/projects/design-paper/tor-design.pdf), das viele der Sicherheitsprobleme und Schwierigkeiten beschreibt, denen sich ein Anonymisierungsprotokoll stellen muss. Die Spezifikation des Proto- kolls ist als »Tor Protocol Specification« (von Roger Dingledine und Nick Mathewson) auf https://gitweb.torproject.org/torspec.git?a5blob_ plain;hb5HEAD;f5tor-spec.txt erhältlich. 22 Kapitel 1: Anonymität und Umgehung der Zensur

Tor beruht auf dem Grundprinzip eines Netzwerkproxys, also eines Me- chanismus, durch den Sie Verbindung mit einem Netzwerk aufnehmen können. Das Proxysystem handelt dabei an Ihrer Stelle. Wenn Sie also über einen Proxy einen entfernten Server erreichen wollen, stellt der Proxy für Sie die Internetverbindung her und tut für diesen Zweck so, als sei er Sie. Der Server glaubt, dass Sie das Proxysystem wären. Woher Sie in Wirklich- keit ins Internet gehen, weiß er nicht.

Proxys sind eine großartige Möglichkeit, Regeln zu umgehen, mit denen Ihr Zugriff zum Internet eingeschränkt wird – sei es durch eine staatli- che Firewall, eine Unternehmensfirewall oder Kindersicherungssoftware. Beispielsweise kann ein Unternehmen, das seinen Angestellten die Be- nutzung von Facebook verbietet, diese Regel durchsetzen, indem es alle Versuche blockiert, von einem System innerhalb des Firmennetzwerks aus eine Verbindung zur Domäne facebook.com oder zu IP-Adressen von Facebook-Servern herzustellen.

Durch die Nutzung eines Proxydienstes können Angestellte diese Sperre umgehen. Dabei nimmt ein anderer Server, der von der Unternehmens- firewall nicht blockiert wird, einen URL entgegen und leitet Inhalte von der verbotenen Website zu dem Benutzer weiter. Da dabei nicht versucht wird, direkt auf die verbotene Website zuzugreifen, wird der Vorgang von der Unternehmensfirewall auch nicht blockiert.

In der Praxis sind Proxys ein bisschen komplizierter, und es sind Gegen- maßnahmen möglich, um den Zugriff zu Proxys zu stören oder ganz zu un- terbinden. Ein solcher Proxydienst lässt sich gewöhnlich leicht aushebeln, indem man seine Adresse zur Liste derjenigen hinzufügt, die von der Un- ternehmensfirewall blockiert werden. Wenn die IT-Mitarbeiter die erhöhte Nutzung von Bandbreite zur Verbindung mit einem Proxyserver feststellen, können sie diesen aufspüren und die Firewallregeln so ändern, dass auch der Zugriff darauf blockiert wird. Die Benutzer müssen dann einen ande- ren Proxyserver finden oder irgendeine andere Maßnahme ergreifen, um den Filter zu umgehen. Was ist Tor? 23

Einfache Proxys können das Problem, ohne Zensureinschränkungen auf beliebige Inhalte zuzugreifen, zwar für einige Benutzer lösen (z. B. für Kin- der, die die Kindersicherung umgehen wollen), aber in manchen Fällen sind sie wirkungslos:

•• Sie müssen Vertrauen darin haben, dass die Personen, die den Proxyser- ver betreiben, Ihre Privatsphäre respektieren, da der Proxyserver mitbe- kommt, welche Websites Sie aufrufen, und diese Informationen proto- kollieren kann. Wenn Ihr Gegner Zugriff auf den Proxyserver bekommt oder Ihre Netzwerksitzung über die Internetverbindung des Proxyser- vers beobachtet, dann ist diese Sitzung nicht länger geheim. •• Proxyserver lassen sich leicht blockieren, wenn sie erst einmal entdeckt sind – und sie lassen sich auch leicht entdecken, vor allem, wenn meh- rere Personen denselben Proxy nutzen.

Tor ist eine ausgeklügeltere Form von Proxy: Es verschleiert Ihr tatsäch- liches Ziel vollständig und verwendet für anonymen Datenverkehr auch nicht immer dieselbe Zieladresse – wodurch es leichter erkennbar wäre und sich daher durch eine Firewall blockieren ließe. (Manche Gegner block­ ieren Tor-Relays, deren Adressen öffentlich zugänglich sind, wodurch es nötig wird, Bridge-Relays und andere Mechanismen zu verwenden. Mehr darüber erfahren Sie in Kapitel 4.)

Anstatt Verbindung zu einem Proxyserver aufzunehmen und ihm mitzutei- len, welchen Server im Internet Sie erreichen wollen, nehmen Sie Verbin- dung mit einem Tor-Knoten auf und lassen Ihren Datenverkehr davon an einen weiteren Tor-Knoten weiterleiten. Tor-Knoten, die Tor-Datenverkehr annehmen und zu anderen Knoten weiterleiten können, werden als Relays bezeichnet. Ein Tor-Knoten, der Datenverkehr von einem anderen Tor- Knoten annimmt, heißt Transitknoten.

Der Tor-Transitknoten, mit dem sich Ihr Tor-Client verbindet, hat keine Ahnung davon, wohin der Datenverkehr geht und womit Sie letzten Endes Verbindung aufzunehmen versuchen. Nur der Tor-Austrittsknoten – also 24 Kapitel 1: Anonymität und Umgehung der Zensur

das Tor-Relay, das Datenverkehr aus dem Tor-Netzwerk ins öffentliche ­Internet weiterleitet – kennt Ihr eigentliches Ziel, aber dafür weiß er nicht, woher der Datenverkehr stammt.

Wenn Sie Verbindung mit dem Tor-Netzwerk aufnehmen, folgt der Com- puter darin einem zufälligen Pfad. Er wählt einen Transitknoten als Eingang in das Netzwerk aus, einen weiteren Transitknoten innerhalb des Netzwerks und einen Austrittsknoten, der den anonymisierten Datenverkehr ins öf- fentliche Internet weiterleitet. Der Eintrittsknoten kennt die IP-Adresse Ih- res Computers und die IP-Adresse des von Ihrem Computer ausgewählten nächsten Knotens, aber das ist auch alles.

Der zweite Transitknoten kennt weder Sie noch das beabsichtigte Ziel, sondern nur den Eintritts- und den Austrittsknoten. Der Austrittsknoten schließlich weiß nichts über Ihr System oder über Sie, sondern lediglich, welches Ziel Sie zu erreichen versuchen.

Abbildung 1.1 gibt Ihnen einen groben Überblick über die Funktionsweise des Tor-Netzwerks: Der Client am linken Bildrand wählt drei Tor-Relays aus (innerhalb der Tor-Netzwerkwolke) und erstellt gestaffelt verschlüssel- te Tunnel, von denen bei jedem Relay einer entfernt wird, bis beim Durch- gang durch den Austrittsknoten die Websitzung geöffnet wird.

Mehr über Tor: Grafische Darstellung des Tor-Netzwerks Die verschiedenen Aspekte des Anonymisierungsnetzwerks von Tor grafisch darzustellen ist nicht sehr einfach. In diesem Kapitel finden Sie einige Abbildungen (siehe Abbildung 1.1 bis 1.3) sowie Links zu anderen Illustrationen. Eine hervorragende Darstellung bietet die in- teraktive Grafik auf der EFF-Seite »Tor and HTTPS« (https://www.eff. org/pages/tor-and-https). Eine Diskussion einiger der Probleme sowie Vorschläge für genauere bzw. ansprechendere grafische Darstellungen von Tor für technisch weniger versierte Personen finden Sie in »Visual overview of the Tor network« (https://blog.torproject.org/blog/visual-overview-tor-network). Was ist Tor? 25

Abbildung 1.1: Tor verschlüsselt die Daten dreimal, einmal für jedes Relay auf dem Weg zum Ziel (Tor-Projekt, https://archive.torproject.org/tor-package- archive/manual/short-user-manual_en.xhtml).

So funktioniert Tor: 1 Tor-Knoten Unverschlüsselte Verbindung Verschlüsselte Verbindung

Alice

Schritt 1: Alices Tor-Client bezieht eine Liste der Tor-Knoten von einem Verzeichnisserver. Jane

Dave Bob

Abbildung 1.2: Alice nimmt über einen Tor-Client Verbindung zu einem Tor- Verzeichnisserver auf dem Computer Dave auf. 26 Kapitel 1: Anonymität und Umgehung der Zensur

So funktioniert Tor: 2 Tor-Knoten Unverschlüsselte Verbindung Verschlüsselte Verbindung

Alice

Schritt 2: Alices Tor-Client wählt einen zufälligen Pfad zum Zielserver aus. Durchgezogene Verbindungen sind verschlüsselt, gestrichelte Jane nicht.

Dave Bob

Abbildung 1.3: Verschlüsselte Verbindungen sind als durchgezogene Linien dargestellt, Klartextverbindungen gestrichelt.

1.3 Gründe für die Verwendung von Tor

Es gibt eine Menge guter Gründe für die Verwendung von Tor, und viele davon werden auf der Website des Tor-Projekts dargestellt. Warum Sie Tor verwenden, ist letzten Endes Ihre Sache. Lesen Sie weiter, wenn Sie nicht sicher sind, ob Tor etwas für Sie ist.

Die beiden Hauptgründe für die Verwendung von Tor bestehen darin, die Privatsphäre zu wahren und Zensurbestimmungen zu umgehen.

Es gibt viele gute Gründe, seine Privatsphäre wahren zu wollen. Insbeson- dere möchte man keine unerwünschte Aufmerksamkeit auf seine Interes- sen ziehen – sei es, um einer Flut von Werbung zu entgehen, die aufgrund Gründe für die Verwendung von Tor 27

Ihrer Google-Suchvorgänge persönlich auf Sie abgestimmt wird, oder um nicht ins Fadenkreuz von Netzwerkadministratoren zu geraten, die den Datenverkehr nach »verbotenen« Inhalten absuchen.

Angesichts der Menge an Daten, die gesammelt werden können – und tat- sächlich gesammelt werden! –, wenn Sie manche populäre Websites aufsu- chen, ist es sinnvoll, keine persönlichen Daten durchsickern zu lassen. Um sich einmal anzusehen, welche persönliche Daten aufgedeckt werden kön- nen, probieren Sie Lightbeam aus (http://www.mozilla.org/de/lightbeam/), ein Firefox-Add-on, das grafisch darstellt, wie viele Informationen von ver- schiedenen Werbenetzwerken gesammelt werden.

Werfen Sie auch einen Blick auf Disconnect (https://disconnect.me/tools), eine Antitracking-Browsererweiterung für Chrome, die Google-, Twitter- und Facebook-Anmeldungen trennt, damit sie nicht aktiv bleiben und Informa- tionen über Sie sammeln, nachdem Sie die betreffenden Websites verlassen haben. Im Coderepository dieses Programms heißt es: »Disconnect hindert Dritte und Suchmaschinen daran, nachzuspüren, welche Webseiten Sie auf- suchen und welche Suchvorgänge Sie durchführen.«

Eine vorgeschlagene Lösung zur Wahrung der Privatsphäre ist die »Do- not-track-Richtlinie« (https://www.eff.org/issues/do-not-track). Dabei soll ein neuer HTTP-Header – der DNT-Header (für »do not track«) – Web- servern und Drittanbieter-Trackingeinrichtungen die Bitte vermitteln, die Aktivitäten des Benutzers nicht zu verfolgen. Das Problem bei dieser »Lösung« besteht darin, dass die Server diese Bitte auch erfüllen müs- sen. Tatsächlich handelt es sich dabei um nicht mehr als um eine Bitte, denn es gibt keine Möglichkeit, die Einhaltung sicherzustellen. Eine sol- che Möglichkeit würde dem Geschäftsmodell gerade der Unternehmen zuwider laufen, die das meiste Tracking durchführen. Der Artikel »Do Not Beg: Moving Beyond DNT through Privacy by Design« (http://www. w3.org/2012/dnt-ws/position-papers/21.pdf) erklärt, warum DNT eine nicht technische Nicht-Lösung für ein Problem ist, für das Tor eine echte Lösung bietet.

60165-8 Titelei_X 24.08.12 10:36 Seite 1

Dr. Peter Kraft/Andreas Weyert Network Hacking 3. überarbeitete Auflage

Professionelle Angriffs- und Verteidigungstechniken gegen Hacker und Datendiebe 5

Vorwort

Wieder sind zwei Jahre ins Land gegangen; der Erfolg blieb uns treu, sodass wir nun mit der dritten aktualisierten Auflage an den Start gehen. Was also hat sich in dieser Zeit ge- ändert? Welche Trends zeichnen sich ab? Was spiegelt sich davon in unserem Buch wider? • Im Gegensatz zu 2010 hat sich Windows 7 fest etabliert, insbesondere die 64-Bit- Variante, für die es vor zwei Jahren noch nicht so viele speziell darauf angepasste Programme und Treiber gab. • Die als »Bundestrojaner« betitelte staatliche Überwachungssoftware wurde enttarnt und ihre Einsatzmöglichkeiten stärker beschnitten. Nichtsdestotrotz betrachten wir allein diese Tatsache als Vorboten staatlicher Reglementierung und merken mahnend an, dass es Kräfte in diesem Staat gibt, die die Vorgaben des Bundesverfassungsgerichts erschreckend lax auslegen. Eine ähnliche Stoßrichtung verfolgen das Anti-Piraterie- Abkommen ACTA (Anbi-Counterfeiting Trade Agreement), der Glücksspielstaats- vertrag und der Jugendmedienschutz-Staatsvertrag, selbst das Zugangserschwerungs- gesetz scheint in Form eines Bumerangs aus Brüssel wieder auf uns zuzukommen. Nicht mehr auszuschließen ist auch, dass die unsägliche Vorratsdatenspeicherung unter dem wachsenden EU-Druck1 wieder gesetzlich verankert werden wird, zumal Rechtspolitiker jede Gelegenheit nutzen, um dieses zweifelhafte Instrument auch zu den absurdesten Vorfällen2 vehement einzufordern. • Der Cyberwar kommt näher. Stuxnet3 und Flame4 – fast scheint es, als seien sie die ersten beiden Reiter der Apokalypse. »Dann sah ich: Das Lamm öffnete das erste der sieben Siegel; und ich hörte das erste der vier Lebewesen wie mit Donnerstimme rufen: Komm! Da sah ich ein weißes Pferd; und der, der auf ihm saß, hatte einen Bogen. Ein Kranz wurde ihm gegeben und als Sieger zog er aus, um zu siegen. Als das Lamm das zweite Siegel öffnete, hörte ich das zweite Lebewesen rufen: Komm! Da erschien ein anderes Pferd; das war feuerrot. Und der, der auf ihm saß, wurde ermächtigt, der Erde den Frieden zu nehmen, damit die Menschen sich gegenseitig abschlachteten. Und es wurde ihm ein großes Schwert gegeben ...« (Offenbarung 6, 1–8). Das eigentlich Bemerkenswerte an Stuxnet ist nicht so sehr die (tatsächlich vorhandene) hohe Virtuosität des Programmiererteams, sondern die Stoßrichtung. Erstmals wurde, vermutlich in staatlichem Auftrag (USA/Israel), Malware produziert mit dem dezidierten Ziel, Industrieanlagen eines gegnerischen Staates zu sabotieren.

1 http://heise.de/-1618979 2 http://heise.de/-1622990 3 http://heise.de/-1588466 4 www.securelist.com/en/blog/208193522/The_Flame_Questions_and_Answers 6 Vorwort

Wenn die Akteure hier nach dem Prinzip tit for tat weiterspielen, sind Szenarien mit hohen Kollateralschäden denkbar, da die Sabotage von Industrie- und Infrastruktur- anlagen direkt oder indirekt auch menschliches Leben in Mitleidenschaft ziehen kann. Viele Experten betrachten Flame zudem als eine Entwicklungsplattform u. a. auch für Stuxnet. Das Bindeglied zwischen beiden Schädlingen ist nach Analysen von Kaspersky Lab das »Modul 207«: ein Plug-in von Flame, das zugleich auch Bestandteil einer frühen Version von Stuxnet war.5 Wie auch der im Anschluss an Stuxnet enttarnte Trojaner Duqu ist Flame hauptsächlich ein Spionagetool, geschrieben auf Basis des Entwicklungssystems LUA. »Laut Kaspersky kann Flame Daten sammeln, die Einstellungen des befallenen Computers verändern, das Mikrofon einschalten, um Gespräche mitzuschneiden, Screenshots machen und Chat-Konversationen aufzeichnen. Betroffen seien bis zu 5000 Computer, vor allem von Unternehmen und Bildungseinrichtungen in Iran, Israel, in Palästina, im Sudan und Syrien.«6 Das Spionagepotpourri klingt auf den ersten Blick beeindruckend: Computerkonfigurationen können geändert, Kommunikationsdaten mitgeschnitten, Tastatureingaben protokolliert, eine Webcam versteckt eingeschaltet und neue Module aus dem Internet nachgeladen werden. Allerdings haben wir schon in unse- rer ersten Auflage über Schädlinge, vorzugsweise Remote Access Tools (RATs) wie z. B. Poison Ivy berichtet, die über analoge »Fähigkeiten« verfügen. Wir sehen also Flame7 jetzt nicht als »Superwaffe im Cyberkrieg«, nichtsdestotrotz ist es beängsti- gend zu sehen, dass jetzt neben Kriminellen auch staatliche bzw. halbstaatliche Gruppen gezielt das Internet kontaminieren. Angriffsziele von Flame sind neben staatlichen Institutionen auch Firmen und Privatleute. Das iranische CERT berich- tete, dass Flame gegenüber allen gängigen AV-Lösungen (43 getestet) immun war, d. h. unentdeckt blieb, sodass die grundsätzliche Frage zur Wirksamkeit8 von Anti- virenprogrammen im Raum steht. • Weiter verstärkt hat sich das Phänomen der »Kapitalisierung der Daten«. Wir verste- hen darunter den Prozess, Daten, vorzugsweise fremde, zu Geld zu machen. Auch hier spielt der Staat häufig den Vorreiter. Erinnert sei in dem Zusammenhang an die Steuer-CDs aus der Schweiz und Liechtenstein mit den Daten deutscher Steuersün- der, die Insider mit einschlägigen Kenntnissen dem BND verscherbelten. Ein anderes prominentes Opfer, sozusagen die Spitze des Eisberges, ist Sony, dessen Spiele-Netz- werk Sony Online Entertainment (SOE) gehackt und die Nutzer- teilweise inkl. Kontendaten von 24,6 Millionen SOE-Konten abgeräumt wurden. Auf einen bekannten Fall kommen vermutlich Dutzende weiterer Opfer; die Dunkelziffer ist unbekannt. Man sollte sich in dem Zusammenhang klarmachen, dass diese Firmen zwar dem Datenklau zum Opfer fielen und materielle wie immaterielle Schäden erlitten, auf der anderen Seite aber auch Millionen von Verbrauchern mitgeschädigt

5 www.fmm-magazin.de/kaspersky-entdeckt-zusammenhang-zwischen-flame-und-stuxnet-entwickler- finanzen-mm_kat_id6248.html 6 www.spiegel.de/netzwelt/web/computerwurm-flame-von-it-experten-entdeckt-a-835604.html 7 www.searchsecurity.de/themenbereiche/bedrohungen/viren-wuermer-trojaner/articles/366686 8 http://arstechnica.com/security/2012/06/why-antivirus-companies-like-mine-failed-to-catch-flame-and- stuxnet/ Vorwort 7

wurden und mit dem Verlust ihrer Privatsphäre teils auch mit ihrem Vermögen für ein unzureichendes IT-Security-Management ihrer Lieferanten einstehen mussten. Dass sich selbst die eigenen Daten fremdkapitalisieren lassen – diese Erkenntnis gewannen die Opfer des Ukash/Paysafe-Trojaners9 und diverser Nachahmer. Durch z. B. einen Drive-by-Download fingen sie sich einen Schädling ein, der ihre Daten-/ Musikarchive verschlüsselte und unter der Vorspiegelung, das BKA hätte sie im Visier, für die Entschlüsselung einen nicht unerheblichen Betrag von ihnen ver- langte. • In der IT-Sicherheitsumfrage 2012 von www.av-comparatives.org findet sich im Punkt 3, S. 5 zur Frage »Welches Betriebssystem verwenden Sie hauptsächlich?« eine interessante Zahl: Demnach nutzen 41,1 % aller Anwender weltweit die 64-Bit-Vari- ante von Win 7. Eigentlich sollte das eine gute Nachricht sein, da diese Variante durch die Kernel-Patch-Protection (PatchGuard), die die Installation unsignierter Treiber verhindert, besser gegen Malwareangriffe geschützt sein sollte. Insbesondere sollte die Arbeit von Rootkitprogrammierern erschwert werden, Schädlinge durch eine Kernelmanipulation vor Entdeckung zu schützen. Leider wurde dieser Sicher- heitsgewinn wieder verspielt durch eine offen gelassene Hintertür10 im System (TESTSIGNING-Option). Einem wirklich sicheren Betriebssystem sind wir in der Windows-Welt nicht viel näher gekommen. • Machthabende sehen sich zunehmend politischen Fraktionen wie »Anonymous« oder aus der Spaßguerilla hervorgegangenen Gruppen wie »LulzSec« ausgesetzt. Staatlichen Behörden, global agierenden Konzernen oder Urheberrechtsgesellschaf- ten fällt der Umgang mit entsprechenden Strömungen nicht leicht, zumal diese flexibel, ohne erkennbare Hierarchie und äußerst koordiniert interagieren. Um mit diesen vielfältigen Bedrohungsszenarien besser umgehen zu können, zeigen wir interessierten Laien wie auch IT-Praktikern, wie »böse Buben« in fremde Rechner und Netze eindringen – nicht, um sie selbst zu »bösen Buben« zu machen, sondern um sie für zusätzliche Sicherheitsmaßnahmen zu sensibilisieren. Versierten Cyberkriminellen sagen wir mit diesem Buch nichts Neues, und die oft geschmähten Script-Kiddies mögen vielleicht an wenigen Stellen profitieren, finden im Internet aber erheblich brisantere Informationen als hier. Richtig profitieren werden aber alle, die motiviert sind, sich mehr und vor allem gezielter für die Sicherheit ihrer Rechner und Netze zu engagieren. Ein Hinweis am Rande: Im Weiteren verwenden wir der Einfachheit halber den Begriff »Hacker« als Synonym für einen Computerkriminellen. Wir sind uns der Tatsache bewusst, dass der Begriff »Hacker« grundsätzlich wertneutral ist und dass es verschie- dene Formen der Interpretation gibt (so beispielsweise bei Steven Levy11 und Bruce Schneier12). Keineswegs möchten wir denjenigen zu nahe treten, die sich selbst als

9 http://heise.de/-1573945 10 http://heise.de/-1137047 11 www.stevenlevy.com/index.php/other-books/hackers 12 www.schneier.com/blog/archives/2006/09/what_is_a_hacke.html 8 Vorwort

»Hacker« bezeichnen und beispielsweise als Kernel-Hacker in der Linux-Community mitwirken. An der bewährten Struktur unseres Buches hielten wir fest. Das Tools-Kapitel wurde intensiv »renoviert«, insbesondere im Hinblick auf Einsatzmöglichkeiten unter Win 7 und den aktuellen Linux-Kerneln. Wir hoffen, dass wir damit, wenigstens für die kom- menden zwei Jahre, wieder auf der Höhe der Zeit sind.

Teil I – Hacking-Tools

Wir haben für dieses Buch die gewohnte dreiteilige Gliederung beibehalten. Im ersten Teil stellen wir gängige Hacking-Werkzeuge vor, wobei wir bewusst darauf verzichtet haben, zwischen Malware-Tools und klassischer bzw. kommerzieller Security-Software zu unterscheiden. Die vorgestellten Tools ermöglichen meistens beides: sowohl Angriffs- vorbereitung und -durchführung als auch Erkennen bzw. Abwehr von Schwachstellen und Sicherheitslücken. Die Tools-Sektion hat darüber hinaus durch die gewählte Systematik den Charakter eines Nachschlagewerks. Durch die Beschreibung des Anwendungszwecks und die Ergänzung mit Bezugshinweisen, Kosten und Installa- tionshinweisen kann jeder abschätzen, wie nützlich und brauchbar das eine oder andere Werkzeug für seine Zwecke ist. Vollständigkeit haben wir bewusst nicht angestrebt. Dennoch glauben wir, damit einen guten Querschnitt über die gängigsten Tools der Hacker wie ihrer Gegenspieler bieten zu können.

Teil II – Angriff und Abwehr

Der zweite Teil unseres Buchs ist der ausführlichste. Hier beschreiben wir im Detail, wie typische Angriffsszenarien aussehen können. Angriffsobjekte sind Rechner mit einer Netzwerkanbindung, im einfachsten Fall ein kleineres Heimnetzwerk. Wir zeigen natür- lich auch, wie Firmennetzwerke und Internetpräsenzen mit den eingangs vorgestellten Tools penetriert werden können. Die Szenarien sind so gewählt, dass sie auch von Nichtprofis praktisch nachvollzogen werden können. Allerdings sollte man als Leser ein Grundverständnis für die Netzwerk-Basics mitbringen. Wem beispielsweise die Unter- schiede zwischen HTTP, FTP, TCP/IP, UDP etc. nicht recht geläufig sind, der wird hier eine grundlegende Erläuterung vermissen und sollte sich an anderer Stelle noch ein wenig einlesen. Auf der anderen Seite beschäftigen wir uns auch nicht damit, wie man Exploits, Trojaner oder Rootkits entwickelt – wir zeigen, wie sie funktionieren und wie man sie in bestimmten Situationen anwendet. An dieser Stelle auch die obligatorische Warnung: Sie als Leser sind auf jeden Fall für die Folgen Ihres Tuns selbst verantwortlich. Wer ein Netzwerk scannt, das nicht sein eigenes ist, bewegt sich in einer rechtlichen Grauzone. Wer sich durch einen Passwortcrack ein Log-in auf einem fremden Rechner erschleicht, eine bestehende Schwäche ausnutzt, um dort eine Remote-Shell zu etablieren, oder Vorwort 9

anderen Usern einen getarnten Keylogger schickt, ist definitiv auf der anderen Seite und kollidiert mit dem Strafgesetzbuch. Alle Angriffsszenarien enden übrigens mit einem Abschnitt, der sich der Abwehr genau dieser zuvor beschriebenen spezifischen Angriffs- technik widmet. Dies soll noch einmal klar belegen, dass wir kein Hackertraining anbieten, sondern für Hackangriffe und ihre Abwehr sensibilisieren wollen.

Teil III – Vorsorge

Im dritten Teil geht es um das grundsätzliche Thema Prävention & Prophylaxe. Proakti- ves Sicherheitsmanagement ist gleichermaßen ein Thema sowohl für den Betreiber pri- vater Netze als auch den Verantwortlichen kleinerer und mittlerer Firmennetze.

11

Inhaltsverzeichnis

Teil I: Tools – Werkzeuge für Angriff und Verteidigung ...... 19

1 Keylogger – Spionage par excellence ...... 21

1.1 Logkeys ...... 22 1.2 Elite Keylogger ...... 23 1.3 Ardamax Keylogger ...... 24

1.4 Stealth Recorder Pro ...... 25 1.5 Advanced Keylogger ...... 26 1.6 Hardware-Keylogger ...... 27 1.7 Abwehr – generelle Tipps ...... 28

2 Passwortknacker: Wo ein Wille ist, ist auch ein Weg ...... 31 2.1 CMOSPwd ...... 31

2.2 Hydra ...... 32 2.3 Medusa ...... 34 2.4 Ncrack (Nmap-Suite) ...... 36 2.5 VNCrack ...... 37 2.6 PWDUMP (in unterschiedlichen Versionen bis PWDUMP 7.1) ...... 38 2.7 John the Ripper ...... 39 2.8 oclHashcat-plus ...... 40

2.9 Ophcrack ...... 41 2.10 SAMInside ...... 42 2.11 Cain & Abel ...... 43 2.12 L0phtcrack ...... 44 2.13 Distributed Password Recovery ...... 45 2.14 Offline NT Password & Registry Editor ...... 46 2.15 PW-Inspector (Hydra-Suite) ...... 46 2.16 Abwehr – generelle Tipps ...... 47

3 An den Toren rütteln: Portscanner & Co...... 49

3.1 Nmap ...... 51 3.2 Lanspy ...... 53 3.3 Essential NetTools ...... 54 12 Inhaltsverzeichnis

3.4 Winfingerprint ...... 55 3.5 Xprobe2 ...... 56

3.6 p0f ...... 58 3.7 Abwehr – generelle Tipps ...... 61

4 Proxy & Socks ...... 63

4.1 ProxyCap ...... 64 4.2 Proxy Finder ...... 65

4.3 Abwehr – generelle Tipps ...... 66

5 Remote Access Tools (RAT) – Anleitung für Zombie-Macher ...... 67

5.1 Atelier Web Remote Commander ...... 67 5.2 Poison Ivy ...... 68 5.3 Turkojan ...... 69 5.4 Optix Pro ...... 70

5.5 Cybergate 2.3.0 Public ...... 71 5.6 Abwehr – generelle Tipps ...... 72

6 Rootkits – Malware stealthen ...... 73

6.1 Oddysee_Rootkit ...... 74 6.2 Hacker_Defender ...... 75

6.3 TDSS alias TDL-4 ...... 76 6.4 Abwehr – generelle Tipps ...... 77

7 Security-/Vulnerability-Scanner ...... 79

7.1 X-NetStat Professional ...... 79 7.2 GFI LANguard N.S.S...... 80

7.3 Nessus ...... 81 7.4 Open Vulnerability Assessment System/OpenVAS ...... 82 7.5 Nikto2 ...... 84 7.6 Abwehr – generelle Tipps ...... 85

8 Sniffer: Die Schnüffler im Netzwerk ...... 87 8.1 dsniff (dsniff-Suite) ...... 88

8.2 mailsnarf (dsniff-Suite) ...... 89 8.3 urlsnarf (dsniff-Suite) ...... 91 8.4 arpspoof (dsniff-Suite) ...... 92 8.5 PHoss ...... 93

8.6 Driftnet ...... 94 Inhaltsverzeichnis 13

8.7 Ettercap/Ettercap NG ...... 95 8.8 tcpdump ...... 96

8.9 Wireshark ...... 97 8.10 Abwehr – generelle Tipps ...... 98

9 Sonstige Hackertools ...... 99

9.1 Metasploit Framework (MSF) ...... 99 9.2 USBDUMPER 2 ...... 100

9.3 USB Switchblade/7zBlade ...... 101 9.4 Net Tools 5.0 ...... 102 9.5 Troll Downloader ...... 103 9.6 H.O.I.C – High Orbit Ion Cannon ...... 104

9.7 Phoenix Exploit’s Kit ...... 105 9.8 fEvicol ...... 106 9.9 0x333shadow ...... 106 9.10 Logcleaner-NG ...... 108 9.11 NakedBind ...... 109 9.12 Ncat (Nmap-Suite) ...... 110 9.13 GNU MAC Changer (macchanger) ...... 111 9.14 Volatility Framework ...... 112 9.15 Abwehr – generelle Tipps ...... 113

10 Wireless Hacking ...... 115 10.1 Kismet-Newcore ...... 116 10.2 Aircrack-NG (Aircrack-NG-Suite) ...... 117 10.3 Aireplay-NG (Aircrack-NG-Suite) ...... 118 10.4 Airodump-NG (Aircrack-NG-Suite) ...... 119 10.5 Airbase-NG (Aircrack-NG-Suite) ...... 120 10.6 coWPAtty ...... 121 10.7 Reaver ...... 122 10.8 Wash (Reaver-Suite) ...... 124 10.9 Pyrit ...... 125 10.10 MDK3 ...... 126 10.11 Vistumbler ...... 127 10.12 Abwehr – generelle Tipps ...... 129 14 Inhaltsverzeichnis

Teil II: Angriffsszenarien und Abwehrmechanismen ...... 131

11 Die Angreifer und ihre Motive ...... 133 11.1 Die Motive ...... 133 11.1.1 Rache ...... 133 11.1.2 Geltungssucht ...... 134 11.1.3 Furcht ...... 134 11.1.4 Materielle Interessen ...... 134 11.1.5 Neugierde ...... 135 11.2 Die Angreifer ...... 136 11.2.1 Hacker ...... 136 11.2.2 Script-Kiddies ...... 137 11.2.3 IT-Professionals ...... 138 11.2.4 Normalanwender und PC-Freaks ...... 139

12 Szenario I: Datenklau vor Ort ...... 141 12.1 Zugriff auf Windows-PCs ...... 141 12.1.1 Erkunden von Sicherheitsmechanismen ...... 141 12.1.2 Überwinden der CMOS-Hürde ...... 142 12.1.3 Das Admin-Konto erobern ...... 144 12.2 Zugriff auf Linux-Rechner ...... 153 12.2.1 Starten von Linux im Single-User-Mode ...... 153 12.2.2 Starten von einem Linux-Boot-Medium ...... 157 12.2.3 Einbinden der zu kompromittierenden Festplatte in ein Fremdsystem ...... 158 12.3 Abwehrmaßnahmen gegen einen physischen Angriff von außen ...... 159 12.4 2-Faktoren-Authentifizierung ...... 161 12.4.1 iKey 2032 von SafeNet ...... 162 12.4.2 Chipdrive Smartcard Office ...... 165 12.4.3 Security Suite ...... 169

13 Szenario II: Der PC ist verwanzt ...... 173 13.1 Software-Keylogger ...... 175 13.1.1 Ausforschen von Sicherheitseinstellungen ...... 175 13.1.2 Festlegen des Überwachungsumfangs ...... 175 13.1.3 Installation des Keyloggers ...... 176 13.1.4 Sichten, Bewerten und Ausnutzen der gewonnenen Daten ...... 179 13.1.5 Die Audiowanze ...... 179 Inhaltsverzeichnis 15

13.2 Big Brother im Büro ...... 181 13.3 Abwehrmaßnahmen gegen Keylogger & Co...... 183

14 Szenario III: Spurensucher im Netz ...... 191 14.1 Google-Hacking ...... 192 14.1.1 Angriffe ...... 192 14.1.2 Abwehrmaßnahmen ...... 202 14.2 Portscanning, Fingerprinting und Enumeration ...... 205 14.2.1 Portscanning ...... 205 14.2.2 Fingerprinting und Enumeration ...... 221 14.2.3 Security-Scanner ...... 225 14.3 Abwehrmaßnahmen gegen Portscanner & Co...... 231

15 Szenario IV: Web Attack ...... 239 15.1 Defacements ...... 239 15.2 XSS-Angriffe ...... 240 15.3 Angriff der Würmer ...... 241 15.4 DoS-, DDoS- und andere Attacken ...... 241 15.5 Ultima Ratio – Social Engineering oder Brute Force? ...... 250 15.6 Sicherheitslücken systematisch erforschen ...... 253 15.6.1 AccessDiver ...... 253 15.6.2 Spuren verwischen mit ProxyHunter ...... 255 15.6.3 Passwortlisten konfigurieren ...... 259 15.6.4 Wortlisten im Eigenbau ...... 261 15.6.5 Websecurity-Scanner: Paros ...... 264 15.6.6 Websecurity-Scanner: WVS ...... 266 15.6.7 Websecurity-Scanner: Wikto ...... 270 15.7 Abwehrmöglichkeiten gegen Webattacken ...... 277 15.7.1 .htaccess schützt vor unbefugtem Zugriff ...... 277

16 Szenario V: WLAN-Attacke ...... 281 16.1 Aufspüren von Funknetzen ...... 283 16.1.1 Hardwareausstattung für Wardriving ...... 283 16.1.2 Vistumbler für Windows ...... 285 16.1.3 Kismet-Newcore für Linux ...... 290 16.2 Kartografierung von Funknetzen ...... 304 16.2.1 Kartografierung von Funknetzen mit Google Maps oder OpenStreetMap ...... 305 16 Inhaltsverzeichnis

16.2.2 Kartografierung von Funknetzen mit und Vistumbler ...... 309 16.2.3 Kartografierung von Funknetzen mit Google Earth und Kismet- Newcore ...... 311 16.3 Angriffe auf Funknetze ...... 313 16.3.1 Zugriff auf ein offenes WLAN ...... 314 16.3.2 Zugriff auf ein WLAN, dessen Hotspot keine SSID sendet ...... 315 16.3.3 Zugriff auf ein WLAN, das keinen DHCP-Dienst anbietet ...... 318 16.3.4 Zugriff auf ein mit MAC-Filter gesichertes WLAN ...... 323 16.3.5 Zugriff auf ein WEP-verschlüsseltes WLAN ...... 328 16.3.6 Zugriff auf ein WPA2-verschlüsseltes WLAN ...... 342 16.3.7 Zugriff auf ein WPA2-verschlüsseltes WLAN durch die WPS- Schwäche ...... 355 16.3.8 Zugriff auf ein WPA2-verschlüsseltes WLAN durch Softwareschwächen ...... 362 16.3.9 WLAN, mon amour – Freu(n)de durch Funkwellen ...... 363 16.4 Sicherheitsmaßnahmen bei Wireless LAN ...... 373

17 Szenario VI: Malware-Attacke aus dem Internet ...... 377 17.1 Angriffe via E-Mail ...... 378 17.1.1 Absendeadresse fälschen ...... 378 17.1.2 Phishen nach Aufmerksamkeit ...... 382 17.1.3 Der Payload oder Malware aus dem Baukasten ...... 386 17.1.4 Massenattacken und Spam-Schleudern ...... 391 17.1.5 Office-Attacken ...... 393 17.1.6 Kampf der Firewall ...... 396 17.2 Rootkits ...... 402 17.2.1 Test-Rootkit Unreal ...... 404 17.2.2 AFX-Rootkit ...... 406 17.3 Die Infektion ...... 409 17.3.1 Experiment 1: rechnung.pdf.exe ...... 409 17.3.2 Experiment 2: bild-07_jpg.com ...... 412 17.4 Drive-by-Downloads ...... 415 17.5 Schutz vor (un)bekannten Schädlingen aus dem Netz ...... 421 17.5.1 Mailprogramm und Webbrowser absichern ...... 423 17.5.2 Pflicht: Malware- und Antivirenscanner ...... 424 17.5.3 Malware-Abwehr mit Sandboxie ...... 427 17.5.4 Allzweckwaffe Behavior Blocker & HIPS ...... 429 Inhaltsverzeichnis 17

18 Szenario VII: Netzwerkarbyten: Wenn der Feind innen hackt ...... 433 18.1 Der Feind im eigenen Netzwerk ...... 433 18.2 Zugriff auf das LAN ...... 434 18.3 Passives Mitlesen im LAN: Sniffing ...... 436 18.3.1 Tcpdump ...... 438 18.3.2 Wireshark ...... 442 18.3.3 Ettercap NG ...... 445 18.3.4 DSniff-Suite ...... 455 18.3.5 Driftnet ...... 466 18.3.6 P0f ...... 466 18.3.7 ARPSpoof ...... 469 18.4 Scanning: »Full Contact« mit dem LAN ...... 472 18.4.1 Xprobe2 ...... 473 18.4.2 Nmap ...... 476 18.4.3 Open Vulnerability Assessment System/OpenVAS ...... 484 18.5 Der Tritt vors Schienbein: Exploits ...... 494 18.5.1 wunderbar_emporium ...... 495 18.5.2 2009-lsa.zip/Samba < 3.0.20 heap overflow ...... 501 18.5.3 Metasploit Framework ...... 505 18.6 Hurra, ich bin root – und nun? ...... 534 18.7 Windows-Rechner kontrollieren ...... 534 18.7.1 Integration von Schadsoftware ...... 541 18.8 Linux unter Kontrolle: Rootkits installieren ...... 543 18.8.1 evilbs ...... 545 18.8.2 Mood-NT ...... 549 18.8.3 eNYeLKM ...... 553 18.9 Linux unter Kontrolle: Spuren verwischen mit Logfile- Cleaner ...... 559 18.10 Linux unter Kontrolle: Keylogger ...... 564 18.11 Linux unter Kontrolle: Password-Cracking ...... 566 18.11.1 John the Ripper ...... 567 18.11.2 ophcrack ...... 567 18.11.3 Medusa ...... 570 18.11.4 Hydra ...... 572 18.12 Schutz vor Scannern, Exploits, Sniffern & Co...... 574 18 Inhaltsverzeichnis

Teil III: Prävention und Prophylaxe ...... 577

19 Private Networking ...... 579 19.1 Sicherheitsstatus mit MBSA überprüfen ...... 579 19.2 Überflüssige Dienste ...... 585 19.3 Vor »Dienstschluss« Abhängigkeiten überprüfen ...... 587 19.4 Alle Dienste mit dem Process Explorer im Blick ...... 588 19.5 Externer Security-Check tut Not ...... 590 19.6 Malware-Check ...... 592 19.7 Risiko: Mehrbenutzer-PCs und Netzwerksharing ...... 605 19.8 Schadensbegrenzung: Intrusion Detection & Prevention ...... 613

20 Company Networking ...... 619 20.1 Basiselemente zur Unternehmenssicherheit ...... 623 20.2 Teilbereich Infrastruktur und Organisation ...... 624 20.3 Teilbereich Personal ...... 626 20.4 Teilbereich Technik ...... 630 19

Teil I: Tools – Werkzeuge für Angriff und Verteidigung

Wir stellen hier einige Tools vor, mit denen man relativ schräge Dinge machen kann. Aber denken Sie daran: Wenn Sie unsere Experimente praktisch nachvollziehen wollen, sollten Sie vorab einige Sicherheitsüberlegungen anstellen. Der wichtigste Punkt betrifft Ihre eigene Sicherheit. Etliche der hier vorgestellten Tools fallen, zumindest aus der Sicht von Virenscannern, ziemlich eindeutig in die Kategorie Malware. Praktisch gesprochen: Allein schon auf der Suche nach den Tools gehen Sie das Risiko ein, infiziert zu werden. Da viele dieser Tools nur im Darknet zu finden sind, wissen Sie nie genau, ob sie nicht mehr Funktionalität bereithalten, als Ihnen lieb sein dürfte. Wenn Sie jetzt denken, dass Sie prinzipiell sehr gut gerüstet sind und die zuverlässigsten und neuesten Antimalware-Tools, Firewalls etc. installiert haben, kommt schon die nächste Ernüchterung. Die meisten Hackertools lassen sich nur dann zur Zusammen- arbeit bewegen, wenn Sie Ihr Visier hochklappen, d. h. aktivierte Firewalls oder Online- Virenwächter werden Ihnen im schlimmsten Fall die Schädlinge schneller löschen, als Sie diese aus dem Internet runterladen; mindestens aber werden sie Sie wirkungsvoll vom Experimentieren abhalten und entsprechende Aktionen der Hackertools deaktivie- ren. Halten Sie das bitte nicht für eine Übertreibung. Ich (PK) hatte eine schöne Sammlung von Schädlingen für weitere Experimente auf meiner Festplatte versammelt. Als ich kurze Zeit später darauf zugreifen wollte, waren die meisten davon nicht mehr vorhanden. Ein Antivirustool hatte sie umbenannt und in Quarantäne verschoben. Als ordentlicher Mensch hatte ich natürlich ein Backup gemacht. Aber als ich jetzt die Ver- zeichnisse öffnen wollte – das alte Spiel, wieder war alles weg. Deshalb müssen Sie im Prinzip drei ziemlich widersprüchliche Ratschläge befolgen: • Laden Sie Hackertools nur von vertrauenswürdigen Quellen – es gibt durchaus Hacker- oder Security-Seiten wie http://packetstormsecurity.org oder www.exploit- db.com (The Exploit Database (EDB)), die es sind. • Prüfen Sie die Dateien, bevor Sie sie anklicken, ob nicht mehr Malware an Bord ist, als sein sollte. • Deaktivieren Sie fallweise Ihren Online-Schutz, um die Tools in ihrer gesamten Bandbreite testen zu können (und lassen Sie hinterher einen oder mehrere Scanner über Ihr System laufen). Wir raten dringend an, dass Sie diese Tests nur auf einer in sich gekapselten, virtuellen Maschine ausführen, z. B. von VMware; ersatzweise tut es auch eine separate, bootfähige Festplatte, die Sie nach den Experimenten mit einem Imagebackup wieder in den ursprünglichen Zustand zurückversetzen. Berücksichtigen sollten Sie hierbei auch 20 Teil I: Tools – Werkzeuge für Angriff und Verteidigung

weitere im Netzwerk befindliche Rechner, natürlich auch den Zugang zum Internet: Starten Sie einen aktuellen Wurm und sind die restlichen Maschinen Ihres Netzwerks verwundbar, dann eskaliert das ursprünglich zu wissenschaftlichen Zwecken angedachte Szenario zu einem GAU. Eine letzte Warnung müssen wir Ihnen auch noch mit auf den Weg geben. Die meisten der hier vorgestellten Tools – auch wenn sie etwas angejahrt sind – haben ein (immer noch) erhebliches Angriffspotenzial mit der realen Möglichkeit, weniger gut geschützte Systeme bzw. deren Anwender zu schädigen. Das wiederum ist kein Kavaliersdelikt, son- dern kann zu strafrechtlichen Konsequenzen führen. Wenn Sie aus Gründen der besse- ren Nachvollziehbarkeit kontrollierte Angriffe starten wollen, dann bitte ausschließlich in Ihrem eigenen Netzwerk oder nach vorheriger Rücksprache mit Ihren »Testkandida- ten«. Was die aktuelle Werkzeugsammlung betrifft: Sie finden hier unterteilt in zehn Rubri- ken Tools aus der Windows- und Linux-/Unix-Welt. Unsere Auswahl ist natürlich subjektiv. Wir haben die Programme ausgewählt, mit denen wir in der Praxis gearbeitet haben und noch arbeiten. Darunter sind sehr gängige Werkzeuge wie Nmap, OpenVAS oder das Metasploit Framework, aber auch ausgefallenere Tools wie USBDUMPER2 und der Stealth Recorder. Bei den kommandozeilenbasierten Linux-Tools haben wir relevante Eingabeparameter und auch das Ausgabeformat in den meisten Fällen voll- ständig aufgelistet. Wem die Routine mit diesen Tools fehlt, der hat somit gleichzeitig auch ein kleines Nachschlagewerk parat. Wir wünschen Ihnen viel Freude beim Testen und bei der Netzwerkerforschung. Bei der Überarbeitung ist uns ein unliebsamer Effekt begegnet: Innerhalb weniger Wochen können die »Lieferadressen« von Underground Tools (selbst wenn sie älteren Ursprungs sind) einfach von der Bildfläche verschwunden sind. So geschehen mit USB Switchblade bzw. 7zBlade. Wir haben uns bemüht, gültige Bezugsquellen anzugeben. Es liegt aber in der Natur der Sache, dass die Halbwertszeit dieser Seiten beschränkt ist. Im Zweifelsfall, der hoffentlich Einzelfall bleiben wird, werden Sie selbst also nach bestimmten hier vorgestellten Tools über die Suchmaschine Ihrer Wahl »nachfassen« müssen. Noch eine letzte Anmerkung zum Stichwort »Redundanz«. Den hier aufgeführten Tools werden Sie zum großen Teil (aber nicht ausschließlich) in unseren Angriffsszenarien begegnen – und sie im konkreten Angriffskontext erleben. Aber wir werden dort wie auch beim Thema Prophylaxe einige weitere Werkzeuge benutzen, die Sie hier nicht finden, weil wir diesen Rahmen nicht sprengen wollten. Es geht uns weniger um die Tools, die in bestimmten Zusammenhängen austauschbar sind, sondern um die kon- krete Durchführung und das dafür notwendige Know-how.

21

1 Keylogger – Spionage par excellence

Der Begriff »Keylogger«, auf Deutsch: Tastaturrekorder, klingt auf den ersten Blick eher harmlos. Keylogger sind aber eine der größten Gefahren, denen sich Privatpersonen und Firmen heute ausgesetzt sehen. Keylogger existieren als Hardware- und als Software- ausführung.13 Ihr Zweck ist derselbe – alles aufzuzeichnen, was der Anwender auf der Tastatur seines PCs eingibt: • CMOS-Passwörter • Benutzeraccounts • PIN-/TAN-Kombinationen fürs Online-Banking • Log-in-Daten für diverse Webdienste (E-Mail-Accounts, Forenanmeldungen etc.) • Passwörter zum Verschlüsseln von Festplatten, Verzeichnissen, Dateien • Zusätzlich natürlich alle Texte in Eingabemasken, Formularen, Chatrooms etc. Manche Keylogger speichern auch Screenshots, damit der Angreifer auch die anderen visuellen Aktivitäten seiner Opfer mitverfolgen kann. Besonders heimtückisch sind Keylogger, die als Hardwaremodul zwischen Tastatur und Rechner eingeschleift werden und dabei alle Daten von der Tastatur mitschneiden, bevor sie über das Betriebssystem an das jeweilige Anwenderprogramm übergeben werden. Die Softwarefraktion geht einen anderen Weg: Meist wird hier ein Treiber installiert – vorzugsweise auf Kernel- ebene – der vom Benutzer völlig unbemerkt alle Eingaben abfängt, aufzeichnet und dann an das jeweilige Programm übergibt. Die Keylogger, die wir hier vorstellen, sind Stand-alone-Produkte. Daneben findet sich die Funktionalität von Keyloggern auch in diversen Malware- und Spywareprogrammen installiert, insbesondere in Trojanern und RATs (Remote Access Tools). Die Funktionalität der SW-Keylogger ist ziemlich ausgereift. So gibt es Programme, die nicht nur Sessions mitschneiden (via Screenshots oder auch als kleine Filme), Tastatureingaben protokollieren, die Eingaben verschlüsseln und ihre Spuren mittels Rootkits tarnen, sondern auch Spezialentwicklungen, um gezielt Daten auszulesen und diese dann durch die Firewall nach außen schmuggeln zu können. Keylogger lassen sich natürlich auch zu Verteidigungszwecken nutzen, beispielsweise um Betrugsfällen und dem Ausspionieren von Firmengeheimnissen auf die Spur zu kommen. In Deutschland fallen diesbezügliche Aktivitäten (im Übrigen wie fast alle hier

13 Eine gute Übersicht über die »besten« Softwarekeylogger findet man hier: www.keylogger.org/monitoring- software-review 22 Kapitel 1: Keylogger – Spionage par excellence

beschriebenen Tools) unter das Strafgesetzbuch § 202a – Ausspähen von Daten – und sind damit strafbewehrt bzw. nur in geregelten Ausnahmefällen zulässig.

1.1 Logkeys

Anbieter http://code.google.com/p/logkeys Preis – Betriebssystem(e) Linux/Unix Sprachen Englisch Kategorie(n) Keylogger Oberfläche GUI CMD x Größe < 1 MB Installation/ Nein/ Schnittstellen Kompilation Ja Usability  Know-how 

Bei Logkeys handelt es sich um einen Keylogger für Linux, der sowohl auf seriellen als auch auf USB-Tastaturen läuft. Logkeys erfasst und protokolliert sämtliche Eingaben, die auf der Tastatur eingegeben werden. Logkeys übersetzt die eingegebenen Zeichen in das ASCII-Format. Der Einsatz von Logkeys mit folgenden Parametern:

• -s start logging keypresses

• -o log output to FILE [/var/log/logkeys.log] bringt durch die Eingabe von logkeys --start --output /var/log/logkeys.log z. B. folgendes Ergebnis:

sh-3.2# cat /var/log/logkeys.log Logging started ...

2010-03-10 19:35:18+0000 > uname -a 2010-03-10 19:35:35+0000 > ps -aux 2010-03-10 19:46:46+0000 > useradd -m hweber 2010-03-10 19:46:55+0000 > passwd hweber 2010-03-10 19:47:22+0000 > maxtor19! 2010-03-10 19:47:29+0000 > maxtor19! (...) 2010-03-10 19:47:47+0000 > aptitude update 2010-03-10 19:48:05+0000 > exit sh-3.2#

Bild 1.1: Logkeys beim Aufzeichnen von Tastatureingaben 1.2 Elite Keylogger 23

1.2 Elite Keylogger

Anbieter www.widestep.com Preis Trial, ab 49 €

Betriebssystem(e) Win XP, Vista, Win 7 (32+64 Bit) Sprachen Englisch Kategorie(n) Keylogger Oberfläche GUI x CMD Größe < 5 MB Installation Ja Schnittstellen Usability  Know-how 

Nach unseren Tests gehört der Elite Keylogger V. 4.5 (Stand IV/2009) nach wie vor zu den besten (Funktionalität) und technologisch fortgeschrittensten Vertretern seiner Art. Er zeigt, was heute in dem Bereich machbar ist, um selbst misstrauische und erfahrene PC-Anwender unbemerkt und effektiv auszuspionieren. Da es sich beim Elite Keylogger um ein kommerzielles Produkt handelt, ist er ziemlich gut getarnt vor den meisten Viren- und Malware-Scannern. Sein Tarnmantel ist so gut, dass er mit herkömmlichen Betriebssystemmitteln nicht entdeckt werden kann. Die einzige Möglichkeit, ihm beizu- kommen, ist der Einsatz von Anti-Rootkits. Besonders hervorzuheben ist seine Fähigkeit, die protokollierten Daten applikations- spezifisch auswerten zu können, d. h., man sieht auf einen Blick, welche Briefe in Word geschrieben, welche Tabellen in Excel angelegt, welche E-Mails mit welchen Inhalten verschickt bzw. in welchen Chats welche Dialoge geführt wurden. Das erleichtert die Auswertung nicht unbeträchtlich. Ein herausragendes Feature ist die Verteilung der Logs auf andere Rechner im Netz. Man muss sich nicht mehr via E-Mail informieren lassen (und gegebenenfalls verdächtige Meldungen der Firewall riskieren), um in aller Ruhe Daten sammeln und auswerten zu können. Der fürs Unsichtbarmachen zuständige Kerneltreiber wird in regelmäßigen Abständen aktualisiert. 24 Kapitel 1: Keylogger – Spionage par excellence

Bild 1.2: Komfortabel und unsichtbar

1.3 Ardamax Keylogger

Anbieter www.ardamax.com Preis Trial, ab 28,95 €

Betriebssystem(e) Win XP, Vista, Win 7 Sprachen Englisch Kategorie(n) Keylogger Oberfläche GUI x CMD Größe > 5 MB Installation Ja Schnittstellen Usability  Know-how 

Nicht vom Leistungsumfang, wohl aber von der Dateigröße einer der kleinsten (und unauffälligsten) Keylogger. Die Bedienung ist sehr simpel; in wenigen Minuten ist der Keylogger konfiguriert und unsichtbar gemacht. Zwei Highlights haben uns besonders gut gefallen: • Die Möglichkeit, ein Remote- bzw. Servermodul zu konfigurieren, das man z. B. mit einem anderen nützlichen Programm bündeln und einem ahnungslosen Opfer zuschicken kann. Vorteil: Man muss den Keylogger nicht vor Ort installieren. • Die Eingabe eines künstlichen Verfalldatums. Das kann sehr nützlich sein, wenn man sein Opfer nur über eine definierte Zeitspanne überwachen kann oder muss. Danach deinstalliert sich das Programm völlig unbemerkt. 1.4 Stealth Recorder Pro 25

Bild 1.3: Auswertungsfenster Keylogger

Die Logs sind verschlüsselt; man kann sie sich als HTML-Report via E-Mail zuschicken oder über einen FTP-Server bzw. relativ leicht übers LAN an eine geheime Adresse ver- schicken lassen.

1.4 Stealth Recorder Pro

Anbieter Über Distributor lieferbar, z. B. Preis Trial, ab 39,95 $ www.brothersoft.com Betriebssystem(e) Windows Sprachen Englisch Kategorie(n) Keylogger Oberfläche GUI x CMD Größe < 500 KB Installation Ja Schnittstellen Usability  Know-how 

Eigentlich kein Keylogger im strengen Sinn des Wortes, sondern eine Audiowanze mit verblüffendem Funktionsumfang. Ziel des Angriffs sind Gespräche, die in der Nähe des Rechners oder Notebooks geführt werden. Eigene Tests ergaben, dass selbst mit einem günstigen Notebook alles aufgezeichnet werden kann, was im Umkreis von mehr als 10 m 26 Kapitel 1: Keylogger – Spionage par excellence

gesprochen wird. Möglich wird dies durch eine neuartige Boostertechnologie, die den Input eines handelsüblichen Mikrofons um mehr als das 100-Fache verstärken kann. Die Software zeichnet – in Abhängigkeit des gewählten Umgebungspegels – jedes gesprochene bzw. geflüsterte Wort im mp3-Format (unterschiedliche Qualitätsstufen wählbar) auf und versendet diese Dateien via E-Mail oder FTP. Ein besonderes Schmankerl ist die Fernabfragemöglichkeit. Dadurch ist es einem Angreifer von außen möglich, über einen definierten Port auf die MP3-Dateien zuzugreifen. Man muss die Software nicht unbedingt einem potenziellen Opfer aufs Notebook oder den Rechner packen, sondern kann sie auf seinem eigenen Notebook installieren und in Meetings platziert einsetzen. Bei vielen Notebooks besteht ja der Vorteil darin, dass man kein separates Mikrofon braucht, sondern dieses bereits eingebaut ist.

Bild 1.4: Zugriff auf die Audiowanze von außen

1.5 Advanced Keylogger

Anbieter www.mykeylogger.com/de/ Preis 49,95 € (Demo verfügbar) Betriebssystem(e) Windows inkl. 64 Bit Sprachen Deutsch Kategorie(n) Keylogger Oberfläche GUI x CMD Größe < 15 MB Installation Ja Schnittstellen Usability  Know-how 

Ein eigenständiges Hackerprodukt mit gewissen Vorzügen. Z. B. kann man den erzeug- ten Remote-Installer noch mit einem anderen, harmlosen Produkt, u. a. einer kleinen Videodatei, bündeln, damit das Opfer keinen Verdacht schöpft. Zusätzlich kann man die Abhöraktion zeitlich auch begrenzen, quasi mit einem Verfallsdatum versehen, was die Gefahr, entdeckt zu werden, ebenfalls minimiert. 131

Teil II: Angriffsszenarien und Abwehrmechanismen

133

11 Die Angreifer und ihre Motive

11.1 Die Motive

Für Angriff wie Verteidigung gilt: Man muss genau wissen, was man und aus welchen Gründen man es tun will. Die Maxime lautet: Wer weiß, was er tut, kann tun, was er will. Die meisten Angriffe lassen sich auf eines der folgenden Motive zurückführen.

11.1.1 Rache

Der Angreifer fühlt sich beleidigt, gar in seiner Ehre gekränkt: Das Opfer hat ihm – wenigstens aus seiner Sicht – etwas Bestimmtes angetan (z. B. ihn im Chatroom beleidigt, seine Fähigkeiten in Frage gestellt, seinen Glauben geschmäht etc.). Der Angreifer wird in der Folge bestrebt sein, dem anderen einen Schaden zuzufügen, der seiner eigenen Schädigung annähernd vergleichbar ist. Es muss sich nicht um ein Script-Kiddie oder einen klassischen Hacker handeln. Aus Rachsucht in einem PC oder in ein Netzwerk einzubrechen, kann beispielsweise auch Sache eines technisch versierten Angestellten sein, dem man seiner Auffassung nach ungerechtfertigt gekündigt hat. Ziel der Rachsucht ist meist das Außergefechtsetzen von Rechnern oder Speichermedien. Dazu kann auch gehören, dass man dem Opfer einen Virus zukommen lässt, der sämtliche Daten seiner Festplatte zerstört. Bei milderen Varianten kann der Angreifer auch »nur« die Internetfähigkeiten seines Opfers zerstören. In eher seltenen Fällen wird nichts zerstört, sondern es werden Daten bzw. Informationen entwendet (z. B. Kreditkarten- oder Kundendaten), um sie entweder an den Meistbietenden zu verscherbeln oder um sie dem Opfer zurückzuverkaufen. Der Angriff muss nicht gezielt erfolgen, sondern kann auch anonyme Internet- /Anwendergruppen treffen. Der Angreifer wird in der Regel erst dann von seinem Opfer ablassen, wenn er mit dem erzielten Effekt zufrieden ist. Gezielter Angriff:  Schadenswirkung:  Eingesetztes Know-how:  134 Kapitel 11: Die Angreifer und ihre Motive

11.1.2 Geltungssucht

Der Angreifer möchte sich beweisen, indem er der Szene, die dabei als Resonanzboden dient, seine zumeist destruktiven Fähigkeiten demonstriert. Nehmen wir den geistigen Wurmschöpfer von Netsky und Sasser, Sven J. Im Frühjahr 2004 infizierte Sasser, der geschickt programmiert war und das System über eine Lücke im LSASS infizierte, in atemberaubendem Tempo Millionen ungepatchter PCs. Nach seinen eigenen Aussagen wollte Sven besonders schöne Programme schreiben und die vorhandenen Schutzein- richtungen austricksen. Einen unsterblichen Platz in der Hall of Fame versprechen auch sensationell durchgeführte Hacks, z. B. in Militärnetze. Der hinterlassene Schaden ist meist unspezifisch und nicht direkt beabsichtigt, aber selten unbeträchtlich. Gezielter Angriff:  Schadenswirkung:  Eingesetztes Know-how: 

11.1.3 Furcht

Der Angreifer fürchtet, dass bestimmte Dinge über ihn aufgedeckt werden oder ihm in näherer Zukunft unliebsame Konsequenzen bevorstehen könnten (z. B. Strafanzeige wegen nachgewiesener Unterschlagungen). Aus Furcht versucht er, die Spuren früherer illegaler oder illegitimer Aktivitäten zu verwischen. Er bricht in den Firmenrechner ein und löscht dort alle Daten, inklusive auf weiteren Festplatten abgelegte Backups, die belastendes Material enthalten könnten. Manchmal schießt er dabei über das Ziel hinaus und hinterlässt eine Wirkung ähnlich einer Streubombe. Die Raffinesse des Angreifers kann sehr groß sein (Computerexperte), es kann sich aber auch um eine verängstigte Ehefrau handeln, die die Festplatte formatiert, um zu verhindern, dass ihr Partner vielleicht durch Zufall belastendes Material zutage fördert. Ein direktes finanzielles Interesse an der Schädigung des Opfers besteht für gewöhnlich nicht, da sich der Angriff weniger gegen die Person des Opfers als vielmehr gegen ihre Infrastruktur richtet. Gezielter Angriff:  Schadenswirkung:  Eingesetztes Know-how: 

11.1.4 Materielle Interessen

Aus unserer Sicht ist dies das vorrangigste Motiv für Netzangriffe. Die Angreifer wollen aus ihren Netzwerkattacken (Einsatz von Ad- und Sypware, RATs, Keyloggern und Trojanern) einen direkten und persönlichen Nutzen ziehen, z. B. durch Verkauf der durch illegale Machenschaften erlangten Daten oder durch Vermieten von Bot-Netzen. Erpressungsversuche von großen Konzernen, z. B. durch angedrohte oder durchgeführte 11.1 Die Motive 135

DDoS-Attacken, gehören ebenfalls zum Repertoire der Angreifer. An der schieren Zerstörung von Daten und/oder Rechnern haben sie in der Regel kein Interesse. Schaut man sich heute die Malware-Statistiken an, dann wird schnell klar, worum es geht: gezieltes Ausspionieren von wieder verwertbaren Userdaten (z. B. Kreditkarten- oder E-Banking-Informationen) bzw. »Zombisierung« von möglichst vielen Rechnern durch breit gestreute Wurminfektionen. Die meisten Angreifer verfügen hier über beträchtliches technisches Know-how. Natürlich ist auch damit zu rechnen, dass klassische Hacker von kriminellen Banden rekrutiert und bezahlt werden, dann amalgamieren Neugierde und Profitsucht zu einer äußerst bösartigen und kriminellen Angreifermentalität wie z. B. Spamversand oder Verbreitung illegaler Software. Gezielter Angriff:  Schadenswirkung:  Eingesetztes Know-how: 

11.1.5 Neugierde

Es ist ein beliebtes Motiv: Einfach mal sehen, wo der Nachbar mit seinem WLAN so surft oder welche E-Mails der Partner in der letzten Zeit geschrieben und verschickt hat. Auch im Firmenumfeld kann man sich nach Lust, Laune und Kenntnissen gut austoben, z. B. mit einer nicht autorisierten, aber dafür exzessiven Dateirecherche im Firmennetz- werk. Meistens geht es nicht darum, jemanden zu schädigen, eher kommt hier das Thema »Macht« ins Spiel: Wissen ist Macht – man macht es, weil man es kann. Gelegentlich werden auch moralische Motive vorgeschoben (in Hackerkreisen durchaus üblich), um das eigene Tun zu rechtfertigen, wie z. B. der Kampf gegen die Profitgier der Konzerne oder gegen die Informationszurückhaltung von Behörden. Lieschen Müller in den Ordner zu schauen, verschafft auch weniger intellektuelle Befriedigung als die Datenbanken und Netze von Konzernen zu infiltrieren. Werden entsprechende Aktivitäten von technisch versierten Amateuren gestartet, sind sehr häufig keine finanziellen Sonderinteressen im Spiel. Gezielter Angriff:  Schadenswirkung:  Eingesetztes Know-how:  Natürlich sind das nur grobe Annäherungen, und Ausnahmen lassen sich sicherlich auch finden. Man denke nur an ein mäßig talentiertes Script-Kiddie, das sich aus Vorlagen einen Wurm zusammengebastelt hat und jetzt neugierig ist, ob der Wurm tut, was er tun soll. Das Motiv ist hier Neugierde, es gibt auch keinen gezielten Angriff auf ein Unternehmen oder eine Institution. Nichtsdestotrotz kann der Schaden durchaus gewaltig sein: Der Internettraffic ist beeinträchtigt, Rechnernetze sind überlastet und auf die betroffenen Administratoren wartet jede Menge Aufräumarbeit. Der Schaden kann schnell in die Millionen gehen. 136 Kapitel 11: Die Angreifer und ihre Motive

11.2 Die Angreifer

Angriffe können zwar automatisiert werden, dahinter stehen aber immer Menschen – mit unterschiedlichen Motiven. Bei den potenziellen Angreifern fallen zwei Gruppen sofort ins Auge:

11.2.1 Hacker

Ihr Selbstbild hat Stewart Brand 1984 auf folgende griffige Formel reduziert: »Infor- mation wants to be free«. Die Motivation der Hacker ist Neugierde gepaart mit extrem gutem IT-Wissen, vor allem Betriebssystem-, Netzwerk- und Programmier-Know-how. In den meisten Fällen wird man Hackern in der IT-Branche begegnen. Der CCC (Chaos Computer Club) hat seine ethischen Grundlagen in den »Hackerethics«34 einmal so formuliert: • Der Zugang zu Computern und allem, was einem zeigen kann, wie diese Welt funktioniert, sollte unbegrenzt und vollständig sein. • Alle Informationen müssen frei sein. • Misstraue Autoritäten – fördere Dezentralisierung. • Beurteile einen Hacker nach dem, was er tut, und nicht nach üblichen Kriterien wie Aussehen, Alter, Rasse, Geschlecht oder gesellschaftlicher Stellung. • Man kann mit einem Computer Kunst und Schönheit schaffen. • Computer können dein Leben zum Besseren verändern. • Mülle nicht in den Daten anderer Leute. • Öffentliche Daten nützen, private Daten schützen. Man muss hier allerdings beachten, dass es sich um eine Form der Selbststilisierung handelt, die dem tradierten Vorurteil »Hacker sind Computerkriminelle« entgegen- wirken soll, die aber letztlich in sich ambivalent ist. Denn wenn alle Informationen frei (verfügbar) sein müssen, wäre es gleichermaßen berechtigt, die Internetzensur (die in vielen Ländern praktiziert wird) anzuprangern und zu sabotieren und in gesicherte Firmennetze einzudringen, um sein Informationsbedürfnis zu stillen. Dass Hacker, die von den White Hats als Abtrünnige bezeichnet werden, sich diese Informationen bzw. dieses Know-how auch versilbern lassen, wie der KGB-Hack35 1985–1989 zeigt, verrät das grundsätzliche Dilemma zwischen »White Hats« (die guten Hacker) und »Black Hats« (die bösen, destruktiven Hacker). Die Grenze zwischen beiden verläuft hier sehr schwimmend.

34 www.ccc.de/hackerethics 35 http://de.wikipedia.org/wiki/KGB-Hack 11.2 Die Angreifer 137

Sehr aufschlussreich in diesem Zusammenhang ist eine Geschichte, die sich im Mai 2006 zutrug. Es fing damit an, dass der Sicherheitsberater Eric McCarty ein Leck im System der Uni von South California entdeckt und bei SecurityFocus.com gemeldet hatte. Und es endete mit einer Strafanzeige, als besagter Sicherheitsberater einer Bank anbot, dieses Sicherheitsleck zu beheben – gegen Cash. Von dort ist es nur ein kleiner Schritt zum »Kopflanger« von kriminellen Banden, die diese Sicherheitslücken gewerbsmäßig ausnutzen. Man verstehe uns aber bitte nicht falsch. Hacker sind keineswegs per definitionem Computerkriminelle. Aber durch ihr Wissen, zumal wenn es von kriminellen Banden instrumentalisiert wird, und ihr Selbstverständnis können sie schnell zu einem potenziellen Sicherheitsrisiko für das von ihnen hochgeschätzte freie Internet werden. Wie so oft entscheiden Motivation und Vorsatz über gut und böse. Ethische Hacker, die sich einem Ehrenkodex verschrieben haben, könnten zwar aufgrund ihres Wissens Schaden verursachen, verteufeln dieses jedoch zutiefst. Im Internet lässt sich diese Zweischneidigkeit sehr gut beobachten – Stichwort Exploits: Ein Exploit ist der mindestens theoretische Beweis, dass in einem Programm eine Sicherheitslücke existiert. Wird dieser Beweis, z. B. der Conficker-Exploit, programm- technisch umgesetzt und ins Netz gestellt, kann ihn jeder, der über ein Minimum an Systemverständnis verfügt, auf den Rest der Menschheit loslassen. Auf der anderen Seite – und das ist die schon zitierte Ambivalenz des Hackens – können dadurch Sicherheits- patches beschleunigt werden, da es mittels Exploits z. B. möglich ist, auch dem lernresistentesten Entscheider zu beweisen, dass nun wirklich etwas getan werden muss.

11.2.2 Script-Kiddies

Oft die jüngere, unausgereifte Ausgabe der Hacker: talentiert, IT-Basis-Know-how, an schnellen Erfolgen und Publicity interessiert, wobei im Großen und Ganzen die Folgen ihrer Handlung oft außen vor bleiben. Die Wikipedia formuliert es so: »Im Bereich der Computersicherheit steht der Begriff Script-Kiddie für eine Person, die kein Sicherheits- experte ist, jedoch in einer meist unreifen Art vorgefertigte Programme benutzt, um Sicherheitsbarrieren zu überwinden oder um Vandalismus zu betreiben. Im Gegensatz zu einem Hacker agiert ein Script-Kiddie ohne Kenntnis darüber, wie die verwendete Schwachstelle funktioniert und wie sich neue Sicherheitslücken aufspüren lassen.« In seinem Trojan White Paper36 hat Aelphaeis Mangarae im Mai 2006 einige Interviews mit typischen Script-Kiddies und jungen Malware-Codern veröffentlicht. Wir zitieren nachfolgend einige Passagen aus dem Interview mit Caesar2k, dem damals 20-jährigen Schöpfer des Nuclear Rat. Er lebt in Brasilien, hat einen Kurs in Psychologie belegt, ist arbeitslos und programmiert in C++ und Delphi: Where do you think the Trojan Scene is heading? It’s getting repetitive, every day one kid decides to release a new recompile of his Latinus clone, or code his awesome new featured Trojan in VB, and it’s »saturating the scene«. But I think it’s getting more serious, since a lot of people are getting to

36 http://igniteds.net 138 Kapitel 11: Die Angreifer und ihre Motive

use the computer every day, and the Trojan is becoming more a remote tool than ever, to make your tasks easier and to be able to control a LAN for example. What new technologies do you think we will see in newer Trojans? Why do you code Trojans? Is it just a hobby? Yes, it’s a very profitable hobby. But I code them because its fun, and when I’m home, that can be more fun than playing games. And it makes you to think a lot, when you decide to try something new. It’s good for your brain health. What features do you think we will be seeing in future Trojans? Hmm I don’t know about the future Trojans, lately any script kid is able to get some open source code and release its yet another Latinus rip l33t Trojan. But from the serious coders that usually code stuff from scratch and such, the Trojans will get more serious as well, like kernel mode Trojans (like akcom and MrJinxy are doing). That’s pretty much the highest level of what a Trojan could have. I’m not much into detailing features, since there’s not much that would have to be implemented, besides DDoS that every kiddie loves. Finally, do you care that your software may be used for malicious purposes? Not at all, its not my problem really. People can decide their behavior, evil or good, as they take the responsibility for their actions, I couldn’t care less. An diesem Interview stechen die wichtigsten Punkte direkt ins Auge. Der 20-Jährige ist, wie Psychologen sagen würden, intrinsisch motiviert; er betreibt das Programmieren mit Hingabe und Profession, sieht sich als »serious coder« (nicht als Script-Kiddie) und rechtfertigt sein Tun als seriöse Aufgabe, die Spaß macht und, mit der sich durchaus auch Geld verdienen lässt. Dass sich mit RATs und Trojanern, die er programmiert, jede Menge Schäden anrichten lassen, geht ihn im Übrigen nichts an, es sei nicht sein Prob- lem. Opfer dieses Angreifertyps, der auf Breitenwirkung aus ist, sind meist Privatanwender, während Hacker mehr Firmen und Institutionen ins Visier nehmen – quasi in Arbeits- teilung. Beide Gruppen verkaufen, unbeschadet von ethischen Überlegungen, ihre Dienste auch gern an zahlungsfähige Klienten aus dem kriminellen Umfeld, die die Malware nutzen, um sich gezielt finanzielle Vorteile zu erschleichen.

11.2.3 IT-Professionals

Nicht nur Hacker und Script-Kiddies, sondern auch Personen, die berufsmäßig mit IT- Security, mit Netzen und Systemen zu tun haben, können aus verschiedensten Gründen zum Angreifer mutieren. Auf jeden Fall bringen sie die wichtigste Voraussetzung mit: neben dem Insiderwissen vor allem das Verständnis von Netzen und Systemen, inklusive ihrer verwundbaren Stellen. Wenn sich jetzt noch das entsprechende Motiv wie Rach- sucht, Neugierde oder Geld dazu gesellt, zählen sie zu den gefährlichsten Angreifern, die es weniger auf Breiten- als Tiefenwirkung abgesehen haben: Informationsgewinnung, Verkaufen von Informationen, Erpressung ihres Arbeitgebers und vieles mehr. 11.2 Die Angreifer 139

11.2.4 Normalanwender und PC-Freaks

Unsere Aufzählung wäre nicht vollständig ohne Berücksichtigung dieser Gruppe. Hier halten allerdings die Motive dem zur Verfügung stehenden IT-Know-how selten stand. Mit anderen Worten: Diese Gruppe ist weitaus weniger qualifiziert als die anderen Angreifer, von daher sind die möglichen Schäden oftmals geringer. Es stimmt allerdings bedenklich, dass im Internet genügend Tools zum Download bereitstehen, mit denen man nicht nur seine Mitmenschen ärgern, sondern durchaus auch semiprofessionell ausspionieren kann, insbesondere dann, wenn das Opfer noch weniger weiß als man selbst. Einem Nachbarn einen Wurm oder Trojaner auf die Platte zu jubeln, ist keine Kunst, wenn der Betreffende weder Virenscanner noch Firewall installiert hat, von ungepatchten Systemen mal ganz abgesehen. Da viele Spionage- und Cracktools auch in regelmäßigen Abständen in den PC-Zeitschriften vorgestellt, besprochen und auf CD geliefert werden, muss sich niemand wundern, wenn sich der Nachbar plötzlich unauf- gefordert ins eigene WLAN einklinkt. Hier möchten wir Ihnen einige typische Fälle von Netz- und Rechnerattacken im Detail vorstellen, denn wir glauben, dass konkrete Beispiele am ehesten das Sicherheits- bewusstsein schärfen. Wer einmal gesehen hat, wie Profis Türen in zwei, drei Minuten öffnen, ist viel stärker motiviert, über eine ordentliche Schließanlage nachzudenken als jemand, der nur darüber gelesen hat. Von daher haben wir uns entschlossen, Ihnen konkrete und häufig auch erfolgreiche Einbruchsversuche vorzustellen.