Pekingo Unibertsitateko, Tsinghua Unibertsitateko eta Dallasko Texasko Unibertsitateko ikertzaile talde bat DoS erasoen klase berri bat - RangeAmp, HTTP goiburu baten erabileran oinarrituta edukien banaketa sareen bidez (CDN) trafikoaren anplifikazioa antolatzea. Metodoaren funtsa da CDN askotan Range goiburuak prozesatzeko moduaren ondorioz, erasotzaileak CDNren bidez fitxategi handi batetik byte bat eska dezakeela, baina CDNk fitxategi osoa edo askoz datu bloke handiagoa deskargatuko du. xede-zerbitzaria cachean jartzeko. Eraso batean trafikoaren anplifikazio-maila, CDNren arabera, 724 eta 43330 aldiz bitartekoa da, eta horrek CDN sarrerako trafikoaz gainkargatzeko edo biktimaren gunerako azken komunikazio kanalaren ahalmena murrizteko erabil daiteke.
Range goiburuak bezeroari aukera ematen dio fitxategian deskargatu beharreko posizio sorta bat zehazteko, fitxategi osoa itzuli beharrean. Adibidez, bezeroak "Barrutia: bytes=0-1023" zehaztu dezake eta zerbitzariak datuen lehen 1024 byteak soilik transmitituko ditu. Ezaugarri hau eskatzen da fitxategi handiak deskargatzen direnean - erabiltzaileak deskarga pausatu eta gero eten dagoen posiziotik jarraitu dezake. "bytes=0-0" zehazten denean, estandarrak fitxategiko lehen bytea emateko agintzen du, "bytes=-1" - azkena, "bytes=1-" - byte 1etik fitxategiaren amaiera arte. Goiburu bakarrean hainbat barruti igor daitezke, adibidez, βBarrutia: bytes=0-1023,8192-10240β.
Gainera, bigarren eraso-aukera bat proposatu da, trafikoa beste CDN baten bidez birbidaltzean sarearen karga areagotzeko xedea duena, proxy gisa erabiltzen dena (adibidez, Cloudflare frontend gisa (FCDN) eta Akamai backend gisa jarduten denean ( BCDN). Metodoa lehen erasoaren antzekoa da, baina CDN sareen barruan kokatzen da eta beste CDN batzuen bidez sartzen denean trafikoa areagotzea ahalbidetzen du, azpiegituraren karga areagotuz eta zerbitzuaren kalitatea murriztuz.
Ideia da erasotzaileak hainbat barrutitako Range eskaerak bidaltzea CDNra, hala nola "bytes=0-,0-,0-...", "bytes=1-,0-,0-..." edo "bytes=-1024,0 ,0-,0-...". Eskaerek "0-" barruti ugari dituzte, fitxategia zero posiziotik amaierara itzultzen dela esan nahi du. Barrutiaren analisiaren inplementazio okerra dela eta, lehenengo CDNa bigarrenera sartzen denean, fitxategi oso bat bidaltzen da "53-" barruti bakoitzeko (barrutiak ez dira batuta, sekuentzialki errepikatuta baizik), barrutiak bikoiztu eta gurutzatzen badira. erasotzaileak hasieran bidalitako eskaera. Horrelako eraso batean trafikoaren anplifikazio-maila 7432 eta XNUMX aldiz bitartekoa da.
Azterketan zehar, 13 CDNren portaera aztertu zen -
Akamai, Alibaba Cloud, Azure, CDN77, CDNsun, Cloudflare, CloudFront, Fastly, G-Core Labs, Huawei Cloud, KeyCDN, StackPath eta Tencent Cloud. Aztertutako CDN guztiek amaierako zerbitzarian lehen eraso mota onartzen zuten. CDN erasoaren bigarren aldaerak 6 zerbitzuri eragin zien, eta horietatik lauk erasoan frontend gisa jardun zezaketen (CDN77, CDNsun, Cloudflare eta StackPath) eta hiru backend gisa (Akamai, Azure eta StackPath). Irabazi handiena Akamai eta StackPath-en lortzen da, Range goiburuan 10 mila barruti baino gehiago zehaztu ahal izateko. CDN jabeei duela 7 hilabete inguru jakinarazi zieten ahultasunen berri, eta informazioa publikoki zabaldu zenerako, 12 CDNetatik 13k identifikatutako arazoak konpondu zituzten edo horiek konpontzeko prest agertu ziren (StackPath zerbitzuak soilik ez zuen erantzun).
Iturria: opennet.ru