{"id":110728,"date":"2023-10-11T03:10:14","date_gmt":"2023-10-11T01:10:14","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimost-v-protokole-http-2-zadejstvovannaya-v-krupnejshej-ddos-atake"},"modified":"2023-10-11T03:10:14","modified_gmt":"2023-10-11T01:10:14","slug":"uyazvimost-v-protokole-http-2-zadejstvovannaya-v-krupnejshej-ddos-atake","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/news\/uyazvimost-v-protokole-http-2-zadejstvovannaya-v-krupnejshej-ddos-atake","title":{"rendered":"Schwachstelle im HTTP\/2-Protokoll, die bei dem gr\u00f6\u00dften DDoS-Angriff verwendet wurde.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Das Unternehmen Google verzeichnete den gr\u00f6\u00dften DDoS-Angriff auf seine Infrastruktur, dessen Intensit\u00e4t 398 Millionen Anfragen pro Sekunde betrug. Der neue Angriff \u00fcbertrifft die Intensit\u00e4t des vorherigen Rekords DDoS-Angriffs um das Siebenfache, bei dem es den Angreifern gelang, einen Datenstrom von 47 Millionen Anfragen pro Sekunde zu erzeugen. Zum Vergleich: Der gesamte Datenverkehr im gesamten Web wird auf 1-3 Milliarden Anfragen pro Sekunde gesch\u00e4tzt. Neben Google waren auch Unternehmen wie Amazon und Cloudflare von dem Angriff betroffen. Die M\u00f6glichkeit eines neuen Angriffs h\u00e4ngt mit der Entdeckung einer Schwachstelle im HTTP\/2-Protokoll (CVE-2023-44487) zusammen, die es erm\u00f6glicht, bei minimaler Belastung des Clients einen riesigen Anfragenstrom an den Server zu senden. <\/p>\n

Neue Angriffstechnik tr\u00e4gt den Namen \u201eRapid Reset\u201c und nutzt die in HTTP\/2 bereitgestellten Multiplexing-M\u00f6glichkeiten, um einen Anfragefluss innerhalb einer bereits etablierten Verbindung zu bilden, ohne neue Netzwerkverbindungen zu \u00f6ffnen und ohne auf die Best\u00e4tigung des Empfangs von Paketen zu warten. Die Schwachstelle wird als Folge einer Unzul\u00e4nglichkeit des HTTP\/2-Protokolls betrachtet, das in seiner Spezifikation festlegt, dass bei dem Versuch, eine zu gro\u00dfe Anzahl von Streams zu \u00f6ffnen, nur die Streams, die das Limit \u00fcberschreiten, abgebrochen werden sollten, jedoch nicht die gesamte Netzwerkverbindung geschlossen werden sollte. <\/p>\n

\u00c4hnlich wie bei fr\u00fcheren Methoden zur Durchf\u00fchrung von Angriffen auf HTTP\/2 wird auch im neuen Angriff eine gro\u00dfe Anzahl von Streams innerhalb einer einzigen Verbindung erzeugt. Der entscheidende Unterschied des neuen Angriffs besteht darin, dass anstelle des Wartens auf eine Antwort nach jeder gesendeten Anfrage ein Frame mit dem RST_STREAM-Flag gesendet wird, der die Anfrage sofort annulliert. Die fr\u00fchzeitige Stornierung der Anfrage erm\u00f6glicht es, den R\u00fcckverkehr zum Client zu vermeiden und die auf HTTP-Servern bestehenden Einschr\u00e4nkungen hinsichtlich der maximal m\u00f6glichen Anzahl von Streams, die innerhalb einer Verbindung \u00fcber HTTP\/2 ge\u00f6ffnet sind, zu umgehen. Auf diese Weise h\u00e4ngt das Volumen der an HTTP-Server gesendeten Anfragen im neuen Angriff nicht mehr von den Verz\u00f6gerungen zwischen dem Senden der Anfrage und dem Erhalten der Antwort (RTT, round-trip time) ab, sondern vielmehr von der Bandbreite der Verbindung.

\"Schwachstelle<\/center> <\/p>\n

Da f\u00fcr einen Angriff auf der Client-Seite lediglich das Versenden von Anfragen ohne Erhalt von Antworten erforderlich ist, kann der Angriff mit minimalen Overheadkosten durchgef\u00fchrt werden. Ein von Cloudflare dokumentierter Angriff mit 201 Millionen Anfragen pro Sekunde wurde mithilfe eines relativ kleinen Botnets von 20.000 Computern durchgef\u00fchrt. Auf der Seite Server<\/a> sind die Kosten f\u00fcr die Verarbeitung eingehender Anfragen erheblich h\u00f6her, obwohl sie storniert werden, da Operationen wie die Zuordnung von Datenstrukturen f\u00fcr neue Streams, die Analyse der Anfrage, das Entpacken der Header und das Abgleichen der URL mit der Ressource erforderlich sind. Bei Angriffen auf Reverse-Proxys kann sich der Angriff auf die Backends ausweiten, da der Proxy die Anfrage m\u00f6glicherweise an das Backend weiterleiten kann, bevor das RST_STREAM-Paket verarbeitet wird. <\/p>\n

Ein Angriff kann nur auf verwundbare Server mit Unterst\u00fctzung f\u00fcr HTTP\/2 durchgef\u00fchrt werden (ein Skript zur \u00dcberpr\u00fcfung des Vorhandenseins von Schwachstellen in Servern, Tools zur Durchf\u00fchrung des Angriffs). F\u00fcr HTTP\/3 wurden bisher keine Angriffe dokumentiert, und die M\u00f6glichkeit ihrer Durchf\u00fchrung ist noch nicht vollst\u00e4ndig analysiert, aber Google-Vertreter empfehlen Entwicklern, Server<\/a> Schutzma\u00dfnahmen in die Implementierung von HTTP\/3 aufzunehmen, die mit den Ma\u00dfnahmen zum Schutz vor Angriffen auf HTTP\/2 vergleichbar sind. <\/p>\n

Anf\u00e4lligkeit f\u00fcr die Schwachstelle und vorhandene Patches f\u00fcr HTTP-Server und Proxys: <\/p>\n