Suchpfade sind eine nützliche Erfindung, gäbe es sie nicht,
wüssten die Programme nicht, wo sie ihre Bibliotheken und Daten finden
und müssten das gesamte Dateisystem durchsuchen. Stimmt der Suchpfad
nicht, kann das unangenehm werden, weil die gesuchte Dateien nicht gefunden
werden. Oder weil Dateien gefunden werden, die besser nicht gefunden
worden wären: Bibliotheken mit Schadcode zum Beispiel. Falls Sie bei
diesen vielen Fundstellen den Überblick verloren haben - kein Problem,
auch vielen Programmen ergeht es so. Also werfen wir doch mal einen
genaueren Blick auf das Problem mit den unsicheren Suchpfaden. Aber zuerst
noch ein wichtiger Rat: "Don't Panic!" - weder gibt es 40 oder
mehr 0-Day-Schwachstellen in eben so vielen Programmen noch eine einzige in
Windows. Jedenfalls keine, die mit dem Suchpfad zusammen hängen.
Der Klassiker: Unsichere Suchpfade unter Unix/Linux
Ein externer Angreifer, der auf das Web-basierte Administrations-Interface
des lokalen Routers zugreifen kann, und das womöglich auch noch interaktiv
- das klingt eigentlich ziemlich unmöglich. Genau das hat aber Craig
Heffner auf der Konferenz "Black Hat USA 2010"
gezeigt.
Besonders erstaunlich ist, dass es sich dabei eigentlich nur um die
Kombination einiger altbekannter Angriffe und Schwachstellen, insbesondere
DNS-Rebinding, handelt. Auch eigentlich längst als erledigt geglaubte
Angriffe oder Schwachstellen sind also immer noch für eine
Überraschung gut
(Paper
und
Präsentation
als PDF).
In dieser Folge gibt es eine Beschreibung der Grundlagen des Angriffs, d.h.
der alten Angriffe und Schwachstellen, in der nächsten Folge dann die
des eigentlichen Angriffs sowie mögliche Gegenmaßnahmen.
Wirklich interessante Vorfälle, die es zu kommentieren lohnt, gab es
in der vergangenen Woche eigentlich nicht. Streetview als Dauer-Reizthema
wollte ich eigentlich ignorieren, aber mangels anderer Themen und der
schönen Vorlage des Google-Europachefs, der meint, Google würde
die Privatsphäre achten, mache ich mal eine Ausnahme
Md Sohail Ahmad von AirTight Networks hat eine Schwachstelle in der
Spezifikation des WLAN-Sicherheitsprotokolls WPA2 entdeckt: Die "Hole196"
genannte
Schwachstelle
erlaubt es einem Benutzer, der den Broadcast-Schlüssel GTK (Group
Temporal Key) kennt, als Access Point getarnt eigene Brodcast-Pakete zu
versenden und Antworten darauf zu entschlüsseln.
In der Exploit-DB tauchen immer mehr Exploits auf, die das Umgehen der
Schutzfunktionen DEP (Data Execution Prevention) und ASLR (Address Space
Layout Randomization) erlauben, wichtige Anwendungen einschließlich
Virenscannern nutzen sie gar nicht, und Microsoft hält Fehler, die ihr
Umgehen erleichtern, nicht für Schwachstellen - sind DEP und ASLR also
überflüssig?
Das Erkennen und Abwehren von Drive-by-Infektionen bildet den Abschluss
dieses Themas. Der Benutzer bemerkt im Allgemeinen nichts von einer
Drive-by-Infektion. Evtl. stürzt irgendwann der Webbrowser oder eine
der Komponenten ab, die Schadsoftware selbst verhält sich aber meist
vollkommen unauffällig. Eine Ausnahme stellt dabei Scareware dar, die
den Benutzer durch die Warnung vor nicht vorhandenen Gefahren zum Kauf
eines Fake-Virenscanners verleiten soll. Auch den präparierten
Webseiten sieht man die Bedrohung i.A. nicht an. Falls ein iframe für
das Einschleusen des Schadcodes verwendet wird, wird er durch Verwenden
einer Höhe oder Breite von 0 vor dem Benutzer verborgen, die
script-Tags fallen einem normalen Benutzer sowieso nicht auf.
Daher kann der Benutzer selbst fast nichts gegen die Angriffe unternehmen.
Wird das Fenster, in dem der bösartige JavaScript-Code läuft,
geschlossen, wird der Angriff zwar beendet, aber bis es dazu kommt ist es
i.A. schon zu spät und der Schadcode installiert. Der Benutzer muss
also schon im Vorfeld aktiv werden und vor allen Dingen ...
Einige Länder interessiert brennend, was für Nachrichten die
Leute wohl mit ihren Blackberrys verschicken. Und weil sie die nicht lesen
können, werden sie sauer. Dass sie auch andere verschlüsselte
Nachrichten nicht lesen können, stört dagegen nicht weiter.
Merkwürdig, oder?
Im Adobe Reader wurde mal wieder eine 0-Day-Schwachstelle gefunden, und
kaum jemanden interessierts. Auf eine Schwachstelle mehr oder weniger
kommt es bei dem Programm ja nun auch wirklich nicht an.
Eine einzige 0-Day-Schwachstelle im Adobe Reader - na und?
In der
vorhergehenden Folge
wurde der Anfang einer Drive-by-Infektion beschrieben: Die Seite, die die
verschiedenen Exploits einbindet, mit denen dann versucht wird, den
Rechner des Besuchers mit Schadsoftware zu infizieren, sowie ein erster
dieser Exploits. In dieser Folge werden zwei weitere Angriffe vorgestellt.
Unverbindliche Allgemeine Geschäftsbedingungen - sowas hat nicht
jeder. Nur die ePost. Eigentlich will sowas ja auch keiner. Wer sich die
Mühe macht, sich AGB anzulegen, will ja gerade, dass die gelten.
Wären sie dann unverbindlich, könnte man sich die Mühe auch
sparen. Vielleicht hätte die Post das auch besser tun sollen.
Andererseits müsste ich mir dann ein anderes Thema für
diesen Standpunkt suchen und könnte nicht einfach dem
RFC aus der vorigen Woche
folgen. Oder war der Kommentar kein Request for Comments?