Изследователи по киберсигурност разкриха две атаки за отказ от услуга (DoS), които експлоатират начина, по който големите мрежи за доставка на съдържание (CDN) преобразуват входящия HTTP/3 трафик от клиенти в HTTP/1.1 заявки към уебсайтовете зад тях. Това засилва потока от заявки с ниска пропускателна способност до 350 пъти срещу сървъра източник.

Атаките, наречени общо „CDN Tsunami“, са оценени спрямо Alibaba, Baidu, Cloudflare, Amazon CloudFront, Fastly и Tencent. И шестте доставчика са се оказали уязвими към варианта за усилване на пропускателната способност, а пет от тях – към варианта за усилване на връзките. Cloudflare не е засегнат от втория вариант, тъй като буферира пълната заявка, преди да отвори връзка към сървъра източник.

Атаката изисква уебсайтът да бъде хостван при един от шестте доставчика, с активиран HTTP/3 в периферията (edge), като не са необходими промени в конфигурацията от страна на уебсайта. Докладът посочва, че HTTP/3 е активиран по подразбиране в Cloudflare и CloudFront. Документацията на Cloudflare обаче описва HTTP/3 като достъпен за всички планове и предоставя стъпки за активирането му, вместо да твърди, че е активиран по подразбиране. Документацията на AWS посочва http2 като версия на HTTP по подразбиране за нови CloudFront дистрибуции.

Факторът от 350x се прилага само за Alibaba, Baidu и Tencent. Тези три доставчика поддържат динамичната таблица QPACK, като измерването е извършено при приблизително 64 едновременни потока, докато максимумът при Cloudflare, CloudFront и Fastly варира от 36.41x до 51.2x.

Не са присвоени CVE идентификатори и не се съобщава за експлоатация в реална среда. Докато Baidu и Tencent потвърдиха докладите и внедриха предложените корекции, изследователите споделят, че всяко предложено смекчаване се прилага на ниво CDN, а не на самия уебсайт източник.

Двете техники са наречени HTTP/3 Bandwidth Amplification (HBA) и HTTP/3 Connection Amplification (HCA), като и двете се основават на един и същ пропуск при внедряването – CDN комуникира с браузъра чрез HTTP/3, но използва само HTTP/1.1 към уебсайта зад него. Несъответствие, което според екипа съществува, защото „CDN мрежите не поддържат HTTP/3 от край до край“.

HBA използва QPACK – форматът за компресиране на хедъри, въведен с HTTP/3. Тъй като HTTP/1.1 не съдържа еквивалентен механизъм, CDN трябва да разшири всяка малка индексна стойност, която получава обратно, в пълен необработен хедър преди препращане на заявката. Така заявка, струваща на атакуващия няколко байта по мрежата, струва на източника декомпресирания размер. Пропускателната способност от страна на атакуващия е останала под 500 Kbps срещу трите CDN мрежи, поддържащи динамичната таблица, и под 5 Mbps срещу останалите, докато консумацията на трафик, измерена при източника, е надхвърлила 100 Mbps през цялото време.

Вариантът с динамична таблица изисква атакуващият първо да изпрати една HTTP/3 заявка, носеща голям хедър, която CDN вмъква в таблицата, и след това да препраща към този запис многократно, използвайки малки индексни стойности. Поддръжката е ограничена до Alibaba, Baidu и Tencent, като всеки от тях декларира 4KB таблица с максимален размер на записа от 3072 байта.

Максималните фактори на усилване на пропускателната способност, измерени с помощта на статичната таблица QPACK, са следните:

  • Baidu: 66.06x (с поддръжка на динамична таблица)
  • Alibaba: 65.8x (с поддръжка на динамична таблица)
  • Tencent: 54.08x (с поддръжка на динамична таблица)
  • Amazon CloudFront: 51.2x (без поддръжка на динамична таблица)
  • Cloudflare: 48.27x (без поддръжка на динамична таблица)
  • Fastly: 36.41x (без поддръжка на динамична таблица)

HCA е насочена към капацитета за връзки, а не към пропускателната способност. Пет от шестте CDN мрежи отварят HTTP/1.1 връзка към източника веднага щом получат HTTP/3 рамката HEADERS, преди да пристигне тялото на заявката. Мултиплексирането на HTTP/3 позволява на една клиентска връзка да пренася множество потоци, всеки от които задейства собствена TCP връзка към бекенда. Изпращането на DATA рамки с много ниска скорост поддържа тези връзки отворени, като CDN продължава да третира заявката като незавършена.

Срещу сървър Apache, конфигуриран с време на изчакване от 300 секунди и лимит от 256 връзки, четири HTTP/3 връзки, всяка от които мултиплексира 96 потока, са принудили 384 бекенд връзки. Fastly е изисквал 48 връзки от 8 потока, тъй като ограничава бекенд връзките до 10 на една HTTP/3 връзка.

Времето за реакция за легитимен клиент е достигнало 60 секунди при Alibaba и до 90 секунди при Baidu и CloudFront (и двете връщащи HTTP 504 Gateway Timeout), докато при Fastly е нараснало до 15 секунди и е върнало HTTP 503 Service Unavailable. Tencent е затворил връзката от страната на клиента приблизително 10 секунди след получаване на сондажна заявка и не е върнал отговор.

Експериментите са били ограничени от лимити, които изследователите са наложили сами на себе си, като източникът е бил ограничен до 100 Mbps, а атакуващият – до 30 Mbps. В доклада се посочва, че атаките се мащабират до сървъри с по-висок капацитет – твърдение, което не е тествано.

Установено е също, че факторът на усилване достига пик близо до 64 едновременни потока и след това намалява, което изследователите приписват на натоварването на процесора в периферията на CDN, въпреки че не са представени измервания на процесора.

За да оценят експозицията, екипът е изброил поддомейни от списъка Tranco Top 1M, обходил е техните CNAME и NS записи и ги е съпоставил с известни адреси, присвоени от CDN.