© saicle/Shutterstock.com
Server, Client, Protokolle ... - Wie steht es aktuell um die Sicherheit im Web?

Alles sicher oder was?


Die Zeit der Schwachstellen und Angriffe mit klangvollen Namen wie ShellShock und Heartbleed scheint vorbei zu sein. Aber auf den Sicherheitskonferenzen wurden trotzdem etliche neue bzw. verbesserte Angriffe vorgestellt.

Erinnern Sie sich noch? 2014 sah es zeitweise so aus, als ginge das ganze Internet in Flammen auf. Immer neue Schwachstellen und Angriffe mit klangvollen Namen wie ShellShock, Heartbleed, Poodle und Co. wurden entdeckt, und man kam aus dem Patchen kaum noch heraus [1], [2].

2016 konnte nicht mit so schönen Namen für seine Schwachstellen aufwarten, und zugegeben, auch nicht mit derartig spektakulären. Trotzdem wurden auf den Sicherheitskonferenzen zig Vorträge zu neuen oder verbesserten Angriffen auf, Schwachstellen in und Schutzmaßnahmen für Webanwendungen, -server und -clients gehalten. Zeit, da mal einen Blick drauf zu werfen.

Vertrauen Sie einer Web-Application-Firewall?

Vladimir Ivanov hat sich die Erkennungslogik einiger Web-Application-Firewalls genauer angesehen und seine Forschungsergebnisse auf der Black Hat USA 2016 vorgestellt [3]. Und die haben es in sich, denn er konnte mehr als fünfzehn neue Möglichkeiten vorstellen, um WAFs zu umgehen. Der Workflow aller WAFs läuft ungefähr gleich ab:

  • Stufe 1: Parsen der vom Client empfangenen HTTP(S)-Pakete

  • Stufe 2: Auswahl des zu verwendenden Regelsatzes auf Basis des Typs der empfangenen Parameter

  • Stufe 3: Normalisieren der Daten

  • Stufe 4: Anwenden der Erkennungslogik

  • Stufe 5: Treffen der (hoffentlich) korrekten Entscheidung

Die Erkennungslogik hakt manchmal ein bisschen ...

Die meisten WAFs verwenden für die Erkennungslogik reguläre Ausdrücke. Nur Repsheet (Reputationslösung), HMM (Anomalieerkennung), libinjection (Tokenizer) und NAXSI (Score Builder) verfolgen andere Ansätze zur Erkennung der Angriffe. Konsequenterweise hat sich Vladimir Ivanov bei seinen Untersuchungen auf die regulären Ausdrücke konzentriert, und zwar die gut 500 Stück von OWASP CRS2, CRS3dev und CRS3rc1 für ModSecurity, PHPIDS, Comodo WAF und QuickDefense. Er ist bei diesen auf über 300 möglicherweise umgehbare Regeln gestoßen, die folgendermaßen zu unterteilen sind:

  • Syntax Bypass: Die Regel ist falsch formuliert, sodass entsprechend aufgebaute Angriffe nicht erkannt werden, siehe auch das Regexp Security Cheatsheet [4].

  • Logical Bypass: Ein Logikfehler in einer Blacklist führt dazu, dass entsprechend aufgebaute Angriffe nicht erkannt werden.

  • Unexpected by primary logic bypass: Die Webanwendung oder Teile davon wie z. B. die SQL-Datenbank akzeptiert eigentlich ungültige Daten als korrekt, worauf die WAF-Regeln nicht vorbereitet sind. Zur Suche nach möglichen SQL-Injection-Angriffen dient der CPP-SQL-FUZZER [5].

Einige Möglichkeiten zum Umgehen der WAF wurden direkt vorgestellt, andere darf jeder selbst suchen und ausprobieren.

... und maschinelles Lernen hilft bei der Suche nach Fehlern

George Argyros und Ioannis Stais haben auf der Black Hat Europe 2016 ebenfalls verschiedene Möglichkeiten vorgestellt, um WAFs zu umgehen [6]. Um diese Möglichkeiten zu finden, haben sie mithilfe maschinellen Lernens Modelle der WAFs erstellt. Danach wurde daraus manuell oder automatisiert eine Grammatik konstruiert, die mögliche Angriffe beschreibt. Diese Angriffe wurden anschließend ausprobiert. Wenn so keine Angriffsmöglichkeit gefunden wurde, wurde zur weiteren Analyse ein Modell der WAF aus regulären Ausdrücken konstruiert.

