Netzwerkprotokolle hacken E-Book

James Forshaw

• Herausgeber: dpunkt.verlag
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Deutsch
• Veröffentlichungsjahr: 2018

Seitenzahl: 450

Beschreibung

Netzwerkprotokolle kommunizieren mit anderen Geräten über ein (öffentliches) Netzwerk und sind daher ein nahe liegendes Angriffsziel für Hacker. Um Sicherheitslücken bei einem vernetzten Gerät zu verstehen und aufzuspüren, müssen Sie sich in die Gedankenwelt eines Angreifers hineinversetzen. Dabei hilft Ihnen dieses Buch. Es umfasst eine Mischung aus theoretischen und praktischen Kapiteln und vermittelt Ihnen Know-how und Techniken, mit denen Sie Netzwerkverkehr erfassen, Protokolle analysieren, Exploits verstehen und Sicherheitslücken aufdecken können. Nach einem Überblick über Netzwerkgrundlagen und Methoden der Traffic-Erfassung geht es weiter zur statischen und dynamischen Protokollanalyse. Techniken zum Reverse Engineering von Netzwerkprogrammen werden ebenso erläutert wie kryptografische Algorithmen zur Sicherung von Netzwerkprotokollen. Für die praktischen Teile hat Autor James Forshaw eine Netzwerkbibliothek (Canape Core) entwickelt und zur Verfügung gestellt, mit der Sie eigene Tools zur Protokollanalyse und für Exploits schreiben können. Er stellt auch eine beispielhafte Netzwerkanwendung (SuperFunkyChat) bereit, die ein benutzerdefiniertes Chat-Protokoll implementiert. Das Auffinden und Ausnutzen von Schwachstellen wird an Beispielen demonstriert und häufige Fehlerklassen werden erklärt. Der Autor ist ein renommierter Computer-Sicherheitsexperte beim Google-Project Zero. Seine Entdeckung von komplexen Designproblemen in Microsoft Windows brachte ihm die "Top-Bug-Prämie" ein und an die Spitze der veröffentlichten Liste des Microsoft Security Response Centers (MSRC). Das Buch schließt mit einem Überblick über die besten Werkzeuge zur Analyse und Nutzung von Netzwerkprotokollen. Es ist damit ein Muss für jeden Penetration Tester, Bug Hunter oder Entwickler, der Netzwerkschwachstellen aufspüren und schützen möchte.

Leseprobe

James Forshaw ist ein renommierter Computer-Sicherheits-Experte beim Google-Project Zero und der Entwickler des Netzwerk-Analyse-Tools Canape. Seine Entdeckung von komplexen Designproblemen in Microsoft Windows brachte ihm die »Top-Bug-Prämie« von 100.000 US-Dollar ein und an die Spitze der veröffentlichten Liste des Microsoft Security Response Centers (MSRC). Er wurde eingeladen, seine Ergebnisse auf globalen Sicherheitskonferenzen wie BlackHat, CanSecWest und dem Chaos Computer Congress vorzustellen.

Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+:

www.dpunkt.plus

James Forshaw

Netzwerkprotokolle hacken

Sicherheitslücken verstehen, analysieren und schützen

Übersetzung aus dem Amerikanischen von Peter Klicman

James Forshaw

Lektorat: Dr. Michael Barabas

Übersetzung: Peter Klicman

Copy-Editing: Ursula Zimpfer, Herrenberg

Satz: Birgit Bäuerlein

Herstellung: Stefanie Weidner

Umschlaggestaltung: Helmut Kraus, www.exclam.de

Druck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:

Print978-3-86490-569-8

PDF978-3-96088-473-6

ePub978-3-96088-474-3

mobi978-3-96088-475-0

1. Auflage 2018

Copyright © 2018 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Copyright © 2017 by James Forshaw. Title of the English-language original: Attacking Network Protocols: A Hacker’s Guide to Capture, Analysis and Exploitation, ISBN 978-1-59327-750-5, published by No Starch Press. German-language edition copyright © 2018 by dpunkt.verlag GmbH. All rights reserved.

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Inhaltsübersicht

Vorwort

Danksagungen

Einführung

Inhaltsverzeichnis

1Netzwerk-Grundlagen

2Capturing von Anwendungsverkehr

3Strukturen von Netzwerk-Protokollen

4Fortgeschrittenes Capturing von Anwendungsverkehr

5Analyse auf der Datenleitung

6Reverse Engineering einer Anwendung

7Sicherheit von Netzwerkprotokollen

8Implementierung des Netzwerkprotokolls

9Die Hauptursachen für Sicherheitslücken

10Sicherheitslücken aufspüren und ausnutzen

Anhang

AToolkit für die Netzwerkprotokoll-Analyse

Index

Vorwort

Als ich James Forshaw zum ersten Mal traf, arbeitete ich in einem Job, den Popular Science 2007 in die Top Ten der miesesten Jobs in der Wissenschaft aufgenommen hatte: als »Sicherheitsknecht bei Microsoft« (»Microsoft Security Grunt«). Das war die recht weit gefasste Bezeichnung, die das Magazin für jeden verwendete, der im Microsoft Security Response Center (MSRC) arbeitete. Was unsere Jobs auf dieser Liste schlimmer als »Walfäkalien-Forscher«, aber doch etwas besser als »Elefanten-Sterilisator« erscheinen ließ, war die enorm hohe Frequenz, mit der Reports über Sicherheitsprobleme in Microsoft-Produkten eingingen. (Die Liste war bei uns in Redmont so bekannt, dass wir uns T-Shirts machen ließen.)

Es geschah hier am MSRC, dass James mit seinem scharfen und kreativen Auge für das Ungewöhnliche und Unbeachtete das erste Mal meine Aufmerksamkeit als Sicherheitsstratege erregte. James war der Autor von einigen der interessantesten Sicherheits-Bug-Reports. Das war durchaus eine Leistung, wenn man bedenkt, dass das MSRC pro Jahr über 200 000 Sicherheits-Bug-Reports von Sicherheitsforschern erhielt. James fand nicht einfach irgendwelche Bugs – er hatte sich das .NET-Framework angesehen und Probleme auf Architekturebene erkannt. Auch wenn diese Bugs auf Architekturebene mit einem einfachen Patch wesentlich schwieriger zu lösen waren, so waren sie doch für Microsoft und seine Kunden sehr wertvoll.

Kommen wir gleich zu Microsofts erstem Bug-Prämien-Programm, das ich im Unternehmen im Juni 2013 einführte. Bei diesem ersten Paket von Bug-Prämien gab es drei Programme. Diese Programme versprachen Sicherheitsforschern wie James Geld für die Meldung schwerwiegender Bugs an Microsoft. Ich wusste, dass qualitativ hochwertige Sicherheits-Bugs eingereicht werden mussten, um die Effizienz des Programms nachzuweisen.

Als wir es auflegten, gab es keine Garantie, dass die Bug-Sucher zu uns kommen würden. Wir wussten, dass wir um einige der höchstqualifizierten Bug-Jäger auf der Welt konkurrierten. Es gab zahlreiche andere Geldprämienprogramme und nicht alle Marktplätze für Bugs dienten der Verteidigung. Nationalstaaten und Kriminelle betrieben etablierte, auf Angriffe ausgerichtete Märkte für Bugs und Exploits, und Microsoft war auf diejenigen Bug-Sucher angewiesen, die kostenlos über 200 000 Bug-Reports pro Jahr einreichten. Die Prämien sollten die Aufmerksamkeit dieser netten, altruistischen Bug-Jäger auf die Probleme richten, bei deren Lösung Microsoft die meiste Hilfe benötigte.

Also rief ich James und eine Handvoll anderer Leute an, weil ich darauf zählte, dass sie die fehlerbehafteten Produkte aufspüren würden. Bei diesen ersten Microsoft Bug-Prämien wünschten wir Sicherheitsknechte am MSRC uns das Aufdecken von Sicherheitslücken für den Internet Explorer (IE) 11 Beta, und wir wollten etwas, wofür ein Softwarehersteller noch nie eine Bug-Prämie ausgelobt hatte: Wir wollten Informationen über neue Exploit-Techniken erfahren. Diese Fangprämie war als »Mitigation Bypass Bounty« bekannt und damals 100 000 Dollar wert.

Ich erinnere mich daran, wie ich mit James in London bei einem Bier zusammensaß und ihn zu überzeugen versuchte, nach IE-Bugs zu suchen. Er erklärte mir, dass er sich noch nie mit der Sicherheit von Browsern beschäftigt hatte und dass ich nicht zu viel von ihm erwarten sollte.

Dennoch reichte James vier verschiedene Sandbox-Escapes für IE 11 Beta ein.

Vier!

Diese Sandbox-Escapes lagen alle in Bereichen des IE-Codes, die unsere internen Teams und externen, privaten Pentester übersehen hatten. Mithilfe von Sandbox-Escapes können andere Bugs zuverlässiger ausgenutzt werden. James erhielt vom IE-Team selbst Prämien für alle vier Bugs sowie einen zusätzlichen Bonus von 5 000 Dollar aus meinem Prämienbudget. Zurückblickend hätte ich ihm wohl 50 000 Dollar geben sollen. Wow, nicht schlecht für jemanden, der sich vorher noch nie mit der Sicherheit von Webbrowsern beschäftigt hatte.

Nur einige Monate später stand ich vor einer Microsoft-Cafeteria und rief völlig atemlos James an einem stürmischen Herbsttag an, um ihm zu berichten, dass er gerade Geschichte geschrieben hatte. Ich konnte es gar nicht abwarten, ihm zu erzählen, dass sein Beitrag für eines der anderen Bug-Prämien-Programme von Microsoft – das Mitigation Bypass Bounty für 100 000 Dollar – akzeptiert worden war. James Forshaw hatte eine neuartige Möglichkeit gefunden, alle Plattform-Verteidigungslinien zu umgehen, indem er architektonische Sicherheitslücken des neuesten Betriebssystems ausnutzte. Er gewann damit die allererste 100 000-Dollar-Prämie von Microsoft.

