News Drucken: KW 27/08: Standpunkt Sicherheit

SQL-Injection in ASP-Seiten, neue Schwachstellen im Internet Explorer und eine Bitkom-Umfrage zu Spam - das sind die Themen dieses "Standpunkt Sicherheit".

SQL-Injection, immer noch

Die SQL-Injection-Angriffe gegen ASP-Seiten, bei denen die Angreifer Code zum Ausnutzen verschiedener Schwachstellen in die Websites einschleusen, laufen jetzt ja schon seit einiger Zeit. Eine erste Welle gab es im Januar, die aktuellen Angriffe laufen seit April, siehe auch den Standpunkt Sicherheit vom 28. April und 13. Mai und den Artikel 'SQL-Injection-Angriffe, wohin man blickt' vom 3. Juni. Die im Artikel gemachten Aussagen sind weiterhin gültig, und im Wesentlichen gibt es keine neuen Entwicklungen... bis auf die Tatsache, dass Microsoft am 24. Juni ein Security-Advisory dazu veröffentlicht hat: 'Rise in SQL Injection Attacks Exploiting Unverified User Data Input'.

Keine Microsoft-Schwachstelle, trotzdem ein Microsoft-Advisory

Wie bereits öfter erwähnt, wird von den Angreifern keine Schwachstelle in der verwendeten Server- oder Datenbanksoftware ausgenutzt, dem entsprechend ist also keine Microsoft-Software Ursache der Angriffe. Ausgenutzt werden SQL-Injection-Schwachstellen in den angegriffenen Webanwendungen, über die der Schadcode in die Webanwendung eingeschleust wird. Das Microsoft darauf mit einem Security-Advisory reagiert, finde ich bemerkenswert. Bravo!

Und was steht drin?

Normalerweise steht in einem Security-Advisory, welche Schwachstelle in welchem Programm gefunden und/oder behoben wurde. In diesem Fall ist das etwas anders: Microsoft macht allgemein auf das Problem aufmerksam und stellt eine Reihe Tools vor, die beim Entdecken von Schwachstellen und der Abwehr der Angriffe helfen. Zur Suche nach SQL-Injection-Schwachstellen wird HPs Scrawlr empfohlen (der beliebte 'Bobby Tables'-Comic darf natürlich nicht fehlen), das aber einen großen Nachteil hat: POST-Aktionen in Formularen werden nicht unterstützt. Wenn man bedenkt, was der Unterschied zwischen der GET- und POST-Methode offiziell ist, dann ist das Tool damit ziemlich nutzlos: GET dient der Abfrage von Daten, POST der Änderung von Daten auf dem Server (siehe z.B. RFC 2616, 'Hypertext Transfer Protocol - HTTP/1.1').

Mit anderen Worten: Dieses Tool prüft die Daten, die laut Standard in die Datenbank geschrieben werden, gar nicht. Natürlich wird oft auch GET für Änderungen auf dem Server verwendet, aber das ist kein Grund, bei der Suche nach Schwachstellen POST-Aktionen nicht zu prüfen. Dieses Programm ist also nicht nur kostenlos, sondern weitestgehend umsonst. Eine typische Testversion halt - wer mehr will, soll die Vollversion kaufen. Hier habe ich eine Reihe von Schwachstellenscannern und SQL-Injection-Tools zusammengestellt, von denen einige bessere Dienste leisten und trotzdem kostenlos sind.

Der 'Microsoft Source Code Analyzer for SQL Injection' wurde von Microsoft für die Suche nach SQL-Injection-Schwachstellen im Sourcecode entwickelt (was bei dem Namen ja wohl nahe liegt), kann aber nur mit ASP-Code in VBScript umgehen. Wer etwas anderes nutzt, kommt damit also nicht weiter. Außerdem wurde für das Tool ein neuer ASP-Parser entwickelt, der nicht mit allen zulässigen ASP-Konstruktionen klar kommt, es gibt also Parser-Fehler. Inwieweit diese die Erkennung von Schwachstellen behindern, lässt sich schlecht abschätzen. Ich vermute mal, da werden einige Schwachstellen nicht gefunden, weil der entsprechende Code gar nicht oder falsch geparst wurde.

UrlScan ist ein Tool von Microsoft, das spezielle HTTP-Anfragen an Microsofts IIS ausfiltert. Das Programm liegt vorerst nur in einer Beta-Version 3.0 vor, der Vorgänger 2.5 kann z.B. keine Query-Strings prüfen und hilft daher gegen die SQL-Injection-Angriffe wenig.

