Man-in-the-middle-Angriff gegen Webseiten (und E-Mail)

Auf der Suche nach der Ursache für ein Ärgernis. Oder: Wo der Bundestrojaner lauern könnte.

Manchmal zeigt sich bei Sicherheitsmaßnahmen, daß sie ihren Zweck erfüllen. Ich verwende als Web-Browser Firefox, und zwar in der Regel u.a. mit der Erweiterung ‘NoScript’, die ich sehr empfehlen kann. NoScript meckert, wenn auf einer Seite JavaScript eingebunden ist, der von einer noch nicht freigegebenen Webseite kommt. So kann man dann einzeln einstellen, von welchem Webseiten man JavaScript akzeptiert. Ganz abschalten kann man das heutzutage nicht mehr, da funktionieren zu viele wichtige Webseiten nicht mehr. Normalerweise sieht man dann im Menü, daß auf einer Webseite JavaScript so von 1-3 verschiedenen Quellen kommt. Normalerweise von der Seite selbst, manchmal auch von anderen Servern derselben Domain, sehr oft aber auch irgendein Mist von irgendwelchen Werbeeinblendungen, die man dann hübsch selektiv ein- und ausschalten kann. Feine Sache.

Seit einiger Zeit fiel mir auf, daß NoScript im Menü sehr oft, nicht immer, auch einen Webserver “1.2.3.4” auflistete. Es stört eigentlich nicht, weil man es sowieso nur sieht, wenn man in dieses Menü guckt. Aber irgendwie nervt das doch und man will ja auch wissen, was dahinter steckt. Ein mehrfaches Umstülpen meines Notebooks nach einer solchen Einstellung brachte nichts, auch das rekursive Durchforsten angewählter Webseiten brachte keinen Erfolg. Da ich mit meinem Notebook öfters mal in irgendwelchen fremden Netzen rumturne, überlegte ich, ob ich nicht vielleicht irgendwo mal testweise als Proxy oder so “1.2.3.4” eingetragen hatte. Das drängt sich ja so als Testfall auf. War aber nicht zu finden.

Die Lösung des Rätsels ergibt sich, wenn man die Quellen direkt im Browser anschaut (seltsamerweise ergibt sich dann was anderes als wenn man die Webseiten abspeichert). Im Header befindet sich nämlich die eingeschmuggelte zusätzliche Zeile

<script src=”http://1.2.3.4/bmi-int-js/bmi.js” language=”javascript”></script>

Das passiert nämlich immer dann, wenn ich über mein UMTS-Handy gehe. Der UMTS-Provider hat einen transparenten (!) Proxy geschaltet, der die Seiten modifiziert und das einfügt. Aus dem UMTS-Netz bekommt man dann sogar tatsächlich unter dieser URL JavaScript-Code, der künstlich in die Seiten eingefügt wird.

De facto scheint der Code beim ersten Überfliegen “harmlos” zu sein. Der UMTS-Provider komprimiert Bilder in Webseiten stärker (z. B. durch Heruntersetzen der JPEG-Qualität) und bietet dann in jedem Bild die Maustasten-Option “Shift+R improves the quality of this image.”, die dann das Bild in voller Qualität nachlädt. Offensichtlich dient das dem Zweck, Netzbandbreite zu sparen und vielleicht, dem Nutzer ein schnelleres Surfen zu ermöglichen. Also nicht unmittelbar böse.

Man muß da aber doch die Frage aufwerfen, inwieweit solche “heimlichen” transparenten Proxies zulässig und vertretbar sind. Denn offiziell informiert wurde ich vom Provider nie darüber. Daß solche Proxies bestehen ist mir schon relativ früh aufgefallen, weil sie manchmal nicht funktionieren und man leere Seiten bekommt, obwohl der Server einwandfrei funktioniert. Mir war auch schon relativ früh das seltsame Phänomen aufgefallen, daß ich auf Port 80 ein Connect zu einem Webserver bekam, den ich gerade höchstpersönlich abgeschaltet hatte. Erst als Reply auf einen HTTP-Request kam dann im Header die Antwort, daß ein Proxy Probleme hätte, jenenwelchen Server zu erreichen. Ich bin auch nicht der erste, der das entdeckt, es gibt schon einige Foreneinträge über Probleme, die Leute mit Web-Editoren damit hatten.

Ich will nicht in Abrede stellen, daß der durchschnittliche Surfer im Mittel davon profitiert und vielleicht auch nie etwas davon merkt.

