Цзянь-Цзюнь Чэнь (Jianjun Chen) — аспирант китайского Университета Цинхуа — обнаружил опасную уязвимость в популярном прокси-сервере Squid. Как ему удалось выяснить, система не соответствует стандарту RFC 7230, а также некорректно работает при парсинге и обработке заголовка Host в HTTP-запросах. В результате злоумышленник может сформировать зловредный пакет и с помощью него осуществить атаку cache poisoning.

В чем проблема

Исследователю удалось осуществить атаку «отравления кэша» Squid-3.5.12 для любых незашифрованных HTTP-запросов. Чтобы провести такую атаку, злоумышленник должен иметь возможность посылать запросы через прокси-сервер к своему сайту (скажем, attack.com). При таком сценарии сначала устанавливается TCP-соединение с веб-сервером сайта attack.com — поскольку Squid работает в режиме прозрачного прокси, он перехватывает и передает эти запросы дальше. На следующем шаге атакующий инициирует HTTP-запрос:

GET http://victim.com/ HTTP/1.1
Host: attack.com 

Кэширующий модуль использует для ключа адрес узла из строки запроса (victim.com), однако модуль верификации использует для проверки связи между узлом и IP-адресом заголовок Host (attack.com). Это и делает атаку возможной.

Исследователь также опубликовал демонстрационное видео.

Подобную атаку можно провести удаленно, например с помощью Flash-рекламы. Поскольку Squid используют в качестве прозрачного прокси многие интернет-провайдеры, эксплуатация обнаруженной уязвимости может привести к серьезным последствиям.

Изначально разработчики Squid посчитали, что обнаруженная уязвимость повторяет ошибку, описанную в CVE-2009-0801. Однако китайский исследователь доказал, что новая атака не связана со старой уязвимостью. В случае CVE-2009-0801 злоумышленник мог осуществить атаку SOP bypass: эта ошибка была связана с некорректной обработкой IP-адреса узла назначения. Проблема была исправлена начиная с версии Squid 3.3. Новая же уязвимость заключается в несогласованной работе модуля проверки маршрутов и модуля кэширования Squid 3.5.

Как защититься

В настоящий момент уязвимость устранена, однако CVE до сих пор нет, как и официального патча в виде отдельной версии Squid. Исправление включено пока только в daily-сборки для версий 4 и 3.5.

Эксперты Positive Technologies рекомендуют включить опцию host_verify_strict, по умолчанию выключенную, а также использовать правило Suricata IDS для обнаружения попыток эксплуатации:

New #Squid HTTP Cache Poisoning Attack detection rule
Affected: <3.5.18 <4.0.10https://t.co/D3hSUmaqnv
CVE:none
CWE-345
CAPEC-141#squoison

— Attack Detection (@AttackDetection) 5 мая 2016 г.