Un team di ricercatori dell'Università di Pechino, dell'Università Tsinghua e dell'Università del Texas a Dallas una nuova classe di attacchi DoS - RangeAmp, basata sull'uso di un'intestazione HTTP organizzare l'amplificazione del traffico attraverso reti di distribuzione dei contenuti (CDN). L'essenza del metodo è che, a causa del modo in cui le intestazioni Range vengono elaborate in molti CDN, un utente malintenzionato può richiedere un byte da un file di grandi dimensioni tramite il CDN, ma il CDN scaricherà l'intero file o un blocco di dati molto più grande dal CDN. server di destinazione da inserire nella cache. Il grado di amplificazione del traffico durante un simile attacco varia, a seconda della CDN, da 724 a 43330 volte, il che può essere utilizzato per sovraccaricare la CDN con traffico in entrata o ridurre la capacità del canale di comunicazione finale verso il sito della vittima.
L'intestazione Range offre al client la possibilità di specificare un intervallo di posizioni nel file che devono essere scaricate invece di restituire l'intero file. Ad esempio, il client può specificare "Intervallo: byte=0-1023" e il server trasmetterà solo i primi 1024 byte di dati. Questa funzionalità è richiesta durante il download di file di grandi dimensioni: l'utente può mettere in pausa il download e quindi continuare dalla posizione interrotta. Quando si specifica “bytes=0-0”, lo standard indica di fornire il primo byte nel file, “bytes=-1” - l'ultimo, “bytes=1-” - a partire da 1 byte fino alla fine del file. È possibile trasmettere più intervalli in un'unica intestazione, ad esempio "Intervallo: byte=0-1023,8192-10240".
Inoltre, è stata proposta una seconda opzione di attacco, volta ad aumentare il carico di rete quando si inoltra il traffico attraverso un altro CDN, che viene utilizzato come proxy (ad esempio, quando Cloudflare funge da frontend (FCDN) e Akamai funge da backend ( BCDN). Il metodo è simile al primo attacco, ma è localizzato all'interno delle reti CDN e consente un aumento del traffico in caso di accesso tramite altre CDN, aumentando il carico sull'infrastruttura e riducendo la qualità del servizio.
L'idea è che l'aggressore invii richieste di intervallo di diversi intervalli alla CDN, ad esempio "bytes=0-,0-,0-...", "bytes=1-,0-,0-..." o "byte=-1024,0-,0-...". Le richieste contengono un gran numero di intervalli "0-", il che implica che il file viene restituito dalla posizione zero fino alla fine. A causa di un'errata implementazione dell'analisi degli intervalli, quando il primo CDN accede al secondo, viene inviato un file completo per ciascun intervallo "0-" (gli intervalli non vengono aggregati, ma iterati sequenzialmente), se c'è duplicazione e intersezione di intervalli in la richiesta inizialmente inviata dall'attaccante. Il grado di amplificazione del traffico in un simile attacco varia da 53 a 7432 volte.
Durante lo studio è stato studiato il comportamento di 13 CDN:
Akamai, Alibaba Cloud, Azure, CDN77, CDNsun, Cloudflare, CloudFront, Fastly, G-Core Labs, Huawei Cloud, KeyCDN, StackPath e Tencent Cloud. Tutte le CDN esaminate hanno consentito il primo tipo di attacco al server finale. La seconda variante dell'attacco CDN ha colpito 6 servizi, di cui quattro potevano fungere da frontend nell'attacco (CDN77, CDNsun, Cloudflare e StackPath) e tre come backend (Akamai, Azure e StackPath). Il guadagno maggiore si ottiene in Akamai e StackPath, che consentono di specificare più di 10mila intervalli nell'intestazione Range. I proprietari di CDN sono stati informati delle vulnerabilità circa 7 mesi fa e, nel momento in cui le informazioni sono state divulgate pubblicamente, 12 CDN su 13 avevano risolto i problemi identificati o espresso la disponibilità a risolverli (solo il servizio StackPath non ha risposto).
Fonte: opennet.ru