HYPERLiNK-SPOOFiNG der Angriff auf die SSL-Server-Authetifikation

Transkript

1 HYPERLiNK-SPOOFiNG der Angriff auf die SSL-Server-Authetifikation 1.) Einführung 2.) Der Hintergrund des Hyperlink-Spoofing 3.) Die Hyperlink-Spoofing-Attacke "bei der Arbeit" 4.) Massnahmen gegen das Hyperlink-Spoofing 5.) Die laengerfristige Loesung gegen das Hyperlink-Spoofing 6.) Abschliessend 1.) Einführung In diesem Paper moechte ich euch mal eine etwas andere Angriffsform naeher bringen, welche den Angriff auf das HTTP Protokoll nutzt. Man richtet diesen Angriff gegen das Server- Authentikationsprotokoll Secure Socket Layer (SSL), welches in gesicherten Browsern wie z. B. denen von Netscape, Microsoft, Opera und anderen verwendet wird. Ein "man-in-the-middle"-hacker kann den Server dazu missbrauchen, sich mit einem vorgetaeuschten Server zu verbinden. Dabei wird dem Browser das uebliche Erscheinungsbild einer gesicherten Sitzung geboten. Ihr wisst nicht was ein "man-in-the-middle"-hacker ist? Pech ;) Nein, unter einem "man-in-themiddle"-hacker versteht man eine Technik, bei der man sich in den Paketstrom zwischen Server und Clinet einschleusst. Ein weiteres Risiko des Hyperlink-Spoofing (ein vorgetaeuschter Hyperlink) besteht darin, dass der Anwender (z. B. ein Bank- oder Datenbank-Client) "boesartige" Java-Applets vom Server herunterlaedt, weil er glaubt, die Applets wuerdem vom echten Server stammen. Das Hyperlink-Spoofing nutzt ein Sicherheitsloch, weil die meisten Browser digitale Zertifikate verwenden, um Websitzungen zu sichern. Das Hyperlink-Spoofing richtet sich nicht gegen die kryptografische Ebene oder den Ablauf von SSL. Deshalb kann dieser Angriff auch gegen andere mit digitalen Zertifikaten gesicherte Applikationen gerichtet werden. Internet Explorer + 3x, Netscape Navigator + 4x sind anfaellig gegenueber dieser Angriffsart. Es sind auch andere Browser und SSL-Proxies anfaellig fuer Hyperlink-Spoofing, das mag unter anderem schon an fehlerhafter Konfiguration liegen. Techniken, die ebenfalls mit Zertifikaten arbeiten, wie signierter Code oder signierte Applets, sind davon nicht betroffen. Angreifer koennen jeden SSL-Server verkoerpern, indem sie sich nach den ueblichen Konventionen fuer Zertifikate richten oder auf die zuvor aufgelisteten Browser zugreifen. Darueber hinaus sind auch Server-Zertifikate wie die von Verisign anfaellig, wenn Browser wie Internet Explorer oder Netscape Navigator eingesetzt werden. Modifikationen der serverseitigen Software machen diese Art des Angriffes weniger erfolgreich. Langfristig ist es die beste Loesung, sowohl den Zertifikatsinhalt als auch den normalen Web-Browser zu modifizieren. Wie schon zuvor ausgefuehrt, sind Client-Zertifikate, das Java-Applet-Signieren und die von Server fuer Code verwendeten Zertifikate, wie bei ActiveX Controls, nicht betroffen. 2.) Der Hintergrund des Hyperlink-Spoofing Wenn ein Anwender eine SSL-Verbindung aufbaut, vereinbaren der Browser und der Server ein Protokoll, um den Server und optional den Client zu authentizieren. Die Hyperlink-Spoofing-

