Bericht zum Thema Anwendungssicherheit für das zweite Quartal 2023

Cloudflare kann das Internet aus einer einzigartigen Perspektive betrachten. Dadurch sind wir in der Lage, Trends zu erkennen und zu erforschen, die sonst unbemerkt bleiben würden. Durch diesen Bericht lassen wir Sie an den Erkenntnissen teilhaben, die wir dabei zu Internettrends im Bereich Anwendungssicherheit gewonnen haben.

Es handelt sich um die dritte Ausgabe dieses Berichts. Die erste wurde im März 2022 veröffentlicht und die zweite im März 2023. Der aktuelle Report deckt erstmals einen Zeitraum von drei Monaten ab.

Seit dem letzten Bericht ist unser Netzwerk gewachsen und schneller geworden: Wir verarbeiten jetzt im Durchschnitt 46 Mio. HTTP-Anfragen pro Sekunde und zu Spitzenzeiten 63 Mio. pro Sekunde. Beständig werden von uns etwa 25 Mio. DNS-Abfragen pro Sekunde verarbeitet. Das sind etwa 2,1 Bio. DNS-Abfragen am Tag und 65 Bio. im Monat. Dabei handelt es sich um die Summe der von unserer Infrastruktur verarbeiteten Anfragen an Nameserver und Resolver. Werden HTTP- und DNS-Anfragen zusammengezählt, kommt eine ganze Menge schädlicher Traffic zusammen. Betrachtet man allein die HTTP-Anfragen, hat Cloudflare im zweiten Quartal 2023 durchschnittlich 112 Mrd. Cyberbedrohungen pro Tag blockiert. Das sind die Daten, die diesem Bericht zugrunde liegen.

Bevor wir stärker in die Tiefe gehen, sollen wie gewohnt die von uns verwendeten Begriffe definiert werden.

In diesem Bericht werden die folgenden Begriffe verwendet:

• Von Prüf- oder Abwehrmaßnahmen betroffener Traffic: HTTP*-Anfragen von Endnutzern, bei denen eine „Beendigungs“-Maßnahme durch die Cloudflare-Plattform ergriffen wurde. Dazu gehören die folgenden Maßnahmen: BLOCK (blockieren), CHALLENGE (mit einer Aufgabe prüfen), JS_CHALLENGE (mit JavaScript prüfen) und MANAGED_CHALLENGE (mit verwalteten Aufgaben prüfen). Nicht darunter fallen Anfragen, auf die mit den folgenden Maßnahmen reagiert wurde: LOG (protokollieren), SKIP (überspringen) und ALLOW (zulassen). Im Gegensatz zum vergangenen Jahr werden nun Anfragen ausgeschlossen, auf die unser DDoS-Abwehrsystem mit CONNECTION_CLOSE (Verbindung beenden) und FORCE_CONNECTION_CLOSE (Beenden der Verbindung erzwingen) reagiert hat. Der Grund dafür ist, dass diese die Verbindungsherstellung genau genommen nur verlangsamen. Außerdem haben sie nur einen relativ kleinen Teil der Anfragen ausgemacht. Darüber hinaus haben wir unsere Berechnungen bezüglich der Maßnahmen der Kategorie CHALLENGE optimiert, um sicherzustellen, dass Traffic nur als abgewehrt eingestuft wird, wenn Aufgaben nicht gelöst wurden. Eine ausführliche Beschreibung der einzelnen Maßnahmen finden Sie in unserer Dokumentation für Entwicklerinnen und Entwickler.

• Bot-Traffic/automatisch generierter Traffic: HTTP*-Anfragen, von denen das Bot-Management-System von Cloudflare zu dem Ergebnis kommt, dass sie von einer Maschine stammen. Dazu gehören Anfragen mit einem Bot-Score von 1 bis 29. Daran hat sich gegenüber dem letztjährigen Bericht nichts geändert.

• API-Traffic: HTTP*-Anfragen, bei denen der MIME-Typ XML oder JSON für die Antwort festgelegt ist. Wenn keine Angabe zum MIME-Typ der Antwort verfügbar ist, wie bei Anfragen, die Prüf- oder Abwehrmaßnahmen unterzogen wurden, wird stattdessen auf den gleichwertigen MIME-Typ Accept (der vom User Agent angegeben wird) zurückgegriffen. Im zweiten Fall wird der API-Traffic zwar nicht in vollem Umfang berücksichtigt, doch diese Fälle tragen trotzdem zum Erkenntnisgewinn bei.

Sofern nicht anders angegeben, wird im vorliegenden Beitrag der Zeitraum von April bis Juni 2023 betrachtet.

Abschließend möchten wir noch darauf hinweisen, dass die Daten allein auf Grundlage des Datenverkehrs erhoben werden, der im Cloudflare-Netzwerk registriert wird. Somit spiegeln sie nicht notwendigerweise die Muster des HTTP-Traffics im gesamten Web wider.

* Mit HTTP-Traffic ist hier sowohl HTTP- als auch HTTPS-Datenverkehr gemeint.

Die Zahl der täglich von Prüf- und Abwehrmaßnahmen betroffenen HTTP-Anfragen ist von 2021 auf 2022 um zwei Prozentpunkte auf durchschnittlich 6 % gesunken. Doch an bestimmten Tagen wurden im Netzwerk überdurchschnittlich viele bösartige Aktivitäten registriert. Ein gutes Beispiel dafür zeigt die folgende Grafik: Ende Mai 2023 ist ein Anstieg von fast 8 % zu verzeichnen. Das ist auf große DDoS-Vorfälle und andere Aktivitäten zurückzuführen, die nicht den üblichen täglichen oder wöchentlichen Zyklen unterworfen sind. Diese Beobachtungen dienen als Erinnerung daran, dass große schädliche Ereignisse immer noch eine sichtbare Auswirkung auf weltweiter Ebene haben können – selbst bei einem Maßstab wie dem, den Cloudflare setzt.

75 % der von Prüf- oder Abwehrmaßnahmen betroffenen HTTP-Anfragen wurden direkt blockiert. Das entspricht einem Rückgang um sechs Prozentpunkte gegenüber dem im vorangegangenen Bericht vermeldeten Wert. Die meisten anderen Anfragen werden mit einer der CHALLENGE-Maßnahmen geprüft und gegebenenfalls blockiert, wobei in diesem Teilbereich verwaltete Challenges rund 20 % ausmachten und damit die Nase vorn hatten.

Im letzten Bericht war unser automatisiertes DDoS-Abwehrsystem im Durchschnitt noch für mehr als 50 % der Fälle verantwortlich, in denen Datenverkehr blockiert oder geprüft wurde. Doch in den letzten zwei Quartalen hat sich ein neuer Trend herausgebildet: Der Anteil von WAFs an den Prüf- und Abwehrmaßnahmen ist inzwischen höher als der des DDoS-Abwehr.systems Das ist einerseits auf die zunehmende Verbreitung von WAFs zurückzuführen, aber wahrscheinlich auch auf den Umstand, dass Unternehmen ihre Anwendungen besser konfigurieren und gegen unerwünschten Datenverkehr absichern. Die Zunahme ist überwiegend nicht auf unsere Managed Rules für WAFs, sondern auf benutzerdefinierte WAF-Regeln zurückzuführen, die auf das Blockieren abzielen. Das deutet darauf hin, dass diese Prüf- und Abwehrmaßnahmen durch Regeln ausgelöst werden, die von Kunden für Geschäftslogik oder ähnliche Zwecke konfiguriert wurden. In der folgenden Grafik ist das deutlich zu erkennen.

Wie Sie sehen können, sind die durch unsere Managed Rules für WAFs eingeleiteten Prüf- und Abwehrmaßnahmen (orange Linie) im Vergleich zum gesamten von der WAF abgewehrten oder geprüften Traffic vernachlässigbar. Das deutet auch darauf hin, dass die Kunden positive Sicherheitsmodelle anwenden, indem sie bekanntermaßen gutartigen Datenverkehr zulassen, anstatt nur bekanntermaßen schädlichen zu blockieren. Allerdings belaufen sich die Prüf- und Abwehrmaßnahmen der Managed Rules für WAFs während des Quartals trotzdem auf bis zu 1,5 Mrd. am Tag.

Unsere DDoS-Abwehr ist natürlich volumetrisch. Die Menge an Traffic, die unseren DDoS-Layer-7-Regeln entspricht, sollte nicht unterschätzt werden – vor allem, wenn man bedenkt, dass die Ausbreitung einer einer Reihe neuartiger Angriffe und Botnetze im Internet zu beobachten ist. Näheres dazu erfahren Sie in unserem Bericht zu DDoS-Bedrohungen im zweiten Quartal.

Wenn man alle Prüf- und Abwehraktionen zusammennimmt, ist die WAF inzwischen für etwa 57 % davon verantwortlich. Es folgt eine tabellarische Übersicht mit verschiedenen Ursprüngen für Prüf- und Abwehrmaßnahmen.

Ursprung

Source	Percentage %
WAF	57%
DDoS Mitigation	34%
IP Reputation	6%
Access Rules	2%
Other	1%

Anteil %

WAF

Field	Used in percentage % of rules
Geolocation fields	40%
HTTP URI	31%
IP address	21%
Other HTTP fields (excluding URI)	34%
Bot Management fields	11%
IP reputation score	4%

57%

DDoS-Abwehr

34%

IP-Reputation

6%

Access Rules

Source	Percentage %
HTTP Anomaly	32%
SQLi	13%
Directory Traversal	10%
File Inclusion	9%
DoS	9%
XSS	9%
Software Specific	7%
Broken Authentication	6%
Common Injection	3%
CVE	1%

2%

Sonstige

1%

In Anbetracht der Zunahme des Prüf- und Abwehrmaßnahmen unterzogenen Datenverkehrs durch von Kunden definierte WAF-Regeln ist es lohnenswert, eine Ebene tiefer zu gehen und uns ein besseres Bild davon zu verschaffen, was von den Kunden blockiert wird und wie. Dafür können wir uns anschauen, wie die Regelfelder in unseren benutzerdefinierten WAF-Regeln benutzt wurden, um Gemeinsamkeiten auszumachen. Natürlich müssen die Daten richtig ausgewertet werden, denn nicht alle Kunden können auf sämtliche Felder zugreifen, da dies je nach Vertrag und Tarif variiert. Trotzdem lassen sich anhand von Feld-„Kategorien“ einige Rückschlüsse ziehen. Wenn wir uns die rund 7 Mio. benutzerdefinierten WAF-Regeln ansehen, die im gesamten Netzwerk zum Einsatz kommen, und uns nur auf die Hauptgruppen konzentrieren, ergibt sich folgende Verteilung der Feldnutzung:

Feld

Anteil an den eingesetzten Regeln

Geolocation

40%

HTTP-URI

31%

IP-Adresse

Source	Percentage %
WAF	77%
DDoS Mitigation	13%
IP reputation	5%
Access Rules	3%
Other	1%

21%

Andere HTTP-Felder (außer URI)

34%

Bot-Management

11%

IP-Reputationswert

4%

Hervorzuheben ist, dass 40 % aller implementierten benutzerdefinierten WAF-Regeln für Entscheidungen über den Umgang mit Datenverkehr auf geolokalisierungsbezogene Felder zurückgreifen. Das ist eine gängige Methode, um Geschäftslogik zu implementieren oder Regionen auszuschließen, aus denen kein Traffic erwartet wird. Sie trägt dazu bei, die Angriffsfläche zu reduzieren. Es handelt sich dabei zwar nur um eine grobmaschige Kontrolle, die raffinierte Angreifer wahrscheinlich nicht aufhalten kann, zur Reduzierung der Angriffsfläche ist dieses Verfahren aber trotzdem wirkungsvoll.

Interessant ist auch die Nutzung von Feldern mit Bot-Management-Bezug bei 11 % der benutzerdefinierten WAF-Regeln. Der Anteil hat im Lauf der Zeit stetig zugenommen, da immer mehr Kunden zum Schutz ihrer Anwendungen Klassifizierungsstrategien einsetzen, die auf maschinellem Lernen beruhen.

Den größten Anteil – von 32 % – an dem durch die Managed Rules für WAFs geprüften oder blockierten Datenverkehr haben HTTP-Anomalien.SQLi ( 12,7%) ist auf den zweiten Platz vorgerückt und hat Directory Traversal (9,9 %) überholt.

Schaut man sich den Anfang des Monats April 2023 an, fällt auf, dass HTTP-Anomalien zu diesem Zeitpunkt von der Angriffkategorie DoS deutlich übertroffen werden. Regeln in der DoS-Kategorie sind HTTP-Signaturen der WAF auf Schicht 7, die spezifisch genug sind, um einzelne Anfragen abzugleichen (und zu blockieren), ohne das Cross-Request-Verhalten zu untersuchen. Sie können entweder bestimmten Botnetzen oder Payloads zugeordnet werden, die zur Nichtverfügbarkeit (Denial of Service – DoS) führen. Normalerweise sind diese Anfragen, wie auch in diesem Fall, nicht Teil von dezentralen bzw. verteilten Angriffen. Deshalb fehlt im Namen der Kategorie das „D“ für „distributed“ (Distributed Denial of Service – DDoS).

Source	Percentage %
HTTP Anomaly	64%
SQLi	11%
XSS	9%
Software Specific	5%
Command Injection	4%

Tabellarische Darstellung (zehn wichtigste Kategorien):

Ursprung

Anteil %

HTTP-Anomalie

32%

SQLi

13%

Directory Traversal

10%

File Inclusion

9%

DoS

9%

XSS

9%

Softwarespezifisch

7%

Fehlerhafte Authentifizierung

6%

Gängige Injection-Methoden

3%

CVE

1%

Wenn man näher heranzoomt und nur die DoS-Kategorie in den Blick nimmt, stellt man fest, dass der größte Teil des geprüften oder blockierten Datenverkehrs auf eine bestimmte Regel zurückzuführen ist: 100031 / ce02fd... (alte bzw. neue WAF-Regel-ID). Diese Regel mit der Beschreibung „Microsoft IIS – DoS, Anomaly:Header:Range – CVE:CVE-2015-1635“ bezieht sich auf eine Schwachstelle aus dem Jahr 2015, die eine Reihe von Microsoft Windows-Komponenten betraf und Remote-Codeausführung* verursachte. Das ist eine gute Erinnerung daran, dass alte Sicherheitslücken (Common Vulnerabilities and Exposures –CVE) – selbst solche, die schon seit mehr als acht Jahren bekannt sind – immer noch aktiv zur Kompromittierung von Rechnern ausgenutzt werden, die möglicherweise ungepatcht sind und auf denen noch anfällige Software läuft.

* Aufgrund der Regelkategorisierung werden einige CVE-spezifische Regeln immer noch einer breiteren Kategorie zugewiesen, in diesem Beispiel etwa „DoS“. Regeln werden nur dann einer CVE-Kategorie zugewiesen, wenn sich der Angriffs-Payload nicht eindeutig mit einer anderen, allgemeineren Kategorie überschneidet.

Interessant ist auch die Zunahme der Regelanwendung aufgrund von „fehlerhafter Authentifizerung“ ab Juni. Dieser Anstieg ist ebenfalls auf eine einzige Regel zurückzuführen, die bei allen unseren Kunden, einschließlich unserer FREE-Nutzer, eingesetzt wird: „Wordpress – Broken Access Control, File Inclusion“. Sie sorgt dafür, dass Zugriffsversuche auf wp-config.php unterbunden werden: die Standardkonfigurationsdatei von WordPress, die sich normalerweise im Stammverzeichnis des Webservers befindet, auf die aber natürlich niemals direkt über HTTP zugegriffen werden sollte.

In diesem Zusammenhang hat die US-amerikanische IT-Sicherheitsbehörde CISA/CSA vor kurzem einen Bericht mit den wichtigsten im Jahr 2022 routinemäßig ausgenutzten Schwachstellen veröffentlicht. Wir haben die Gelegenheit genutzt, um der Frage nachzugehen, welche Rolle die im CISA-Bericht erwähnten CVEs bei unseren eigenen Daten spielen. Im CISA/CSA-Bericht werden zwölf Sicherheitslücken genannt, die von Akteuren im Cyberspace, die Böses im Schilde führen, 2022 routinemäßig ausgenutzt wurden. Unsere Analyse hat aber ergeben, dass zwei der im CISA-Bericht erwähnten CVEs für die überwiegende Mehrheit des Angriffsdatenverkehrs verantwortlich sind, den wir beobachten konnten: Log4J und Atlassian Confluence Code Injection. Unsere Daten deuten klar auf einen großen Unterschied beim Angriffsvolumen zwischen den beiden Spitzenreitern und dem Rest der Liste hin. In dem folgenden Diagramm wird das Angriffsvolumen (in logarithmischer Skala) der wichtigsten sechs Schwachstellen auf der CISA-Liste gemäß unseren Protokollen verglichen.

In das Bot-Management von Cloudflare wird weiterhin stark investiert, z. B. in JavaScript-geprüfte URLs für einen besseren Schutz vor browserbasierten Bots, in Detection IDs, die jetzt in benutzerdefinierten Regeln für zusätzliche Konfigurierbarkeit zur Verfügung stehen, und in eine verbesserte Benutzeroberfläche für ein einfacheres Onboarding. Für Self-Service-Kunden haben wir die Möglichkeit hinzugefügt, Regeln für den „Super Bot Fight“-Modus zu „überspringen“, sowie Support für Wordpress-Loopback-Anfragen. So können wir eine bessere Integration in die Anwendungen unserer Kunden ermöglichen und ihnen den erforderlichen Schutz bieten.

Unser Vertrauen in die Klassifizierungsergebnisse des Bot-Managements ist nach wie vor sehr hoch. Wenn wir die Bot-Scores über den analysierten Zeitraum hinweg aufzeichnen, stellen wir eine sehr klare Verteilung fest, bei der die meisten Anfragen entweder eindeutig als Bot (Score unter 30) oder eindeutig als menschlich (Score über 80) eingestuft werden. Tatsächlich erreichen die meisten Anfragen einen Score von weniger als 2 oder mehr als 95. Dies entspricht im gleichen Zeitraum 33 % des Datenverkehrs, der als automatisiert (von einem Bot generiert) eingestuft wird. Über längere Zeiträume hinweg liegt der Gesamtanteil des Bot-Traffics stabil bei 29 %, was den bei Cloudflare Radar dargestellten Daten entspricht.

Gegenüber den Ergebnissen des letzten Berichts ist der Anteil des nicht verifizierten Bot-HTTP-Traffics (um sechs Prozentpunkte) gesunken. Die Nutzung des Bot-Management-Felds im Rahmen der benutzerdefinierten WAF-Regeln liegt jedoch bei 11 %, was nicht zu vernachlässigen ist. Das bedeutet, dass bei Cloudflare mehr als 700.000 benutzerdefinierte WAF-Regeln eingesetzt werden, die sich zur Durchführung einer Aktion an Bot-Signalen orientieren. Das am häufigsten verwendete Feld ist cf.client.bot, ein Alias für cf.bot_management.verified_bot. Dies basiert auf unserer Liste verifizierter Bots und ermöglicht es Kunden, zwischen „gutartigen“ und potenziell „bösartigen“, nicht verifizierten Bots zu unterscheiden.

Enterprise-Kunden haben Zugriff auf die leistungsstärkere Option cf.bot_management.score, die direkten Zugriff auf den für jede Anfrage berechneten Score bietet – denselben Score, der auch für die Erstellung des Diagramms zur Verteilung des Bot-Scores im vorherigen Abschnitt verwendet wurde.

Die genannten Daten werden auch dadurch untermauert, dass wir uns ansehen, welcher Cloudflare-Dienst nicht verifizierten Bot-Traffic prüft und blockiert. Obwohl unser DDoS-Abwehrsystem automatisch HTTP-Traffic bei allen Kunden blockiert, macht dies nur 13 % der Prüf- oder Abwehrmaßnahmen gegen nicht verifizierte Bots aus. Auf der anderen Seite sind WAF-Regeln und vor allem kundeneigene Regeln für 77 % solcher Prüf- und Blockiermaßnahmen verantwortlich – dieser Anteil ist deutlich höher als bei den eingangs genannten Prüf- und Abwehrmaßnahmen für den gesamten Datenverkehr (57 %). Es ist zu beachten, dass das Bot-Management ausdrücklich genannt wird, sich aber auf unsere „standardmäßigen“ Ein-Klick-Regeln bezieht. Letztere werden getrennt von den Bot-Feldern erfasst, die in den benutzerdefinierten WAF-Regeln verwendet werden.

Tabellarische Darstellung:

Ursprung

Anteil %

WAF

77%

DDoS-Abwehr

13%

IP-Reputation

5%

Access Rules

3%

Sonstige

1%

Das von Cloudflare beobachtete Wachstum des gesamten API-Traffics verlangsamt sich nicht. Im Vergleich zum Vorquartal werden 58 % des gesamten dynamischen Datenverkehrs als API-bezogen eingestuft. Dies stellt einen Anstieg um drei Prozentpunkte dar.

Auch unsere Investitionen in das API-Gateway folgen einem ähnlichen Wachstumstrend. Während des Berichtsquartals haben wir mehrere neue API-Sicherheitsfunktionen eingeführt.

Zunächst haben wir die API-Erkennung mit einer neuen Posteingangsansicht einfacher gestaltet. Die API-Erkennung inventarisiert Ihre APIs, um Schatten-IT und Zombie-APIs zu verhindern. Zudem können Kunden bei der Suche jetzt einfach nach neuen Endpunkten filtern, die von der API-Erkennung gefunden wurden. Durch das Speichern von Endpunkten aus der API-Erkennung werden diese in unserem Endpunktverwaltungssystem erfasst.

Als Nächstes haben wir eine brandneue API-Sicherheitsfunktion hinzugefügt, die nur bei Cloudflare angeboten wird: die Möglichkeit, den API-Zugriff nach Client-Verhalten zu steuern. Wir nennen diese Funktion Sequence Mitigation. Kunden können nun positive oder negative Sicherheitsmodelle erstellen, die auf der Reihenfolge der API-Pfade basieren, auf die die Clients zugreifen. Sie können jetzt sicherstellen, dass die Nutzer Ihrer Anwendung die einzigen sind, die auf Ihre API zugreifen. Dadurch lassen sich Brute-Force-Angriffsversuche unterbinden, bei denen die eigentlichen Anwendungsfunktionen ignoriert werden. Im Fall einer Banking-Anwendung können Sie jetzt beispielsweise erzwingen, dass der Zugriff auf den Endpunkt für Geldüberweisungen erst möglich ist, nachdem ein Nutzer auch auf den Endpunkt für den Abruf des Kontostands zugegriffen hat.

Wir freuen uns schon darauf, bis Jahresende und darüber hinaus weitere API-Sicherheits- und -Verwaltungsfunktionen einzuführen.

Der Anteil des API-Traffics, der von Browsern generiert wird, ist im Berichtsquartal ausgesprochen stabil geblieben. Mit dieser Statistik beziehen wir uns auf HTTP-Anfragen, die keine HTML-basierten Inhalte bereitstellen, die vom Browser ohne Vorverarbeitung direkt gerendert werden – wie beispielsweise die allgemein als AJAX-Aufrufe bekannten Anfragen, die normalerweise JSON-basierte Antworten liefern würden.

Wie schon im Vorquartal sind HTTP-Anomalien bei API-Traffic erneut der Angriffsvektor, gegen den am häufigsten Prüf- und Blockiermaßnahmen ergriffen wurden. Auch SQLi-Injection-Angriffe sind aber nicht zu vernachlässigen. Ihr Anteil an dem von Prüf- und Blockiermaßnahmen betroffenen Datenverkehr beläuft sich auf etwa 11 %. Knapp dahinter folgen XSS-Angriffe, die es auf etwa 9 % bringen.

Tabellarische Darstellung als Referenz (Top 5):

Ursprung

Anteil %

HTTP-Anomalie

64%

SQLi

11%

XSS

9%

Softwarespezifisch

5%

Command Injection

4%

Im Zuge der Umstellung unseres Berichts zum Thema Anwendungssicherheit auf einen vierteljährliche Erscheinungsrhythmus planen wir, einige der Erkenntnisse zu vertiefen und zusätzliche Daten von einigen unserer neueren Produkte wie Page Shield bereitzustellen. Das erlaubt es uns, über den HTTP-Datenverkehr hinaus zu schauen und die Online-Abhängigkeiten von Drittanbietern in den Fokus zu nehmen.

Bleiben Sie dabei und schauen Sie ab und zu bei Cloudflare Radar vorbei, um häufiger Berichte und Erkenntnisse zum Thema Anwendungssicherheit zu erhalten.