Компания Google регистрира рекорден DDoS-атак на своята инфраструктура, с интензивност от 398 милиона заявки в секунда. Новата атака е с 7 пъти по-висока интензивност от предишната рекордна DDoS-атака, при която злоупотребителите успяха да генерират поток от 47 милиона заявки в секунда. За сравнение, целият трафик в интернет се оценява на ниво от 1-3 милиарда заявки в секунда. Освен Google, с атаката се сблъскаха също и компаниите Amazon и Cloudflare. Възможността за нова атака е свързана с откритие на уязвимост в протокола HTTP/2 (CVE-2023-44487), позволяваща при минимално натоварване на клиента да се насочва огромен поток от заявки към сървъра.
Новата тактика за атака получи името „Rapid Reset“ и се възползва от предлаганите в HTTP/2 средства за мултиплексиране на каналите, които позволяват да се генерира поток от заявки в рамките на вече установена връзка, без да се отварят нови мрежови връзки и без да се чака потвърждение за получаване на пакети. Уязвимостта се разглежда като следствие от недоработка на протокола HTTP/2, в спецификацията на който е посочено, че при опит да се отвори прекалено много потоци, трябва да се анулират само надвишаващите лимита потоци, а не да се затваря цялата мрежова връзка.
По аналогия с по-рано използваните методи за провеждане на атаки на HTTP/2, в новата атака също се създава голям брой потоци в рамките на една връзка. Ключовата разлика в новата атака е, че вместо да се чака отговор след всяка изпратена заявка, веднага след всяка изпратена заявка се изпраща кадър с флаг RST_STREAM, който веднага отменя заявката. Отменянето на заявката на ранен етап позволява да се избегне обратния трафик към клиента и да се заобиколят ограниченията, съществуващи на HTTP-сървърите за максималния брой потоци, едновременно отворени в рамките на една връзка по HTTP/2. Така обемът на заявките, отправяни към HTTP-сървера, престава да зависи от закъсненията между изпращането на заявката и получаването на отговор (RTT, round-trip time) и зависи само от пропускателната способност на комуникационния канал.
Тъй като за извършване на атака от страна на клиента е достатъчно просто да се изпращат заявки, без да се получават отговори, атаката може да бъде проведена с минимални разходи. Например, регистрираната от компанията Cloudflare атака с 201 милиона заявки в секунда е била извършена с Relatively малък ботнет от 20 хиляди компютъра. От страна на сървър разходите за обработка на входящите заявки са значително по-високи, въпреки тяхната отмяна, тъй като е необходимо да се извършват операции като разпределение на структурни данни за новите потоци, парсинг на заявката, разопаковане на заглавката и съпоставяне на URL с ресурса. При атака на обратни прокси, атаката може да се разпространи към бекендите, тъй като проксито може да успее да пренасочи заявката към бекенда преди обработката на фрейма RST_STREAM.
Атаката може да бъде извършена само срещу уязвими сървъри с поддръжка на HTTP/2 (скрипт за проверка на уязвимост на сървърите, инструменти за извършване на атака). В момента не са регистрирани атаки срещу HTTP/3 и възможността за тяхното извършване не е напълно анализирана, но представители на Google препоръчват на разработчиците сървъри да добавят в реализациите на HTTP/3 мерки за защита, подобни на приложените за блокиране на атаки срещу HTTP/2.
Подверженост на уязвимостта и наличието на корекции за HTTP-сървъри и проксита:
- nginx (анонс, пояснение, че уязвимостта не се проявява напълно в nginx с настройка по подразбиране, тъй като атаката ще се сблъска с лимит на броя на заявките на връзка (т.е. след всяка 1000 заявки, връзката ще бъде нулирана). В корекцията е добавена допълнителна защита за ограничаване на интензитета на заявките чрез директивата „limit_req“).
- В HAProxy ефективна защита срещу превишаване на лимита на потоците HTTP/2 е добавена още през 2018 г. и действа от версия 1.9-dev.
- Apache httpd (създава се определено натоварване на httpd, но то не се разпространява към бекендите и е ограничено до действащите от 2016 г. лимити за клиентски връзки).
- mod_h2 за Apache httpd.
- caddy
- envoy
- golang (проблемът е решен в версиите Go 1.21.3 и 1.20.10).
- h2o (патч).
- grpc-go
- hyper (уязвимостта не се проявява).
- jetty (коригирано в 12.0.2, 11.0.17, 10.0.17 и 9.4.53.v20231009).
- netty
- nghttp2 (коригирано в версия 1.57.0).
- Facebook proxygen
- .NET и ASP.NET Core (уязвим е http-сървърът ASP.NET Core Kestrel).
- Node.js
- proxygen
- swift-nio-http2 (коригирано в версия 1.28.0).
- Apache Tomcat (коригирано в версиите 11.0.0-M12, 10.1.14, 9.0.81, 8.5.94).
- Apache Traffic Server (коригирано в клон 9.2.x).
Източник: opennet.ru
