In dieser Woche war nicht besonders viel los, also werde ich die Gelegenheit nutzen und auf ein paar Themen eingehen, die nicht im Security-Ticker erschienen ind.

Ein neues Warnschild wird gesucht...
Und zwar eines nach der Art "Wir müssen leider draußen bleiben" für USB-Geräte: Gadi Evron hat über neue Trends bei der Nutzung von USB-Devices für Angriffe berichtet. Ein GFI-Whitepaper widmet sich dem gleichen Thema: "Pod Slurping - an easy technique for stealing data (PDF)". Ich hatte das Thema ja bereits in About Security #4, "Gefährdung aus der Peripherie", kurz angesprochen.

Einige webbasierte Themen, bunt gemischt...
Amit Klein hat darauf hingewiesen, dass dem HTTP-Host-Header nicht vertraut werden sollte, da es mehrere Möglichkeiten zu seiner Manipulation gibt.

Dragos Ruiu hat vor den neuen Netzwerkfähigkeiten gewarnt, die Adobes Flash-Player seit Version 9 besitzt. Während er dafür sieben Worte benutzte, "The new Flash player adds network functions!", hat 'Dave "No, not that one" Korn' es in drei Worten ausgedrückt: "Flash. Must. Die.". Das ist dann doch etwas sehr rigoros. Aktive Inhalte stellen eine potenzielle Gefahr dar, egal ob es nun Flash, JavaScript, ActiveX oder sonstwas ist. Und ohne würde man besser surfen, werden sie doch meist für nutzlose Spielereien oder Werbung verwendet. Aber da man den Webdesignern und Marketingabteilungen kaum eines ihrer Lieblingsspielzeuge wegnehmen kann, ohne einen Aufstand zu riskieren, werden wir damit leben müssen. Vielleicht fällt ja zumindest der Werbebranche irgendwann auf, das man potenzielle Kunden nicht mit blinkenden Flash-Filmchen vergraulen, sondern besser mit ruhig auf einen Klick wartender Text- oder Bildwerbung anlocken sollte.

David Kierznowski hat mit dem "ASP Auditor" ein Tool zur Suche nach typischen Fehlkonfigurationen und Informationslecks in ASP.NET-Anwendungen veröffentlicht.

Exploits mal anders...
Für das Exploit-Framework Metasploit wurde "VoMM (eVade-o-Matic Module for metasploit)" angekündigt, einige Details wurden ebenfalls bereits veröffentlicht. Das Tool dient dazu, die Erkennung von Browser-Exploits durch Virenscanner und ähnliche Schutzmaßnahmen zu verhindern bzw. erschweren.

Neue Ansätze mit JavaScript...
Von den SPI Labs gibt es ein neues Paper (PDF) über das "Stehlen" von Suchanfragen samt Proof-of-Concept. Nette Idee, wenn auch etwas nutzlos. Jedenfalls vorerst noch. Aber wieso "stehlen" – die Anfrage ist ja noch da. Genauso wie niemand Cookies stiehlt. Ich finde, "ausspähen" oder "ausspionieren" passt da viel besser.

Vom bereits oben erwähnten David Kierznowski gibt es "JSWebPing – JavaScript Web Ping" und den "JSEScanner – JavaScript Port Scanner". Die sind zwar akut noch nicht für Angriffe verwendbar, aber vielleicht begegnen uns die Konzepte demnächst als Teil komplexer Angriffe über Cross-Site-Scripting?

Und nun noch ein paar neue Texte von 'pdp (architect)', den ich ja schon in der Standpunkte-Kolumne vom 18. September erwähnt habe: In "Self-contained XSS Attacks" beschreibt er einen neuen Angriffsvektor für Cross-Site-Scripting: "Sich selbst enthaltende Angriffe". Dabei handelt es sich um Cross-Site-Scripting-Code, der keine Schwachstelle benötigt, sondern aus sich selbst heraus lauffähig ist. Dazu wird das data://-Protokoll genutzt, sodass übliche Cross-Site-Scripting-Filter entsprechende Angriffe schlicht nicht erkennen. "A bag full of tricks" behandelt das Thema, was man denn mit JavaScript noch anstellen kann. In "Traversing the Web" geht es um den Ausbruch aus dem 'Same-Origin'-Sicherheitsmodell der Webbrowser. Der "Javascript Spider" ist ein erster Proof-of-Concept dazu. Und wie wäre es mit einem SQL-Wurm, der sich selbstständig neue Schwachstellen über Google sucht? In "Google Search API Worms 3" geht es um solches (noch theoretisches) Ungeziefer. Seine Tools fasst 'pdp (architect)' in der "AttackAPI" zusammen.

Klein, kleiner, am kleinsten...?
Ein Programm, das ein anderes aus dem Internet lädt und danach ausführt in 411 Byte gibt es nicht? Gibt es doch. Und weil klein nicht klein genug ist, wurde eine Challenge daraus. Der nächste Schritt waren 384 Bytes, aktuell sind es noch 304 Bytes. Daran sollten sich Anwendungsentwickler mal ein Beispiel nehmen. Nein, nicht am "aus dem Internet nachladen", an der Programmgröße natürlich!

Ich bin gespannt, wo das noch hinführt ... braucht man demnächst eine Bit-Lupe zur Erkennung von Schädlingen?

Carsten Eilers