Një bug në HTTP/2 shumëfishon sulmet DDoS

Një dobësi në protokollin HTTP/2 i lejoi hakerët të shfrytëzonin funksionalitetin e tij për të ekspozuar serverët e aplikacioneve në internet dhe përfaqësuesit e uebit ndaj sulmeve të Shpërndara të Mohimit të Shërbimit (DDoS) në një shkallë të paprecedentë në dy muajt e fundit. Google, Amazon Web Services, CloudFlare dhe operatorë të tjerë të IT-së punuan privatisht për të zhvilluar rregullime dhe arnime përpara se të bënin publike defektin.

Sulmet DDoS, të quajtura HTTP/2 Rapid Reset, mbështeten në aftësinë e protokollit HTTP/2 për të trajtuar transmetime të shumta HTTP në të njëjtën kohë. Protokolli ju lejon të dërgoni disa kërkesa HTTP paralelisht në të njëjtën lidhje TCP, pa pasur nevojë të hapni të reja. Pika e dobët është një funksion specifik: mundësia e ndërprerjes së njëanshme të flukseve. Kompanitë inkurajohen të kontrollojnë nëse partnerët e tyre të TI-së kanë lëshuar arnime ose rekomandime zbutëse për këtë cenueshmëri.

Sulme më efektive DDoS
Në versionin e vjetër 1 të protokollit HTTP, i mbështetur ende nga shumica e serverëve dhe klientëve të internetit, është e mundur të dërgohen disa kërkesa përmes një lidhjeje të vetme TCP, por kjo bëhet në mënyrë serike dhe serveri përpunon kërkesat dhe përgjigjet në rendin në të cilin janë marrë. Në rastin e HTTP/2, disa kërkesa, të quajtura “streams” dhe të përbëra nga HEADERS ose korniza DATA, mund të dërgohen njëkohësisht dhe në mënyrë të rastësishme përmes një lidhjeje TCP. Me multipleksimin e transmetimit, çdo transmetim shoqërohet me një identifikues, kështu që serveri e di gjithmonë se cilës transmetim i përket kornizës dhe si të përgjigjet.

Sulmet DDoS shfrytëzojnë karakteristikat e efikasitetit të protokollit të internetit
Ky multipleksim lejon përdorimin më efikas të lidhjeve TCP dhe përshpejton kohën e ngarkimit të faqes. Imagjinoni një faqe interneti moderne që përmban një mori burimesh, skripte të palëve të treta dhe imazhe të ngarkuara nga vende të ndryshme. Një shfletues që hyn në këtë faqe nëpërmjet HTTP/2 do të fillojë menjëherë t’i ngarkojë këto burime paralelisht, duke u dhënë përparësi atyre që janë të dukshme për përdoruesin. Nëse përdoruesi klikon menjëherë një buton dhe largohet nga faqja, shfletuesi mund të mbyllë transmetimet edhe nëse burimet nuk janë ngarkuar ose dhënë plotësisht, pa e mbyllur plotësisht lidhjen dhe pa hapur kërkesa shtesë.

“Që nga fundi i vitit 2021, shumica e sulmeve DDoS të Layer 7 që kemi vëzhguar në Shërbimet e Google dhe projektet e Google Cloud të mbrojtura nga Cloud Armor janë mbështetur në HTTP/2, si në numrin e sulmeve ashtu edhe në shkallën maksimale të kërkesës”, thanë inxhinierët e Google në një postim në blog. duke shpjeguar sulmin e ri. “Një nga qëllimet kryesore të HTTP/2 ishte efikasiteti, dhe për fat të keq, veçoritë që e bëjnë HTTP/2 më efikas për klientët legjitimë mund të përdoren gjithashtu për t’i bërë sulmet DDoS më efikase,” shtuan studiuesit.

Anashkalimi i kufizimeve të rrjedhës së njëkohshme
Meqenëse një server duhet të konsumojë CPU dhe ciklet e memories për të përpunuar çdo kornizë dhe transmetim, zhvilluesit e protokollit ishin të vetëdijshëm që në fillim se do të ishte e mundur të abuzohej me transmetimet e njëkohshme për të shterur burimet e një serveri dhe kështu të shkaktonte një mohim shërbimi. Për këtë arsye ata shtuan një parametër të quajtur SETTINGS_MAX_CONCURRENT_STREAMS. Serveri e komunikon këtë me pikat fundore të klientit në lidhjen e parë nëpërmjet një kornize SETTINGS.

Si parazgjedhje, vlera e këtij parametri është e pakufizuar, por projektuesit e protokollit rekomandojnë që të jetë jo më pak se 100 për të ruajtur paralelizmin efikas. Për këtë arsye, në praktikë, shumë klientë nuk presin kornizën SETTINGS dhe thjesht supozojnë se kufiri minimal është 100 dhe dërgojnë 100 korniza që në fillim. Problemi buron nga një veçori tjetër e quajtur RST_STREAM, e cila qëndron për “rivendosjen e transmetimit”. Ky është një lloj kuadri që një klient mund ta dërgojë te një server për të treguar se ID-ja e një transmetimi të hapur më parë duhet të anulohet.

