Kompania Google ka regjistruar sulmin më të madh DDoS në infrastrukturën e saj, me një intensitet prej 398 milion kërkesash në sekondë. Sulmi i ri është 7 herë më intensiv se sulmi rekord i kaluar DDoS, ku sulmuesit arritën të formonin një rrjedhë prej 47 milion kërkesash në sekondë. Për të bërë një krahasim, gjithë trafiku në të gjithë Web-in vlerësohet nga 1-3 miliard kërkesash në sekondë. Përveç Google, sulmit iu nënshtruan gjithashtu kompanitë Amazon dhe Cloudflare. Mundësia e realizimit të një sulmi të ri është e lidhur me zbulimin e një dobësie në protokollin HTTP/2 (CVE-2023-44487), që lejon që me një ngarkesë minimale nga klienti të dërgohet një rrjedhë e madhe kërkesash në server.
Teknika e re e sulmit është emërtuar «Rapid Reset» dhe përfiton nga mjetet e ofruara në HTTP/2 për multipleximin e kanaleve të komunikimit, duke lejuar formimin e një rrjedhe kërkesash brenda një lidhjeje tashmë të vendosur, pa hapur lidhje të reja rrjetesh dhe pa pritur konfirmimin e pranimit të paketave. Dobësia konsiderohet si pasojë e papërsosmërisë së protokollit HTTP/2, në specifikimin e të cilit thuhet se kur përpiqesh të hapësh një numër shumë të madh të rrjedhave, duhet të anulohet vetëm rrjedhat që kalojnë kufirin, por jo të mbyllet e gjithë lidhja e rrjetit.
Si me metodat e mëparshme të sulmeve në HTTP/2, në sulmin e ri gjithashtu krijohet një numër i madh rrjedhash brenda një lidhjeje. Dallimi kryesor i sulmit të ri është se, në vend të pritjes për një përgjigje pas çdo kërkese të dërguar, dërgohet një kadër me flamurin RST_STREAM, që menjëherë anulon kërkesën. Anulimi i kërkesës në një fazë të hershme lejon që të eliminohet trafiku në drejtim të klientit dhe të anashkalohet kufizimet e pranishme në serverët HTTP për numrin maksimale të rrjedhave, të hapura njëkohësisht brenda një lidhjeje në HTTP/2. Kështu, në sulmin e ri, volumi i kërkesave të dërguara në serverin HTTP nuk varet më nga vonesat midis dërgimit të kërkesës dhe pranimit të përgjigjes (RTT, koha e kthimit) dhe kufizohet vetëm në kapacitetin e kanalit të komunikimit.
Pasi për të kryer një sulm nga ana e klientit, mjafton të dërgosh kërkesa pa marrë përgjigje, kështu që sulmi mund të kryhet me shpenzime minimale. Për shembull, një sulm i regjistruar nga kompanitë Cloudflare me 201 milion kërkesa në sekondë u realizua me një botnet relativisht të vogël prej 20 mijë kompjuterësh. Nga ana tjetër, serverë kostot për përpunimin e kërkesave që mbërrijnë janë ndjeshëm më të larta, pavarësisht se ato anulohen, pasi nevojitet të kryhen operacione të tilla si ndarja e strukturave të të dhënave për rrjedhat e reja, analiza e kërkesës, shpërbërja e titullit dhe përputhja e URL me burimin. Në një sulm ndaj proxy-ve të prapambetur, sulmi mund të përhapet në backend, pasi proxy mund të arrijë të redirectojë kërkesën në backend para se të përpunojë kornizën RST_STREAM.
Sulmi mund të kryhet vetëm ndaj serverëve të cenueshëm që mbështesin HTTP/2 (skedari për kontrollimin e shfaqjes së cenueshmërisë në servera, mjetet për kryerjen e sulmit). Për HTTP/3 nuk janë regjistruar akoma sulme dhe mundësia e kryerjes së tyre nuk është analizuar plotësisht, por përfaqësuesit e Google rekomandojnë zhvilluesve serverësh të shtojnë në implementimet e HTTP/3 masa mbrojtëse, të ngjashme me ato të zbatuara për bllokimin e sulmeve ndaj HTTP/2.
Cenueshmëria dhe disponueshmëria e rregullimeve për serverat dhe proxy-t HTTP:
- nginx (njoftim, shpjegim se cenueshmëria nuk shfaqet plotësisht në ngjyrën e konfigurimit standard në nginx, pasi sulmi do të hasë limitin e numrit të kërkesave për lidhje (pra, pas çdo 1000 kërkesash, lidhja do të rimbushë). Në rregullim është shtuar një mbrojtje e mëtejshme për kufizimin e intensitetit të kërkesave përmes direktivës "limit_req").
- Në HAProxy mbrojtja efektive ndaj tejkalimit të limitit për numrin e rrjedhave HTTP/2 është shtuar që në vitin 2018 dhe është efektive duke filluar nga versioni 1.9-dev.
- Apache httpd (krijohet një ngarkesë e caktuar në httpd, por ajo nuk shtrihet në backend dhe është e kufizuar nga limitet aktive që nga viti 2016 për lidhjet e klientëve).
- mod_h2 për Apache httpd.
- caddy
- envoy
- golang (problemi është zgjidhur në lëshimet Go 1.21.3 dhe 1.20.10).
- h2o (patch).
- grpc-go
- hyper (cenueshmëria nuk shfaqet).
- jetty (e rregulluar në 12.0.2, 11.0.17, 10.0.17 dhe 9.4.53.v20231009).
- netty
- nghttp2 (e rregulluar në versionin 1.57.0).
- Facebook proxygen
- .NET dhe ASP.NET Core (cenueshmëria është për serverin http të ASP.NET Core Kestrel).
- Node.js
- proxygen
- swift-nio-http2 (e rregulluar në versionin 1.28.0).
- Apache Tomcat (korrigjuar në versionet 11.0.0-M12, 10.1.14, 9.0.81, 8.5.94).
- Apache Traffic Server (korrigjuar në degën 9.2.x).
Burimi: opennet.ru
