![](https://habrastorage.org/files/efc/a4e/9c2/efca4e9c217549c4b624384842c17443.png)
Цзянь-Цзюнь Чэнь (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
— Attack Detection (@AttackDetection) 5 мая 2016 г.
Affected: <3.5.18 <4.0.10https://t.co/D3hSUmaqnv
CVE:none
CWE-345
CAPEC-141#squoison
Комментарии (5)
imbasoft
06.05.2016 10:51+4Всем ждать «море радости» со squid во встраиваемых системах: openwrt, routeros и т.д.
xsash
06.05.2016 23:05При использовании прозрачного проксирования есть вероятность столкнуться с такой штукой
https://habrahabr.ru/sandbox/99037/
В squid-3.2.11 появилась внутренняя функция hostHeaderIpVerify, которая проверяла — действительно ли http.host может быть доступен по указанному ip адресу. Прогресс, тем временем, не стоял на месте и количество ip для домена росло, набрал популярность Round-robin DNS. В таких условиях совсем не удивительно, что на одном хосте что-то резолвится в один IP, на соседнем (с таким же подключением) — иногда в другой, т.к. существует кеш DNS и обновляется он не синхронно. В момент таких «рассинхронизаций» squid не находит соответствия ip-домен в своём кеше (потому что обновил свой кеш немного раньше или позже) и squid прерывает соединение.
ajaxtpm
Squidlock!
Pinkbyte
Так скоро все «что-то-том»lock закончатся, если каждой уязвимости присваивать такое имя :-)
ajaxtpm
В таком случае можно будет писать Badsquid! :)