Mit diesen Ansätzen fanden die Forscher mehr als zehn zuvor unbekannte Schwachstellen in populären WAFs wie ModSecurity, PHPIDS und Expose, über die sie die Firewall umgehen und SQL-Injection- und XSS-Angriffe durchführen konnten. Die vorgestellten Techniken wurden im Open-Source-Python-Framework LightBulb implementiert, mit dem sich WAFs testen lassen [7].

Vertrauen Sie keiner Web-Application-Firewall, jedenfalls nicht vollständig!

Als Fazit bleibt festzustellen: Eine WAF schützt nur vor einem Teil der Angriffe. Aber mehr erwartet doch hoffentlich auch niemand ernsthaft, oder? Zumal die WAF ja nur eine zusätzliche Verteidigungslinie ist, die nur dazu dient, erkannte Angriffe gar nicht erst bis zur Webanwendung durchzulassen.

Unabhängig davon, ob es eine WAF gibt oder nicht, darf die Webanwendung natürlich generell keine Schwachstellen enthalten – was sich leicht fordern, aber nur schwer umsetzen lässt. Enthält die Webanwendung eine bekannte Schwachstelle, die über einen Exploit ausgenutzt werden kann, der sich durch die WAF schmuggeln lässt, ist sie trotz vorhandener WAF genau so gefährdet wie eine Anwendung, die ohne den zusätzlichen Schutz mit dem Internet verbunden ist. Aber zum Glück auch nicht mehr. Wenn man einmal davon absieht, dass natürlich auch die WAF selbst ein mögliches Angriffsziel ist, wenn auch im Allgemeinen kein sehr ergiebiges. Denn wenn sie richtig installiert ist, ist der Angreifer seinem Ziel nach der Kompromittierung der WAF nicht viel näher als vorher.

Aber kommen wir zurück zu den Schwachstellen in den Webanwendungen. Eine WAF macht es ziemlich schwierig, nach bisher unbekannten Schwachstellen zu suchen. Die meisten Angreifer beschränkten sich aber auf Angriffe auf bereits bekannte Schwachstellen, und die verbreiten sich dank Copy and Paste mitunter über unzählige verschiedene Webanwendungen, wie Vanessa Henderson auf der HITB GSEC Singapore 2016 gezeigt hat [8].

Copy, Paste, Schwachstelle drin!

Sie zielt dabei auf die Übernahme von Abhängigkeiten oder Codeteilen in ein anderes Projekt ab, sodass Schwachstellen aus dem Quellprojekt ins Zielprojekt übernommen werden. Für das Entstehen solcher Copy-Paste-Schwachstellen gibt verschiedene Möglichkeiten:

  • Wird eine komplette Bibliothek übernommen und verwendet, liegt eine vollständige Abhängigkeit (Full Dependency) vor. Die in der übernommenen Bibliothek enthaltenen Schwachstellen sind dann, sofern die betroffenen Funktionen verwendet werden bzw. vom Angreifer erreicht werden können, auch Schwachstellen im eigenen Projekt.

  • Werden nur einzelne Funktionen (Code Snippets) übernommen, gibt es mehrere Möglichkeiten, wie Schwachstellen entstehen können. Enthält die kopierte Funktion eine Schwachstelle, wird die natürlich mit übernommen. Durch einen Fehler beim direkten Kopieren oder auch beim Abtippen kann eine neue Schwachstelle entstehen, die nur das eigene Projekt betrifft.

  • Wird beim Portieren von Code aus einer anderen Programmiersprache ein Fehler gemacht, kann im eigenen Code eine Schwachstelle entstehen, obwohl der Ausgangscode fehlerfrei ist.

Solche Schwachstellen sind schwer zu finden?

Vanessa Henderson ist der Ansicht, dass diese Schwachstellen nur schwer zu finden seien. Ihre Kritikpunkte gelten aber eigentlich genauso für Schwachstellen in komplett selbst geschriebenem Code:

  • Der kopierte Code befindet sich nicht immer in einer Anwendung, die in der gleichen Sprache geschrieben ist: Also zumindest übernommene Codeausschnitte sollten doch wohl besser in der gleichen Sprache wie der Rest der Anwendung geschrieben sein, sonst sehe ich da gewisse Probleme beim Ausführen oder Kompilieren der Anwendung auf den Entwickler zukommen. Aber auch sonst ist das eigentlich kein Grund, warum Schwachstellen schwerer zu finden sein sollten...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang