Серьезная уязвимость прокси-сервера Squid позволяет «отравить кэш»



    Цзянь-Цзюнь Чэнь (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 для обнаружения попыток эксплуатации:

    • +13
    • 17.4k
    • 5
    Positive Technologies
    252.63
    Company
    Share post

    Comments 5

      +2
      Squidlock!
        0
        Так скоро все «что-то-том»lock закончатся, если каждой уязвимости присваивать такое имя :-)
          0
          В таком случае можно будет писать Badsquid! :)
        +4
        Всем ждать «море радости» со squid во встраиваемых системах: openwrt, routeros и т.д.
          0
          При использовании прозрачного проксирования есть вероятность столкнуться с такой штукой
          https://habrahabr.ru/sandbox/99037/

          В squid-3.2.11 появилась внутренняя функция hostHeaderIpVerify, которая проверяла — действительно ли http.host может быть доступен по указанному ip адресу. Прогресс, тем временем, не стоял на месте и количество ip для домена росло, набрал популярность Round-robin DNS. В таких условиях совсем не удивительно, что на одном хосте что-то резолвится в один IP, на соседнем (с таким же подключением) — иногда в другой, т.к. существует кеш DNS и обновляется он не синхронно. В момент таких «рассинхронизаций» squid не находит соответствия ip-домен в своём кеше (потому что обновил свой кеш немного раньше или позже) и squid прерывает соединение.

          Only users with full accounts can post comments. Log in, please.