RegEx auf dem Rückzug

Reguläre Ausdrücke sind eine prägnante Art, den Abgleich bestimmter Token-Muster oder Sequenzen (meist Text) zu beschreiben. Aber ist der Abgleich von Textsequenzen ein effektiver Ansatz, um Malware oder Angriffe auf Webanwendungen zu erkennen? Oder genauer gesagt: Bei welchen Typen von Webangriffen sind reguläre Ausdrücke (RegEx) effektiv? Schließlich wollen wir nicht im Hier und Jetzt gefangen sein und unsere Sicherheitsbemühungen sabotieren, indem wir an inaktiven Lösungen festhalten.

RegEx sind nützlich bei Nachahmungstaten, die besonders bei unerfahrenen Angreifern beliebt sind, das heißt, wenn der Angreifer die Angriffsmechanik nicht versteht, weil jemand anderer sie für ihn entwickelt hat. Als Amateure setzen unerfahrene Angreifer bekannte Angriffstaktiken einfach um und bombardieren damit über Tools wie Shodan das Internet. Aber damit wären wir mit unserer Liste der Anwendungsfälle, für die RegEx eine effektive Strategie darstellen, auch schon am Ende.

Diejenigen, die die wiederverwendbaren Teile des Angriffs entwickelt haben, wissen, wie sie den einfachen Musterabgleich von RegEx durch einige Änderungen umgehen können. Tatsächlich ist die genaue Token-Sequenz gar nicht so wichtig, es kommt vielmehr auf das vollständige Token an. 

Was zählt, ist der Ablauf des Angriffs. Die jeweiligen Bits bzw. der Text sind nur ein kleiner Bestandteil der Implementierung und beschreiben nicht, wie der Angriff funktioniert. 

Stellen Sie sich doch einfach mal einen Fernseher vor, der von der Wand genommen wird. Ist es dabei grundsätzlich hilfreich zu wissen, welcher Schraubenzieher dafür verwendet wird? Wenn wir den Fernseher mithilfe eines Schraubenziehers selbst von der Wand nehmen, um seine Höhe anzupassen, vielleicht schon. Aber was, wenn stattdessen das Wohnzimmerfenster eingeschlagen wird und ein Einbrecher den Fernseher anschließend einfach aus der Wand reißt?

Im Grunde genommen bedeuten Textmuster in verschiedenen Situationen unterschiedliche Dinge und führen zu unterschiedlichen Ergebnissen. Auf den Kontext kommt es an! Eine Beschreibung eines SQL Injection (SQLi)-Exploits in einem Blogpost ist etwas ganz anderes als ein SQLi-Angriff auf den Betreiber des Blogs. Beide enthalten zwar das für diese Angriffsklasse repräsentative Textmuster, aber nur bei einem davon handelt es sich um einen echten Angriff.

Das soll natürlich nicht heißen, dass reguläre Ausdrücke grundsätzlich nutzlos wären. Schließlich handelt es sich dabei um idiomatische und relativ leicht lesbare, abgespeckte Versionen eines Musterabgleichs. Das Problem liegt im Musterabgleich selbst, und zwar in der Tatsache, dass Pattern Matching Tokens wie Text in Query-Parametern oder POST-Body-Felder nur die einfachsten Angriffe erkennen. Dasselbe gilt auch abseits von Webanwendungen: Eine RegEx für einen bestimmten Datei-Hash setzt voraus, dass der Angreifer so unmotiviert und unvorsichtig ist, dass er sich nicht die Mühe macht, die Datei so umzuschreiben, dass sie von einem so einfachen Erkennungsmechanismus nicht entdeckt wird. Das mag zwar bisweilen der Fall sein, meistens aber nicht.

Sogar wenn wir die Genauigkeit außer Acht lassen, können RegEx einen überwältigenden Mehraufwand bei der Angriffsabwehr verursachen. Sie sind oft unflexibel, unhandlich und schwer zu verwalten – vor allem, wenn man versucht, sie mit mehr Kontext zu versehen. Der Versuch, eine Liste gültiger Linux oder Windows Befehle zu erfassen, um Command Injection zu erkennen, wäre zum Beispiel mit RegEx nur schwer umsetzbar, wenn nicht sogar unmöglich. Dasselbe gilt für SQLi. Das daraus resultierende Muster wäre für den Menschen unlesbar, was nicht akzeptabel ist (selbst wenn man RegEx-Grammatiken erstellt). 

Sehen wir uns zum Beispiel diesen „einfachen“ regulären Ausdruck für die Validierung einer E-Mail-Adresse an:

`(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:(2(5[0-5]|[0-4][0-9])|1[0-9][0-9]|[1-9]?[0-9]))\.){3}(?:(2(5[0-5]|[0-4][0-9])|1[0-9][0-9]|[1-9]?[0-9])|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])`

Würden Sie diesen gerne mit bloßem Auge auseinanderklamüsern oder kommt Ihnen das Ganze ein wenig spanisch vor?

Bildquelle

Wenn Sie mit neu entstehenden oder sich entwickelnden Angriffstechniken und -mustern Schritt halten wollen, bedeutet der damit verbundene Aufwand (Zeit, Mühe, Koffein usw.), dass Änderungen seltener vorgenommen werden und somit die Wirksamkeit Ihrer Lösung abnimmt. RegEx können auch zeit- und ressourcenaufwändig sein, insbesondere, wenn es sich um komplexe Ausdrücke handelt, die schwer zu optimieren sind. Ob menschlicher Overhead oder Performance Overhead, das Kosten-Nutzen-Verhältnis bei der Erkennung von Angriffen mittels RegEx rechnet sich letztlich nicht.

Verstehen Sie mich nicht falsch, RegEx haben durchaus ihre Daseinsberechtigung, nur nicht bei der Erkennung von Angriffen. Viele Anbieter versuchen, ihren Kunden dies zu verheimlichen, da es weitaus kostengünstiger ist, bestehende Technologien zu pflegen, als in Innovationen zu investieren. Ungeachtet jeglicher Bemühungen zeigen sich Angreifer von RegEx oft unbeeindruckt, denn es entstehen ihnen dadurch keine höheren Kosten. 

Methoden wie das Parsen von HTTP-Anfragen erweisen sich als wirtschaftlichere Investition. Sie ermöglichen es, bei der Angriffsabwehr den Kontext besser zu berücksichtigen und gleichzeitig den Aufwand für Mensch und Maschine zu verringern. Durch die Analyse des Angriffsverhaltens werden sowohl sämtliche Varianten rudimentärer als auch aufwändigerer Angriffe abgefangen, ohne dass für jede neue Sicherheitslücke eine neue Regel aufgestellt werden muss. Wenn wir uns den Angriffskontext und die Verarbeitung einer Anfrage in der Laufzeitumgebung anschauen, können wir genauere Entscheidungen treffen als mit RegEx.

Dieser Gedanke bringt mich zur heutigen Marktverzerrung: Auf den Checklisten der Kunden von Sicherheitslösungen für Web-Apps (und oft auch für andere Produkte) steht nach wie vor der „RegEx-Abgleich“ unter den Schlüsselfunktionen, obwohl er unzureichend ist. (Dasselbe ist übrigens auch bei anderen Produkten der Fall, zum Beispiel bei YARA-Regeln in Endpoint-Tools). Diese Anforderung hat Kunden eine Zeit lang gute Dienste erwiesen, als die Produkte der meisten Anbieter noch auf RegEx basierten und als es noch keine besseren Lösungen gab. Die Zeiten haben sich allerdings geändert.

Nehmen Sie Ihre Scheuklappen ab und aktualisieren Sie Ihre Checklisten

Stellen Sie sich zur Veranschaulichung einfach mal folgendes Szenario vor: Ein Kunde betritt ein Autohaus und fragt, ob das Auto Scheuklappen hat. 

„Nein“, antwortet die Verkäuferin verdutzt. „Ein Auto braucht keine Scheuklappen.“ Der Kunde schüttelt missbilligend den Kopf und tippt auf seine Checkliste.

„Und was ist mit einer Pferdepeitsche?“, fragt der Kunde weiter.

„Sie brauchen auch keine Pferdepeitsche. Moderne Fahrzeuge werden nicht mehr von Pferden gezogen.“

„Als Nächstes erzählen Sie mir wohl, dass es hier auch kein Geschirr und kein Zaumzeug gibt!“

„Korrekt! Wir verkaufen Autos.“ Die Verkäuferin kneift sich seufzend in den Nasenrücken und fragt: „Was genau ist eigentlich Ihr Ziel?“

„Zügig von A nach B zu kommen“, antwortet der selbstbewusste Kunde.

„Verstehe. Ein Auto ist für Ihre Zwecke viel besser geeignet als eine Pferdekutsche. Es ist aus gutem Grund so konzipiert. Es handelt sich dabei um eine Innovation, die Ihnen das Leben leichter machen soll“, so die Verkäuferin.

„Und trotzdem fehlen ihm alle diese wichtigen Eigenschaften?“, entgegnet der Kunde.

Dieses Beispiel ist offensichtlich absurd, und doch ähnelt es so manchen Unterhaltungen, die heute im Bereich der Cybersicherheit geführt werden. Verständlicherweise klammern sich Käufer an ihren gewohnten Anforderungskatalog. Schließlich sind Fragen nach Scheuklappen, Peitschen und Zaumzeug beim Kauf einer Pferdekutsche durchaus angebracht. Aber diese Checklisten sind in der Regel statisch und oft längst überholt.

Wir beklagen uns über schnelle, sich ständig weiterentwickelnde Angriffsmethoden, und dennoch wählen wir unsere Produkte allzu oft anhand von technischen Merkmalen aus, die nur in grauer Vorzeit angemessen waren. Angreifer halten sich ihre Optionen offen und wählen die richtigen Tools, um ihre Ziele zu erreichen. Wir sollten bei der Angriffsabwehr dasselbe tun. So können wir unter anderem neuere, bewährte Abwehrtechniken wie das Parsen von Anfrageparametern in Betracht ziehen, um die Ergebnisse einer Anfrage in der Laufzeitumgebung zu analysieren – und so mehr Geschwindigkeit, Genauigkeit und Flexibilität zu erreichen.

Es ist nicht leicht, sich einzugestehen, dass unsere Gedankenmodelle auf einem bestimmten Gebiet falsch und veraltet sind oder dass sich die Realität schneller entwickelt hat, als uns lieb ist, wo wir doch so viele Ressourcen in diese letztlich fruchtlosen Bemühungen gesteckt haben. Und genau diese Unbeweglichkeit, diese unbestrittenen Annahmen machen sich Angreifer zunutze. Wenn wir Angreifern zuvorkommen wollen, müssen wir über den RegEx-Tellerrand hinausblicken und eine modernere Ära der Angriffserkennung einläuten.

Erfahren Sie mehr darüber, wie Fastly sich bei der Angriffsabwehr auf Parsing anstatt auf RegEx verlässt. Lesen Sie unser Datenblatt zum Thema SmartParse Erkennung oder unseren Blogpost über das Parsing bei Log4Shell-Angriffen. Oder fordern Sie eine kostenlose Testversion an. Wir zeigen Ihnen gerne, wie alles funktioniert.