Kutatócsoport a Pekingi Egyetemről, a Tsinghua Egyetemről és a texasi Dallas-i Egyetemről kiadott információkat a az ön munkája, hogy azonosítani tudja a DoS támadások új osztálya, amelyet "RangeAmp" -nak neveztek el és amelyek a Range HTTP fejléc használatán alapulnak a forgalom erősítésének megszervezéséhez a tartalomszolgáltató hálózaton (CDN) keresztül.
A módszer lényege A dolog, számos CDN-n lévő Range fejlécek feldolgozásának furcsasága miatt, egy támadó nagy fájlból kérhet bájtot CDN-en keresztül, de a CDN letölti a teljes fájlt vagy egy lényegesen nagyobb adatblokkot a célkiszolgálóról gyorsítótárazáshoz.
Az ilyen típusú támadás során a forgalom erősítésének mértéke a CDN szerint 724-43330-szorosa, amely felhasználható a bejövő CDN-forgalom túlterhelésére, vagy a végső kommunikációs csatorna sávszélességének csökkentésére az áldozat helyszínére.
A Range fejléc lehetővé teszi az ügyfél számára, hogy meghatározza a fájl pozícióinak tartományát amelyet a teljes fájl visszaadása helyett be kell tölteni.
Például az ügyfél megadhatja a "Tartomány: bájt = 0-1023" értéket, és a szerver csak az első 1024 bájt adatot továbbítja. Erre a szolgáltatásra nagy szükség van nagy fájlok letöltésekor: a felhasználó szüneteltetheti a letöltést, majd folytathatja a megszakított pozícióból. A "bájt = 0-0" megadásakor a szabvány előírja, hogy a fájl első bájtját "bájt = -1" - az utolsó, "bájt = 1-" - adja meg 1 bájttól a fájl végéig. Több fejlécet adhat át egy fejlécben, például "Tartomány: bájt = 0-1023.8192-10240".
Ezen túlmenően, egy második támadási lehetőséget javasoltak (RangeAmp Overlapping Byte Ranges (OBR) támadásnak hívják, amelynek célja a hálózati terhelés növelése amikor a forgalmat egy másik CDN-en keresztül továbbítják, amelyet proxyként használnak (például amikor a Cloudflare frontendként (FCDN), az Akamai pedig backendként (BCDN) működik). A módszer hasonlít az első támadásra, de a CDN-eken belül lokalizálódik, és lehetővé teszi a forgalom növelését, amikor más CDN-eken keresztül ér el, növelve az infrastruktúra terhelését és csökkentve a szolgáltatás minőségét.
Az ötlet az, hogy a támadó több tartományt küldjön a CDN tartomány kérésére, például "bytes = 0-, 0-, 0 - ...", "bytes = 1-, 0-, 0 - ..." vagy "bájt = - 1024,0-, 0 -…«.
A kérelmek nagyszámú "0-" tartományt tartalmaznak, ami a fájl nulláról a végére való visszatérését jelenti. Ha az első CDN a másodikra vonatkozik, a helytelen értelmezés miatt egy teljes fájl visszatér minden "0-" sávba (a tartományokat nem összesítik, hanem egymás után rendezik), ha az eredetileg benyújtott támadási kérelemben a tartomány duplikációja és kereszteződése szerepel. A forgalom erősítésének mértéke egy ilyen támadásban 53-7432-szer mozog.
A tanulmány 13 CDN-k viselkedését vizsgálta: Akamai, Alibaba Cloud, Azure, CDN77, CDNsun, Cloudflare, CloudFront, Fastly, G-Core Labs, Huawei Cloud, KeyCDN, StackPath és Tencent Cloud.
"Sajnos, bár többször e-mailt küldtünk nekik, és megpróbáltuk felvenni a kapcsolatot az ügyfélszolgálatukkal, a StackPath nem adott visszajelzést" - mondta a kutatócsoport.
„Összességében mindent megtettünk a sebezhetőségek felelősségteljes bejelentése és az enyhítő megoldások érdekében. A kapcsolódó CDN-szolgáltatóknak közel hét hónapja volt a mérséklési technikák bevezetésére, mielőtt ezt a dokumentumot közzétették.
Minden áttekintett CDN engedélyezte az első típusú támadást a célszerveren. Kiderült, hogy a CDN támadás második verziója 6 szolgáltatásnak van kitéve, amelyek közül négy interfészként működhet a támadásban (CDN77, CDNsun, Cloudflare és StackPath), három pedig háttérprogram szerepében (Akamai, Azure és StackPath).
A legnagyobb nyereséget az Akamai és a StackPath programban érik el, amelyek lehetővé teszik, hogy több mint 10 XNUMX rangot jelezzen a Rank címben.
A CDN-tulajdonosokat értesítették sérülékenységek körülbelül 7 hónapja és az információk nyilvános nyilvánosságra hozatala idején a 12 CDN-ből 13 megoldotta a feltárt problémákat, vagy kifejezte hajlandóságát azok megoldására.
forrás: https://www.liubaojun.org