A digitális infrastruktúránk alapját képező protokollok rejtett, logikai sebezhetőségei rendszerszintű kockázatot jelentenek az internet egészére nézve. Ezt a fenyegetést tökéletesen példázza a nemrégiben felfedezett „MadeYouReset” HTTP/2 sebezhetőség, amely a webes kommunikáció egyik sarokkövét teszi sebezhetővé a szolgáltatásmegtagadási (DoS) támadásokkal szemben. A digitális világ teljesítményének és hatékonyságának növelésére tervezett protokollok összetettsége gyakran rejt magában olyan logikai hibákat, amelyek kihasználásával a támadók komoly zavarokat okozhatnak. A „MadeYouReset” sebezhetőség tökéletes példája ennek a jelenségnek, amely a HTTP/2 protokoll egyik alapvető funkcióját fordítja fegyverré a szerverek ellen.
TL;DR
A protokollszintű sebezhetőségek rendszerszintű kockázatot jelentenek. A „MadeYouReset” és elődje, a „Rapid Reset” rávilágít arra, hogy az internet alapját képező protokollok tervezési hibái továbbra is súlyos, széles körben kihasználható sebezhetőségek forrásai lehetnek. Ezek megelőzése és kezelése proaktív kutatást és az iparági szereplők (kutatók, gyártók, koordinációs központok) szoros együttműködését igényli.
A kifinomult támadások a protokoll logikáját fordítják önmaga ellen. A „MadeYouReset” nem egy egyszerű túlterheléses támadás, hanem egy intellektuális ugrás, ahol a támadó a szervert kényszeríti a kapcsolatok leállítására, ezzel megkerülve azokat a védelmeket, amelyek a kliensoldali viselkedést figyelik. Ez a mélyreható, a mögöttes logikai hibát orvosló javítások fontosságát hangsúlyozza a felületes, tüneti kezelésekkel szemben.
A koordinált közzététel kulcsfontosságú a megelőzésben. A „MadeYouReset” esete a felelős közzétételi folyamat sikerének mintapéldája. A kutatók, a hibajavító programot működtető vállalat (Akamai) és a koordinációs központ (CERT/CC) együttműködése lehetővé tette a javítások kidolgozását és elterjesztését, mielőtt a támadók kihasználhatták volna a sebezhetőséget, ellentétben a „Rapid Reset” esettel, amelyet már aktív támadások során fedeztek fel.
/TL;DR
A http/2 stream kezelés működése és a visszaélés lehetőségei
A HTTP/2 protokoll forradalmasította a webes kommunikációt azáltal, hogy bevezette a multiplexing koncepcióját, amely lehetővé teszi több kérés és válasz egyidejű továbbítását egyetlen TCP kapcsolaton keresztül. Ez a párhuzamosság „streamek” vagy adatfolyamok segítségével valósul meg, amelyek a kapcsolaton belüli logikai csatornákként funkcionálnak. A szerverek túlterhelésének megakadályozására a protokoll tartalmaz egy fontos védelmi mechanizmust, a
SETTINGS_MAX_CONCURRENT_STREAMS
paramétert. Ez a beállítás meghatározza, hogy egy kliens egy adott kapcsolaton belül legfeljebb hány aktív streamet tarthat fenn egyidejűleg, ami elméletben korlátozza a szerverre nehezedő terhelést.
A protokolltervezés során a fejlesztőknek gondolniuk kell a hibakezelésre és a rugalmasságra is. Ennek egyik eleme a stream-visszaállítás (RST_STREAM
) funkciója. Ez egy legitim mechanizmus, amely lehetővé teszi a kliens vagy a szerver számára, hogy egy streamet idő előtt lezárjon, például ha a kért erőforrásra már nincs szükség, vagy ha hiba lép fel. A „MadeYouReset” és elődje, a „Rapid Reset” támadások pontosan ezt a legitim, a protokoll működéséhez szükséges funkciót használják ki rosszindulatúan, hogy a szerver erőforrásait kimerítsék.
Technikai lebontás: hogyan kerüli meg a „madeyoureset” a védelmi mechanizmusokat?
A „MadeYouReset” (CVE-2025-8671) támadás egy kifinomultabb megközelítést alkalmaz a szerverek túlterhelésére, mint a korábbi, hasonló jellegű sebezhetőségek. A támadás lényege, hogy a kliens nem közvetlenül küld nagy mennyiségű RST_STREAM
keretet, hanem szándékosan hibás, de a protokoll szintaktikája szerint érvényes vezérlőkereteket továbbít a szerver felé. A kutatók több ilyen „primitívet” is azonosítottak, amelyekkel a támadás kiváltható :
Egy
WINDOW_UPDATE
keret küldése, amelynek növekménye 0, vagy amelynek hatására az áramlásvezérlési ablak mérete meghaladná a 231−1 értéket.HEADERS
vagyDATA
keretek küldése egy olyan streamen, amelyet a kliens oldalon már lezártak (azEND_STREAM
jelzővel).Egy
PRIORITY
keret küldése, amelynek hossza nem a specifikációban előírt 5 bájt.
A HTTP/2 protokoll specifikációja (RFC 9113) egyértelműen előírja, hogy a szervernek az ilyen típusú protokollsértésekre PROTOCOL_ERROR
hibával és az érintett stream RST_STREAM
kerettel történő lezárásával kell válaszolnia. És itt rejlik a támadás kulcsa: a szerver, miután elküldte a
RST_STREAM
keretet, a streamet lezártnak tekinti, és csökkenti az aktív streamek számlálóját. Azonban sok implementációban a háttérben futó alkalmazáslogika nem állítja le azonnal a kérés feldolgozását, és továbbra is értékes CPU- és memória-erőforrásokat emészt fel. Mivel a szerveroldali számláló „felszabadult”, a kliens azonnal jogosulttá válik egy új stream megnyitására, még mielőtt a korábbi kérés feldolgozása ténylegesen befejeződött volna. Ezzel a módszerrel a támadó aSETTINGS_MAX_CONCURRENT_STREAMS
limitet gyakorlatilag a végtelenségig kijátszhatja, korlátlan számú, erőforrás-igényes kérést zúdítva a szerverre egyetlen TCP kapcsolaton keresztül.
Összehasonlító elemzés: „madeyoureset” vs. „rapid reset” (cve-2023-44487)
A „MadeYouReset” sebezhetőség megértéséhez elengedhetetlen összehasonlítani azt a 2023-ban felfedezett és széles körben kihasznált „Rapid Reset” (CVE-2023-44487) támadással. A „Rapid Reset” mechanizmusa egyszerűbb volt: a támadó kliens nagy számban nyitott meg streameket, majd szinte azonnal le is zárta azokat saját maga által küldött RST_STREAM
keretekkel. Ez a gyors nyitás-zárás ciklus szintén a szerver erőforrásainak kimerítését célozta, kihasználva a stream lezárása és a háttérfeldolgozás leállítása közötti késleltetést.
Az iparág erre a fenyegetésre viszonylag gyorsan reagált, de sokan a legegyszerűbb, reaktív megoldást választották: a kliens által küldött RST_STREAM
keretek számának vagy arányának korlátozását. Ez a megközelítés egyfajta „tüneti kezelés” volt, amely a támadás egy specifikus megnyilvánulását célozta, nem pedig a mögöttes logikai hibát.
A „MadeYouReset” egyértelműen a „Rapid Reset” elleni védekezések elemzéséből született evolúciós lépés. A támadók felismerték a kliensoldali korlátozások gyengeségét, és ahelyett, hogy maguk küldenék a resetet, a szervert „kényszerítik” annak generálására. Ezzel a kifinomult módszerrel a támadás teljesen megkerüli azokat az egyszerűsített védelmi mechanizmusokat, amelyek csupán a kliens viselkedését figyelik. Ez a támadás egy intellektuális ugrást képvisel: a stratégia a „több resetet küldeni” helyett az lett, hogy „a meglévő védelmet kihasználni önmaga ellen”.
Ipari hatás és érintett rendszerek jegyzéke
A sebezhetőség potenciális hatása óriási, tekintve, hogy a weboldalak több mint egyharmada használja a HTTP/2 protokollt a jobb teljesítmény érdekében. A felelős közzétételi folyamatnak köszönhetően a sebezhetőséget még a széles körű kihasználás előtt sikerült orvosolni, de a probléma számos, széles körben használt szoftvert és rendszert érintett. A koordinált bejelentés után több gyártó is megerősítette termékeinek sebezhetőségét, és kiadta a szükséges javításokat.
Az érintett rendszerek listája rávilágít a szoftverellátási lánc komplexitására, ahol egyetlen protokollimplementációs hiba több tucat, egymásra épülő termékben is megjelenhet. A CERT Coordination Center (CERT/CC) által közzétett lista alapján a sebezhetőség számos népszerű keretrendszert, szervert és hálózati eszközt érintett.
Védekezési és javítási stratégiák
A „MadeYouReset” sebezhetőség kezelése a kiberbiztonsági ökoszisztéma együttműködésének mintapéldája. A sebezhetőséget a Tel-Avivi Egyetem kutatói fedezték fel, és az Akamai bug bounty programján keresztül jelentették. Ezt követően az Akamai, a kutatók és a CERT/CC szorosan együttműködve, egy koordinált folyamat keretében értesítették az érintett gyártókat, lehetővé téve számukra, hogy a nyilvánosságra hozatal előtt kifejlesszék és kiadják a szükséges javításokat. Ez a proaktív megközelítés megakadályozta, hogy a sebezhetőséget a támadók széles körben kihasználhassák, ellentétben a „Rapid Reset” esettel, amelyet már aktív támadások során fedeztek fel.
Érdekes tanulság, hogy a „Rapid Reset” elleni korábbi védekezések hatékonysága nagyban befolyásolta a „MadeYouReset” elleni védettséget. Azok a gyártók, mint például az Akamai, amelyek a „Rapid Reset” ellen egy robusztusabb, a probléma gyökerét célzó megoldást implementáltak – ahelyett, hogy csupán a kliens által küldött reseteket számolták volna –, automatikusan védettek voltak a „MadeYouReset” támadással szemben is. Ez aláhúzza a mélyreható, a mögöttes logikai hibát orvosló javítások fontosságát a felületes, tüneti kezelésekkel szemben.
A szervezetek számára a védekezés elsődleges és legfontosabb lépése a sebezhető szoftverek azonosítása és a gyártók által kiadott javítások azonnali telepítése. Azokban az esetekben, ahol a javítás azonnal nem lehetséges, átmeneti enyhítő intézkedések alkalmazhatók:
Szerveroldali
RST_STREAM
korlátozása: A szerver által egy kapcsolaton belül küldöttRST_STREAM
keretek számának vagy arányának korlátozása ideiglenes védelmet nyújthat.Protokollszabályok szigorítása: A webszerverek és a hálózati védelmi eszközök (pl. WAF) konfigurálása a protokoll anomáliáinak szigorúbb ellenőrzésére. A hibás vezérlőkeretek (pl. nullás növekményű
WINDOW_UPDATE
) fogadásakor a kapcsolat azonnali bontása hatékonyan megakadályozhatja a támadást.
A „MadeYouReset” sebezhetőség rávilágított, hogy a digitális infrastruktúránk technikai alapjai továbbra is rejtenek olyan logikai hibákat, amelyek kihasználása rendszerszintű kockázatot jelent. A támadás kifinomultsága, amely a szerver saját hibakezelési mechanizmusát fordítja fegyverré, egyértelműen jelzi a támadási technikák evolúcióját.
Share this post