Исследователи описали DoS-атаки через преобразование HTTP/3 в CDN
Техники CDN Tsunami используют разрыв между HTTP/3 на стороне клиента и HTTP/1.1 на стороне исходного сайта. В испытаниях максимальное усиление трафика достигало 350 раз, но такой показатель получен лишь у трёх CDN.
Исследователи в области кибербезопасности раскрыли две техники DoS-атак, объединённые названием CDN Tsunami. Они используют схему, при которой CDN принимает клиентский трафик по HTTP/3, но передаёт запросы на защищаемый исходный сервер по HTTP/1.1. В результате небольшой поток данных от атакующего может превратиться в существенно более крупную нагрузку на сервер-источник.
Авторы работы проверили Alibaba, Baidu, Cloudflare, Amazon CloudFront, Fastly и Tencent. Варианту с усилением пропускной способности оказались подвержены все шесть сервисов, а атаке на ресурсы соединений — пять из шести. Cloudflare не затронут вторым вариантом, поскольку сначала буферизует запрос целиком и только затем открывает соединение с исходным сервером.
Первая техника, HTTP/3 Bandwidth Amplification (HBA), связана со сжатием заголовков QPACK в HTTP/3. CDN должна развернуть сжатые значения в обычные заголовки HTTP/1.1 перед отправкой на исходный сервер. Поэтому компактный запрос может создать на стороне источника трафик заметно большего объёма. Наибольший заявленный коэффициент усиления — до 350 раз — исследователи получили у Alibaba, Baidu и Tencent, поддерживающих динамическую таблицу QPACK. Для Cloudflare, CloudFront и Fastly измеренные максимумы находились в диапазоне от 36,41 до 51,2 раза.
В тестах трафик атакующего не превышал 500 Кбит/с для трёх CDN с динамической таблицей QPACK и 5 Мбит/с для остальных. При этом трафик, измеренный на исходном сервере, во всех случаях превышал 100 Мбит/с. Эксперименты были ограничены самими авторами: источник был ограничен 100 Мбит/с, а атакующая сторона — 30 Мбит/с.
Вторая техника, HTTP/3 Connection Amplification (HCA), нацелена не на канал связи, а на число соединений с сервером-источником. Пять CDN из шести открывали соединение HTTP/1.1 после получения HTTP/3-фрейма HEADERS, не дожидаясь тела запроса. Один HTTP/3-сеанс допускает множество параллельных потоков, и каждый из них способен вызвать отдельное TCP-соединение с бэкендом. Если затем передавать тело запроса крайне медленно, эти соединения остаются занятыми.
При проверке на Apache с лимитом в 256 соединений и тайм-аутом 300 секунд четыре HTTP/3-соединения по 96 потоков создали 384 соединения с исходным сервером. В таких условиях запросы обычного клиента выполнялись до 60 секунд на Alibaba и до 90 секунд на Baidu и CloudFront; последние два сервиса возвращали ошибку 504. У Fastly задержка достигала 15 секунд, после чего сервис отвечал ошибкой 503.
Авторы также просканировали поддомены из списка Tranco Top 1M и обнаружили 151 685 поддоменов, размещённых у шести затронутых провайдеров. Из них 42 330 ответили на HTTP/3-запрос и были отнесены к потенциально уязвимым. Больше всего таких адресов пришлось на CloudFront — 17 431, Cloudflare — 12 371 и Fastly — 11 606. Эта проверка показывает доступность HTTP/3 на CDN, но не подтверждает атаку на конкретные сторонние сайты.
Идентификаторы CVE для CDN Tsunami не назначены, сведений об эксплуатации техник в реальных атаках нет. Baidu и Tencent подтвердили получение отчётов и внедрили предложенные исправления. Все описанные меры применяются на стороне CDN, а не владельцами исходных сайтов. Среди предложений — ограничить размер записей в динамической таблице QPACK, число обращений к одной записи и максимально допустимый размер развёрнутого HTTP/1.1-запроса.