Montag, 22. Juni 2009


Topthema

Donnerstag, 16. April 2009 | Topthema

About Security #200: Ein Rückblick auf 4 Jahre IT-Sicherheit

(Link zum Artikel: http://www.entwickler.de/entwicklerde/kolumnen/048357)

Dies ist die 200. Folge "About Security", dazu kommen jeweils vier nicht nummerierte Weihnachts-Special und CeBIT-Berichte. Damit handelt es sich um ein doppeltes Jubiläum: Die Serie wird gleichzeitig 4 Jahre alt, #1 erschien am 14.4.2005. 4 Jahre - das ist im IT-Bereich eine halbe Ewigkeit. Da lohnt es sich, mal einen Blick auf die Entwicklungen seit dem Erscheinen der alten Folgen zu werfen.

Alle bis dahin erschienenen Folgen wurden im Frühjahr 2008 leicht überarbeitet und aktualisiert. Vor allem wurden inzwischen veraltete Links korrigiert und die Verlinkung der einzelnen Folgen untereinander verbessert.

Zur Einführung in #1 bis #4 gibt es wenig Neues zu berichten. Lediglich im Fall der in #4 beschriebenen Angriffe über Firewire gibt es einige neue Entwicklungen, auf die im Standpunkt Sicherheit vom 10. März 2008 eingegangen wird. Aktuell ist im Zusammenhang mit mitgebrachter Hardware (siehe auch #126) noch die AutoRun/AutoPlay-Funktion der Betriebssysteme zu erwähnen, die am besten ausgeschaltet werden sollte. Solange sie aktiviert ist, können sich darüber Schädlinge einschmuggeln, wie z.B. aktuell der RPC-Wurm Conficker/Downadup. Und wenn die Nutzung von USB-Sticks verboten wird, kann man statt dessen ja auch einen MP3-Player verwenden.

Bei den in Folge #5 bis #10 beschriebenen Pufferüberlauf-Schwachstellen gibt es erfreuliche Entwicklungen: Sowohl in die Betriebssysteme als auch in die Compiler wurden inzwischen Schutzmaßnahmen integriert. In einigen Betriebssystemen sorgt die Nicht-Ausführbarkeit der für Daten genutzten Speicherbereiche dafür, das eingeschleuster Code nicht ausgeführt wird, und die zufällige Zuweisung der Speicherbereiche verhindert das Anspringen eingeschleusten Codes. Die entsprechenden Techniken werden als Data Execution Prevention (DEP) und Address space layout randomization (ASLR) bezeichnet. Die Compiler schreiben Prüfwerte auf dem Stack, bei deren Überschreiben durch einem Pufferüberlauf die Programmausführung abgebrochen wird. Für Microsofts Visual C++ Compiler ist dafür z.B. die Option /GS zuständig. Zwei Einträge in Microsofts Security Research & Defense Blog befassen sich mit der Wirksamkeit dieser Schutzfunktion: 'GS cookie protection - effectiveness and limitations' und 'Enhanced GS in Visual Studio 2010'. Ein weiterer, neuer Ansatz in Windows wird als Structured Exception Handler Overwrite Protection (SEHOP) bezeichnet und ebenfalls in einem Eintrag in Microsofts Security Research & Defense Blog beschrieben.

Bei den SQL-Injection-Schwachstellen, beschrieben in Folge #11 bis #13 und #166 bis #176, sind die Entwicklungen weniger erfreulich. Wurden die Schwachstellen früher meist nur zum Eindringen in den Webserver oder das Ausspähen von Daten aus der Datenbank eingesetzt, werden sie inzwischen genutzt, um Websites für Drive-by-Infektionen zu präparieren. Dazu muss lediglich ein iFrame in ein Datenbankfeld geschrieben werden, dessen Inhalt später an die Besucher der Website ausgegeben wird. Meist werden dafür quasi Brute-Force-Angriffe durchgeführt: In jedes Datenbankfeld von passendem Typ wird ein iFrame geschrieben, egal, wo diese Daten später verwendet werden. Mindestens eines der Felder wird meist unverändert ausgegeben und die Website dadurch im Sinne der Angreifer präpariert.

Cross-Site-Scripting-Schwachstellen, beschrieben in #14 und #15, #129 bis #137 sowie #158 bis #165, bleiben weiter aktuell, vor allem in Verbindung mit den in #127 und #128 beschriebenen Cross-Site-Request-Forgery-Schwachstellen: Damit lassen sich sehr leicht die in #138 bis #143 beschriebenen XSS- oder Web-Würmer realisieren - einige davon machen sich zur Zeit ja über Twitter her. Ein guter Grund, diese Schwachstellen nicht auf die leichte Schulter zu nehmen.

Zu den in Folge #17 bis #25 beschriebenen HTTP-Request-Smuggling- und HTTP-Response-Splitting-Angriffen gibt es wider Erwarten eigentlich nichts Neues zu berichten. In einigen Programmen wurden entsprechende Schwachstellen behoben, das wars dann aber auch schon. Wie man HTTP-Response-Splitting verhindert, beschreibt z.B. ein Eintrag im Blog der McAfee Avert Labs: "So web programmers: Don’t forget to filter %0d%0a in your code."

Jetzt ein kurzer Schnelldurchlauf: Zu Firewalls (#29 bis #36), der Logfile-Analyse (#37 - #41), den Intrusion-Detection- und -Prevention-Systemen (#42 - #49), den Honeypots (#50 - #52) und der Security Policy (#53 - #56) gibt es nichts erwähnenswertes Neues.

Anders sieht es dagegen im Bereich der TCP/IP-Sicherheit aus, die in Folge #57 bis #64 behandelt wird: Da gibt es die von Dan Kaminsky entdeckte Design-Schwachstelle in der DNS-Spezifikation, die 2008 für Aufsehen gesorgt hat (die entsprechenden Erkenntnisse wurden bereits in About Security #62 eingearbeitet, außerdem gibt es einen Sammel-Eintrag in Security aktuell dazu), sowie eine Schwachstelle im Border Gateway Protocol (BGP), für die ein neuer Angriff beschrieben wurde. Berichte über eine weitere gefährliche Schwachstelle scheinen dagegen übertrieben gewesen zu sein, denn davon war nichts mehr zu hören.

Im Bereich der Kryptographie, beschrieben ab #66, gibt es insbesondere eine neue Entwicklung, die berücksichtigt werden muss: Eine Schwachstelle im MD5-Algorithmus (siehe #103) erlaubt das Fälschen von SSL-Zertifikaten (siehe #82), die MD5 verwenden. Entsprechende Zertifikate können z.B. die Firefox-Erweiterung SSL Blacklist und ein Modul für das Metasploit-Framework erkennen. Didier Stevens ist es gelungen, durch Ausnutzung von MD5-Kollisionen zwei Programme zu erstellen, die zwar von Microsofts Code-Signatur-Mechanismus Authenticode die gleiche Signatur erhalten, aber unterschiedliche Funktionen erfüllen.

About Security: Alle Folgen

Zu virtuellen privaten Netzen (VPNs), die ab #88 beschrieben werden, gibt es nichts neues zu berichten. Anders sieht es wieder beim Schutz von WLANs aus, der in #105 bis #117 beschrieben wird. Eine 2008 durchgeführte RSA-Studie hat ergeben, das es mit der Sicherheit von WLAN-Netzen teilweise nicht weit her ist. Insbesondere scheinen Unternehmensnetze allgemein schlechter geschützt zu sein als die Netze von Privatpersonen. Untersucht wurde die Verbreitung und Sicherheit von WLANs in London, New York und Paris. Die Ergebnisse der Studien aus 2007 und 2008 stehen, sortiert nach Städten, zum Download bereit. Ähnliche Ergebnisse hat ein ebenfalls 2008 durchgeführter Test der WLANs in Santiago de Chile durch die Kaspersky Labs ergeben. Während es sich dabei um einfach zu korrigierende Konfigurationsfehler handelt (wenn man denn eine gar nicht vorgenommene Konfiguration auch dazu zählt), ist eine andere Entwicklung gefährlicher: Die WPA-Verschlüsselung mit TKIP wurde teilweise gebrochen, siehe diesen Blogeintrag von Raul Siles, einen Artikel bei ars technica und das Paper der Entdecker des Angriffs, Martin Beck und Erik Tews: 'Practical attacks against WEP and WPA' (PDF). Das ist ein weiterer Grund, zur sichereren WPA2-Verschlüsselung (beschrieben ab #109) zu wechseln.

Eine weitere Bedrohung bei der Nutzung unverschlüsselter WLAN-Verbindungen sind Tools zum Ausspähen von Cookies, deren 'Secure'-Flag nicht gesetzt ist: Ein Angreifer kann darüber die während einer HTTPS-Sitzung gesetzten Cookies ausspähen. Wie das geht, wird im Standpunkt Sicherheit vom 18. August 2008 beschrieben, weitere Informationen gibt es auf einer Übersichtsseite des Entdeckers der Schwachstelle, Mike Perry. Die Firefox-Erweiterung NoScript enthält eine Option, um für alle über HTTPS übertragenen Cookies das 'Secure'-Flag automatisch zu setzen. Websites, die ihre Cookies bereits vor dem Aufbau der geschützten Verbindung ungeschützt übertragen haben, werden dadurch nicht sicherer. Ebenso gibt es Probleme mit Websites, die zwar für die Anmeldung HTTPS verwenden, danach aber wieder zur ungeschützten HTTP-Übertragung wechseln. Da die Cookies dann nicht übertragen werden, wird der Benutzer nicht mehr erkannt.

Zum aktuellen Themenkomplex 'Schwachstellen-Suche in Webanwendungen', der mit #144 begann, gibt es außer den bereits oben erwähnten Ergänzungen noch nichts neues.

Einen Überblick über die ersten 99 Folgen gibt es in About Security #100, eine nach Themen sortierte Liste aller bisherigen Folgen auf meiner eigenen Website. Im Security Channel von entwickler.de gibt es eine rückwärts sortierte Liste aller bisherigen Folgen samt den jeweiligen Einleitungen.

In der nächsten Folge geht es mit der Schwachstellensuche in Webanwendungen weiter, dann werden Angriffe auf die Anwendungsarchitektur und die Suche danach beschrieben.

Wenn Sie Fragen oder Themenvorschläge haben, können Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!

Carsten Eilers

Kommentare

Folgende Links könnten Sie auch interessieren