Производитель сетевого оборудования Ubiquiti не может исправить баг

Производитель сетевого оборудования Ubiquiti не может исправить баг

Производитель сетевого оборудования Ubiquiti не может исправить баг

Специалисты австрийской компании SEC Consult рассказали о странной истории, связанной с известным производителем Ubiquiti Networks, который разрабатывает различные аппаратные и софтверные решения для провайдеров и предприятий.

Еще в ноябре 2016 года исследователи обнаружили серьезную проблему в устройствах Ubiquiti, которая позволяет атакующему полностью перехватить контроль над девайсом. Специалисты сообщили об уязвимости производителю, воспользовавшись официальной bug bounty программой на HackerOne, но разработчики Ubiquiti повел себя весьма странно. Вначале представители компании заявили, что уже знают о баге и отказались принимать заявку исследователей. Затем заявка все же была принята, а проблема признана, но патча для уязвимости до сих пор нет, потому что связь с сотрудниками Ubiquiti оборвалась еще в январе 2017 года. В настоящий момент специалисты SEC Consult уже окончательно отчаялись вновь установить контакт с Ubiquiti и решили публично раскрыть информацию о проблеме, сообщает xakep.ru.

Исследователи пишут, что файл pingtest_action.cgi на ряде устройств Ubiquiti содержит уязвимость типа command injection. Баг возник в силу того, что разработчики использовали для создания встроенного сервера устройств невероятно старую версию PHP – это PHP 2.0.1, вышедшая в 1997 году, то есть двадцать лет назад! Но есть две новости: хорошая и плохая. Хорошая: к счастью, проблему command injection может эксплуатировать только авторизованный пользователь. Плохая: данная уязвимость не является единственной. Также прошивка устройств Ubiquiti уязвима перед CSRF-атаками, что позволяет фальсифицировать действия пользователя.

Устроить CSRF-атаку на уязвимое устройство совсем несложно. Исследователи пишут, атака может быть реализована посредством одного GET-запроса, и для этого достаточно заманить жертву на вредоносный сайт. Так как защиты от CSRF у девайсов Ubiquiti нет, злоумышленник сможет обратиться к админке устройства и выполнить произвольные действия, за спиной легитимного пользователя.

Демонстрацию атаки исследователи записали на видео, однако proof-of-concept эксплоит пока не был опубликован. Исследователи все-таки решили дождаться выхода патча, надеясь, что огласка привлечет внимание к проблеме.

Эксперты SEC Consult опробовали атаку против четырех девайсов Ubiquiti и пришли к выводу, что такая же проблема существует еще как минимум у 38 моделей устройств. Список можно увидеть ниже.

Протестированы:

  • TS-8-PRO, прошивка 3.3 (SW)
  • (Rocket) M5, прошивка v5.6.9/v6.0 (XM)
  • (PicoStationM2HP) PICOM2HP, прошивка 6.9/v6.0 (XM)
  • (NanoStationM5) NSM5, прошивка6.9/v6.0 (XM)

