Ein Forscherteam von der Peking University, der Tsinghua University und der University of Texas in Dallas veröffentlichte Informationen über Ihre Arbeit getan, um identifizieren zu können eine neue Klasse von DoS-Angriffen, die sie "RangeAmp" nannten und die auf der Verwendung des Range-HTTP-Headers basieren, um die Verstärkung des Datenverkehrs über das Content Delivery Network (CDN) zu organisieren.
Die Essenz der Methode die Sache ist, aufgrund der Eigenart der Verarbeitung von Range-Headern auf vielen CDNs, ein Angreifer kann ein Byte aus einer großen Datei anfordern über CDN, aber Das CDN lädt die gesamte Datei oder einen wesentlich größeren Datenblock vom Zielserver herunter zum Zwischenspeichern.
Der Grad der Verkehrsverstärkung während eines Angriffs dieses Typs beträgt laut CDN das 724- bis 43330-fache, was verwendet werden kann, um den eingehenden CDN-Verkehr zu überlasten oder die Bandbreite des endgültigen Kommunikationskanals zum Ort des Opfers zu verringern.
Mit dem Range-Header kann der Client den Positionsbereich in der Datei bestimmen Dies sollte geladen werden, anstatt die gesamte Datei zurückzugeben.
Beispielsweise kann der Client "Bereich: Bytes = 0-1023" angeben, und der Server überträgt nur die ersten 1024 Datenbytes. Diese Funktion ist beim Herunterladen großer Dateien sehr gefragt: Der Benutzer kann den Download anhalten und dann von der unterbrochenen Position aus fortsetzen. Bei Angabe von "Bytes = 0-0" schreibt der Standard vor, das erste Byte in der Datei "Bytes = -1" - das letzte "Bytes = 1-" - von 1 Byte bis zum Ende der Datei anzugeben. Sie können mehrere Bereiche in einem Header übertragen, z. B. "Bereich: Bytes = 0-1023.8192-10240".
Zusätzlich Eine zweite Angriffsoption wurde vorgeschlagen (Es heißt RangeAmp Overlapping Byte Ranges (OBR) -Angriff, entwickelt, um die Netzwerklast zu erhöhen Wenn der Datenverkehr über ein anderes CDN weitergeleitet wird, das als Proxy verwendet wird (z. B. wenn Cloudflare als Frontend (FCDN) und Akamai als Backend (BCDN) fungiert). Die Methode ähnelt dem ersten Angriff, ist jedoch in CDNs lokalisiert und ermöglicht es Ihnen, den Datenverkehr beim Zugriff über andere CDNs zu erhöhen, die Infrastruktur zu belasten und die Servicequalität zu verringern.
Die Idee ist, dass der Angreifer mehrere Bereiche an die CDN-Bereichsanforderung sendet, z. B. "Bytes = 0-, 0-, 0 - ...", "Bytes = 1-, 0-, 0 - ..." oder "bytes = - 1024,0-, 0 -…«.
Anfragen enthalten eine große Anzahl von "0-" Bereichen, Dies impliziert die Rückgabe der Datei von Grund auf bis zum Ende. Aufgrund einer falschen Bereichsanalyse, wenn sich das erste CDN auf das zweite bezieht, wird eine vollständige Datei an jedes "0-" Band zurückgegeben (Bereiche werden nicht aggregiert, sondern nacheinander sortiert), wenn in der ursprünglich übermittelten Angriffsanforderung Bereichsduplizierung und Schnittmenge vorhanden sind. Der Grad der Verkehrsverstärkung bei einem solchen Angriff reicht von 53 bis 7432 Mal.
Die Studie untersuchte das Verhalten von 13 CDNs: Akamai, Alibaba Cloud, Azure, CDN77, CDNsun, Cloudflare, CloudFront, Fastly, G-Core Labs, Huawei Cloud, KeyCDN, StackPath und Tencent Cloud.
"Obwohl wir ihnen mehrmals eine E-Mail geschickt und versucht haben, ihren Kundenservice zu kontaktieren, hat StackPath leider kein Feedback gegeben", sagte das Forschungsteam.
„Insgesamt haben wir unser Bestes getan, um Schwachstellen verantwortungsvoll zu melden und Lösungen zur Schadensbegrenzung bereitzustellen. Verwandte CDN-Anbieter hatten fast sieben Monate Zeit, um Schadensbegrenzungstechniken zu implementieren, bevor dieses Dokument veröffentlicht wurde. "
Alle überprüften CDNs erlaubten die erste Art von Angriff auf den Zielserver. Die zweite Version des CDN-Angriffs war 6 Diensten ausgesetzt, von denen vier als Schnittstelle für den Angriff (CDN77, CDNsun, Cloudflare und StackPath) und drei als Back-End (Akamai, Azure) fungieren können und StackPath).
Der höchste Gewinn wird in Akamai und StackPath erzielt, wodurch Sie mehr als 10 Ränge in der Rangüberschrift angeben können.
CDN-Besitzer wurden darüber informiert von Schwachstellen vor ungefähr 7 Monaten Zum Zeitpunkt der Veröffentlichung von Informationen lösten 12 von 13 CDN die identifizierten Probleme oder drückten ihre Bereitschaft aus, diese zu lösen.
Quelle: https://www.liubaojun.org