Peking Egyetem, Qinghua Egyetem és a Dallas-i Texas Egyetem kutatócsoportja új DoS-támadási osztály — RangeAmp, amely az HTTP-fejlécek használatán alapul a tartalomszolgáltató hálózatokon (CDN) történő forgalomfokozás megszervezéséhez. A módszer lényege, hogy a Range-fejlécek feldolgozásának sajátosságai miatt sok CDN-nél a támadó egy bájt adhat meg egy nagy fájlhoz, de a CDN teljes fájlt vagy jelentősen nagyobb adatblokkokat tölt le a célkiszolgálóról a gyorsítótárhoz. Az ezen a támadáson átfolyó forgalom fokozódásának mértéke a CDN-től függően 724 és 43330 között változik, ami felhasználható egy CDN túlterhelésére vagy a céloldal sávszélességének csökkentésére.
A Range-fejléc lehetővé teszi a kliens számára, hogy meghatározza a fájl milyen pozícióinak tartományát kell letölteni a teljes fájl helyett. Például a kliens megadhatja, hogy «Range: bytes=0-1023», és a szerver csak az első 1024 bájt adatot fogja átadni. Ez a lehetőség különösen népszerű nagy fájlok letöltésekor — a felhasználó szüneteltetheti a letöltést, majd az megszakított pozícióról folytatható. A «bytes=0-0» megadásakor a norma előírja, hogy az első bájt legyen átadva, a «bytes=-1» az utolsó bájt, míg a «bytes=1-» az 1. bájtól a fájl végéig. Továbbá, több tartomány is megadható egy fejléccel, például «Range: bytes=0-1023,8192-10240».
Egy második támadási változatot is javasoltak, amely a hálózati terhelés növelésére irányul egy másik CDN-en keresztüli forgalomirányítással, amely proxyként működik (például amikor a Cloudflare a frontend (FCDN), míg az Akamai a backend (BCDN)). A módszer hasonlít az első támadáshoz, de a CDN-hálózatokon belül lokalizálódik, és lehetővé teszi a forgalom fokozását más CDN-eken keresztüli hozzáférés esetén, ezáltal növelve az infrastruktúrára nehezedő terhet és csökkentve a szolgáltatás minőségét.
Az ötlet az, hogy a támadó a CDN-hez több tartományra vonatkozó kéréseket küld, mint például: „bytes=0-,0-,0-…”, „bytes=1-,0-,0-…”, vagy „bytes=-1024,0-,0-…”. A kérések számos „0-” tartományt tartalmaznak, amelyek a fájl visszaadását jelentik a nulladik pozíciótól a végéig. A tartományok helytelen implementálása miatt, amikor az első CDN a másodikhoz fordul, minden „0-” tartományhoz a teljes fájl visszaadásra kerül (a tartományok nem aggregálódnak, hanem sorban kerülnek feldolgozásra), ha a támadó által elküldött eredeti kérésben tartományok megismétlődnek és keresztezik egymást. Az ilyen támadás forgalomfokozásának mértéke 53-tól 7432-szeresig terjed.
A kutatás során 13 CDN viselkedését vizsgálták meg -
Akamai, Alibaba Cloud, Azure, CDN77, CDNsun, Cloudflare, CloudFront, Fastly, G-Core Labs, Huawei Cloud, KeyCDN, StackPath és Tencent Cloud. Az összes vizsgált CDN engedett az első támadást a végső szerver ellen. A második CDN elleni támadásra 6 szolgáltatás volt érzékeny, amelyek közül négy a támadás front-endjeként (CDN77, CDNsun, Cloudflare és StackPath), míg három a backend szereplőjeként (Akamai, Azure és StackPath) működhetett. A legnagyobb fokozás az Akamai és StackPath esetén tapasztalható, amelyek lehetővé teszik, hogy a Range fejlécben több mint 10 ezer tartományt adjanak meg. A CDN-ek tulajdonosait körülbelül 7 hónappal ezelőtt értesítették a sebezhetőségekről, és a nyilvános nyilvánosságra hozatal pillanatában 12 a 13 CDN-ből orvosolta a felmerült problémákat, vagy jelezte, hogy készen áll az orvoslásra (csak a StackPath szolgáltatás nem reagált).
Forrás: opennet.ru