Могут быть уязвимы:

  • Ubiquiti Networks AF24 (Версия прошивки: AF24 v3.2)
  • Ubiquiti Networks AF24HD (Версия прошивки: AF24 v3.2)
  • Ubiquiti Networks AF-2X (Версия прошивки: AF2X v3.2 )
  • Ubiquiti Networks AF-3X (Версия прошивки: AF3X v3.2)
  • Ubiquiti Networks AF5 (Версия прошивки: AF5 v3.2)
  • Ubiquiti Networks AF5U (Версия прошивки: AF5 v3.2)
  • Ubiquiti Networks AF-5X (Версия прошивки: AF5X v3.2.1)
  • Ubiquiti Networks AG-PRO-INS (Версия прошивки: AirGWP v1.1.7)
  • Ubiquiti Networks airGateway (Версия прошивки: AirGW v1.1.7)
  • Ubiquiti Networks airGateway-LR (Версия прошивки: AirGW v1.1.7)
  • Ubiquiti Networks AMG-PRO (Версия прошивки: AirGWP v1.1.7)
  • Ubiquiti Networks LBE-5AC-16-120 (Версия прошивки: WA v7.2.4)
  • Ubiquiti Networks LBE-5AC-23 (Версия прошивки: WA v7.2.4)
  • Ubiquiti Networks LBE-M5-23 (Версия прошивки: XW v5.6.9/v6.0)
  • Ubiquiti Networks NBE-5AC-16 (Версия прошивки: WA v7.2.4)
  • Ubiquiti Networks NBE-5AC-19 (Версия прошивки: XC v7.2.4)
  • Ubiquiti Networks NBE-M2-13 (Версия прошивки: XW v5.6.9/v6.0)
  • Ubiquiti Networks NBE-M5-16 (Версия прошивки: XW v5.6.9/v6.0)
  • Ubiquiti Networks NBE-M5-19 (Версия прошивки: XW v5.6.9/v6.0)
  • Ubiquiti Networks PBE-5AC-300 (Версия прошивки: XC v7.2.4)
  • Ubiquiti Networks PBE-5AC-300-ISO (Версия прошивки: XC v7.2.4)
  • Ubiquiti Networks PBE-5AC-400 (Версия прошивки: XC v7.2.4)
  • Ubiquiti Networks PBE-5AC-400-ISO (Версия прошивки: XC v7.2.4)
  • Ubiquiti Networks PBE-5AC-500 (Версия прошивки: XC v7.2.4)
  • Ubiquiti Networks PBE-5AC-500-ISO (Версия прошивки: XC v7.2.4)
  • Ubiquiti Networks PBE-5AC-620 (Версия прошивки: XC v7.2.4)
  • Ubiquiti Networks PBE-M2-400 (Версия прошивки: XW v5.6.9/v6.0)
  • Ubiquiti Networks PBE-M5-300 (Версия прошивки: XW v5.6.9/v6.0)
  • Ubiquiti Networks PBE-M5-300-ISO (Версия прошивки: XW v5.6.9/v6.0)
  • Ubiquiti Networks PBE-M5-400 (Версия прошивки: XW v5.6.9/v6.0)
  • Ubiquiti Networks PBE-M5-400-ISO (Версия прошивки: XW v5.6.9/v6.0)
  • Ubiquiti Networks PBE-M5-620 (Версия прошивки: XW v5.6.9/v6.0)
  • Ubiquiti Networks R5AC-Lite (Версия прошивки: XC v7.2.4)
  • Ubiquiti Networks R5AC-PRISM (Версия прошивки: XC v7.2.4)
  • Ubiquiti Networks R5AC-PTMP (Версия прошивки: XC v7.2.4)
  • Ubiquiti Networks R5AC-PTP (Версия прошивки: XC v7.2.4)
  • Ubiquiti Networks RM2-Ti (Версия прошивки: XW v5.6.9/v6.0)
  • Ubiquiti Networks RM5-Ti (Версия прошивки: XW v5.6.9/v6.0)

Блокировка по фингерпринту: почему у россиян снова посыпались Xray, REALITY

В сообществе пользователей VPN вновь неспокойно. В начале июня многие россияне столкнулись с массовыми сбоями в работе популярных решений на базе Xray, VLESS и REALITY. Автор под ником hyperion_cs провёл на Хабре собственное исследование и заявил, что обнаружил новый алгоритм ограничений, который применяется как мобильными, так и домашними провайдерами.

По его версии, проблема связана не с блокировкой конкретных серверов или IP-адресов.

Гораздо интереснее другое: система анализирует параметры TLS-соединений, включая SNI, сетевую принадлежность сервера и так называемый фингерпринт клиента — набор признаков, по которым можно определить, под какой браузер маскируется соединение.

Как утверждает исследователь, под особое внимание попадают подключения к серверам в определённых подсетях и автономных системах. Причём речь идёт не только о зарубежных площадках, но и о крупных российских инфраструктурных провайдерах, включая Selectel, Яндекс Облако и Cloud.ru.

Согласно опубликованному анализу, если система фиксирует несколько параллельных TLS-подключений к одному ресурсу за короткий промежуток времени, соединения могут быть принудительно заморожены на две минуты. Если после этого клиент меняет свой сетевой отпечаток, срок ограничения якобы увеличивается уже до десяти минут.

Автор исследования отмечает, что такой подход напоминает известную среди специалистов сибирскую блокировку, но с более жёсткими параметрами и расширенным охватом.

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

Для проверки своей гипотезы автор использовал инструмент dpi-ch из проекта dpi-checkers. По его словам, результаты тестирования показывают, что ограничения затрагивают часть популярных российских инфраструктурных площадок, а для зарубежных операторов по-прежнему применяются дополнительные механизмы фильтрации трафика.

 

Следует отметить, что опубликованное исследование представляет собой независимый технический анализ. Официальных комментариев со стороны операторов связи или регулирующих органов по поводу описанного механизма на момент публикации не поступало.

RSS: Новости на портале Anti-Malware.ru