RangeAmp — новая уязвимость позволяет проводить DDoS-атаки с коэффициентом амплификации в десятки тысяч

Буквально на днях группой китайских ученых была открыта уязвимость, позволяющая проводить DDoS-атаки с амплификацией. Авторам удалось провести атаку с коэффициентом 43000! Новая атака может не только истощать ресурсы иcходящего канала целевого веб-сервера, но и каналы CDN нод. Уязвимыми оказались все 13 из 13 проверенных крупнейших CDN провайдеров, включая Akamai, Fastly и Cloudflare. Под катом рассмотрим механизм атаки и предложенные авторами меры.

Эту атаку, а вернее класс атак, назвали Range-based Amplification Аttack или сокращенно RangeAmp. Для проведения атак используется CDN и уязвимость механизма range request протокола HTTP, позволяющего клиентам скачивать файлы с веб-сервера частями. Обе технологии — неотъемлемая часть современного Интернета. Так, например, сеть Akamai обслуживает ~15-30% всего веб-трафика в сети Интернет. Стандарты RFC рекомендуют поддержку технологии range request на всех веб и кэширующих серверах, и CDN вендоры этой рекомендации придерживаются. Все это делает проблему особенно актуальной.

Как проводилось исследование

Авторы протестировали 13 популярных CDN сервисов: Akamai, Alibaba Cloud, Azure, CDN77, CDNsun, Cloudflare, CloudFront, Fastly, G-Core Labs, Huawei Cloud, KeyCDN, StackPath и Tencent Cloud.

В качестве целевого веб-сервера они использовали Linux сервер c 2.4GHz CPU, 16G DDR и 1000 Mbps каналом.

Целевой веб-сайт работал на Apache/2.4.18 с дефолтными настройками. Облачный CDN использовался с настройками по умолчанию.

Range request

Благодаря механизму range request клиент может запрашивать отдельные части веб-ресурса. Это позволяет осуществлять многопоточную загрузку и не начинать загрузку больших файлов заново в случае разрыва соединения. В результате скорость увеличивается, а объем загружаемых данных уменьшается за счет сокращения повторной отправки одних и тех же данных.

Чтобы запросить частичную загрузку ресурса, клиент добавляет в запрос заголовок Range. Соответствующее значение указывает, какие байты клиент хочет загрузить. Это может быть отдельный байт, диапазон из нескольких последовательных байт или несколько таких диапазонов. Если сервер поддерживает побайтовые запросы, он вставит в ответ заголовок Accept-Ranges со значением "bytes".

При пересылке валидных range запросов узлы разных CDN могут по-разному обрабатывать заголовок Range. Главным образом применяются три политики:

1. Laziness (лень) — переслать без изменений.
2. Deletion (удаление) — полностью удалить заголовок.
3. Expansion (расширение) — расширить указанный диапазон, согласно настройкам.

По умолчанию сервисы CDN используют политики 2 и 3. Скорее всего, предполагается, что если клиент обратился к части ресурса, то велика вероятность, что к другим частям ресурса тоже будут обращаться в дальнейшем.

Что делать, если байтовые диапазоны запрашиваемого файла пересекаются? RFC7233 советует игнорировать, объединять либо отклонять range запросы с более чем двумя пересекающимися диапазонами. Несмотря на это, 4 из 13 исследованных CDN этого не делают.

Собственно вы наверное уже догадались, предыдущие два абзаца — это две уязвимости для проведения атак. Т.е. атак даже не одна, а две! Давайте посмотрим на каждую подробнее.

Атака на канал целевого сервера