Soweit ich mich erinnere, stellte er sich bei diesem Telefongespräch vor, wie ich ihm bei der Microsoft-internen BlueHat-Konferenz auf der Bühne einen witzigen, riesigen Scheck überreiche. Ich schickte nach dem Telefonat eine Notiz an die Marketingabteilung und im Handumdrehen wurde »James und der Riesenscheck« für immer Teil der Microsoft- und Internet-Geschichte.

Ich bin mir sicher, dass der Leser aus den folgenden Seiten einen Teil von James’ unvergleichlicher Brillanz mitnehmen kann – die gleiche Brillanz, die ich vor vielen Jahren in einem Bug-Report (oder vier) sah. Es gibt nur wenige Sicherheitsforscher, die Bugs in einer fortgeschrittenen Technologie finden können, und noch weniger, die sie durchgängig in mehr als einer finden. Und dann gibt es Menschen wie James Forshaw, die sich mit der Präzision eines Chirurgen auf tieferliegende architektonische Aspekte konzentrieren. Ich hoffe, dass die Leser dieses Buches (und aller Bücher, die James noch schreiben wird) es als Praxisleitfaden nutzen, um die gleiche Brillanz und Kreativität in ihrer eigenen Arbeit zu erzielen.

In einem Bug-Prämien-Meeting bei Microsoft, wo die Mitglieder des IE-Teams den Kopf schüttelten und sich fragten, wie sie einige von James gemeldeten Bugs hatten übersehen können, erklärte ich einfach: »James kann die Frau in Rot sehen sowie den Code, der sie in der Matrix gerendert hat.« Alle am Tisch akzeptierten diese Erklärung für den in James arbeitenden Geist. Er kann so ziemlich jeden Löffel verbiegen und wenn Sie seine Arbeit studieren (und einen offenen Geist haben), können Sie das vielleicht auch.

Für alle Bug-Jäger auf der Welt liegt hier die Messlatte und sie ist hoch. Und all den ungenannten Sicherheitsknechten auf der ganzen Welt wünsche ich, dass ihre Bug-Reports ebenso interessant und wertvoll sind wie die von James Forshaw.

Katie MoussourisGründerin und CEO, Luta SecurityOktober 2017

Danksagungen

Vielen Dank, dass Sie dieses Buch lesen. Ich hoffe, Sie finden es aufschlussreich und von praktischem Nutzen. Viele verschiedene Menschen haben dazu beigetragen, worüber ich dankbar bin.

Ich muss mit einem Dank an meine Frau Huayi beginnen, die dafür sorgte, dass ich beim Schreiben blieb, auch wenn ich es nicht wollte. Dank ihrer Unterstützung ist es in nur vier Jahren fertig geworden. Ohne sie hätte ich es vielleicht in zwei Jahren schaffen können, doch es hätte nicht so viel Spaß gemacht.

Natürlich wäre ich ohne meine wunderbaren Eltern heute nicht hier. Ihre Liebe und Unterstützung hat dazu geführt, dass ich ein weithin anerkannter Sicherheitsforscher und Autor bin. Als ich jung war, kauften sie für die Familie einen Computer – einen Atari 400 –, und sie waren es, die mein Interesse für Computer und die Softwareentwicklung geweckt haben. Ich kann ihnen nicht genug dafür danken, mir all diese Möglichkeiten gegeben zu haben.

Der große Kontrapunkt zu meinem Leben als Computer-Nerd war mein ältester Freund Sam Shearon. Er war immer der Selbstbewusstere und Kontaktfreudigere und darüber hinaus ein begnadeter Künstler, der mir eine andere Seite des Lebens zeigte.

Im Verlauf meiner Karriere gab es viele Kollegen und Freunde, die wesentlich zu meinen Erfolgen beigetragen haben. Unter ihnen muss ich Richard Neal hervorheben, einen guten Freund und manchmal Vorgesetzten, der mir die Gelegenheit gab, mich für Computersicherheit zu interessieren. Die erforderlichen Fähigkeiten kamen meiner Mentalität entgegen.

Ich darf auch Mike Jordon nicht vergessen, der mich überzeugte, für Context Information Security in Großbritannien zu arbeiten. Zusammen mit den Inhabern Alex Church und Mark Raeburn gab er mir die Zeit, eindrucksvolle Sicherheitsforschung zu betreiben, mein Wissen um die Analyse von Netzwerkprotokollen zu erweitern und Werkzeuge wie Canape zu entwickeln. Diese Erfahrung, reale und üblicherweise vollständig maßgeschneiderte Netzwerkprotokolle anzugreifen, bildet den größten Teil des Inhalts dieses Buches.

Ich muss Katie Moussouris danken, die mich überredet hat, am Microsoft Mitigation Bypass Bounty teilzunehmen, was mein Ansehen in der Welt der Informationssicherheit deutlich steigerte und mir für meine Mühen auch einen Scheck über 100 000 Dollar einbrachte.

Mein gestiegenes Ansehen war auch von Nutzen, als das Team für Google Project Zero – eine Gruppe weltweit führender Sicherheitsforscher mit dem Ziel, die Plattformen, von denen wir alle abhängig sind, sicherer zu machen – aufgebaut wurde. Will Harris erwähnte meinen Namen gegenüber Chris Evans, dem aktuellen Chef des Teams, der mich zu einem Interview einlud, und plötzlich war ich ein Googler. Mitglied eines solch exzellenten Teams zu sein macht mich stolz.

Zum Schluss muss ich Bill, Laurel und Liz von No Starch Press danken, die die Geduld hatten, mich dieses Buch fertig schreiben zu lassen, und mir Ratschläge gaben, wie ich es angehen sollte. Ich hoffe, dass sie – und die Leser – mit dem Ergebnis zufrieden sind.

Einführung

Bei ihrer Einführung stand die Technik, die es Geräten erlaubte, sich zu einem Netzwerk zu verbinden, nur großen Unternehmen und Regierungen zur Verfügung. Heutzutage tragen die meisten Menschen ein voll vernetztes Gerät mit sich herum und mit dem Aufkommen des Internets der Dinge (Internet of Things, IoT) können Sie Ihren Kühlschrank und die heimische Alarmanlage an diese vernetzte Welt anbinden. Die Sicherheit dieser vernetzten Geräte wird daher immer wichtiger. Möglicherweise kümmert es Sie nicht sonderlich, wenn jemand weiß, welchen Joghurt Sie kaufen, doch wenn Ihr Smartphone über das gleiche Netzwerk wie Ihr Kühlschrank kompromittiert wird, könnten all Ihre persönlichen und finanziellen Daten in die Hände böser Hacker gelangen.

Dieses Buch heißt Netzwerkprotokolle hacken, weil Sie sich in die Gedankenwelt eines Angreifers hineinversetzen müssen, um Sicherheitslücken bei einem vernetzten Gerät aufzuspüren. Netzwerkprotokolle kommunizieren mit anderen Geräten über ein (öffentliches) Netzwerk. Sie durchlaufen häufig nicht die Prüfungen wie die anderen Komponenten des Gerätes und sind daher ein nahe liegendes Angriffsziel.

Warum sollten Sie dieses Buch lesen?

Viele Bücher behandeln das Erfassen (Capturing) von Netzwerkverkehr für Diagnosezwecke und eine grundlegende Netzwerkanalyse, kümmern sich aber nicht um die Sicherheitsaspekte der abgefangenen Protokolle. Im Gegensatz dazu konzentriert sich dieses Buch darauf, Protokolle auf ihre Sicherheitslücken hin zu analysieren.

Dieses Buch richtet sich an alle, die Netzwerkprotokolle analysieren und angreifen wollen, aber nicht wissen, wo sie anfangen sollen. Die Kapitel vermitteln Ihnen Techniken zum Erfassen von Netzwerkverkehr, zur Analyse der Protokolle und zur Aufdeckung und dem Exploit von Sicherheitslücken. Das Buch bietet Hintergrundinformationen zur Vernetzung und zur Sicherheit von Netzwerken, aber auch praktische Beispiel für zu analysierende Protokolle.

Ob Sie nun Netzwerkprotokolle angreifen wollen, um Sicherheitslücken an den Hersteller einer Anwendung zu melden, oder ob Sie nur wissen wollen, wie Ihr neuestes IoT-Gerät kommuniziert, Sie werden verschiedene interessante Themen entdecken.

Was finden Sie in diesem Buch?

Dieses Buch umfasst eine Mischung aus theoretischen und praktischen Kapiteln. Für die praktischen Kapitel habe ich eine Netzwerkbibliothek namens Canape Core entwickelt und zur Verfügung gestellt, mit der Sie eigene Tools zur Protokollanalyse und für Exploits schreiben können. Ich stelle auch eine beispielhafte Netzwerkanwendung namens SuperFunkyChat bereit, die ein benutzerdefiniertes Chat-Protokoll implementiert. Während Sie der Diskussion in den Kapiteln folgen, können Sie die Beispielanwendung nutzen, um die Protokollanalyse zu erlernen und die Beispielprotokolle anzugreifen. Hier eine kurze Beschreibung der jeweiligen Kapitel:

Kapitel 1

:

Netzwerk-Grundlagen

Dieses Kapitel erläutert die Grundlagen der Vernetzung von Computern, wobei es sich auf TCP/IP konzentriert, das die Basis anwendungsspezifischer Netzwerkprotokolle bildet. Die nachfolgenden Kapitel gehen davon aus, dass Sie die Grundlagen der Vernetzung beherrschen. Dieses Kapitel stellt auch den Ansatz vor, den ich zur Modellierung von Anwendungsprotokollen verwende. Dieses Modell teilt das Anwendungsprotokoll in flexible Schichten auf und abstrahiert komplexe technische Details. Auf diese Weise können wir uns auf bestimmte Teile des zu analysierenden Protokolls konzentrieren.

Kapitel 2

:

Capturing von Anwendungsverkehr

Dieses Kapitel führt in die Konzepte des passiven und aktiven Capturings von Netzwerkverkehr ein. Es ist das erste Kapitel, das die Canape-Core-Bibliotheken für praktische Aufgaben nutzt.

Kapitel 3

:

Strukturen von Netzwerk-Protokollen

