Montag, 1. März 2010


Topthema

Donnerstag, 6. Juli 2006 | Topthema

About Security #62: Angriffe auf TCP/IP — HTTP-Hijacking

(Link zum Artikel: http://www.entwickler.de/php/kolumnen/029916)

In dieser Folge geht es um eine weitere Möglichkeit zum Vergiften des DNS-Caches: Um das Entführen von HTTP-Verbindungen, das HTTP-Hijacking.

Cache Pollution

Beim so genannten 'Cache Pollution'-Angriff wird ausgenutzt, dass manche Nameserver beliebige empfangene Daten in ihren Cache speichern. Ursprünglich wurde das Verfahren zur Effizienzsteigerung verwendet: Wenn nach einem bestimmten DNS-Eintrag, z.B. dem Mailserver einer Domain, gefragt wird, ist die Wahrscheinlichkeit hoch, dass danach auch z.B. ihre IP-Adresse benötigt wird. Um diese Anfrage einzusparen, werden bei der Antwort außer der angeforderten Information auch weitere zur betroffenen Domain gehörende Daten in so genannten Additional Resource Records (RR) mitgeschickt. Ein Angreifer kann dies ausnutzen, um über einen unter seiner Kontrolle stehenden Nameserver zusätzlich falsche Daten mitzuschicken.

About Security: Die komplette Serie

Beim Beispiel aus der vergangenen Woche würde der Angreifer bei der Antwort auf die Frage nach total.unwichtig.example ungefragt zusätzlich die Information www.spoof.example = e.f.g.h mitschicken. dns.opfer.example würde die Daten in seinem Cache speichern und später die Anfrage des Opfers damit beantworten.

DNS-Spoofing: Cache Pollution

Inzwischen prüfen die meisten Nameserver zur Verhinderung derartige Angriffe zusätzlich übertragene Daten. Informationen, die weder zur Anfrage gehören, noch von einem zuständigen Nameserver stammen, werden verworfen. Diese Prüfungen werden 'Bailiwick Checking' genannt: Zusätzliche Informationen werden immer nur für die abgefragte Domain akzeptiert ('in-bailiwick'). Damit wird verhindert, dass dem Server bei der Anfrage nach www.server.example in der Antwort zusätzlich noch Informationen über www.anderer-server.example untergeschoben werden - diese RRs sind 'out-bailiwick' und werden ignoriert.

Statt nur den Eintrag für einen normalen Server zu fälschen, könnte der Angreifer sich auch als zuständiger Nameserver für eine ganze Top Level Domain (z.B. .com) ausgeben. Danach würden alle Anfragen nach Domains aus diesem Bereich an den Angreifer gesendet, der sie nach Belieben mit richtigen oder falschen Daten beantworten könnte. Der letzte großangelegte Angriff dieser Art fand im Frühjahr 2005 statt. Ziel war die Verbreitung von Schadsoftware: Anwender wurden auf Webseiten umgeleitet, die Windows-Rechner über Schwachstellen im Internet Explorer mit Spyware infizierten.

Nachtrag 2008: Neue Entwicklungen

Anfang Juli 2008 wurde eine von Dan Kaminsky entdeckte Designschwachstelle in der DNS-Spezifikation bekannt, die Cache-Poisoning-Angriffe sehr einfach möglich macht. Gleichzeitig wurden Patches für verbreitete Nameserver bereitgestellt. Eigentlich sollten Details zur Schwachstelle erst im August veröffentlicht werden, durch unglückliche Umstände wurden sie jedoch bereits Ende Juli bekannt. Wenige Tage später wurden erste Exploits veröffentlicht, worauf bald die ersten Angriffe gemeldet und kurz darauf bestätigt wurden.

Erste Details zum neuen Angriff, die dann im August im wesentlichen bestätigt wurden, liefert dieser Artikel. In diesem Eintrag im Bereich Security aktuell von entwickler.de werden Exploits und weiterführende Informationen gesammelt.

Der neue Angriff, kurz beschrieben

Dan Kaminsky hat in einem Vortrag auf der Sicherheitskonferenz Black Hat die Details zur Design-Schwachstelle präsentiert. Die Präsentation des Vortrags steht in seinem Blog zum Download bereit (PowerPoint-Datei).

Um in einem Nameserver den Eintrag für www.opfer.example mit der IP-Adresse 1.2.3.4 zu vergiften, geht der Angreifer vereinfacht folgendermaßen vor:

  1. Er fragt den Nameserver nach .opfer.example, wobei eine beliebige Zeichenkette ist
  2. Er sendet sofort danach viele gefälschte Antworten mit unterschiedlichen IDs an den Nameserver, in denen er behauptet, dass der für .opfer.example zuständige Nameserver www.opfer.example ist und die IP-Adresse 1.2.3.4 hat.
  3. Schlägt der Angriff fehl, weil der für opfer.example zuständige Nameserver schneller war oder nicht die richtige ID erraten wurde, wird er sofort mit einem neuen Wert für wiederholt.

Versucht der Angreifer, den DNS-Eintrag für www.opfer.example direkt zu vergiften, muss er schneller als der zuständige Nameserver antworten und die richtige ID erraten. Ist er zu langsam, ist der nächste Angriff erst wieder möglich, wenn die Lebensdauer (TTL, Time to Life) des Eintrags abgelaufen ist. Durch die Verwendung unsinniger Domains und das sofortige Senden der Antworten hat er im Wettlauf mit dem zuständigen Nameserver einen Vorteil und muss 'nur noch' die richtige ID erraten, von denen es nur 65536 gibt – seine Chancen stehen also 1 zu 65535.

Um diese Angriffe zu erschweren, wird nun zusätzlich auch der Quell-Port für die DNS-Abfragen zufällig gewählt. Der Angreifer muss also für einen erfolgreichen Angriff ID und Quell-Port richtig erraten. Damit sinkt die Wahrscheinlichkeit für einen erfolgreichen Angriff auf 1 zu 163.840.000 bis 1 zu 2.147.483.648.

HTTP Hijacking

Ziel des HTTP Hijackings 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.

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, ist dies über ARP-Spoofing möglich (s. About Security #60). Aber auch, wenn sich alle Beteiligten in verschiedenen Netzen befinden, ist ein Angriff möglich.

N E U ! Security aktuell
Täglich aktuelle Security-Infos!

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. Dabei 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.

HTTPS-Verbindungsaufbau

Der Angriff
Zuerst vergiftet der Angreifer den Cache des DNS-Servers dns.opfer.example wie in About Security #61 beschrieben, sodass Anfragen nach www.bank.example mit seiner IP-Adresse beantwortet werden.

Vorbereitung des Angriffs

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. 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 unwahrscheinlich 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.

Durchführung des Angriffs

Da der Angreifer in Echtzeit agiert, bietet auch das iTAN-Verfahren keinen Schutz.

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

Wenn Sie Fragen oder Themenvorschläge haben, können Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!

Carsten Eilers

About Security – Übersicht zum aktuellen Thema "Angriffe auf TCP/IP"

Kommentare

Folgende Links könnten Sie auch interessieren