A Pekingi Egyetem, a Tsinghua Egyetem és a Dallasi Texasi Egyetem kutatóiból álló csapat a DoS támadások új osztálya - RangeAmp, amely egy HTTP-fejléc használatán alapul a forgalom erősítésének megszervezése tartalomszolgáltató hálózatokon (CDN) keresztül. A módszer lényege, hogy a Range fejlécek sok CDN-ben történő feldolgozási módja miatt a támadó egy bájtot kérhet egy nagy fájlból a CDN-en keresztül, de a CDN letölti a teljes fájlt vagy egy sokkal nagyobb adattömböt a CDN-ről. a gyorsítótárba helyezendő célszervert. Egy ilyen támadás során a forgalom erősítése a CDN-től függően 724-től 43330-ig terjed, ami felhasználható a CDN túlterhelésére a bejövő forgalommal, vagy csökkentheti az áldozat helyéhez vezető végső kommunikációs csatorna kapacitását.
A Range fejléc lehetőséget ad az ügyfélnek, hogy meghatározza a fájl azon pozícióinak tartományát, amelyeket le kell tölteni a teljes fájl visszaadása helyett. Például a kliens megadhatja a "Tartomány: bytes=0-1023" értéket, és a szerver csak az első 1024 bájt adatot továbbítja. Erre a funkcióra nagy fájlok letöltése esetén van szükség – a felhasználó szüneteltetheti a letöltést, majd a megszakított pozícióból folytathatja. A „bytes=0-0” megadásakor a szabvány azt utasítja, hogy a fájl első bájtját adja meg, „bytes=-1” - az utolsót, „bytes=1-” - 1 bájttól kezdve a fájl végéig. Lehetőség van több tartomány átvitelére egy fejlécben, például „Tartomány: bytes=0-1023,8192-10240”.
Ezenkívül egy második támadási lehetőséget is javasoltak, 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 az előtér (FCDN), az Akamai pedig a háttérrendszer. BCDN). A módszer hasonló az első támadáshoz, de a CDN-hálózatokon belül lokalizálódik, és megnövekedett forgalmat tesz lehetővé, ha más CDN-eken keresztül érik 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ányú Range kérést küld a CDN-nek, például "bytes=0-,0-,0-...", "bytes=1-,0-,0-..." vagy "bytes=-1024,0 ,0-,0-...". A kérések nagyszámú „0-” tartományt tartalmaznak, ami azt jelenti, hogy a fájl a nulla pozícióból a végére kerül vissza. A tartományelemzés helytelen megvalósítása miatt, amikor az első CDN hozzáfér a másodikhoz, akkor minden „53-” tartományhoz egy teljes fájl kerül elküldésre (a tartományok nem aggregálódnak, hanem szekvenciálisan iterálódnak), ha a tartományok duplikációja és metszéspontja van a támadó által eredetileg küldött kérés. A forgalom erősítése egy ilyen támadásnál 7432-XNUMX-szeres.
A vizsgálat során 13 CDN viselkedését vizsgálták -
Akamai, Alibaba Cloud, Azure, CDN77, CDNsun, Cloudflare, CloudFront, Fastly, G-Core Labs, Huawei Cloud, KeyCDN, StackPath és Tencent Cloud. Az összes vizsgált CDN lehetővé tette az első típusú támadást a végkiszolgáló ellen. A CDN-támadás második változata 6 szolgáltatást érintett, amelyek közül négy frontendként működhetett a támadásban (CDN77, CDNsun, Cloudflare és StackPath), három pedig háttérprogramként (Akamai, Azure és StackPath). A legnagyobb nyereség az Akamai és a StackPath esetében érhető el, amelyek több mint 10 ezer tartomány megadását teszik lehetővé a Range fejlécben. A CDN-tulajdonosokat körülbelül 7 hónapja értesítették a sérülékenységekről, és mire az információ nyilvánosságra került, 12 CDN-ből 13 javította az azonosított problémákat, vagy jelezte készségét a javításukra (csak a StackPath szolgáltatás nem válaszolt).
Forrás: opennet.ru