Ich halte es aber für fragwürdig und juristisch riskant, offiziell “Internet” zu verkaufen und dann heimlich, ohne das irgendwo mitzuteilen, Proxies dazwischenzuschalten. Das birgt eine ganze Menge von Gefahren:

• Logfiles beim Client erzeugen falsche Daten
• Es führt, wie sich in einigen Blogs und Foren nachlesen läßt, zu Funktionsstörungen. Und damit auch zu Aufwand und Arbeitszeit, wenn man an der falschen Stelle nach der Ursache sucht.
• Die Vertraulichkeit der Daten ist kompromittiert. Der Proxy kann genau protokollieren, welche Seiten man besucht, ein- und ausgegebene Daten einschließlich Cookies und Zugangspasswörter abhören. Wer den Proxy kompromittiert hat einen Jackpot geknackt. Freilich könnte man einwenden, daß man gefälligst HTTPS verwenden möge. Das setzt aber voraus, daß der Server dies anbietet, und das geht mangels Virtualisierung von Webservern unter HTTPS (gibt’s theoretisch, hat sich aber nicht durchgesetzt) eben meist nicht. Außerdem siehe Angriff unten.
• Und natürlich beweist das auch, daß diese Proxies ohne weiteres Seiten manipulieren und weiteren Code einschmuggeln können, denn genau das tun sie ja.

  Lauert hier der Bundestrojaner?

  Ein solcher Provider-Proxy wird für Spione & Co. zum primären Angriffsziel. Schon mit dem Einschmuggeln von JavaScript kann man genügend Unfug anstellen. Vielleicht kann man dem Opfer auf die Weise auch ein falsches CA-Zertifikat unterschieben, womit man dann auch die HTTPS-Verbindungen angreifen könnte.

  Kritischer ist aber, daß ein solcher Proxy nicht nur HTML-Seiten angreifen kann. Man lädt normalerweise über Port 80 alle möglichen Binaries, die nicht über eine Signatur verifiziert werden. Geht es um ausführbare Programme (oder z. B. Programmsourcen) kann Schadsoftware unmittelbar eingeschleust werden. Aber auch bei anderen Dateiarten kann durch Modifikation was laufen. Wieder mal ein Pufferüberlauf in irgendeinem Multimedia-Format? Es ist gar nicht nötig, daß die Daten auf dem eigentlichen Webserver den Exploit enthalten. Das Beispiel zeigt ja, daß der Proxy in der Lage ist, etwa JPEG-Bilder on-the-fly durch selbsterzeugte zu ersetzen – und dadurch sogar noch einen subjektiven Geschwindigkeitsvorteil erzielt. Da kann man natürlich auch den nächsten Pufferüberlauf drin unterbringen.

Manchmal wird die Meinung geäußert, daß die Bundesregierung mit ihrem Bundestrojaner naiv sei, wenn sie glaube, daß man den einfach so in beliebige Rechner reinbringen könnte. Vielleicht ist es naiv zu glauben, daß das ein größeres Problem sei. Dabei sind vielleicht gerade Reisende mit UMTS-Zugängen besonders interessant.

Das Problem ist nicht auf Port 80 und HTTP beschränkt.

Vor ca. 2 Jahren untersuchte ich bei einem Kunden mal Mail-Probleme. Dabei stellte sich heraus, daß der Provider einen Mail-Relay transparent zwischengeschaltet hatte. Was ihn dazu veranlaßt hatte, war nicht zu erkennen, aber das war höllisch gefährlich, weil der Kunde da blauäugig vertrauliche Informationen unverschlüsselt per Mail versandte. Das wirklich Böse daran war aber, daß Mails auf dem Relay hängen geblieben war und dann in den Logfiles des Absenders (also des besagten Kunden) stand, daß die Mail ordnungsgemäß an die IP-Adresse des MX des Empfängers ausgeliefert worden sei, obwohl sie in Wirklichkeit vom transparenten Relay abgefangen und niemals beim Empfänger angekommen war. Es enstanden dadurch also unwahre Log-Einträge und zwischen Sender und Empfänger ein ziemlicher Streit darüber, wer die wichtige E-Mail vergeigt hatte.

Grundsätzlich könnte man solche Vorgänge als Verletzung des Fernmeldegeheimnisses ansehen. Bin mal gespannt, ob es da irgendwann Auseinandersetzungen oder weitere Erkenntnisse gibt.