2 Methode zielt ausschliesslich auf die Server-Authentikation ab. Waehrend der Initialschritte des SSL-Protokollaufbaus erhaelt der Client vom Server ein Zertifikat angeboten. Es handelt sich dabei um eine Struktur, die mit einer digitalen Signatur versehen ist, in der der oeffentliche Schluessel des Servers mit bestimmten Attributen verbunden ist. SSL verwendet einen Domain-Name-Server-(DNS-)Namen im Zertifikat. Alternativ dazu kann das Zertifikat einen Platzhalter anstelle des vollstaendigen Namens enthalten(er koennte oder *.bnd.de lauten). Durch den korrekten Protokollaufbau und das Prasentieren eines gueltigen Zertifikats, dem der Client vertraut, stellt der Server fuer den Browser sicher, dass er ueber den korrespondierten privaten Schluessel verfuegt. Der Browser akzeptiert diese Pruefung und weiss nun, dass der Server wirklich er ist bzw. dass er das Recht hat, den gezeigten DNS-Namen zu fuehren. Fuer das Hyperlink-Spoofing ist SSL nicht das eignetliche Problem. Statt dessen sind der Inhalt der Zertifikate und die Anwenderschnittstelle des Browsers die kritischen Punkte. 3.) Die Hyperlink-Spoofing-Attacke "bei der Arbeit" Die Hyperlink-Attacke kann erfolgreich sein, weil die meisten Anwender Verbindungen nicht mit DNS-Namen oder URLs herstellen, sondern ueber Hyperlinks. Der aktuelle Entwicklungsstand von SSL reicht nur zum Pruefen des Serveranteils in der URL, jedoch nicht zum Pruefen des Hyperlinks, auf den der Anwender klickte. Genauso wie DNS-Namen gegenueber dem DNS-Spoofing anfaellig sind (ein DNS-Server "luegt" bezueglich seiner Internet-Adresse), so sind URLs das Zielobjekt fuer das Hyperlink-Spoofing, bei der eine Website ueber den DNS-Namen einer URL unwahre Angaben macht. Beide Spoofing- Formen steuern einen auf die falsche Site. Hyperlink-Spoofing laesst sich vom technischen Standpunkt aus betrachtet leichter durchfuehren als das DNS-Spoofing. Beispielsweise koennte man dem Browser des Opfers folgendes mit auf den Weg geben: Klicken Sie hier fuer kostenlose Angebote aller Art. Man sieht einen Link, der verspricht, dass es dort kostenlose Angebote aller Art gibt. Wenn man darauf klickt, wird man zu einem anderen gesicherten Server geschickt(attacking.com) und landet im Verzeichnis infogatherer. Die heutige Browser-Generation stellt fest, ob es sich um eine gesicherte Verbindung handelt, und zeigt dies entsprechend an. Dennoch hat man das Opfer ueberlistet. Man benutzt dazu einige Tricks auf die ich spaeter noch zurueckkomme. Nun hat man zwar eine "vertrauliche" Verbindung, aber leider mit dem falschen Server. Natuerlich bietet die infogathering-site keine kostenlosen Angebote. Statt dessen befindet man sich mitten in einem Angriff. Der Angreifer hat dafuer gesorgt, dass die Website wie das Original aussieht - das man sonst zur Eingabe einer Kreditkartennummer auffordert, bevor man die eigentlichen kostenlosen Angebote erhaelt. Wenn man sich in die Tiefen seines Browsers begibt, und den Source des Dokuments oder die Dokumentinformationen betrachtet, wird man feststellen, dass es sich bei der authentizierten Identitaet keineswegs um den Server handelt, den man erwartet hat. Als Serverzertifikate weitere Verbreitung fanden, wurde das Aufrechterhalten der Server- Authentikation pradoxerweise schwieriger und nicht einfacher. Weil mehr Server ueber Zertifikate verfuegen, haben Angreifer eine groessere Auswahl fuer das Umleiten des leichtsinnigen Surfers. Ausserdem schalten viele Anwender den Zertifikatsdialog ab, weil der man jedesmal von dem Browser gewarnt wird, wenn man eine neue Website ansteuert. Darueber hinaus ist es nicht