Zum Abschluss gibt es dann noch einige Links zu weiteren Informationen über SQL-Injection und deren Verhinderung, natürlich mit Schwerpunkt ASP/ASP.NET. Die sind aber auch allgemein von Interesse, denn SQL-Injection und Gegenmaßnahmen sind unabhängig von der verwendeten Programmiersprache immer gleich.

Es spukt im IE

Letzte Woche wurde eine neue Schwachstelle im Internet Explorer allgemein bekannt, die Microsoft wohl lieber noch einige Zeit unter Verschluss gehalten hätte. Die Schwachstelle wurde auf Microsofts Sicherheitskonferenz Bluehat vorgeführt, ohne Details zu veröffentlichen: Ein einmal eingeschleustes Skript verfolgte das auf das Einschleusen folgende Surfverhalten des Benutzers ('A Resident in My Domain').

Nichts bleibt lange geheim...

Wie nicht anders zu erwarten war, brachte die Geheimhaltung natürlich wenig. Der alte Grundsatz "Wenn ich weiß, dass etwas funktioniert, und es mich nur stark genug interessiert, dann bekomme ich auch heraus, wie es funktioniert" galt natürlich auch in diesem Fall. Einer der an der Schwachstelle Interessierten war der auch als sirdarckcat bekannte Eduardo Vela, der die Schwachstelle im IE 7 und IE 8 recht schnell ermittelte.

Ghostbusters in den Einsatz, bitte...

Ursache der Schwachstelle im IE 7 und IE 8 ist die Möglichkeit, die Cross-Domain-Policy auszuhebeln. Mit anderen Worten: Während eigentlich Zugriffe auf Fenster oder Frames, die zu anderen Domains gehören, nicht möglich sein sollen, sind sie durch die Schwachstelle doch möglich. Konkret geht es darum, die Schutzmaßnahmen beim Zugriff auf die location-Eigenschaft eines Fensters oder Frames zu umgehen. Im IE 7 und IE 8 reicht es dazu aus, statt eines Strings ein Objekt zu verwenden, um danach z.B. die Tastendrücke in anderen Fenstern protokollieren zu können. Auch, nachdem die URL einige 100-mal gewechselt wurde. Eine ähnliche Schwachstelle befand sich auch im IE 6, diese ist aber im IE 7 nicht mehr vorhanden.

Ist das schlimm? Das ist schlimm!

Der Keylogger allein sieht ja erst mal nur ganz putzig aus, das Potenzial in dieser Schwachstelle ist aber gigantisch: Bisher wird bei den am Anfang erwähnten Angriffen auf ASP-Seiten Code zum Ausnutzen von Schwachstellen eingeschleust, um darüber die Kontrolle über die Rechner der Besucher zu übernehmen. Stattdessen könnte aber auch so ein Keylogger eingeschleust werden, der dann alle danach eingegeben vertraulichen Informationen an den Angreifer schickt. Und dabei ist es vollkommen egal, ob die Seiten über HTTP oder das verschlüsselte HTTPS angesurft werden - die Daten werden bereits im Browser abgegriffen, bevor die Verschlüsselung für die Übertragung zum Tragen kommt.

Auch du, mein Sohn Firefox?

Während die Schwachstelle bisher nur für den Internet Explorer bestätigt wurde, sind laut Nathan McFeters alle Browser betroffen. Dabei stellt sich die Frage, ob wirklich alle Browser unabhängig voneinander betroffen sind, oder ob es ein Problem in irgendeiner Spezifikation ist.

Bitkom-Umfrage: Spam ist ein Problem

Ach, was die nicht sagen. Und dafür brauchen sie eine Umfrage? Mir reicht dazu ein Blick in meine Spamordner und Mailfilter. Ganz entzückend finde ich auch den ersten Anti-Spam-Tipp: Komplizierte E-Mail-Adresse wählen. Genial. Natürlich verhindert man damit, dass die Spammer diese Adresse erraten. Aber möchten Sie wirklich irgendjemanden "Meine Mailadresse ist quetzlopqyzt135@meine-domain" diktieren? Oder denken Sie, dass jemand diese Adresse von Ihrer Visitenkarte abtippt? Ich würde beide Fragen mit 'nein' beantworten, entsprechend bin ich auch (unter anderem) über die info@-Adressen meiner Domains zu erreichen. Auch die anderen Bitkom-Tipps sind verbesserungswürdig, aber da dieser Text schon ziemlich lang ist, werde ich darauf später mal eingehen.

Carsten Eilers