- 29,310
- 46
- 8 Ноя 2022
Найден способ использовать инфраструктуру CDN против защищаемых ею сайтов.
<div class="articl-text-cover" style="position:relative;width:100%;max-width:800px;margin-left:auto;margin-right:auto;aspect-ratio:1200/675;margin-bottom:2rem;overflow:hidden">
<div itemprop="articleBody">Технология, которая должна ускорять загрузку сайтов, может многократно усилить направленный на них вредоносный трафик. Группа ученых описала две новые DoS-атаки на сети доставки контента (CDN), позволяющие использовать инфраструктуру провайдера против защищаемого сайта. В некоторых условиях трафик усиливается примерно в 350 раз. Исследование получило название CDN Tsunami.
Проблема возникает из-за разницы протоколов на двух участках соединения. Пользователь может обращаться к CDN по современному HTTP/3, однако между CDN и исходным сервером шесть проверенных провайдеров используют HTTP/1.1 . CDN приходится преобразовывать запросы из одного формата в другой. Авторы показали, что злоумышленник способен заставить CDN расходовать при таком преобразовании значительно больше ресурсов исходного сервера.
Первый вариант авторы назвали HTTP/3 Bandwidth Amplification (HBA). HTTP/3 сжимает заголовки с помощью QPACK и может передавать вместо повторяющихся данных короткие индексы. HTTP/1.1 такого механизма не имеет, поэтому CDN разворачивает компактные записи обратно в полные заголовки, прежде чем отправить запрос серверу. Небольшой поток со стороны злоумышленника в результате превращается в гораздо больший поток к исходному серверу.
В испытаниях трафик усилился примерно в 350 раз, когда специалисты задействовали динамическую таблицу QPACK. Пик наблюдался примерно при 64 параллельных потоках. Для трех CDN, которые поддерживают такую таблицу, атакующей стороне требовалось менее 500 Кбит/с, тогда как нагрузка на тестовый сервер превышала 100 Мбит/с.
Второй вариант, HTTP/3 Connection Amplification (HCA), атакует не пропускную способность, а доступные соединения. HTTP/3 позволяет передавать множество потоков внутри одного соединения. Пять из шести проверенных CDN сразу открывали отдельные соединения HTTP/1.1 с исходным сервером, как только получали заголовки. Медленно передавая оставшиеся данные, злоумышленник может удерживать такие соединения открытыми и исчерпать их допустимое число.
Специалисты проверили Alibaba, Baidu, Cloudflare, Amazon CloudFront, Fastly и Tencent. Все шесть оказались подвержены HBA, пять из шести – HCA. Cloudflare избежала второго варианта, поскольку сначала получает запрос целиком и лишь затем устанавливает соединение с исходным сервером. Специалисты проверили список Tranco Top 1M и выявили 151 685 поддоменов за затронутыми CDN, причем 42 330 из них соответствовали условиям потенциальной атаки.
Авторы сообщили результаты всем шести провайдерам. Baidu и Tencent подтвердили проблемы, выплатили вознаграждения и внедрили предложенные меры защиты. Tencent, в частности, ограничила число соединений между CDN и исходным сервером и размер заголовков в динамической таблице. Для защиты специалисты предлагают ограничивать развернутый размер запросов и коэффициент усиления, не открывать соединение с сервером, пока не получен полный запрос, а также вводить независимые ограничения времени и количества таких соединений.
<div class="articl-text-cover" style="position:relative;width:100%;max-width:800px;margin-left:auto;margin-right:auto;aspect-ratio:1200/675;margin-bottom:2rem;overflow:hidden">
<div itemprop="articleBody">Технология, которая должна ускорять загрузку сайтов, может многократно усилить направленный на них вредоносный трафик. Группа ученых описала две новые DoS-атаки на сети доставки контента (CDN), позволяющие использовать инфраструктуру провайдера против защищаемого сайта. В некоторых условиях трафик усиливается примерно в 350 раз. Исследование получило название CDN Tsunami.
Проблема возникает из-за разницы протоколов на двух участках соединения. Пользователь может обращаться к CDN по современному HTTP/3, однако между CDN и исходным сервером шесть проверенных провайдеров используют HTTP/1.1 . CDN приходится преобразовывать запросы из одного формата в другой. Авторы показали, что злоумышленник способен заставить CDN расходовать при таком преобразовании значительно больше ресурсов исходного сервера.
Первый вариант авторы назвали HTTP/3 Bandwidth Amplification (HBA). HTTP/3 сжимает заголовки с помощью QPACK и может передавать вместо повторяющихся данных короткие индексы. HTTP/1.1 такого механизма не имеет, поэтому CDN разворачивает компактные записи обратно в полные заголовки, прежде чем отправить запрос серверу. Небольшой поток со стороны злоумышленника в результате превращается в гораздо больший поток к исходному серверу.
В испытаниях трафик усилился примерно в 350 раз, когда специалисты задействовали динамическую таблицу QPACK. Пик наблюдался примерно при 64 параллельных потоках. Для трех CDN, которые поддерживают такую таблицу, атакующей стороне требовалось менее 500 Кбит/с, тогда как нагрузка на тестовый сервер превышала 100 Мбит/с.
Второй вариант, HTTP/3 Connection Amplification (HCA), атакует не пропускную способность, а доступные соединения. HTTP/3 позволяет передавать множество потоков внутри одного соединения. Пять из шести проверенных CDN сразу открывали отдельные соединения HTTP/1.1 с исходным сервером, как только получали заголовки. Медленно передавая оставшиеся данные, злоумышленник может удерживать такие соединения открытыми и исчерпать их допустимое число.
Специалисты проверили Alibaba, Baidu, Cloudflare, Amazon CloudFront, Fastly и Tencent. Все шесть оказались подвержены HBA, пять из шести – HCA. Cloudflare избежала второго варианта, поскольку сначала получает запрос целиком и лишь затем устанавливает соединение с исходным сервером. Специалисты проверили список Tranco Top 1M и выявили 151 685 поддоменов за затронутыми CDN, причем 42 330 из них соответствовали условиям потенциальной атаки.
Авторы сообщили результаты всем шести провайдерам. Baidu и Tencent подтвердили проблемы, выплатили вознаграждения и внедрили предложенные меры защиты. Tencent, в частности, ограничила число соединений между CDN и исходным сервером и размер заголовков в динамической таблице. Для защиты специалисты предлагают ограничивать развернутый размер запросов и коэффициент усиления, не открывать соединение с сервером, пока не получен полный запрос, а также вводить независимые ограничения времени и количества таких соединений.
- Источник новости
- www.securitylab.ru