3 besonders hilfreich, ein gesichertes Dokument anzufordern, wenn man weiss, dass jede Verbindung und jedes Dokument gesichert sind. Mit anderen Worten: Das Verifizieren der Serververbindung wird ausschliesslich bedeutungslos. Abgesehen von der umfangreichen Authentikation gibt es keine Ueberwachungsaufzeichnung, mit der der Anwender nachvollziehen koennte, was beim Hyperlink-Spoofing geschehen ist. Im guenstigsten Fall zeigt das Logbuch des Browsers das es einen HTTP-(oder HTTPS-)GET-Befehl an den echten und einen anderen an den gefaelschten Server gab. Mit etwas Glueck koennte sich im lokalen Cache noch die veraenderte Seite finden lassen. Tatsaechlich kann der Angreifer die Seite aber sehr leicht mit dem PRAGMA-Befehl aus dem Cache entfernen. Waehrend eines Spoofing- Angriffs tritt die zweite GET-Anforderung auf, weil die erste einen inkorrekten, verfaelschten Inhalt hatte. Leider ist es auch mit dem besten aller Logbuecher nicht moeglich, das Initiieren des zweiten GET-Befehls durch die zweite Seite zu verifizieren. Der zweite GET-Befehl koennte durch einen Bookmark oder mit einem anderen Fenster verursacht worden sein. Sogar wenn man vollig ist, das man keine Bookmarks verwendet, koennte das Falsifikat immer noch von einem Cache (auch von einem Nachbarcache des ISP) stammen. Man kann zwar vermuten, dass die Website von einem Angreifer ist, belegen kann man es aber nicht (obwohl man moeglicherweise die Schritte wiederholen koennte, die einen zur Spoofing-Site brachte, und dann den Angreifer in flagranti zu ertappen). Es liegt nicht im Interesse des Angreifers, einen zu seiner gesicherten Seite zu locken (weil man damit das Zertifikat des Angreifers ermitteln wuerde und somit ein grosser Schritt zur Ermittlung seiner Identitaet gemacht waere). Der Angreifer schickt einen zur SSL-Box von jemand ganz anderen, vielleicht sogar zu einer Site, zu der man wirklich will. Mit anderen Worten wuerde die URL /attackseite anstelle von /sichereseite lauten. Diese Art der "verbogenen" Adressierung erfolgt hauptsaechlich bei virtuell aufgebauten Websites oder Websites, bei denen die URL ein CGi-Script oder eine Java-Klasse angibt, die von einem Angreifer legitimierte kontrolliert wird. (Um fair zu bleiben: SSL wurde nicht konzipiert, um diese Ebene der Sicherheitsfragen auch noch abzudecken. Es ist nur dazu gedacht Websites zu authentizieren). 4.) Massnahmen gegen das Hyperlink-Spoofing Falls man bereits Web-gestuetzte Applikationen einsetzt, die sich auf die Server-Authentikation verlassen, und man kann nicht auf ein Update des Internet-Software-Providers warten, besteht die einzige derzeit machbare Loesung darin, den Anwender auf einer wirklich gesicherten Seite starten zu lassen. Die Anwender koennen dann den Empfangslinks vertrauen und der Angreifer ist nicht mehr in der Lage, einen in gefaehrliche Bereiche zu schicken. Eine gesicherte Seite ist eine Seite, auf deren Integritaet man sich verlassen kann. In der Praxis bedeutet dies, dass man eine lokale HTML-Seite oder eine gesicherte Seite auf einem SSL-Server verwendet. Falls man den Brwoser eines Anwenders dafuer vorsehen, eine SSL-Seite zu oeffnen, muss man die URL fuer die Seite auf einen Weg versenden, der schwierig, am besten so gut wie gar nicht, zu unterbrechen ist (z. B. auf einer Diskette oder einem Brief per Post ;). Andernfalls stellt die Seite einen Ansatzpunkt fuer den Angriff dar, den man verhindern wollte. Alle Links, die aus dieser Seite herausfuehren, muessen den Anwender zu vertrauenswuerdigen Sites weiterleiten. Ausserdem sollte es sich bei allen um SSL-Links handeln. Man legt fest, welche Sites man als vertrauenswuerdig einstuft. Dazu orientiert man sich am besten an den folgenden zwei Kriterien: 1. Die Site wird gesichert betrieben (das bedeutet, die gesamte Site ist gegen Angriffe und das

4 Abfangen von Seiten gesichert). 2. Die Site bedient nur Hyperlinks zu gesichert betriebenen Sites. Das erste Kriterium trifft fuer die meissten Sites nicht zu. Deshalb ist der gesicherte Zugriff auf Seiten nur fuer Intranet-Applikationen moeglich, die sich hinter einer Firewall befinden, oder fuer Applikationen, bei denen die Anwender nur auf die firmierten betriebenen Sites zugreifen und deshalb den Zugriff auf das Internet nicht benoetigen. Alternativ kann man ein relativ unverwechselbares Objekt auf einer Website unterbringen. Beispiele sind die Zertifikate Verisign Java und Microsoft Athenticode. Weil Verisign die Zertifikate und die zugehoerigen Applets aus einem numerischen Hash der Website erzeugt, ist es fuer Angreifer sehr schwer, das Zertifikat zu simulieren. Die dritte Moeglichkeit leasst sich recht schnell realisieren. Die meisten Webbrowser bieten Sicherheitsoptionen an. Eine dieser Optionen ermoeglicht es, Site-basierte Zertifikate einzusehen. Man sollte sich einfach mal die Optionen die einem der Browser bietet, sie sind zahlreich, sehr genau anschauen, damit eine grosse Sicherheit gewaehrleistet wird. Die vierte Moeglichkeit einer Abhilfe waere die Verwendung von gesicherten Bookmarks. Sicherheitsbeauftragte testen und verifizieren jedes gesicherte Bookmark, bevor es in die entsprechende Datei des Browsers aufgenommen wird. Zusaetzlich sollte jedes Bookmark nur manuell weitergegeben werden, z. B. auf einer Diskette. Die gesicherten Bookmarks koennen besonders gekennzeichnet werden, damit jedem Anwender klar wird, womit er es zu tun hat. Hier muesste durch ein Plug-In fuer den Browser eine Grundlage geschaffen werden, die das Vewenden gesicherter Bookmarks erzwingt. Ein gesichertes Lesezeichen koennte aus einem Hyperlink-Text, von Bildern oder von URL s abgeleitet werden. Ein entsprechender Eintrag koennte so aussehen: "*KryptoKom*:**.kryptokom.de*" "Sieht" der Browser einen Link mit dem Text "KryptoKom", dann prueft er, ob es in der Domaene kryptokom.de ein Server-Zertifikat gibt. Er stellt damit gleichzeitig sicher, dass die Verbindung wirklich zu Kryptokom.de aufgebaut wird. Bei der Verbindung mit einer anderen Site wuerde der Browser den Anwender davor warnen, dass die mit ihm verbundene Domaene identisch mit der von ihm erwarteten ist. Optional koennte die Verwendung entsprechender Lesezeichen erzwungen werden, so dass Anwender nur mit den Sites Verbindungen herstellen koennen, bei denen die Namen der Domaenen uebereinstimmen. Diese Loesung sorgt dafuer, dass die Anwender die Sicherheitsmassnahmen fuer ihre Browser konfigurieren, um auf die "lokalen" hochwertigen Dienste zuzugreifen, und verhindern, dass weniger trainierten Anwender zufaellig ungeschuetzte Informationen verschicken. Grundsaetzlich behebt die Lesezeichenloesung die Luecke zwischen dem Link-Text und dem URL- Domaenennamen. Jeder der zuvor besprochenen Loesungsansaetze versucht, das Mapping zu ersetzen oder dem Anwender zu versichern, dass das Mapping korrekt ist. Dies ist aber nicht der einzige Weg, gesichertes Mapping fuer Web-Adressen bereitzustellen. Man koennte z. B. auch einen gesicherten Internet-Verzeichnisdienst oberhalb der zertifizierten Website-Protokolle anlegen. Leider wuerde dies aber auch bedeuten, eine kuenstliche Ebene des Weiterleitens zwischem dem Link, der Identitaet der Site und der Site selbst (dem privatem Schluessel) herzustellen, damit wuerden nicht nur einige der anderen Loesungssaetze in Frage gestellt, sondern es waere auch schwieriger, die Sicherheit der Links zu garantieren. Keiner der diskutierten Loesungsansaetze kann verhindern, dass eine Verbindung zu beliebigen Diensten im Netz hergestellt wird. Ausserdem hilft keine der gezeigten Loesungen gegen Adressverbiegungen innerhalb einer Site.

