Недавно на конференции USENIX Security Symposium была опубликована статья под названием Weaponizing Middleboxes for TCP Reflected Amplification. До этого традиционно считалось, что атаки типа Reflected Amplification - побочный эффект использования протокола UDP. TCP казался абсолютно неуязвимым в связи с необходимостью верификации инициатора сессии методом "тройного рукопожатия". Оказалось, что Reflected Amplification с TCP не только возможен, но в некоторых случаях коэффициент усиления может быть практически бесконечным.
Конечно, вольное переложение статьи на русский было уже предпринято такими порталами, как Securitylab.ru и xakep.ru, но позволю себе не только покритиковать их, но и представить свой вариант изложения сути исследования по TCP amp DDoS на русском языке. Для иллюстрации буду использовать слайды оригинальной презентации - уж слишком они хороши, чтобы придумывать что-то свое.
Атака типа amplification с использованием протокола на базе UDP при условии подмены адреса жертвы выглядит так:
За счет чего TCP считался неуязвимым к атакам reflected amp, хорошо показано на рисунке:
То есть, сценарий отправки SYN/ACK жертве возможен, но по способностям заполнения канала малоэффективен. Исследование показало, что подобную защиту можно обойти. И это не уязвимость протокола TCP, а недостатки сетевой реализации внедрения определенного класса сетевых решений.
В своем исследовании авторы используют такой термин, как middlebox - устройство с возможностями фильтрации, интеллектуальной обработки и перенаправления трафика.
Middlebox'ами можно назвать:
- FW/NGFW
- IPS
- Proxy
- Reverse proxy
- WAF
- DPI
- Censor
Перечень не исчерпывающий.
Условия, которым должен соответствовать middlebox, чтобы его можно было использовать в атаке TCP Reflected Amplification:
- Имплементация с поддержкой асимметричной маршрутизации, подразумевающая обработку пакетов только в одном направлении.
- Сконфигурирована отправка/перенаправление на страницу при определенных условиях.
- Присутствует петля маршрутизации.
- Повторная отправка контента в случае получения RST-пакета в ответ на страницу блокировки.
То есть, архитектура, подразумевающая обработку TCP-сессий полностью на одном устройстве, либо с онлайн-обменом информацией о сессиях между участниками обработки трафика, не может быть использована в TCP amp-атаке.
В норме, middlebox с поддержкой асимметричной маршрутизации должен увидеть в одном направлении в рамках одной сессии SYN, ACK и дальнейшие PSH+ACK. Опытным путем ученые определили, что завершающий тройное рукопожатие ACK не отслеживается. Вероятно, с целью экономии ресурсов. Проверено 5 возможных комбинаций пакетов с целью вызвать атаку TCP reflected amp на 184 middlebox'ах.
Результаты описаны в таблице:
|
Флаги
пакетов
|
Успешно
|
% успешности
|
Коэффициент усиления
|
|
[SYN; PSH+ACK]
|
128
|
69,6
|
7455
|
|
[SYN; PSH]
|
121
|
65,7
|
24
|
|
[PSH]
|
82
|
44,6
|
14
|
|
[PSH; ACK]
|
61
|
33,2
|
21
|
|
[SYN+payload]
|
21
|
11,4
|
527
|
При этом, главным корнем зла, как и в атаках "усиления" с использованием UDP, является возможность подмены IP-адреса отправителя в пакете.
Бесконечное усиление может быть вызвано повторной отправкой middlebox'ом страницы с контентом на RST-пакет жертвы, отправляемый в ответ на нежданный пакет с данными вне существующей TCP-сессии.
Также, если при внедрении была допущена ошибка, приводящая к петле маршрутизации - сам факт закольцовывания без некорректной обработки RST-ответа жертвы будет вызывать умножение количества пакетов, пока не иссякнет TTL. Если же TTL в петле по какой-то причине регенерируется - коэффициент усиления может быть бесконечным.
Для того, чтобы минимизировать риск участия оборудования государственной цензуры в атаках TCP reflected amplification, стоит обратить внимание на такие меры:
- Архитектура, подразумевающая контроль трафика в обе стороны. Зачастую невозможно на больших транзитных сетях провайдеров.
- Уменьшение размера ответа. Например, вместо выдачи всей страницы, отправлять только redirect с адресом страницы блокировки.
- ACL. Обрабатывать запросы, приходящие только из сетей своих клиентов на соответствующий интерфейс. Инициировать атаку можно будет только из сети клиента на адреса других клиентов, что минимизирует вероятность атаки и упростит поиск злоумышленника своей юрисдикцией.
- Удостовериться в отсутствии петель маршрутизации.
- Настроить middlebox на отсутствие отправки страницы блокировки в ответ на каждый RST-пакет от жертвы, либо устранить дефект ПО.
- Настроить конечные устройства не отправлять RST в ответ на непонятные пакеты, во избежание штормовой реакции middlebox'а на RST от жертвы.
