Дослідники з кібербезпеки з компанії Calif.io оприлюднили відомості про критичну вразливість у проксі-сервері Squid, яка отримала назву Squidbleed. Ця проблема безпеки унікальна, оскільки вона залишалася непоміченою в кодовій базі проєкту протягом 29 років — з 1997 року, коли розробники змінили логіку парсингу відповідей FTP. Протягом усього цього часу Squid, який використовується мільйонами організацій для кешування та фільтрації вебтрафіку, містив уразливість класу heap over-read (читання за межами виділеного буфера в купі пам'яті).

Суть проблеми полягає в тому, що Squidbleed дозволяє зловмиснику з базовим доступом до проксі-сервера викрадати конфіденційні дані інших користувачів, які проходять через цей самий проксі. Оскільки Squid обробляє HTTP-запити від багатьох клієнтів одночасно, у його оперативній пам'яті постійно містяться незашифровані дані сесій: HTTP-заголовки, cookie-файли, JWT-токени, облікові дані Basic Auth та тіла запитів. Експлуатуючи помилку в коді парсингу FTP, атакуючий може змусити Squid прочитати сусідні блоки пам'яті та повернути їх у складі своєї відповіді.

З технічної точки зору, уразливість виникає під час взаємодії Squid з FTP-серверами. Коли користувач надсилає запит на отримання файлу або перегляд каталогу через FTP, використовуючи Squid як шлюз, проксі-сервер повинен розпарсити відповіді від FTP-сервера. Процедура парсингу, написана мовами C/C++, містить помилку обчислення довжини буфера. При отриманні спеціально сформованої відповіді від FTP-сервера, код Squid некоректно визначає межі пам'яті. Замість того, щоб зупинитися на кінці FTP-повідомлення, функція копіює дані з купи пам'яті далі. У результаті зловмисник отримує відповідь, яка містить «сміття» з оперативної пам'яті сервера, де зберігаються чужі незашифровані HTTP-запити.

Для успішної атаки зловмиснику не потрібні права адміністратора чи високі привілеї. Достатньо мати легітимне право надсилати трафік через проксі-сервер. Це робить Squidbleed надзвичайно небезпечною загрозою для корпоративних мереж, де Squid часто є проміжним шлюзом для виходу в інтернет для тисяч співробітників. Внутрішній порушник — наприклад, компрометований робочий комп'ютер або шкідливе ПЗ, що закріпилося в мережі — може безперервно експлуатувати цю вразливість, збираючи авторизаційні токени колег та адміністраторів мережі. Це відкриває простий шлях до швидкого горизонтального переміщення (lateral movement) та захоплення контролю над інфраструктурою компанії.

Історія цієї вразливості яскраво ілюструє проблему накопичення технічного боргу. Протокол FTP вважається застарілим і в сучасних реаліях використовується вкрай рідко, поступившись місцем безпечнішим SFTP та HTTPS. Проте великі legacy-проєкти, такі як Squid, змушені підтримувати його для зворотної сумісності. Код, написаний у 1990-х роках, вкрай рідко проходить сучасні процедури аудиту чи автоматизованого фаззінг-тестування, оскільки фокус розробників зазвичай зміщується на нові функції та сучасні протоколи. В результаті критичні помилки безпеки в управнінні пам'яттю десятиліттями залишаються непоміченими, чекаючи на свого дослідника.

Ситуація ускладнюється тим, що Squid є де-факто стандартом для багатьох дистрибутивів Linux та інтегрованих рішень безпеки (наприклад, UTM-шлюзів). Багато компаній навіть не здогадуються про те, що в їхній мережі функціонує Squid, оскільки він може бути вбудований у комерційні продукти сторонніх вендорів. Тому виправлення цієї проблеми вимагатиме не лише оновлення окремих автономних серверів Squid, а й випуску патчів від численних виробників мережевого обладнання та програмного забезпечення для безпеки.

Що це означає на практиці

  • Негайне оновлення та перевірка версій: Проведіть аудит усіх серверів та мережевих шлюзів у вашій інфраструктурі на наявність встановленого Squid. Оновіть проксі-сервер до останньої стабільної версії, у якій усунено вразливість Squidbleed. Якщо Squid інтегровано у сторонні рішення (наприклад, pfSense, OPNsense або комерційні UTM), перевірте наявність безпекових оновлень від відповідних вендорів та встановіть їх.
  • Тимчасове вимкнення FTP: Якщо швидке оновлення неможливе з технічних причин, повністю вимкніть підтримку протоколу FTP у конфігураційному файлі squid.conf. Оскільки уразливість криється саме в коді парсингу FTP, вимкнення цього функціоналу усуває вектор атаки. Заблокуйте порти FTP або забороніть використання методів FTP у політиках доступу (ACL).
  • Обмеження доступу та сегментація: Перегляньте правила доступу до вашого проксі-сервера. Переконайтеся, що доступ до Squid мають лише суворо визначені та довірені підмережі. Повністю забороніть неавторизований доступ із гостьових бездротових мереж чи VPN для підрядників, щоб мінімізувати ризик внутрішньої експлуатації.
  • Аудит конфігурацій SSL-Decrypt: Якщо у вашій компанії налаштовано дешифрування SSL-трафіку на проксі-сервері (SSL-intercept/SSL-bump) для аналізу вмісту, Squid отримує доступ до повних HTTP-запитів користувачів у відкритому вигляді. У такому сценарії ризик витоку конфіденційних даних через Squidbleed є надзвичайно високим, тому встановлення патчів має отримати найвищий пріоритет.
  • Моніторинг логів на предмет аномалій: Налаштуйте збір та аналіз журналів Squid у вашій SIEM-системі. Звертайте увагу на нетипові запити до FTP-ресурсів або різке збільшення кількості помилок з'єднання з FTP-серверами від окремих хостів у внутрішній мережі. Це може свідчити про спроби проведення фаззингу або активну експлуатацію вразливості.