Dieses Kapitel erläutert interne Strukturen, die bei Netzwerkprotokollen üblich sind, etwa die Repräsentation von Zahlen oder lesbarem Text. Bei der Analyse von Netzwerkverkehr können Sie dieses Wissen nutzen, um gängige Strukturen schnell zu identifizieren, und so die Analyse beschleunigen.

Kapitel 4

:

Fortgeschrittenes Capturing von Anwendungsverkehr

Dieses Kapitel untersucht eine Reihe fortgeschrittener Capturing-Techniken, die die Beispiele aus Kapitel 2 ergänzen. Zu diesen Techniken gehören etwa die »Network Address Translation« zur Umleitung von Verkehr und das Spoofing von ARP.

Kapitel 5

:

Analyse auf der Datenleitung

Dieses Kapitel stellt Methoden zur Analyse des aufgezeichneten Netzwerkverkehrs vor und nutzt dabei die in Kapitel 2 erläuterten passiven und aktiven Techniken. In diesem Kapitel lassen wir die SuperFunkyChat-Anwendung erstmals Beispielverkehr erzeugen.

Kapitel 6

:

Reverse Engineering einer Anwendung

In diesem Kapitel werden Techniken zum Reverse Engineering von Netzwerkprogrammen erläutert. Reverse Engineering erlaubt die Analyse eines Protokolls, ohne dass Sie dazu Beispielverkehr benötigen. Diese Methoden helfen auch dabei, die verwendete Verschlüsselungs- oder Verschleierungstechnik zu identifizieren, sodass sich der aufgezeichnete Verkehr besser analysieren lässt.

Kapitel 7

:

Sicherheit von Netzwerkprotokollen

Dieses Kapitel versorgt Sie mit Hintergrundinformationen zu Techniken und kryptografischen Algorithmen, die zur Absicherung von Netzwerkprotokollen verwendet werden. Der Schutz der über öffentliche Netzwerke laufenden Daten vor Enthüllung oder Veränderung ist für die Sicherheit des Netzwerkprotokolls von höchster Bedeutung.

Kapitel 8

:

Implementierung des Netzwerkprotokolls

Dieses Kapitel erläutert Techniken zur Implementierung des Anwendungsprotokolls in selbst entwickeltem Code. Auf diese Weise können Sie das Verhalten des Protokolls testen und Sicherheitslücken aufspüren.

Kapitel 9

:

Die Hauptursachen für Sicherheitslücken

Dieses Kapitel zeigt gängige Sicherheitslücken auf, denen Sie bei einem Netzwerkprotokoll begegnen werden. Wenn Sie die Hauptursachen für Sicherheitslücken kennen, können Sie diese während der Analyse einfacher identifizieren.

Kapitel 10

:

Sicherheitslücken aufspüren und ausnutzen

Dieses Kapitel beschreibt den Prozess der Aufspürens von Sicherheitslücken anhand der Hauptursachen aus Kapitel 9 und demonstriert eine Reihe von Möglichkeiten, wie Sie das ausnutzen können. Dazu entwickeln wir eigenen Shell-Code und umgehen möglicherweise getroffene Gegenmaßnahmen durch »Return-Oriented Programming«.

Anhang A

:

Toolkit für die Netzwerkprotokoll-Analyse

In diesem Anhang finden Sie die Beschreibung einiger der Tools, die ich zur Protokollanalyse häufig einsetze. Viele dieser Tools werden auch im Text angesprochen.

Wie Sie dieses Buch nutzen

Wenn Sie Ihr Grundlagenwissen in Sachen Vernetzung auffrischen wollen, lesen Sie zuerst Kapitel 1. Wenn Sie mit den Grundlagen vertraut sind, können Sie mit den Kapiteln 2 und 3 weitermachen sowie in Kapitel 5 praktische Erfahrungen mit dem Aufzeichnen von Netzwerkverkehr und dem Analyseprozess sammeln.

Mit dem Wissen um die Grundlagen des Erfassens und der Analyse können Sie mit den Kapiteln 7 bis 10 weitermachen. Darin finden Sie praxisorientierte Hinweise, wie man Sicherheitslücken dieser Protokolle aufspürt und ausnutzt. Die Kapitel 4 und 6 enthalten weiterführende Informationen zu zusätzlichen Capturing-Techniken und dem Reverse Engineering von Anwendungen. Wenn Sie wollen, können Sie diese lesen, nachdem Sie die anderen Kapitel durchgelesen haben.