5 5.) Die laengerfristige Loesung gegen das Hyperlink-Spoofing Das Hyperlink-Spoofing stellt ein hohes Risiko fuer die Datensicherheit dar, wenn sich Anwender im Internet bewegen. Das grundlegende Problem mit dem Hyperlink-Spoofing besteht darin, dass die von SSL bereitgestellten Zertifikate falsche Informationen enthalten, den Namen des DNS- Servers. Der DNS-Name ist mehr ein technisches Detail als die URL, die selbst wiederum mehr ein technisches Detail ist, als der Hyperlink, auf den der Anwender klickt. Mit der zunehmenden Zahl technisch untrainierter Anwender im Internet sollte weniger technische Inhalte von den Zertifikaten angezeigt werden. Die meissten Anwender greifen auf das Internet mit Hilfe von URLs und nicht von DNS zu und gehen davon aus, dass hinter einer URL schon der erwartete Partner zu finden ist. Der durchschnittliche User versteht die Bedeutung der DNS nicht, weshalb die Authentikation von DNS-Namen wenig oder gar keinen Sinn hat. Viele Anwender kennen ueber die in Print-Medien oder im TV veroeffentlichten URLs wie hinaus keine weitergehenden URL- Konstrukte. Darueber hinaus sind die aktuellen Weiterentwicklungen wie "freundliche URLs" im Internet Explorer bei denen auf die gesamte Site mit minimalen Aenderungen in der Anzeige der URL zugegriffen wird, ein weiterer Schritt in den Unterschied zwischen dem, was der Anwender angezeigt bekommt und dem Server-Zertifikat. Das von den Internet-Verantwortlichen zu loesende Problem ist, was ein Zertifikat zertifizieren soll. Dies ist einerseits von der Applikation abhaengig. Bei einigen Applikationen (z. B. Befehlszeilen- FTP) ist der DNS-Name gut fuer das Anzeigen des Zertifikats geeignet, wie er vom Anwender ohnehin eingetippt wurde. Beim Betrieb eines Browsers sollte das Zertifikat jedoch das Hyperlink- Bild, den Text oder eine andere Besonderheit der Website enthalten, die dem Browser durch die zertifizierte Seite uebermittelt wird, moeglicherweise ueber den Tag. Das Zertifikat koennte die folgenden Informationen enthalten: - repraesentative Bilder (Firme- und Produktlogos, Gesichter von Leuten) - englische (die haeufigste Serversprache) oder national-sprachliche Redewendundgen, die sich gut als Links einsetzen lassen. Dabei waere zu beruecksichtigen, ob der Aufbau durch die das Zertifikat ausstellende Autoritaet oder durch die Applikation bestimmt wird. Obwohl URLs im wesentlichen fuer das Web zugreifende Applikationen sehr nuetzlich sind, wuerden sie innerhalb von Zertifikaten Platzhalter oder Ausdruecke enthalten. Man sollte beachten, dass dieser URL-Typ meist Intranet-Applikationen oder Daten repraesentiert und deshalb wahrscheinlich eher durch eine Intranet-Zertifikationsautoritaet als durch Internet-Dienste wie Verisign zertifiziert wird. Enthaelt das Zertifikat ein Bild, kann es vom Browser in ein Dialogfenster plaziert und angezeigt werden. Es koennte auch im Bild-Fenster anstelle der Logos von Netscape oder des Internet Explorers angezeigt werden. Dies wuerde dem Anwender permanent zeigen, mit wem er verbunden ist. Selbst technisch weniger Trainierte kennten feststellen, dass man nicht mit der Seite verbunden ist, mit der man verbunden sein wollte. Ausserdem koennte der Browser mit wenigen Aenderungen Zertifikate automatsich pruefen. Folgt der Anwender einem Link mit einem Bild, koennte der Browser das enthaltene Zertifikat pruefen. Erscheint das Bild nicht, erhaelt der Anwender eine Warnung. Folgt der Anwender einem Textlink, untersucht der Browser die Funktion des Texts. So koennte der Browser z. B. das Zertifikat fuer einen Zeichenkettenteil des Text-Links oder eine bekannte Hash-Funktion des Links pruefen. Das

6 Verifizieren des Bildes oder des Textlinks wuerde dem Anwender die gesicherte Erkenntnis liefern, dass der Link in einer Ende-zu-Ende-Relalion einwandfrei ist und kein Spoofing zulaesst. PGP: [EOF] xaitax (alexander hagenah)