Skip to content

Angriffe auf TCP/IP (7) - HTTP-Hijacking

Ziel des HTTP-Hijacking ist die Umleitung einer bestehenden Verbindung, um danach z.B. vertrauliche Daten wie z.B. Passwörter zu belauschen oder Ein- bzw. Ausgaben zu manipulieren. Der Angreifer hat dazu zwei Möglichkeiten: Entweder er gibt sich beim Verbindungsaufbau als der gewünschte Server aus oder er leitet die Verbindung durch das Einschleusen gefälschter HTTP-Response-Meldungen (z.B. der Statusmeldung 301, "Moved Permanently") zu sich um.

Der Einfachheit halber beschreibe ich den Angriff im Folgenden am Beispiel des HTTPS-Hijackings. HTTP-Hijacking ist deutlich einfacher, da der Angreifer dann nur die Verbindung über seinen Rechner umleiten muss und nicht auch noch die HTTPS-Verbindung aufbrechen muss.

HTTPS-Hijacking

Der Angreifer möchte sich als Man-in-the-Middle in die Verbindung zwischen einem Benutzer und seiner Bank einschalten. Befinden sich Angreifer und Opfer im selben lokalen Netz, kann der Angreifer dies über ARP-Spoofing erreichen. Aber auch, wenn sich alle Beteiligten in verschiedenen Netzen befinden, ist ein Angriff möglich.

Beim normalen Verbindungsaufbau gibt der Benutzer die Adresse der Bank in seinen Webbrowser ein, z.B. www.bank.example. Sein Rechner sendet daraufhin eine DNS-Anfrage an seinen DNS-Server (dns.opfer.example), der seinerseits die entsprechende IP-Adresse sucht. Nachdem der Rechner des Benutzers die IP-Adresse (z.B. a.b.c.d) vom DNS-Server erfahren hat, baut er die Verbindung auf, siehe Abb. 1.

HTTPS-Verbindungsaufbau
Abb. 1: HTTPS-Verbindungsaufbau (Klick für großes Bild im neuem Tab/Fenster)

Daraufhin wird ihm vom Server der Bank deren SSL-Zertifikat präsentiert. Der Webbrowser prüft, ob das Zertifikat von einer vertrauenswürdigen Certificate Authority (CA) unterzeichnet wurde. Ist dies der Fall, wird die Verbindung automatisch als 'sicher' markiert.

Wurde das Zertifikat nicht von einer vertrauenswürdigen CA unterzeichnet, wird der Benutzer um Zustimmung gebeten. Bestätigt er das Zertifikat, wird die Verbindung ebenfalls als 'sicher' markiert. Der Benutzer kann nun seine Bankgeschäfte erledigen.

Der Angriff

Zuerst vergiftet der Angreifer den Cache des DNS-Servers dns.opfer.example, im Abb. 2 am Beispiel des DNS-Spoofings gezeigt, so dass Anfragen nach www.bank.example mit seiner IP-Adresse beantwortet werden.

Vorbereitung des Angriffs
Abb. 2: Vorbereitung des Angriffs (Klick für großes Bild im neuem Tab/Fenster)

Wenn der Benutzer danach www.bank.example in seinem Webbrowser aufruft, wird ihm vom DNS-Server die falsche IP-Adresse e.f.g.h genannt, zu der die Verbindung aufgebaut wird, siehe Abb. 3.

Der Einfachheit halber gehe ich dabei davon aus, dass der Angreifer die Verbindung über seinen DNS-Server umleitet bzw. das sein Rechner gleichzeitig als sein DNS-Server arbeitet. Ansonsten wäre einfach ein weiterer Rechner nötig, der die IP-Adresse e.f.g.h hat und als MitM agiert.

Der Angreifer präsentiert ein gefälschtes Zertifikat. Ist es ihm bei der Vorbereitung des Angriffs gelungen, dafür die Unterschrift einer vertrauenswürdigen CA zu bekommen (was leider durchaus möglich ist), wird der Webserver das falsche Zertifikat akzeptieren. Aber auch ohne entsprechende Unterschrift kann der Angriff gelingen, z.B., wenn ein unaufmerksamer Benutzer das gefälschte Zertifikat bei der Nachfrage des Webbrowsers akzeptiert oder der Angreifer über eine Schwachstelle im Webbrowser ein eigenes CA-Zertifikat einschleusen konnte.

Der Angreifer baut dann eine eigene HTTPS-Verbindung zum Webserver der Bank auf und verwendet dabei die ihm vom Opfer mitgeteilten Zugangsdaten. Danach hat er die vollständige Kontrolle über die Kommunikation zwischen Benutzer und Bank. MitM-Angriffe auf HTTPS-Verbindungen hatte ich ja bereits allgemein beschrieben, dieser ist einfach ein Spezialfall davon.

Durchführung des Angriffs
Abb. 3: Durchführung des Angriffs (Klick für großes Bild im neuem Tab/Fenster)

In der nächsten Folge werden weitere Angriffe auf TCP/IP vorgestellt, dann geht es um Distributed Denial-of-Service-Angriffe. Zunächst in der klassischen Variante.

Carsten Eilers

>
        </div>
                
        <footer class= Kategorien: Grundlagen | 0 Kommentare

Trackbacks

Keine Trackbacks

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Noch keine Kommentare

Kommentar schreiben

Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
BBCode-Formatierung erlaubt
Formular-Optionen

Kommentare werden erst nach redaktioneller Prüfung freigeschaltet!