Für die praktischen Beispiele müssen Sie .NET Core (https://www.microsoft.com/net/core/) installieren. Das ist die plattformübergreifende Version der .NET-Runtime von Microsoft, die unter Windows, Linux und macOS läuft. Sie können Versionen von Canape Core über https://github.com/tyranid/CANAPE.Core/releases/ und SuperFunkyChat über https://github.com/tyranid/Example-ChatApplication/releases/ herunterladen. Beide nutzen .NET Core als Runtime. Links zu diesen Websites finden Sie in den Ressourcen zu diesem Buch auf https://www.dpunkt.de/netze_hacken.

Um die Canape-Core-Beispielskripten auszuführen, müssen Sie CANAPE.Cli nutzen, das im Releasepaket enthalten ist, das Sie aus dem Github-Repository zu Canape Core heruntergeladen haben. Führen Sie das Skript mit der folgenden Kommandozeile aus und ersetzen Sie dabei script.csx durch den Namen des Skripts, das Sie ausführen wollen.

dotnet exec CANAPE.Cli.dll script.csx

Alle Beispiel-Listings aus den praktischen Kapiteln sowie die Paket-Captures (erfassten Pakete) stehen auf der Webseite zu diesem Buch unter https://www.dpunkt.de/netze_hacken zur Verfügung. Bevor Sie anfangen, sollten Sie sich diese Beispiele herunterladen, damit Sie den praktischen Kapiteln folgen können, ohne eine große Menge Quellcode von Hand eingeben zu müssen.

Kontakt

Ich bin immer an positivem wie negativem Feedback zu meiner Arbeit interessiert und dieses Buch bildet da keine Ausnahme. Sie erreichen mich per E-Mail unter [email protected].

Sie können mir auch auf Twitter unter @tiraniddo folgen oder meinen Blog unter https://tyranidslair.blogspot.com/ abonnieren, wo ich über meine neuesten Forschungen zur IT-Sicherheit schreibe.

Inhaltsverzeichnis

1Netzwerk-Grundlagen

1.1Netzwerkarchitekturen und -protokolle

1.2Die Internet-Protokoll-Suite

1.3Datenkapselung

1.3.1Header, Footer und Adressen

1.3.2Datenübertragung

1.4Netzwerk-Routing

1.5Mein Modell für die Analyse von Netzwerkprotokollen

1.6Am Ende dieses Kapitels

2Capturing von Anwendungsverkehr

2.1Passives Capturing von Netzwerkverkehr

2.2Eine kurze Einführung in Wireshark

2.3Alternative passive Capturing-Techniken

2.3.1Tracing von Systemaufrufen

2.3.2Das strace-Utility unter Linux

2.3.3Netzwerkverbindungen mit DTrace verfolgen

2.3.4Process Monitor unter Windows

2.4Vor- und Nachteile passiven Capturings

2.5Aktives Capturing von Netzwerkverkehr

2.6Netzwerk-Proxys

2.6.1Port-Forwarding-Proxy

2.6.2SOCKS-Proxy

2.6.3HTTP-Proxys

2.6.4Forwarding eines HTTP-Proxys

2.6.5HTTP-Reverse-Proxy

2.7Am Ende dieses Kapitels

3Strukturen von Netzwerk-Protokollen

3.1Binäre Protokollstrukturen

3.1.1Numerische Daten

3.1.2Boolesche Werte

3.1.3Bit-Flags

3.1.4Binäre Bytereihenfolge (Endianness)

3.1.5Text und menschenlesbare Daten

3.1.6Binärdaten variabler Länge

3.2Datum und Uhrzeit

3.2.1POSIX/Unix-Zeit

3.2.2Windows FILETIME

3.3TLV-Muster

3.4Multiplexing und Fragmentierung

3.5Netzwerk-Adressinformationen

3.6Strukturierte Binärformate

3.7Strukturen textbasierter Protokolle

3.7.1Numerische Daten

3.7.2Boolesche Werte in Textform

3.7.3Datum und Uhrzeit

3.7.4Daten variabler Länge

3.7.5Formate für strukturierten Text

3.8Codierung binärer Daten

3.8.1Hex-Codierung

3.8.2Base64

3.9Am Ende dieses Kapitels

4Fortgeschrittenes Capturing von Anwendungsverkehr

4.1Rerouting von Verkehr

4.1.1Traceroute nutzen

4.1.2Routing-Tabellen

4.2Konfiguration eines Routers

4.2.1Routing unter Windows aktivieren

4.2.2Routing unter *nix aktivieren

4.3Network Address Translation

4.3.1SNAT aktivieren

4.3.2SNAT unter Linux konfigurieren

4.3.3DNAT aktivieren

4.4Verkehr an ein Gateway weiterleiten

4.4.1DHCP-Spoofing

4.4.2ARP-Poisoning

4.5Am Ende dieses Kapitels

5Analyse auf der Datenleitung

5.1Die Verkehr produzierende Anwendung: SuperFunkyChat

5.1.1Den Server starten

5.1.2Clients starten

5.1.3Kommunikation zwischen Clients

5.2Ein Crashkurs zur Analyse mit Wireshark

5.2.1Netzwerkverkehr generieren und Pakete erfassen

5.2.2Grundlegende Analyse

5.2.3Inhalte einer TCP-Session lesen

5.3Die Paketstruktur mit Hex Dump identifizieren

5.3.1Einzelne Pakete betrachten

5.3.2Die Protokollstruktur ermitteln

5.3.3Unsere Annahmen überprüfen

5.3.4Das Protokoll mit Python sezieren

5.4Einen Wireshark-Dissector in Lua entwickeln

5.4.1Den Dissector entwickeln

5.4.2Sezieren mit Lua

5.4.3Parsen eines Nachrichtenpakets

5.5Einen Proxy zur aktiven Verkehrsanalyse nutzen

5.5.1Den Proxy einrichten

5.5.2Protokollanalyse mittels Proxy

5.5.3Grundlegendes Parsen von Protokollen hinzufügen

5.5.4Das Protokollverhalten ändern

5.6Am Ende dieses Kapitels

6Reverse Engineering einer Anwendung

6.1Compiler, Interpreter und Assembler

6.1.1Interpretierte Sprachen

6.1.2Kompilierte Sprachen

6.1.3Statisches und dynamisches Linking

6.2Die x86-Architektur

6.2.1Instruction Set Architecture

6.2.2CPU-Register

6.2.3Ablaufsteuerung

6.3Betriebssystem-Grundlagen

6.3.1Dateiformate für Executables

6.3.2Abschnitte

6.3.3Prozesse und Threads

6.3.4Netzwerkschnittstelle des Betriebssystems

6.3.5Application Binary Interface

6.4Statisches Reverse Engineering

6.4.1Kurzanleitung für die Nutzung der IDA Pro Free Edition

6.4.2Stackvariablen und Argumente analysieren

6.4.3Schlüsselfunktionalitäten identifizieren

6.5Dynamisches Reverse Engineering

6.5.1Breakpunkte setzen

6.5.2Debugger-Fenster

6.5.3Wo setzt man Breakpunkte?

6.6Reverse Engineering von Managed Code

6.6.1.NET-Anwendungen

6.6.2ILSpy nutzen

6.6.3Java-Anwendungen

6.6.4Mit Verschleierungstaktiken umgehen

6.7Reverse-Engineering-Ressourcen

6.8Am Ende dieses Kapitels

7Sicherheit von Netzwerkprotokollen

7.1Verschlüsselungsalgorithmen

7.1.1Substitutionschiffre

7.1.2XOR-Verschlüsselung

7.2Zufallszahlengeneratoren

7.3Symmetrische Verschlüsselung

7.3.1Blockchiffre

7.3.2Blockchiffre-Modi

7.3.3Blockchiffre-Padding

7.3.4Padding Oracle Attack

7.3.5Stromchiffre

7.4Asymmetrische Verschlüsselung

7.4.1RSA-Algorithmus

7.4.2RSA-Padding

7.4.3Schlüsselaustausch nach Diffie-Hellman

7.5Signaturalgorithmen

7.5.1Kryptografische Hash-Algorithmen

7.5.2Asymmetrische Signaturalgorithmen

7.5.3Message Authentication Codes

7.6Public-Key-Infrastruktur

7.6.1X.509-Zertifikate

7.6.2Verifikation einer Zertifikatskette

7.7Fallbeispiel: Transport Layer Security

7.7.1Der TLS-Handshake

7.7.2Initiale Aushandlungen

7.7.3Endpunkt-Authentifizierung

7.7.4Die Verschlüsselung aufbauen

7.7.5Sicherheitsanforderungen erfüllen

7.8Am Ende dieses Kapitels

8Implementierung des Netzwerkprotokolls

8.1Replay von erfasstem Netzwerkverkehr

8.1.1Verkehr mit Netcat erfassen

8.1.2Replay von UDP-Verkehr mittels Python

8.1.3Unseren Analyse-Proxy wiederverwenden

8.2Ausführbaren Code wiederverwenden

8.2.1Code in .NET-Anwendungen wiederverwenden

8.2.2Code in Java-Anwendungen wiederverwenden

8.2.3Unmanaged Executables

8.3Verschlüsselung und der Umgang mit TLS

8.3.1Die verwendete Verschlüsselung ermitteln

8.3.2TLS-Verkehr entschlüsseln

8.4Am Ende dieses Kapitels

9Die Hauptursachen für Sicherheitslücken

9.1Vulnerabilitätsklassen

9.1.1Remote Code Execution

9.1.2Denial-of-Service

9.1.3Offenlegung von Informationen

9.1.4Authentifizierung umgehen

9.1.5Autorisierung umgehen

9.2Verfälschung des Speichers

9.2.1Speichersichere und speicherunsichere Programmiersprachen

9.2.2Pufferüberlauf

9.2.3Out-of-Bounds-Indexierung

9.2.4Datenexpansion

9.2.5Fehler bei der dynamischen Speicherallozierung

9.3Voreingestellte oder festcodierte Anmeldedaten

9.4Offenlegung von Benutzernamen

9.5Fehlerhafter Zugriff auf Ressourcen

9.5.1Kanonisierung

9.5.2Fehlermeldungen mit zu viel Information

9.6Speicherüberlastung

9.7Massenspeicherüberlastung

9.8CPU-Überlastung

9.8.1Algorithmische Komplexität

9.8.2Konfigurierbare Kryptografie

9.9Formatstrings

9.10Befehlsinjektion

9.11SQL-Injektion

9.12Zeichenersetzung bei Textcodierung

9.13Am Ende dieses Kapitels

10Sicherheitslücken aufspüren und ausnutzen

10.1Fuzzing

10.1.1Der einfachste Fuzzing-Test

10.1.2Mutations-Fuzzer

10.1.3Testdatensätze generieren

10.2Sicherheitslücken untersuchen

10.2.1Debugging von Anwendungen

10.2.2Die Chancen erhöhen, um die Hauptursache für einen Absturz zu ermitteln

10.3Gängige Sicherheitslücken ausnutzen

10.3.1Exploit von Speicherlücken

10.3.2Willkürliche Schreiboperationen

10.4Shell-Code entwickeln

10.4.1Erste Schritte

10.4.2Einfache Debugging-Technik

10.4.3Systemaufrufe ausführen

10.4.4Andere Programme ausführen

10.4.5Shell-Code mit Metasploit generieren

10.5Maßnahmen gegen Speicherlücken

10.5.1Data Execution Prevention

10.5.2Return-Oriented Programming

10.5.3Address Space Layout Randomization (ASLR)

10.5.4Stacküberläufe durch Canaries erkennen

10.6Am Ende dieses Kapitels

Anhang

AToolkit für die Netzwerkprotokoll-Analyse

A.1Tools zum passiven Capturing und zur Analyse von Netzwerkprotokollen

A.1.1Microsoft Message Analyzer

A.1.2TCPDump und LibPCAP

A.1.3Wireshark

A.2Aktives Netzwerk-Capturing und Analyse

A.2.1Canape

A.2.2Canape Core

A.2.3Mallory

A.3Netzwerkkonnektivität und Protokolltests

A.3.1Hping

A.3.2Netcat

A.3.3Nmap

A.4Webanwendungen testen

A.4.1Burp Suite

A.4.2Zed Attack Proxy (ZAP)

A.4.3Mitmproxy

A.5Frameworks zum Fuzzing, zur Paketgenerierung und zur Entwicklung von Exploits

A.5.1American Fuzzy Lop (AFL)

A.5.2Kali Linux

A.5.3Metasploit-Framework

A.5.4Scapy

A.5.5Sulley

A.6Netzwerk-Spoofing und -Umleitung

A.6.1DNSMasq

A.6.2Ettercap

A.7Reverse Engineering von Executables

A.7.1Java Decompiler (JD)

A.7.2IDA Pro

A.7.3Hopper

A.7.4ILSpy

A.7.5.NET Reflector

Index

1

Netzwerk-Grundlagen

Um Netzwerkprotokolle angreifen zu können, müssen Sie die Grundlagen der Vernetzung von Computern kennen. Je besser Sie verstehen, wie gängige Netzwerke aufgebaut sind und funktionieren, desto einfacher können Sie dieses Wissen nutzen, um neue Protokolle zu erfassen, zu analysieren und auszunutzen.

Im Verlauf dieses Kapitels werde ich grundlegende Konzepte vorstellen, die Ihnen bei der Analyse von Netzwerkprotokollen tagtäglich begegnen. Außerdem schaffe ich auch die Voraussetzung für eine bestimmte Art des Denkens über Netzwerkprotokolle, die es einfacher macht, bisher unbekannte Sicherheitslücken während der Analyse zu entdecken.

1.1Netzwerkarchitekturen und -protokolle

Wir wollen zuerst einige grundlegende Netzwerkbegriffe besprechen und uns die fundamentale Frage stellen: Was ist ein Netzwerk? EinNetzwerk ist eine Gruppe von zwei oder mehr Computern, die miteinander verbunden sind, um Informationen zu teilen. Jedes mit dem Netzwerk verbundene Gerät wird gewöhnlich als Knoten (engl. Node) bezeichnet, um die Beschreibung auf eine größere Palette von Geräten anwenden zu können. Abbildung 1–1 zeigt ein sehr einfaches Beispiel.

Abb. 1–1Einfaches Netzwerk mit drei Knoten

Die Abbildung zeigt drei Knoten, die über ein gängiges Netzwerk miteinander verbunden sind. Jeder Knoten kann ein anderes Betriebssystem oder eine andere Hardware verwenden. Doch solange jeder Knoten einer Reihe von Regeln folgt, dem Netzwerkprotokoll, können sie mit jedem anderen Knoten des Netzwerks kommunizieren. Um sauber miteinander kommunizieren zu können, müssen alle Knoten im Netzwerk das gleiche Netzwerkprotokoll verstehen.

Ein Netzwerkprotokoll übernimmt viele Funktionen, dazu gehören eine oder mehrere der folgenden:

Verwaltung des Sessionzustands

Protokolle implementieren typischerweise Mechanismen, mit denen neue Verbindungen aufgebaut und vorhandene Verbindungen beendet werden können.

Identifizierung von Knoten durch Adressierung

Daten müssen im Netzwerk an den richtigen Knoten übertragen werden. Einige Protokolle implementieren einen Adressierungsmechanismus, um bestimmte Knoten oder Gruppen von Knoten zu identifizieren.

Flusssteuerung

Die Menge der über ein Netzwerk übertragenen Daten ist beschränkt. Protokolle können Wege zur Verwaltung des Datenflusses implementieren, um den Durchsatz zu erhöhen und die Latenz zu reduzieren.

Garantierte Reihenfolge der übertragenen Daten

Viele Netzwerke garantieren nicht, dass die Reihenfolge, in der die Daten gesendet werden, auch der Reihenfolge entspricht, in der sie eingehen. Ein Protokoll kann die Daten neu ordnen, um die Zustellung in der richtigen Reihenfolge sicherzustellen.

Erkennung und Korrektur von Fehlern

Viele Netzwerke sind nicht zu 100 Prozent zuverlässig, d. h., Daten können beschädigt werden. Es ist wichtig, Beschädigungen zu erkennen und (idealerweise) zu beheben.

Formatierung und Codierung von Daten

Daten liegen nicht immer in einem Format vor, das für die Übertragung in einem Netzwerk geeignet ist. Ein Protokoll kann Regeln zur Codierung von Daten festlegen, etwa die Codierung von Text in Binärdaten.

1.2Die Internet-Protokoll-Suite

TCP/IP ist der von modernen Netzwerken verwendete De-facto-Protokollstandard. Obwohl Sie sich TCP/IP als ein Protokoll vorstellen können, ist es tatsächlich die Kombination von zwei Protokollen: dem Transmission Control Protocol (TCP) und dem Internet Protocol (IP). Diese beiden Protokolle sind Teil der Internet Protocol Suite (IPS), eines konzeptionellen Modells, das angibt, wie Netzwerkprotokolle Daten über das Internet senden. Es teilt die Netzwerkkomunikation, wie in Abbildung 1–2 zu sehen, in vier Schichten (Layer) auf.

Abb. 1–2Schichten der Internet-Protokoll-Suite

Diese vier Schichten bilden einen Protokollstack. Die folgende Liste erläutert jede Schicht der IPS:

Netzzugangsschicht (Layer 1)

Diese Schicht liegt auf der untersten Ebene und beschreibt die physikalischen Mechanismen, mit denen Informationen zwischen den Knoten eines lokalen Netzwerks übertragen werden. Bekannte Beispiele sind Ethernet (kabelgebunden und drahtlos) und das Point-to-Point-Protokoll (PPP).

Internetschicht (Layer 2)

Diese Schicht stellt die Mechanismen zur Adressiung der Netzwerkknoten bereit. Im Gegensatz zur Netzzugangsschicht müssen die Knoten nicht im gleichen Netzwerk liegen. Diese Schicht enthält das IP. In modernen Netzwerken kann das verwendete Protokoll die Version 4 (IPv4) oder die Version 6 (IPv6) sein.

Transportschicht (Layer 3)

Diese Schicht ist für die Verbindungen zwischen Clients und Servern verantwortlich. Manchmal stellt sie auch die korrekte Reihenfolge der Pakete sicher oder bietet das Multiplexing von Diensten an. Das Multiplexing von Diensten erlaubt es einem einzelnen Knoten, unterschiedliche Dienste zu unterstützen, indem jedem Service eine andere Nummer zugewiesen wird. Diese Nummer wird als Port bezeichnet. TCP und UDP (User Datagram Protocol) arbeiten auf dieser Schicht.

Anwendungsschicht (Layer 4)

Auf dieser Schicht sind Netzwerkprotokolle wie das HyperText Transport Protocol (HTTP, zur Übertragung von Webseiten), das Simple Mail Transport Protocol (SMTP, zur Übertragung von E-Mails) und das Domain Name System (DNS, zur Umwandlung von Namen in Adressen) angesiedelt. In diesem Buch konzentrieren wir uns hauptsächlich auf diese Schicht.

Jede Schicht interagiert nur mit der direkt über oder unter ihr liegenden Schicht, doch es muss auch externe Interaktionen mit dem Stack geben. Abbildung 1–2 zeigt zwei externe Verbindungen. Die Netzzugangsschicht interagiert mit einer physikalischen Netzwerkverbindung und überträgt Daten in ein physikalisches Medium wie Strom- oder Lichtimpulse. Die Anwendungsschicht interagiert mit der Anwendung: Eine Anwendung ist eine Sammlung zusammengehöriger Funktionalitäten, die dem Benutzer einen Dienst zur Verfügung stellen. Abbildung 1–3 zeigt beispielhaft eine Anwendung zur Verarbeitung von E-Mails. Der Dienst, der von der E-Mail-Anwendung angeboten wird, ist das Senden und Empfangen von Nachrichten über ein Netzwerk.

Abb. 1–3Beispielhafte E-Mail-Anwendung

Typischerweise umfassen Anwendungen die folgenden Komponenten:

Netzwerkkommunikation

Diese Komponente kommuniziert über das Netzwerk und verarbeitet ein- und ausgehende Daten. Bei einer E-Mail-Anwendung läuft die Netzwerkkommunikation meist über ein Standardprotokoll wie SMTP oder POP3.

Parsen der Inhalte

Über ein Netzwerk transferierte Daten müssen üblicherweise extrahiert und verarbeitet werden (Parsen). Bei den Inhalten kann es sich um Textdaten (z. B. den Text der E-Mail), Bilder oder Videos handeln.

Benutzerschnittstelle

Die Benutzerschnittstelle (User Interface, kurz UI) erlaubt es dem Benutzer, empfangene E-Mails anzusehen und neue E-Mails zu verfassen bzw. zu senden. Bei einer E-Mail-Anwendung könnte die UI E-Mails mittels HTML in einem Webbrowser darstellen.

Beachten Sie, dass der Benutzer, der mit der UI interagiert, kein Mensch sein muss. Es kann sich auch um eine andere Anwendung handeln, die das Senden und Empfangen von E-Mails (z. B. über ein Kommandozeilen-Tool) automatisiert.

1.3Datenkapselung

Jede Schicht der IPS baut auf der darunterliegenden Schicht auf und jede Schicht ist in der Lage, Daten der darüberliegenden Schicht zu kapseln, sodass sie zwischen den Schichten bewegt werden können. Die von jeder Schicht übertragenen Daten werden Protocol Data Unit (PDU) genannt.

1.3.1Header, Footer und Adressen

Die PDU jeder Schicht enthält die zu übertragenden Nutzdaten. Üblicherweise stellt man den Nutzdaten einen Header voran, der für die Übertragung der Nutzdaten benötigte Informationen enthält, wie z. B. die Adressen der Quell- und Zielknoten. Manchmal besitzt eine PDU auch einen Footer, der an die Nutzdaten angehängt wird und Werte enthält, die eine korrekte Übertragung sicherstellen, etwa Prüfsummen. Abbildung 1–4 zeigt, wie die PDUs der IPS ausgelegt sind.

Abb. 1–4IPS-Datenkapselung

Der TCP-Header enthält den Quell- und Zielport . Diese Portnummern erlauben es einem einzelnen Knoten, mehrere Netzverbindungen aufzubauen. Die Portnummern für TCP (und UDP) reichen von 0 bis 65535. Die meisten Portnummern werden neuen Verbindungen nach Bedarf zugewiesen, doch einigen Nummern wurden bestimmte Dienste zugeordnet, wie etwa Port 80 für HTTP. (Eine aktuelle Liste der zugewiesenen Portnummern finden Sie bei den meisten unixoiden Betriebssystemen in der Datei /etc/services.) Die TCP-Nutzdaten und den Header nennt man üblicherweise ein Segment, während UDP-Nutzdaten und -Header als Datagramm bezeichnet werden.

Das IP-Protokoll verwendet eine Quell- und eine Zieladresse . Die Zieladresse erlaubt das Senden der Daten an einen bestimmten Knoten im Netzwerk. Über die Quelladresse weiß der Empfänger, welcher Knoten ihm Daten gesendet hat, was es ihm ermöglicht, dem Sender zu antworten.

IPv4 verwendet 32-Bit-Adressen, die üblicherweise als vier durch Punkte getrennte Zahlen wie z. B. 192.168.10.1 dargestellt werden. IPv6 nutzt 128-Bit-Adressen, weil 32-Bit-Adressen für die Anzahl der Knoten in modernen Netzwerken nicht mehr ausreichen. IPv6-Adressen werden üblicherweise als durch Doppelpunkte getrennte Hexadezimalzahlen wie z. B. fe80:0000:0000:0000:897b:581e: 44b0:2057 geschrieben. Lange Folgen von 0000-Werten werden durch zwei Doppelpunkte ersetzt, d. h., die obige IPv6-Adresse kann auch als fe80::897b:581e: 44b0:2057 geschrieben werden. IP-Nutzdaten und -Header werden üblicherweise als Paket (packet) bezeichnet.

Ethernet enthält ebenfalls Quell- und Zieladressen . Ethernet verwendet einen als MAC-Adresse (Media Access Control) bezeichneten 64-Bit-Wert, der normalerweise bei der Produktion des Ethernet-Adapters festgelegt wird. MAC-Adressen werden üblicherweise als Folge von durch Minuszeichen oder Doppelpunkte getrennten Hexadezimalzahlen wie 0A-00-27-00-00-0E dargestellt. Die Ethernet-Nutzdaten, zusammen mit dem Header und dem Footer, werden üblicherweise als Frame bezeichnet.

1.3.2 Datenübertragung

Sehen wir uns kurz an, wie beim IPS-Modell der Datenkapselung Daten von einem Knoten zum anderen übertragen werden. Abbildung 1–5 zeigt ein einfaches Ethernet-Netzwerk mit drei Knoten.

Abb. 1–5Einfaches Ethernet-Netzwerk

In diesem Beispiel möchte der Knoten mit der IP-Adresse 192.1.1.101 Daten per IP-Protokoll an den Knoten mit der IP-Adresse 192.1.1.50 senden. (Der Switch leitet Ethernet-Frames zwischen allen Netzwerkknoten weiter. (Der Switch benötigt keine IP-Adresse, da er nur auf der Netzzugangsschicht arbeitet.) Wenn Daten zwischen den beiden Knoten gesendet werden sollen, passiert Folgendes:

1. Der Netzwerkstack des Betriebssystems kapselt die Daten der Anwendungsund der Transportschicht und erzeugt ein IP-Paket mit der Quelladresse 192.1.1.101 und der Zieladresse 192.1.1.50.

2. An diesem Punkt kann das Betriebssystem die IP-Daten in einem Ethernet-Frame kapseln, kennt möglicherweise aber nicht die MAC-Adresse des Zielknotens. Es kann die MAC-Adresse für eine bestimmte IP-Adresse über das Address Resolution Protocol (ARP) anfordern, das einen Request an alle Knoten im Netzwerk sendet, um die MAC-Adresse für die IP-Adresse des Ziels zu ermitteln.

3. Sobald der Knoten an die ARP-Antwort erhält, kann er den Frame erzeugen, wobei die Quelladresse mit der lokalen MAC-Adresse 00-11-22-33-44-55 und die Zieladresse mit 66-77-88-99-AA-BB angegeben wird. Der neue Frame wird in das Netzwerk übertragen und vom Switch empfangen.

4. Der Switch leitet den Frame an den Zielknoten weiter, der das IP-Paket entpackt und prüft, ob die Ziel-IP-Adresse stimmt. Dann werden die IP-Nutzdaten entpackt und im Stack weitergeleitet, um von der wartenden Anwendung empfangen zu werden.

1.4Netzwerk-Routing

Ethernet verlangt, dass alle Knoten direkt mit dem gleichen Netzwerk verbunden sind. Diese Anforderung ist für ein wirklich globales Netzwerk eine wesentliche Einschränkung, da es praktisch unmöglich ist, physikalisch jeden Knoten mit jedem anderen Knoten zu verbinden. Statt also alle Knoten direkt miteinander verbinden zu müssen, erlauben es die Quell- und Zieladressen, dass Daten über verschiedene Netzwerke gerouted (weitergeleitet) werden, bis sie den gewünschten Zielknoten erreichen (siehe Abb. 1–6).

Abb. 1–6Routing zwischen zwei Ethernet-Netzwerken

Abbildung 1–6 zeigt zwei Ethernet-Netzwerke mit eigenen IP-Adressbereichen. Die folgende Beschreibung erklärt, wie das IP-Protokoll dieses Modell nutzt, um Daten von dem Knoten bei in Netzwerk 1 an den Knoten bei in Netzwerk 2 zu senden.

1. Der Netzwerkstack des Betriebssystems auf dem Knoten bei kapselt die Daten der Anwendungs- und Transportschicht und baut ein IP-Paket mit der Quelladresse 192.1.1.101 und der Zieladresse 200.0.1.50 auf.

2. Der Netzwerkstack muss einen Ethernet-Frame senden, da aber die IP-Zieladresse in keinem Ethernet-Netzwerk existiert, mit dem der Knoten verbunden ist, befragt der Netzwerkstack die

Routing-Tabelle

des Betriebssystems. In diesem Beispiel enthält die Routing-Tabelle einen Eintrag für die IP-Adresse 200.0.1.50. Dieser Eintrag zeigt an, dass der Router an IP-Adresse 192.1.1.1 weiß, wie man zu dieser Zieladresse gelangt.

3. Das Betriebssystem nutzt ARP, um die MAC-Adresse des Routers an 192.1.1.1 nachzuschlagen und das Original-IP-Paket wird im Ethernet-Frame mit dieser MAC-Adresse gekapselt.

4. Der Router empfängt den Ethernet-Frame und entpackt das IP-Paket. Wenn er die IP-Zieladresse prüft, erkennt er, dass dieses IP-Paket nicht für diesen Router, sondern für einen Knoten in einem anderen Netzwerk gedacht ist. Der Router schlägt die MAC-Adresse für 200.0.1.50 nach, kapselt das ursprüngliche IP-Paket in einem neuen Ethernet-Frame und sendet diesen an Netzwerk 2.

5. Der Zielknoten empfängt den Ethernet-Frame, entpackt das IP-Paket und verarbeitet dessen Inhalt.

Dieser Routing-Prozess kann sich mehrfach wiederholen. Ist der Router beispielsweise nicht direkt mit dem Netzwerk verbunden, das den Knoten 200.0.1.50 enthält, würde er seine eigene Routing-Tabelle konsultieren und den nächsten Router bestimmen, an den er das IP-Paket sendet.

Natürlich ist es praktisch nicht möglich, dass jeder Knoten im Netzwerk weiß, wie er zu jedem anderen Knoten im Internet gelangt. Wenn es für ein Ziel keinen expliziten Routing-Eintrag gibt, stellt die Routing-Tabelle einen Standardeintrag bereit, das sogenannte Default Gateway, der die IP-Adresse eines Routers enthält, der IP-Pakete an ihr Ziel weiterleiten kann.

1.5Mein Modell für die Analyse von Netzwerkprotokollen

Die IPS beschreibt, wie die Netzwerkkommunikation funktioniert. Für Analysezwecke ist ein Großteil des IPS-Modells aber nicht relevant. Es ist einfacher, mein Modell zu nutzen, um das Verhalten eines Anwendungsprotokolls zu verstehen. Mein Modell besteht aus drei Schichten. Abbildung 1–7 zeigt diese Schichten und verdeutlicht, wie ich einen HTTP-Request analysieren würde.

Hier die drei Schichten meines Modells:

Inhaltsschicht (Content Layer)

Gibt den »Sinn« dessen wieder, was kommuniziert wird. In Abbildung 1–7 besteht der Sinn darin, mit einem HTTP-Request die Datei image.jpg abzurufen.

Codierungsschicht (Encoding Layer)

Legt die Regeln fest, nach denen der Inhalt repräsentiert werden soll. In diesem Beispiel wird die HTTP-Anfrage als HTTP-GET-Request codiert, der die abzurufende Datei festlegt.

Transportschicht (Transport Layer)

Legt die Regeln fest, nach denen die Daten zwischen den Knoten übertragen werden. In diesem Beispiel wird der HTTP-GET-Request über eine TCP/IP-Verbindung mit Port 80 des entfernten Knotens durchgeführt.

Abb. 1–7Mein Modellkonzept für Protokolle

Diese Art der Aufteilung des Modells reduziert die Komplexität anwendungsspezifischer Protokolle, weil wir die Teile des Netzwerkprotokolls herausfiltern können, die für uns nicht relevant sind. Da es uns beispielsweise nicht interessiert, wie TCP/IP an den entfernten Knoten gesendet wird (wir gehen einfach davon aus, dass es irgendwie funktioniert), können wir TCP/IP-Daten als binären Transport betrachten, der schlicht funktioniert.

Um zu verstehen, warum dieses Protokollmodell nützlich ist, stellen Sie sich einfach vor, Sie müssen den Netzwerkverkehr irgendeiner Malware untersuchen. Sie finden heraus, dass die Malware HTTP nutzt, um Befehle vom Operator über einen Server zu empfangen. Der Operator könnte die Malware zum Beispiel anweisen, alle Dateien auf der Festplatte des infizierten Computers aufzulisten. Die Dateiliste kann an den Server zurückgeschickt werden und der Operator kann dann den Upload einer bestimmten Datei anfordern.

Wenn wir das Protokoll aus dem Blickwinkel betrachten, wie der Operator mit der Malware interagiert, indem er z. B. den Upload einer Datei veranlasst, können wir das neue Protokoll in die in Abbildung 1–8 aufgeführten Schichten aufteilen.

Abb. 1–8Modellkonzept für ein HTTP nutzendes Malware-Protokoll

Die folgende Liste erläutert jede Schicht des neuen Protokollmodells:

Inhaltsschicht

Die bösartige Anwendung sendet eine gestohlene Datei namens secret.doc an den Server.

Codierungsschicht

Die Codierung des Befehls zum Senden der gestohlenen Datei besteht aus einem einfachen Textstring mit dem Befehl SEND, gefolgt vom Dateinamen und den Daten.

Transportschicht

Das Protokoll verwendet einen HTTP-Request-Parameter, um den Befehl zu übertragen. Es benutzt die übliche Prozentcodierung, um einen gültigen HTTP-Request zu erzeugen.

Beachten Sie, dass wir in diesem Beispiel nicht berücksichtigt haben, wie der HTTP-Request über TCP/IP gesendet wird. Wir haben die Codierungs- und Transportschicht aus Abbildung 1–7 in Abbildung 1–8 in der Transportschicht zusammengefasst. Zwar nutzt die Malware Low-Level-Protokolle wie TCP/IP, doch diese Protokolle sind nicht wichtig, wenn wir analysieren wollen, wie der Malware-Befehl eine Datei sendet. Das ist deshalb nicht wichtig, weil wir HTTP über TCP/IP als einzelne Transportschicht betrachten können, die einfach funktioniert, und uns lieber auf die Malware-Befehle konzentrieren wollen.

Indem wir unseren Blick auf die Schichten des Protokolls richten, die wir analysieren müssen, vermeiden wir viel Arbeit und können uns auf die wesentlichen Aspekte des Protokolls konzentrieren. Würden wir dieses Protokoll andererseits nach den Schichten aus Abbildung 1–7 analysieren, könnten wir annehmen, dass die Malware einfach die Datei image.jpg anfordert, weil es so aussieht, als wäre das alles, was der HTTP-Request macht.

1.6Am Ende dieses Kapitels

Dieses Kapitel hat kurz in die Netzwerk-Grundlagen eingeführt. Ich habe die IPS vorgestellt sowie einige der Protokolle, denen Sie in echten Netzwerken begegnen werden. Außerdem habe ich gezeigt, wie Daten zwischen Knoten eines lokalen Netzwerks und über Router auch an entfernte Netzwerke übertragen werden. Darüber hinaus habe ich einen Weg beschrieben, Anwendungsprotokolle zu betrachten, der es Ihnen einfacher macht, sich auf die spezifischen Features des Protokolls zu konzentrieren und so die Analyse zu beschleunigen.

In Kapitel 2 werden wir diese Netzwerk-Grundlagen nutzen, um den Netzwerkverkehr für die Analyse zu erfassen, was man als Capturing bezeichnet. Das Ziel des Erfassens von Netzwerkverkehr besteht darin, auf die Daten zugreifen zu können, die Sie benötigen, um mit dem Analyseprozess zu beginnen, die verwendeten Protokolle zu identifizieren und letztlich die Sicherheitslücken aufzuspüren, die Sie ausnutzen können, um Anwendungen zu kompromittieren, die dieses Protokoll verwenden.

2

Capturing von Anwendungsverkehr

Überraschenderweise kann das Capturing, also das Erfassen nützlichen Verkehrs bei der Protokollanalyse, eine Herausforderung darstellen. Dieses Kapitel beschreibt zwei Aufzeichnungstechniken: passives und aktives Capturing. Passives Capturing interagiert nicht direkt mit dem Netzwerkverkehr. Stattdessen extrahiert es die Daten, während sie über die Leitung laufen, was Ihnen aus Tools wie Wireshark vertraut sein dürfte.

Sie werden sehen, dass unterschiedliche Anwendungen unterschiedliche Mechanismen (mit ihren jeweiligen Vor- und Nachteilen) verwenden, um Verkehr umzuleiten. Aktives Capturing greift in den Verkehr zwischen einer Clientanwendung und dem Server ein, was zwar sehr leistungsfähig ist, aber auch zu Komplikationen führen kann. Sie können sich aktives Capturing als eine Art Proxy, oder auch als Man-in-the-Middle-Angriff vorstellen. Sehen wir uns diese aktiven und passiven Techniken etwas genauer an.

2.1Passives Capturing von Netzwerkverkehr

Passives Capturing ist eine relativ einfache Technik: Sie verlangt üblicherweise keine spezielle Hardware und Sie müssen auch keinen eigenen Code entwickeln. Abbildung 2–1 zeigt ein gängiges Szenario: Ein Client und ein Server kommunizieren per Ethernet über ein Netzwerk.

Abb. 2–1Passives Netzwerk-Capturing

Passives Capturing kann entweder im Netzwerk erfolgen, indem man den laufenden Verkehr abhört, oder durch direktes Sniffing auf dem Client oder Server.

2.2Eine kurze Einführung in Wireshark

Wireshark ist der wohl beliebteste Paket-Sniffer. Er läuft auf vielen Plattformen, ist einfach zu verwenden und hat viele Features für die Protokollanalyse an Bord. In Kapitel 5 werden Sie lernen, wie man einen sogenannten Dissector entwickelt, der Sie bei der Protokollanalyse unterstützt. Doch für den Moment wollen wir Wireshark nur einrichten und IP-Verkehr aus dem Netzwerk aufzeichnen.

Um Verkehr von einer Ethernet-Schnittstelle (kabelgebunden oder drahtlos) zu erfassen, muss sich die Capturing-Vorrichtung im »Promiskuitätsmodus« (engl. Promiscuous Mode) befinden. In diesem Modus empfängt und verarbeitet eine Schnittstelle jeden Ethernet-Frame, den sie sieht, selbst wenn dieser Frame nicht für diese Schnittstelle gedacht ist. Das Erfassen einer Anwendung, die auf dem gleichen Rechner läuft, ist einfach: Sie brauchen nur die ausgehende Netzwerkschnittstelle oder das lokale Loopback-Interface (besser bekannt als localhost) zu überwachen. Anderenfalls müssen Sie Netzwerk-Hardware wie einen Hub oder einen konfigurierten Switch verwenden, um sicherzustellen, dass der Verkehr an Ihre Netzwerkschnittstelle geht.

Abbildung 2–2 zeigt die Standardansicht beim Erfassen von Verkehr über eine Ethernet-Schnittstelle.

Abb. 2–2Standardansicht von Wireshark

Die Hauptansicht ist in drei wichtige Bereiche unterteilt. Bereich stellt eine Zeitachse der Rohpakete dar, die im Netzwerk erfasst wurden. Sie enthält eine Liste der IP-Quell- und -Zieladressen sowie eine Zusammenfassung decodierter Protokollinformationen. Bereich enthält eine analysierte Ansicht des Pakets, untergliedert in verschiedene Protokollschichten, die dem OSI-Modell entsprechen. Bereich zeigt das abgegriffene Paket in Rohform.

Das TCP-Protokoll ist Stream-basiert und kann verlorene Pakete und beschädigte Daten wiederherstellen. Bedingt durch die Natur von Netzwerken und des IP-Protokolls gibt es keine Garantie, dass Pakete in einer bestimmten Reihenfolge empfangen werden. Die Interpretation des Zeitleistenbereichs kann daher beim Erfassen von Paketen recht schwierig sein. Glücklicherweise bietet Wireshark »Sezierer« für bekannte Protokolle an, die den gesamten Stream wiederherstellen und alle Informationen an einem Ort bündeln. Markieren Sie beispielsweise eine TCP-Verbindung in der Zeitleisten-Ansicht und wählen Sie dann AnalyzeFollow TCP Stream aus dem Hauptmenü, so erscheint ein Dialog wie in Abbildung 2–3. Für Protokolle ohne eigenen Sezierer kann Wireshark den Stream decodieren und in einer einfachen Ansicht darstellen.

Abb. 2–3Einem TCP-Stream folgen

Wireshark ist ein sehr umfangreiches Werkzeug. Alle verfügbaren Features zu behandeln geht weit über den Rahmen dieses Buches hinaus. Wenn Sie nicht mit ihm vertraut sind, sollten Sie sich eine gute Referenz besorgen, z. B. Wireshark® 101: Einführung in die Protokollanalyse (mitp, 2018), und die vielen nützlichen Features kennenlernen. Wireshark ist für die Analyse von anwendungsbezogenem Netzwerkverkehr unverzichtbar und unter der General Public License (GPL) kostenlos verfügbar.

2.3Alternative passive Capturing-Techniken

Manchmal ist die Nutzung eines Paket-Sniffers nicht möglich, z. B. in den Fällen, in denen man nicht das Recht hat, Netzwerkverkehr zu erfassen. Sie könnten etwa Penetrationstests auf einem System durchführen, für das Sie keine administrativen Rechte besitzen, oder Sie könnten auf einem mobilen Gerät mit einer Shell mit nur eingeschränkten Rechten arbeiten müssen. Sie könnten auch nur sicherstellen wollen, dass nur der für die zu testende Anwendung notwendige Verkehr untersucht wird. Das ist per Paket-Sniffing nicht immer einfach, solange man Netzwerkverkehr und Zeit nicht in Beziehung setzt. In diesem Abschnitt wollen wir einige Techniken beschreiben, mit denen Netzwerkverkehr einer lokalen Anwendung ohne Paket-Sniffing-Tool extrahiert werden kann.

2.3.1Tracing von Systemaufrufen

Viele moderne Betriebssysteme bieten zwei Ausführungsmodi an. Der Kernel-Modus läuft mit hohen Privilegien und enthält Code, der die Kernfunktionalität des Betriebssystems implementiert. Die alltäglichen Prozesse laufen hingegen im User-Modus. Der Kernel stellt dem User-Modus seine Dienste über den Export einer Reihe spezieller Systemaufrufe (siehe Abb. 2–4) zur Verfügung, die es den Nutzern erlauben, auf Dateien zuzugreifen, Prozesse zu erzeugen und – für unsere Zwecke das Wichtigste – die Verbindung mit Netzwerken herzustellen.

Abb. 2–4Nutzer-Kernel-Netzwerkkommunikation über Systemaufrufe

Möchte eine Anwendung sich mit einem entfernten Server verbinden, stellt sie einen speziellen Systemaufruf an den Betriebssystemkern, der die Verbindung aufbaut. Die Anwendung kann dann die Netzwerkdaten lesen und schreiben. Je nachdem, auf welchem Betriebssystem Ihre Netzwerkanwendung läuft, können Sie diese Aufrufe direkt überwachen, um passiv Daten aus der Anwendung zu extrahieren.

Die meisten unixoiden Systeme implementieren Systemaufrufe basierend auf dem Berkeley-Sockets-Modell. Das ist nicht weiter überraschend, da das IP-Protokoll ursprünglich in der Berkeley Software Distribution (BSD) 4.2 eingeführt wurde. Die Socket-Implementierung ist Teil von POSIX und damit ein De-facto-Standard. Tabelle 2–1 führt einige der wichtigsten Systemaufrufe der Berkeley-Sockets-API auf.

Name

Beschreibung

socket

Erzeugt einen neuen Socket-Dateideskriptor

connect

Verbindet einen Socket mit einer bekannten IP-Adresse und einem Port

bind

Bindet den Socket an eine lokal bekannte IP-Adresse und einen Port

recv, read, recvfrom

Empfängt Daten aus dem Netzwerk über den Socket. Die generische Funktion read liest aus einem Dateideskriptor, während recv und recvfrom Aufrufe der Socket-API sind.

send, write, sendfrom

Sendet Daten über den Socket an das Netzwerk

Tab. 2–1Gängige Netzwerk-Systemaufrufe unter Unix

Wer wissen möchte, wie diese Systemaufrufe funktionieren, findet in The TCP/IP Guide (No Starch Press, 2005) eine ausgezeichnete Quelle. Viele Ressourcen sind auch online verfügbar und die meisten unixoiden Betriebssysteme beinhalten Handbücher, die man sich im Terminal mit einem Befehl wie man 2 syscall_name ansehen kann. Schauen wir uns nun an, wie man Systemaufrufe überwacht.

2.3.2Das strace-Utility unter Linux

Unter Linux können Sie die Systemaufrufe eines Benutzerprogramms ohne besondere Rechte direkt verfolgen, solange die zu überwachende Anwendung nicht unter einem privilegierten Nutzer ausgeführt wird. Viele Linux-Distributionen liefern ein nützliches Utility namens strace mit, das den Großteil der Arbeit für Sie erledigt. Ist es standardmäßig nicht installiert, können Sie es über den Paketmanager Ihrer Distribution nachinstallieren oder es aus dem Quellcode kompilieren.

Um die Netzwerk-Systemaufrufe der Anwendung festzuhalten, führen Sie den folgenden Befehl aus und ersetzen Sie dabei /pfad/auf/app durch die zu testende Anwendung und args durch die benötigten Parameter:

$ strace –e trace=network,read,write /pfad/auf/app args

Wir wollen beispielhaft eine Netzwerkanwendung überwachen, die ein paar Strings über das Netzwerk liest und schreibt, und uns die Ausgabe von strace ansehen. Listing 2–1 zeigt vier Logeinträge (wobei wir die irrelevanten Einträge der Kürze halber weggelassen haben).

Listing 2–1Ausgabe von strace-Utility

Der erste Eintrag erzeugt einen neuen TCP-Socket, der dem Handle 3 zugewiesen wird. Der nächste Eintrag zeigt den Systemaufruf connect, der eine TCPVerbindung mit der IP-Adresse 192.168.10.1 an Port 5555 herstellt. Die Anwendung schreibt dann den String Hello World!, bevor sie den String Boo! einliest. Die Ausgabe zeigt, dass man eine recht gute Vorstellung davon bekommt, was die Anwendung auf Ebene der Systemaufrufe macht, selbst wenn man nicht über besonders hohe Privilegien verfügt.

2.3.3 Netzwerkverbindungen mit DTrace verfolgen

DTrace ist ein leistungsfähiges Tool, das für viele unixoide Systeme verfügbar ist, darunter Solaris (wo es ursprünglich entwickelt wurde), macOS und FreeBSD. Es erlaubt das Setzen systemweiter Messpunkte für spezielle Trace-Provider, darunter auch Systemaufrufe. Sie konfigurieren DTrace über Skripte in einer Sprache mit C-ähnlicher Syntax. Weitere Details zu diesem Tool finden Sie online im DTrace-Handbuch unter http://www.dtracebook.com/index.php/DTrace_Guide.

Listing 2–2 zeigt ein Beispielskript, das ausgehende IP-Verbindungen mit DTrace überwacht.

traceconnect.d

Listing 2–2Einfaches DTrace-Skript zur Überwachung eines connect-Systemaufrufs

Dieses einfache Skript überwacht den Systemaufruf connect und gibt IPv4-TCP- und -UDP-Verbindungen aus. Der Systemaufruf erwartet drei Parameter, die im DTrace-Skript durch arg0, arg1 und arg2 repräsentiert werden und für uns im Kernel initialisiert werden. Der Parameter arg0 ist der Socket-Dateideskriptor (den wir nicht brauchen), arg1 ist die Adresse des Sockets, zu dem wir die Verbindung herstellen, und arg2 ist die Länge dieser Adresse. Parameter 0 ist das Socket-Handle, das in diesem Fall nicht benötigt wird. Der nächste Parameter ist die Speicheradresse einer Socket-Adressstruktur innerhalb des Benutzerprozesses, d. h. die Adresse, mit der die Verbindung hergestellt werden soll. Die Größe dieser Adresse kann variieren und ist vom Socket-Typ abhängig (z. B. sind IPv4-Adressen kleiner als IPv6-Adressen). Der letzte Parameter ist die Länge der Socket-Adressstruktur in Bytes.

Das Skript definiert eine sockaddr_in-Struktur für IPv4-Verbindungen bei . In vielen Fällen kann diese Struktur direkt aus den C-Header-Dateien des Systems kopiert werden. Der zu überwachende Systemaufruf steht bei . Bei wird ein DTrace-spezifischer Filter genutzt, um sicherzustellen, dass wir nur connect-Aufrufe untersuchen, bei denen die Socket-Adresse die gleiche Größe hat wie sockaddr_in. Bei wird die sockaddr_in-Struktur von Ihrem lokalen Prozess in eine lokale Struktur kopiert, damit DTrace sie untersuchen kann. Bei wird der Name des Prozesses, die IP-Zieladresse und der Port über die Konsole ausgegeben.

Um dieses Skript auszuführen, kopieren Sie es in eine Datei namens traceconnect.d und führen dann den Befehl dtrace -s traceconnect.d als root aus. Wenn Sie eine mit dem Netzwerk verbundene Anwendung nutzen, sollte die Ausgabe in etwa so aussehen wie in Listing 2–3.

process:'Google Chrome' 173.194.78.125:5222

process:'Google Chrome' 173.194.66.95:443

process:'Google Chrome' 217.32.28.199:80

process:'ntpd' 17.72.148.53:123

process:'Mail' 173.194.67.109:993

process:'syncdefaultsd' 17.167.137.30:443

process:'AddressBookSour' 17.172.192.30:443

Listing 2–3Ausgabe des traceconnect.d-Skripts

Die Ausgabe zeigt einzelne Verbindungen zu IP-Adressen. Ausgegeben werden der Name des Prozesses (z. B. 'Google Chrome'), die IP-Adresse und der Port. Leider ist die Ausgabe nicht immer so hilfreich, wie die Ausgabe von strace unter Linux, doch DTrace ist mit Sicherheit ein nützliches Werkzeug. Dieses Beispiel kratzt nur an der Oberfläche dessen, was DTrace kann.

2.3.4Process Monitor unter Windows

Im Gegensatz zu unixoiden Systemen implementiert Windows die Netzwerkfunktionen für den User-Modus ohne direkte Systemaufrufe. Der Netzwerkstack wird über einen Treiber bereitgestellt und der Aufbau einer Verbindung erfolgt über die Systemaufrufe open, read und write. Selbst wenn Windows so etwas wie strace unterstützen würde, macht diese Implementierung das Monitoring von Netzwerkverkehr im Gegensatz zu anderen Plattformen wesentlich schwieriger.

Seit Vista unterstützt Windows ein Ereignisse generierendes Framework, das es Anwendungen erlaubt, die Netzwerkaktivität zu überwachen. Das alles selbst zu implementieren wäre recht komplex, doch glücklicherweise hat jemand bereits ein Tool geschrieben, das das für Sie erledigt: Microsofts Process Monitor. Abbildung 2–5 zeigt die Hauptschnittstelle beim Filtern von Netzwerkereignissen.

Abb. 2–5Capturing mit dem Process Monitor

Die Wahl des Filters in Abbildung 2–5 gibt nur Ereignisse aus, die etwas mit den Netzwerkverbindungen des überwachten Prozesses zu tun haben. Zu den Details gehören die beteiligten Hosts sowie das Protokoll und der verwendete Port. Obwohl das Capturing keine mit den Verbindungen verknüpften Daten liefert, bietet es doch wertvolle Einblicke in die von der Anwendung aufgebaute Netzwerkkommunikation. Der Process Monitor kann auch den Zustand des aktuellen Aufrufstacks festhalten, was dabei zu ermitteln hilft, wo in einer Anwendung Netzwerkverbindungen hergestellt werden. Das wird in Kapitel 6 wichtig, wenn wir mit dem Reverse Engineering von Binaries beginnen, um das Netzwerkprotokoll auszuloten. Abbildung 2–6 zeigt eine einzelne HTTP-Verbindung mit einem entfernten Server im Detail.

Abb. 2–6Capturing einer einzelnen Verbindung

Spalte zeigt den Namen des Prozesses, der die Verbindung hergestellt hat. Spalte zeigt die durchgeführte Operation, in diesem Fall den Verbindungsaufbau mit dem entfernten Server, das Senden des einleitenden HTTP-Requests und den Empfang der Response. Spalte enthält die Quell- und Zieladressen und Spalte zeigt detaillierte Informationen zum festgehaltenen Ereignis.

Zwar ist diese Lösung nicht so hilfreich wie das Monitoring von Systemaufrufen bei anderen Plattformen, sie ist unter Windows aber dennoch nützlich, wenn man die Netzwerkprotokolle feststellen möchte, die eine bestimmte Anwendung nutzt. Ein Erfassen von Daten ist mit dieser Technik nicht möglich, doch sobald Sie die verwendeten Protokolle kennen, können Sie diese Daten mit aktiven Capturing-Techniken abrufen.

2.4Vor- und Nachteile passiven Capturings

Der größte Vorteil des passiven Capturings besteht darin, dass es die Kommunikation zwischen Client- und Serveranwendung nicht stört. Die Quell- oder Zieladressen des Datenverkehrs werden nicht geändert und eine Modifikation oder Rekonfiguration der Anwendungen ist nicht nötig.

Passives Capturing könnte auch die einzige zur Verfügung stehende Technik sein, wenn Sie keine direkte Kontrolle über den Client oder den Server haben. Üblicherweise findet sich ein Weg, den Netzwerkverkehr abzuhören und mit relativ wenig Aufwand zu erfassen. Nachdem Sie Ihre Daten gesammelt haben, können Sie ermitteln, welche aktiven Capturing-Techniken Sie nutzen wollen und welcher Weg des beste ist, das zu analysierende Protokoll anzugreifen.

Ein wesentlicher Nachteil des passiven Capturings besteht darin, dass Capturing-Techniken wie Paket-Sniffing auf niedriger Ebene laufen und die von der Anwendung empfangenen Daten daher schwer zu interpretieren sein können. Tools wie Wireshark sind natürlich hilfreich, doch wenn Sie ein benutzerdefiniertes Protokoll analysieren, ist es eventuell nicht möglich, es in seine Bestandteile zu zerlegen, ohne direkt mit ihm zu interagieren.

Beim passiven Capturing ist es auch nicht immer einfach, den von einer Anwendung erzeugten Verkehr zu modifizieren. Eine Modifikation ist nicht immer nötig, aber nützlich, wenn Sie verschlüsselte Protokolle entdecken, die Komprimierung deaktivieren wollen oder die Daten verändern wollen, um Sicherheitslücken auszunutzen.

Wenn die Analyse des Verkehrs und das Einspeisen neuer Pakete nicht zu den gewünschten Ergebnissen führen, sollten Sie die Taktik ändern und auf aktive Capturing-Techniken zurückgreifen.

2.5Aktives Capturing von Netzwerkverkehr

Aktives Capturing unterscheidet sich vom passiven Capturing darin, dass man versucht, den Fluss der Daten zu beeinflussen. Das geschieht üblicherweise durch einen Man-in-the-Middle-Angriff auf die Netzwerkkommunikation. Wie in Abbildung 2–7 zu sehen, sitzt die Einrichtung, die den Verkehr erfasst, üblicherweise zwischen der Client- und der Serveranwendung und agiert als Bridge. Dieser Ansatz hat verschiedene Vorteile. So ist es beispielsweise möglich, den Verkehr zu modifizieren und Features wie Verschlüsselung und Komprimierung zu deaktivieren, was die Analyse des Protokolls und die Ausnutzung von Sicherheitslücken vereinfacht.

Abb. 2–7Man-in-the-Middle-Proxy