Серйозна уразливість проксі-сервера 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 для виявлення спроб експлуатації:

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 р.


Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.