В августе и сентябре злоумышленники развернули крупнейшие распределённые DDoS-атаки в истории интернета, эксплуатирующие известную уязвимость в ключевом техническом протоколе. В отличие от других серьёзных атак нулевого дня последних лет – например, Heartbleed или log4j – которые вызвали хаос повсеместным наплывом эксплойтов, более недавняя их форма, получившая название HTTP/2 Rapid Reset, привлекла пристальное внимание лишь нескольких инженеров.
HTTP2/Rapid Reset – это новейшая техника развёртывания DDoS-атак в беспрецедентном масштабе, которая была раскрыта лишь в свете использования для реализации рекордных по своему охвату нападений. Одна из атак на клиента, использующего сеть доставки содержимого Cloudflare, достигла пика в 201 миллион запросов в секунду, почти втрое превзойдя предыдущий рекорд в 71 миллион. При этом атака на сайт, использующий облачную инфраструктуру Google, достигла 398 миллионов запросов/сек, более чем в 7,5 раз, превзойдя предыдущий рекорд, составлявший 46 миллионов.
▍ Достижение большего — меньшими средствами
DDoS-атаки на Cloudflare были реализованы сетью из примерно 20,000 компьютеров, то есть относительно небольшим числом в сравнении со множеством так называемых ботнетов. Дополнительно эта атака выделилась тем, что в отличие от многих других, направленных на клиентов Cloudflare, она приводила к выдаче чередующихся ошибок 4хх и 5хх при попытке легитимных пользователей подключиться к некоторым сайтам.
«Cloudflare регулярно обнаруживает ботнеты, которые на порядки превосходят этот – включая в себя сотни тысяч и даже миллионы машин. Возможность относительно небольшой ботнет выдать столь огромный объём запросов, способный вывести из строя практически любой сервер или приложение с поддержкой HTTP/2, подчёркивает высокую степень её угрозы для незащищённых сетей». – писал начальник службы безопасности Грант Боурзикас.
Эксплуатируемая атакой HTTP/2 Rapid Reset уязвимость заключается в протоколе HTTP/2, который был введён в 2015 году и с тех пор претерпел ряд доработок. В сравнении со своими предшественниками, HTTP/1 и HTTP/1.1, этот протокол предоставил возможность одному HTTP-запросу переносить 100 и более «потоков», получаемых сервером одновременно. То есть пропускная способность каждого соединения увеличилась практически в 100 раз в сравнении с прежними протоколами HTTP.
Но столь возросшая эффективность оказалась полезна не только для распространения видео, аудио и прочих видов безобидного контента. Злоумышленники начали задействовать HTTP/2 для реализации атак, в разы превосходящих предыдущие по своим масштабам. Этот протокол обладает двумя свойствами, позволяющими выполнять новые эффективные DDoS-атаки. Прежде чем их рассмотреть, будет нелишним узнать, как вообще работают подобные атаки, и вспомнить принцип действия протоколов, предшествовавших HTTP/2.
Существует несколько видов DDoS-атак. Самые известные – это волюметрические атаки и атаки сетевых протоколов. При волюметрических входящие подключения целевого сайта заполняются количеством битов, превосходящим их пропускную способность. Это можно сравнить с ситуацией, когда по трассе за единицу времени пытается проехать больше автомобилей, чем позволяет её ширина. В конечном счёте движение останавливается в пробке. За последний год рекордная волюметрическая атака заключалась в передаче 3,47 терабит/сек.
DDoS-атаки сетевых протоколов нацелены на перегрузку маршрутизаторов и прочих устройств, расположенных на 3 и 4 уровнях сетевого стека. Поскольку реализуются они именно на этих сетевых уровнях, то их сила измеряется в количестве пакетов, переданных в секунду. Одна из крупнейших атак протокола, на пике которой передавалось 500 миллионов пакетов/сек, была пресечена компанией по кибербезопасности Imperva.
Атака HTTP/2 Rapid Reset попадает в третью категорию DDoS, известную как атаки прикладного уровня. Вместо того чтобы пытаться перегрузить входящее подключение (как волюметрические атаки) или сетевую инфраструктуру (атаки на сетевой протокол), DDoS-атаки прикладного уровня нацелены на исчерпание вычислительных ресурсов, доступных на 7 уровне атакуемой инфраструктуры. К наиболее распространённым средствам достижения этого относится перегрузка запросами серверных приложений для HTTP, HTTPs и голосовых служб SIP.
В августе 2022 года в Google заявили, что заблокировали подобную атаку, достигшую 46 миллионов запросов/сек. В феврале Cloudflare также заблокировали DDoS-атаку прикладного уровня, пик которой составил 71 миллион запросов/сек.
Столь высокая мощь атаки HTTP/2 Rapid Reset определяется двумя аспектами. Первый – это её возможность задействовать повышенную пропускную способность входящего канала и передавать до 100 запросов за один круговой путь (round trip). Как объяснили в Google на этой неделе:
Одно из основных ограничений при реализации DDoS-атаки на 7 уровень заключается в количестве параллельных транспортных соединений. Каждое соединение имеет свою стоимость, включая оперативную память для записей сокетов и буферов, а также процессорное время, затрачиваемое на TLS-рукопожатие. Кроме того, каждому соединению требуется уникальный IP-адрес, состоящий из четырёх кортежей, и пара портов для каждой стороны подключения, что ограничивает число параллельных подключений между двумя IP-адресами.
В HTTP/1.1 каждый запрос обрабатывается последовательно. Сервер его считывает, обрабатывает, пишет ответ и только затем считывает и обрабатывает следующий запрос. На практике это означает, что скорость запросов, которые могут быть переданы по одному соединению, составляет один на круговой путь, который включает сетевую задержку, время обработки прокси-сервером и бэкендом. И хотя на некоторых клиентах и серверах при использовании HTTP/1.1 доступна конвейеризация, повышающая пропускную способность подключения, среди легитимных клиентов она используется редко.
В случае же HTTP/2 клиент может открывать на одном TCP-подключении множество параллельных потоков, каждый из которых будет соответствовать одному HTTP-запросу. Максимальное число параллельных потоков в теории управляется сервером, но на практике клиенты могут открывать по 100 потоков на запрос, которые сервер будет обрабатывать параллельно. Важно понимать, что ограничения сервера нельзя устанавливать в одностороннем порядке.
Например, клиент может открыть 100 потоков и отправить запрос по каждому из них в одном круговом пути. Прокси-сервер будет прочитывать и обрабатывать каждый поток последовательно, но запросы к серверам бэкенда, опять же, могут отправляться параллельно. Клиент может открывать новые потоки по мере получения ответов на предыдущие. Это, по сути, формирует для одного подключения пропускную способность в 100 запросов/круговой путь при константах тайминга, аналогичных запросам, передаваемым по HTTP/1.1. Это обычно ведёт к почти 100-кратному задействованию возможностей каждого соединения.
В своём письме от 12 октября исследователь в сфере кибербезопасности Паскаль Гиненс из компании Radware сказал, что Rapid Reset отличается от других видов атак своей способностью повторно использовать сеанс TCP/TLS для отправки практически бесконечного числа запросов.
«Мультиплексирование HTTP/2 задействует для запросов/ответов потоки между клиентом и сервером, а эти потоки реализуются на седьмом уровне поверх сеансов TCP и TLS. Клиент и сервер теоретически могут выполнять бесконечное число транзакций запросов/ответов без необходимости повторно устанавливать TCP-соединение или выполнять TLS-рукопожатие».
В своей статье Гиненс объяснил это следующим образом, попутно предоставив наглядный график для визуализации работы HTTP/2.0:
В HTTP/1.0 каждое TCP-соединение обрабатывает по одному запросу и ответу. В HTTP/1.1, описанном в RFC2616, появилась конвейеризация. И хотя нечасто, но злоумышленники задействовали эту возможность для повышения скорости отправки запросов в одном сеансе TLS с целью перегрузить веб-сервер или инфраструктуру его бэкенда.
Несмотря на то что доступная в HTTP/1.1 конвейеризация позволяет инициировать новый запрос ещё до получения ответа на предыдущий, эти ответы всегда доставляются по порядку. Это означает, что один большой запрос, например, на скачивание, может задерживать небольшие ответы на запросы, совершённые после него. Это явление обычно называют блокировкой очереди.
В HTTP/2, согласно RFC7540, появилось решение этой проблемы за счёт реализации нового двоичного слоя фрейминга, который инкапсулирует и передаёт HTTP-сообщения между клиентом и сервером.
Рис. 1: Двоичный слой фрейминга HTTP/2 (изображение: Ilya Grigorik)
Сеанс TLS между клиентом и серверами, по сути, служит в качестве туннеля, позволяющего передавать множество параллельных независимых потоков. Теперь уже ответы не обязательно будут поступать по порядку, и запросы не будут блокировать передачу более мелких из них.
Блокировка очереди перестала быть проблемой для атакующих. Их цель – переполнить сервер как можно большим числом запросов за кратчайший период времени, сохраняя максимально эффективную скорость их генерации, желательно без необходимости получать и обрабатывать большое число ответов от сервера.
▍ Сброс потоков
Стократное увеличение количества запросов – это лишь первый из двух аспектов, которые делают протокол HTTP/2 столь эффективным средством для DDoS-атак. Второй аспект заключается в том, что этот протокол позволяет клиентам и серверам завершать конкретный поток в одностороннем порядке. Технически известная как RST_STREAM, эта функциональность действует незамедлительно, позволяя атакующему отправлять новый поток вредоносных запросов. Получается, что хакер может совершать такие повторы и почти мгновенно раз за разом сбрасывать потоки. Отсюда и возникло название атаки Rapid Reset, то есть быстрый сброс.
В Google по этому поводу пишут так:
Возможность быстрого сброса потоков позволяет каждому соединению включать неограниченное число обрабатываемых запросов. Явно отменяя эти запросы, атакующий никогда не пересекает лимит на число одновременно открытых потоков. Количество обрабатываемых запросов больше не зависит от времени приёма-передачи (Round-Trip Time, RTT) и определяется только доступной пропускной способностью сети.
В типичной реализации сервера на протоколе HTTP/2 серверу по-прежнему придётся совершать значительный объём работы для отменённых запросов, например, выделять новые потоковые структуры данных, парсить запрос, распаковывать заголовок, а также сопоставлять URL с ресурсом. В реализациях обратных прокси-серверов запрос может передаваться бэкенд-серверу до обработки фрейма
RST_STREAM. С другой стороны, для клиента отправка запросов практически ничего не стоит. Это создаёт между сервером и клиентом асимметрию затрат, которую можно эксплуатировать.Ещё одно преимущество атакующего заключается в том, что явный сброс запросов сразу после их создания исключает ответ на них со стороны обратного прокси-сервера. В итоге такая отмена запросов до создания ответов разгружает нисходящий канал (от сервера/прокси к атакующему).
Атаки HTTP/2 Rapid Reset в основном влияют на крупных провайдеров инфраструктуры. Программное обеспечение, используемое более мелкими провайдерами, такое как NGINX, Apache Server и HAProxy, в основном уже имело определённые защиты, хотя многие компании для большей эффективности дополнительно пропатчили свои системы.
«Google и Cloudflare должны были написать: ‘угрозе не подвержены типичные веб-сервера, только стандартная облачная реализация Cloud’. Наивно обвинять в появившемся эксплойте стандарт протокола. Ваша работа не заканчивается 100% реализацией RFC». – написал на Mastodon Стивен Ейсинг, инженер из команды Apache, также работающий над HTTP/2 и HTTP/3.
Алекс Форстер, старший инженер Cloudflare в команде по противодействию DDoS, опроверг идею о том, что атака Rapid Reset оказалась неэффективной в отношении ряда других серверных приложений, использующих HTTP/2.
«По примерным оценкам не менее 60% публичных сайтов и API используют HTTP/2, то есть эта угроза была и остаётся опасной для всех. Это подчёркивает, что она не преувеличена и представляет реальную экзистенциальную угрозу для интернета. И хотя в результате применения патчей наиболее крупными игроками самые худшие сценарии были устранены, остаётся длинный хвост вендоров, которые не реализуют патчи, и ещё более длинный хвост организаций, которые эти патчи не применяют».
Гиненс из Radware дополнительно заметил, что новая атака, сохрани она столь же высокую эффективность, могла бы довести масштабы DDoS до беспрецедентного уровня. Он объяснил:
Значимость Rapid Reset заключается в эффективности, с которой атакующие могут генерировать запросы. Обладая теми же ресурсами, они могут значительно повышать скорость атаки, устраняя издержки, относящиеся к TCP-соединению и TLS-рукопожатиям. Эволюция технологий всегда расширяла наши возможности. В следствие этого витка развития возможности атакующих действительно расширились, но то же касается и бизнеса. С течением времени злоумышленники начинают использовать всё более изощрённые техники, и бизнес в той же степени обретает новые ресурсы для противодействия столь скоростным атакам. Затраты и ресурсы атакующих напрямую коррелируют с затратами и ресурсами, доступными для эффективного противодействия их атакам. Описанная уязвимость в HTTP/2, которую успели задействовать злоумышленники, прежде чем её обнаружили в Google, могла нарушить этот баланс, позволив хакерам получить фору перед их жертвами.
И хотя масштаб угрозы со стороны HTTP/2 Rapid Reset для небольших серверных приложений не столь велик, любой администратор такого приложения должен связаться с его разработчиками для получения рекомендаций по противодействию этой атаке. Многие создатели небольших, перечисленных здесь, приложений, предоставляют патчи против этой уязвимости, которая была зарегистрирована под кодом CVE-2023-44487. Все крупные облачные провайдеры уже патчи применили.
Автор: Дмитрий Брайт