При Deletion и Expansion CDN запрашивает у целевого сервера гораздо больше данных, чем указано в исходном запросе, и чем CDN реально перешлет в ответ на запрос. Здесь и возникает амплификация. Атакующий может посылать запросы с маленькими диапазонами в заголовке Range, а CDN будет их автоматически увеличивать и запрашивать у целевого веб-сервера большее количество данных. Такую атаку назвали Small Byte Range Attack или SBR RangeAmp. В отличие от многих DDoS-атак, такая атака истощает ресурсы именно исходящего от сервера канала. Запрос, конечно, делается таким, чтобы "обойти" кэш CDN, т.е., чтобы CDN пришлось обращаться к целевому серверу.

Амплификация тем сильнее, чем больше размер запрашиваемого файла. Так для файла размером 25 MB амплификация у Akamai достигала 43000!

Все 13 протестированных CDN оказались уязвимыми к этой атаке: Akamai, Alibaba Cloud, Azure, CDN77, CDNsun, Cloudflare, CloudFront, Fastly, G-Core Labs, Huawei Cloud, KeyCDN, StackPath и Tencent Cloud.

Атака на каналы CDN

Эту атаку можно организовать, если использовать каскад из сетей доставки контента. CDN, принимающую запрос от атакующего и пересылающая его следующей CDN в каскаде, будем называть Frontend CDN или FCDN. CDN, запрашивающую ответ у целевого веб-сервера, будем называть Backend CDN (см. картинку ниже).

Атака возможна, когда выполняются два условия:

1. FCDN применяет Laziness политику и пересылает заголовок Range "как есть".
2. BCDN возвращает ответ, не проверяя пересекаются ли запрошенные в Range диапазоны.

Тогда, если атакующий отправит запрос с n пересекающимися диапазонами, то ответ от BCDN сервера может достигать n * (размер запрашиваемого ресурса). При этом не важно, как целевой сервер обрабатывает пересекающиеся запросы. На своей стороне атакующий может максимально уменьшить TCP Receive Window, чтобы получать как можно меньше данных в ответ на свои запросы.

Получается, чем больше в запросе пересекающихся диапазонов, тем выше коэффициент амплификации. Т.е. он зависит от максимальной длины заголовка Range.

Оказалось, не следуют RFC и не проверяют, пересекаются ли диапазоны запрашиваемых байт, 4 провайдера: CloudFlare, CDN77, CDNsun, StackPath. Вот какие коэффициенты удалось получит с их использованием для файла ресурса размером 1KB (напомню, n — число пересечений диапазонов в запросе):

Что в итоге?

А в итоге имеем две атаки на каналы с огромными коэффициентами амплификации, для выполнения которых достаточно ноутбука. Одна направлена на истощение исходящего от целевого сервера-жертвы канала (SBR RangeAmp), вторая — на переполнение каналов CDN провайдеров (OBR RangeAmp) Обе работают как для HTTP/1.1, так и HTTP/2.

Авторы уже направили результаты своих исследований и рекомендации CDN провайдерам и в редакцию RFC.

CDN вендорам в качестве первоочередных мер рекомендуется:

• Вспомнить, наконец, про RFC7233 и проверять запрашиваемые диапазоны на пересечение.
• При обработке запросов с заголовком Range применять политику Laziness и не трогать заголовок, либо применять Expansion, но сильно не увеличивать диапазоны.

Source:
CDN Backfired: Amplification Attacks Based on HTTP Range Requests, Weizhong Li, Kaiwen Shen, Run Guo, Baojun Liu, Jia Zhang, Haixin Duan, Shuang Hao, Xiarun Chen, Yao Wan.

Изображения были взяты из оригинала и переведены.

P.S.

По заявлению авторов исследования CloudFlare признали существование уязвимости, но отказались использовать предложенные методы для борьбы с ней, сославшись на то, что не хотят кешировать частичные ответы для определенных ресурсов.

"They thought that the SBR attack relies on constantly triggering a cache-miss and a customer can add a page rule to ignore query strings. But this does not solve the problem fundamentally. The malicious customers and some normal customers will not follow this suggestion. Unfortunately, they won’t implement our mitigation solutions because Cloudflare does not want to cache partial responses of certain resources."