Si një veçori e rikuperimit të shpejtë mund të bëhet një armë për sulmet DDoS
Kjo i lejon klientit të anulojë menjëherë kërkesat për burime që nuk nevojiten më, për shembull sepse përdoruesi u largua nga faqja përpara se burimi të ngarkohej. Kjo është e dobishme sepse i thotë serverit të ndalojë së përgjigjuri ndaj një kërkese të mëparshme dhe të mos humbasë gjerësinë e brezit. Por ka një problem. Duke dërguar një kornizë RST_STREAM, transmetimi i synuar nuk llogaritet më në kufirin maksimal të transmetimit të njëkohshëm, kështu që klienti mund të hapë menjëherë një transmetim të ri pasi të dërgojë një rivendosje për një transmetim të mëparshëm. Kjo do të thotë që edhe me një kufi prej 100 fluksesh të njëkohshme, klienti mund të hapë dhe rivendosë qindra flukse në të njëjtën lidhje TCP në vazhdimësi të shpejtë. Si rezultat, serveri duhet të shpenzojë burime për të përpunuar kornizat RST_STREAM. Ndërsa nuk është shumë, me miliona kërkesa shtohet shpejt.

Sulme më të fuqishme DDoS
Duke përdorur këtë teknikë, hakerët arritën të nisnin sulme DDoS në një shkallë të paprecedentë kundër serverëve të organizuar nga Google, Cloudflare dhe AWS. “Kur një server HTTP/2 mund të përpunojë kornizat RST_STREAM të dërguara nga klientët dhe të çmontojë gjendjen mjaft shpejt, këto rikthime të shpejta nuk janë problem,” shpjegojnë inxhinierët e Cloudflare në raportin e tyre. “Problemet fillojnë të lindin nëse ka një vonesë ose rrëshqitje në përpunim. Klienti mund të dërgojë aq shumë kërkesa sa të krijojë një ngarkesë të mbetur, duke shkaktuar konsum të tepruar të burimeve në server.”

Sulmi më i madh i rivendosjes së shpejtë HTTP/2 i vëzhguar nga Google arriti kulmin në mbi 398 milionë kërkesa për sekondë (rps). Për krahasim, sulmi më i madh që kompania vëzhgoi në 2022 arriti kulmin në 46 milionë kërkesa në sekondë. Sulmi që synoi Cloudflare në gusht arriti në 201 milionë kërkesa në sekondë, tre herë më shumë se sulmi më i madh DDoS i zbuluar më parë nga ofruesi. Ky sulm HTTP/2 Rapid Reset u nis nga një botnet prej vetëm 22,000 kompjuterësh, një numër i vogël në krahasim me botnet-et e tjera.

Masat zbutëse
Strategjitë zbutëse për këto sulme nuk janë të thjeshta, pasi disa kërkesa për fshirje RST_STREAM mund të jenë legjitime, kështu që çdo pronar server duhet të vendosë kur ndodh abuzimi dhe si të përshtatë përgjigjen bazuar në statistikat e lidhjes dhe logjikën e biznesit. Për shembull, nëse një lidhje TCP ka më shumë se 100 kërkesa dhe klienti anulon më shumë se 50% të tyre, lidhja mund të konsiderohet abuzive. Përgjigjet mund të variojnë nga dërgimi me forcë i kornizave GOAWAY deri te mbyllja e menjëhershme e lidhjes TCP. Një përgjigje tjetër mund të jetë bllokimi i adresës IP ofenduese nga aksesi në shërbimin HTTP/2 dhe transferimi i përkohshëm në HTTP 1.x.

Problemi me filtrat IP është se disa klientë mund të ndajnë të njëjtën adresë IP, dhe jo të gjithë janë me qëllim të keq. Duke kufizuar kërkesat në HTTP 1.x, klientët e padëmshëm pas një adrese IP të filtruar do të jenë ende në gjendje të aksesojnë shërbimin në internet, megjithëse performanca e tyre do të reduktohet. Zhvilluesit e Nginx, një përfaqësues popullor i kundërt dhe balancues i ngarkesës, kanë propozuar gjithashtu masa zbutëse bazuar në funksione specifike të zbatuara tashmë nga serveri, të tilla si keepalive_requests, limit_conn dhe limit_req.

Në ditët në vijim do të shpërndahet gjithashtu një patch që do të kufizojë më tej ndikimin e këtyre sulmeve. Microsoft, AWS, F5 dhe kompani të tjera të infrastrukturës kanë publikuar masa ose arnime zbutëse. Përdoruesit mund të kontrollojnë rregullisht formularin zyrtar në CVE Tracker për të gjetur lidhje me përgjigjet e përditësuara nga shitësit.