Et team av forskere fra Peking University, Tsinghua University og University of Texas i Dallas gitt ut informasjon om arbeidet ditt gjort for å kunne identifisere en ny klasse av DoS-angrep som de kalte "RangeAmp" og som er basert på bruken av Range HTTP header for å organisere forsterkning av trafikk gjennom innholdsleveringsnettverket (CDN).
Essensen av metoden tingen er, på grunn av særegen behandling av Range headers på mange CDN-er, en angriper kan be om byte fra en stor fil via CDN, men CDN vil laste ned hele filen eller en betydelig større datablokk fra målserveren for hurtigbufring.
Graden av trafikkforsterkning under et angrep av denne typen, ifølge CDN, er 724 til 43330 ganger, som kan brukes til å overbelaste den innkommende CDN-trafikken eller redusere båndbredden til den endelige kommunikasjonskanalen til stedet for offeret.
Områdeoverskriften lar klienten bestemme rekkevidden til posisjonene i filen som skal lastes i stedet for å returnere hele filen.
For eksempel kan klienten spesifisere "Range: bytes = 0-1023", og serveren vil bare overføre de første 1024 byte med data. Denne funksjonen er veldig etterspurt når du laster ned store filer: brukeren kan sette nedlastingen på pause og deretter fortsette den fra avbrutt posisjon. Når du spesifiserer "bytes = 0-0", foreskriver standarden å gi den første byten i filen, "bytes = -1" - den siste, "bytes = 1-" - fra 1 byte til slutten av filen. Du kan passere flere områder i en overskrift, for eksempel "Range: bytes = 0-1023.8192-10240".
Videre et annet angrepsalternativ ble foreslått (det kalles RangeAmp Overlapping Byte Ranges (OBR) angrep, designet for å øke nettverksbelastningen når trafikk videresendes gjennom en annen CDN, som brukes som proxy (for eksempel når Cloudflare fungerer som frontend (FCDN) og Akamai fungerer som backend (BCDN)). Metoden ligner det første angrepet, men er lokalisert i CDN-er og lar deg øke trafikken når du får tilgang gjennom andre CDN-er, øker belastningen på infrastrukturen og reduserer kvaliteten på tjenesten.
Tanken er at angriperen skal sende flere områder til CDN-rekkevidde, for eksempel "bytes = 0-, 0-, 0 - ...", "bytes = 1-, 0-, 0 - ..." eller "bytes = - 1024,0-, 0 -…«.
Forespørsler inneholder et stort antall "0-" områder, som innebærer retur av filen fra bunnen av til slutten. På grunn av feil områdeparsering når den første CDN refererer til den andre, returneres en full fil til hvert "0-" bånd (områdene er ikke aggregerte, men bestilles sekvensielt) hvis rekkevidde duplisering og skjæringspunkt er til stede i angrepsforespørselen opprinnelig sendt. Graden av trafikkforsterkning i et slikt angrep varierer fra 53 til 7432 ganger.
Studien undersøkte oppførselen til 13 CDN-er: Akamai, Alibaba Cloud, Azure, CDN77, CDNsun, Cloudflare, CloudFront, Fastly, G-Core Labs, Huawei Cloud, KeyCDN, StackPath og Tencent Cloud.
"Dessverre, selv om vi sendte dem flere ganger og prøvde å kontakte kundeservicen deres, ga ikke StackPath noen tilbakemelding," sa forskerteamet.
“Samlet sett har vi gjort vårt beste for å rapportere sårbarheter på en ansvarlig måte og tilby avbøtende løsninger. Beslektede CDN-leverandører har hatt nesten syv måneder på seg til å implementere avbøtende teknikker før dette dokumentet ble publisert. "
Alle gjennomgåtte CDN-er tillot den første typen angrep på målserveren. Den andre versjonen av CDN-angrepet viste seg å være utsatt for 6 tjenester, hvorav fire kan fungere som et grensesnitt i angrepet (CDN77, CDNsun, Cloudflare og StackPath) og tre i rollen som back-end (Akamai, Azure og StackPath).
Den høyeste gevinsten oppnås i Akamai og StackPath, som lar deg angi mer enn 10 XNUMX rangeringer i Rank-overskriften.
CDN-eiere ble varslet om av sårbarheter ca 7 måneder siden og på tidspunktet for offentliggjøring av informasjon løste 12 av 13 CDN-er problemene som ble identifisert, eller ga uttrykk for at de var villige til å løse dem.
Fuente: https://www.liubaojun.org