28C3: Denial-of-Service-Attacken auf Web-Applikationen leicht gemacht
Hashverfahren in gängigen Skriptsprachen und Plattformen für Web-Anwendungen wie PHP, ASP.NET oder Java sind laut Sicherheitsforschern für einfache Angriffe mit durchschlagender Wirkung anfällig.
Sicherheitsforscher haben am Mittwoch auf dem 28. Chaos Communication Congress (28C3) in Berlin auf gefährliche Schwachstellen in gängigen Skriptsprachen und Plattformen für Web-Applikationen wie PHP, ASP.NET, Java oder Python hingewiesen. Die dort zum Einsatz kommenden Hashverfahren zum Ausfindigmachen einzelner Objekte in größeren Datenmengen seien zunächst für einfache Angriffe anfällig, die wiederum für massive "Denial of Service"-Attacken (DoS) missbraucht werden könnten, warnten Alexander 'alech' Klink von der Sicherheitsfirma n.runs und Julian Wälde von der TU Darmstadt.
Hashtabellen seien bei vielen Programmierern beliebt, führte Wälde aus. Bei diesen Verfahren könnten aber zwei verwendete unterschiedliche Schlüssel zum selben Hash-Wert beziehungsweise Tabellenfeld führen. Derartige Kollisionen könnten gezielt verstärkt werden. So sei es vergleichsweise einfach, gleichwertige Teilzeichenfolgen zu finden und willkürlich Kollisionen zu erzeugen, ergänzte Klink. Darüber hinaus könnten gängige kryptographische Attacken wie "Meet in the Middle"-Angriffe auf Hashfunktionen mit ähnlichem Effekt erfolgreich durchgeführt werden.
Web-Programmiersprachen nutzen Klink zufolge in der Regel die von Daniel Bernstein entworfenen Hashfunktionen DJBX33A oder DJBX33X. Für erstere, die etwa in PHP5, Ruby 1.8 oder Java sowie darauf basierenden Lösungen wie Tomcat und Glasfish zum Einsatz kämen, seien gleichwertige Teilketten auszumachen und so die beschriebenen Kollisionen auszulösen. PHP4, ASP.NET, Python und JavaScript verwendeten DJBX33X oder vergleichbare Algorithmen und seien mithilfe von "Meet in the Middle" aus dem Lot zu bringen.
Über die skizzierten Möglichkeiten zum Herbeiführen von Kollisionen könne ein Angreifer letztlich mithilfe einer vom Client ausgelösten Anforderung den Prozessor des Servers in Beschlag nehmen. Skriptsprachen oder Applikationsumgebungen begrenzten das Eingabefenster für eigene Daten an den Server zwar gemeinhin durch das Setzen von Parametern für die maximale Größe oder Dauer einer "Post"-Aktion, räumte Klink ein. Diese Werte böten in der Regel aber ausreichend Spielraum, um den beanspruchten Prozessor gehörig in Aktion zu halten und gegebenenfalls zu blockieren. Dazu komme die Möglichkeit, entsprechende Anforderungen über verschiedene Clients zu koordinieren.
Die Effizienz derartiger Angriffe suchte Klink mit Beispielen zu verdeutlichen: Wer bei einer PHP-Anwendung mit einer verfügbaren Bandbreite von 70 bis 100 KBit/s Post-Requests und damit verknüpfte Formulareingaben sowie Kollisionen auslöse, könne andauernd die Rechenfähigkeiten eines hochwertigen Prozessors aus der Serie Core i7 auslasten, erklärte er. Zum Lostreten entsprechender Attacken müsse ein Nutzer im schlimmsten Fall nur auf einen Link klicken, der einen der präparierten HTTP-Requests generiere, malte Klink das vor Ort in einer Demo in Grundzügen veranschaulichte Bedrohungsszenario aus.
Im Zweifelsfall werde darüber ausreichend Power für einen DoS-Angriff freigesetzt, der sehr effektiv sein und beispielsweise ein ganzes soziales Netzwerk lahmlegen könnte. Angreifbare Hashtabellen habe man auch bei Facebook ausfindig gemacht, fügte Wälde in diesem Sinne an. Derartige Funktionen seien aber genauso im Linux-Kernel, in der Programmiersprache Lua, die der "World of Warcraft"-Client verwende, in Erlang oder Objective-C im Einsatz. Die beste Abhilfe gegen das Problem liefert den Forschern zufolge die Verwendung zufälliger Hashfunktionen, wie dies bei Perl bereits seit 2003 nach einer konkreten Sicherheitswarnung der Fall sei.
Man habe im November die Entwickler der anfälligen Programmiersprachen und Applikationsplattformen informiert und damit etwa bei den Ruby-Machern oder Microsoft gute beziehungsweise vertretbare Ergebnisse erzielt; Microsoft warnt in einem eigenen Advisory. Auch die meisten anderen einschlägigen Projektbetreuer hätten die Angriffsstellen zumindest notdürftig auf Umwegen geflickt. So seien für PHP etwa die Eingabeparameter verkleinert worden. Derlei Reaktionen könnten aber nur einen ersten Schritt in die richtige Richtung darstellen. (ps)
