Tîm o ymchwilwyr o Brifysgol Peking, Prifysgol Tsinghua a Phrifysgol Texas yn Dallas dosbarth newydd o ymosodiadau DoS - RangeAmp, yn seiliedig ar ddefnyddio pennawd HTTP i drefnu mwyhad traffig trwy rwydweithiau darparu cynnwys (CDN). Hanfod y dull yw, oherwydd y ffordd y mae penawdau Ystod yn cael eu prosesu mewn llawer o CDNs, gall ymosodwr ofyn am un beit o ffeil fawr trwy'r CDN, ond bydd y CDN yn lawrlwytho'r ffeil gyfan neu floc llawer mwy o ddata o'r gweinydd targed i'w roi yn y storfa. Mae graddfa'r chwyddo traffig yn ystod ymosodiad o'r fath, yn dibynnu ar y CDN, yn amrywio o 724 i 43330 o weithiau, y gellir ei ddefnyddio i orlwytho'r CDN â thraffig sy'n dod i mewn neu leihau cynhwysedd y sianel gyfathrebu derfynol i safle'r dioddefwr.
Mae'r pennawd Ystod yn rhoi'r gallu i'r cleient nodi ystod o safleoedd yn y ffeil y dylid eu llwytho i lawr yn lle dychwelyd y ffeil gyfan. Er enghraifft, gall y cleient nodi "Ystod: bytes = 0-1023" a bydd y gweinydd yn trosglwyddo'r 1024 beit cyntaf o ddata yn unig. Mae galw am y nodwedd hon wrth lwytho i lawr ffeiliau mawr - gall y defnyddiwr oedi'r lawrlwythiad ac yna parhau o'r sefyllfa amharwyd. Wrth nodi "bytes = 0-0", mae'r safon yn cyfarwyddo i roi'r beit cyntaf yn y ffeil, "bytes = -1" - yr olaf, "bytes = 1-" - gan ddechrau o 1 beit tan ddiwedd y ffeil. Mae'n bosibl trawsyrru sawl ystod mewn un pennawd, er enghraifft “Ystod: beit = 0-1023,8192-10240”.
Yn ogystal, mae ail opsiwn ymosodiad wedi'i gynnig, gyda'r nod o gynyddu llwyth y rhwydwaith wrth anfon traffig ymlaen trwy CDN arall, a ddefnyddir fel dirprwy (er enghraifft, pan fo Cloudflare yn gweithredu fel pen blaen (FCDN), ac Akamai yn gweithredu fel y pen ôl ( BCDN). Mae'r dull yn debyg i'r ymosodiad cyntaf, ond mae wedi'i leoleiddio o fewn rhwydweithiau CDN ac mae'n caniatáu ar gyfer mwy o draffig pan gyrchir ato trwy CDNs eraill, gan gynyddu'r llwyth ar y seilwaith a lleihau ansawdd y gwasanaeth.
Y syniad yw bod yr ymosodwr yn anfon ceisiadau Ystod o sawl ystod i'r CDN, megis "bytes=0-,0-,0-...", "bytes=1-,0-,0-..." neu "beit=-1024,0 ,0-,0-...". Mae ceisiadau'n cynnwys nifer fawr o ystodau “0-”, sy'n awgrymu bod y ffeil yn cael ei dychwelyd o safle sero i'r diwedd. Oherwydd gweithrediad anghywir dosrannu amrediad, pan fydd y CDN cyntaf yn cyrchu'r ail, anfonir ffeil gyflawn ar gyfer pob ystod "53-" (nid yw'r ystodau wedi'u hagregu, ond yn cael eu hailadrodd yn ddilyniannol), os oes dyblygu a chroestoriad ystodau yn y cais a anfonwyd i ddechrau gan yr ymosodwr. Mae graddau'r chwyddo traffig mewn ymosodiad o'r fath yn amrywio o 7432 i XNUMX o weithiau.
Yn ystod yr astudiaeth, astudiwyd ymddygiad 13 CDN -
Akamai, Alibaba Cloud, Azure, CDN77, CDNsun, Cloudflare, CloudFront, Fastly, G-Core Labs, Huawei Cloud, KeyCDN, StackPath a Tencent Cloud. Roedd pob un o'r CDNs a archwiliwyd yn caniatáu'r math cyntaf o ymosodiad ar y gweinydd terfynol. Effeithiodd ail amrywiad yr ymosodiad CDN ar 6 gwasanaeth, a gallai pedwar ohonynt weithredu fel blaen yn yr ymosodiad (CDN77, CDNsun, Cloudflare a StackPath) a thri fel cefn (Akamai, Azure a StackPath). Ceir y cynnydd mwyaf yn Akamai a StackPath, sy'n caniatáu nodi mwy na 10 mil o amrediadau ym mhennawd Ystod. Hysbyswyd perchnogion CDN o’r gwendidau tua 7 mis yn ôl, ac erbyn i’r wybodaeth gael ei datgelu’n gyhoeddus, roedd 12 o’r 13 CDN wedi trwsio’r problemau a nodwyd neu wedi mynegi parodrwydd i’w trwsio (dim ond gwasanaeth StackPath wnaeth ymateb).
Ffynhonnell: opennet.ru