Эксперты показали, как выявить фишинговый MitM-сайт по сетевому отпечатку

Эксперты показали, как выявить фишинговый MitM-сайт по сетевому отпечатку

Эксперты показали, как выявить фишинговый MitM-сайт по сетевому отпечатку

Разработанная исследователями методика, полагающаяся на ИИ, позволяет с высокой точностью установить наличие фишингового сайта между сервисом-мишенью и его пользователями. Такие угрозы обычно плохо детектятся и редко попадают в блоклисты.

Для начала сборная команда из Университета штата Нью-Йорк в Стоуни-Брук и Palo Alto Networks изучила (PDF) 13 ходовых фишинг-паков MitM. Спрос на такой продвинутый инструментарий, упакованный в ZIP-файл, последнее время растет: в отличие от обычных тулкитов для фишинга он позволяет воровать учетные данные на лету, из запросов пользователя к целевому сервису.

При MitM-сценарии атаки поддельный сайт-зеркало размещается между точками обмена и ведет перехват трафика, извлекая нужную информацию из сетевых пакетов. В итоге злоумышленник сможет получить не только логины-пароли, но и куки сессий, а также обойти двухфакторную аутентификацию (2FA).

 

Достоверность фишинговых страниц при использовании такого прокси не столь уж важна: иллюзию для жертвы поддерживает возможность просмотра других страниц сайта-ловушки после аутентификации. Сервис-оригинал при этом тоже вряд ли заметит подмену.

Как оказалось, подобные фейки живут дольше: исследование показало, что в блоклисты попадает лишь 43,7% доменов и 18,9% IP-адресов, ассоциированных с MitM-фишингом. Предложенный метод, по словам авторов, позволяет избавиться от слепой зоны и повысить точность детектирования до 99,9%.

Для выявления умело спрятанных фальшивок исследователи создали самообучаемый классификатор, работающий с сетевыми данными — TLS-отпечатками, временем передачи и приема запросов. Сбор образцов для анализа проводился автоматизированными средствами — с помощью инструмента PHOCA собственной разработки, который выискивал нужную информацию в доступных базах по фишингу, таких как OpenPhish и PhishTank.

 

В качестве основного критерия были выбраны задержки: использование прокси-сервера (в данном случае с фиш-паком MitM) замедляет процедуру передачи и подтверждения запросов. При перехвате TLS-запросов отклонение от нормы становится еще более заметным.

За год экспериментаторам удалось выявить 1220 сайтов, созданных для MitM-фишинга, — в основном в США и Европе, с хостингом у Amazon, DigitalOcean, Microsoft либо Google. Фальшивки чаще всего имитировали Instagram, Google, Facebook, Microsoft Outlook, PayPal, Apple, Twitter, Coinbase, Yahoo и LinkedIn. Изучение 260 таких ловушек показало, что за полгода они получили 6403 запроса от пользователей.

 

Фреймворк PHOCA, по словам исследователей, легко встраивается в существующую инфраструктуру. Он может, к примеру, расширить возможности веб-сервиса блоклистов или оградить популярный сайт от вредоносных запросов, генерируемых с помощью фишингового MitM-пака. Тестирование показало, что пробная методика позволяет обойти средства маскировки из арсенала таких тулкитов и эффективно выявить прежде скрытый фишинговый контент.

Критическая уязвимость в TLP позволяет обойти защиту Linux

В популярной утилите TLP, которую многие владельцы ноутбуков на Linux используют для управления энергопотреблением, обнаружили критическую уязвимость. Причём проблема нашлась во время обычной проверки пакета командой SUSE Security Team и располагается во вполне штатном коде.

Брешь получила идентификатор CVE-2025-67859 и затрагивает версию TLP 1.9.0, где появился новый profiles daemon.

Этот демон работает с root-правами и управляет профилями питания через D-Bus. Задумка хорошая, но реализация подвела: в механизме аутентификации Polkit нашлась логическая ошибка, которая фактически позволяет обойти проверку прав.

Как объясняют исследователи, демон должен был строго проверять, кто именно отправляет команды. Но из-за ошибки любой локальный пользователь мог взаимодействовать с ним без должной аутентификации — а значит, менять системные настройки питания от имени root.

На этом сюрпризы не закончились. В ходе анализа специалисты SUSE нашли ещё несколько проблем, уже связанных с исчерпанием ресурсов. В частности, механизм profile hold, который позволяет временно «зафиксировать» профиль питания, оказался совершенно без валидации. Локальный пользователь мог создавать неограниченное количество таких блокировок, причём без прав администратора.

В итоге это открывает прямую дорогу к DoS-атаке: демон начинает захлёбываться от бесконечных записей в структуре данных, куда попадают числа, строки с причиной и идентификаторы приложений — всё это полностью контролируется клиентом.

Любопытно, что SUSE вспомнила похожую историю с демоном управления питанием в GNOME: аналогичную проблему находили ещё несколько лет назад. Отдельно исследователи отметили вопросы к механизму «куки», которыми отслеживаются profile hold. Формально речь шла о предсказуемости значений, но в сочетании с отсутствием лимитов это лишь расширяло поверхность атаки.

К счастью, реакция была быстрой. SUSE сообщила об уязвимостях разработчикам ещё в декабре, и в версии TLP 1.9.1 проблема уже закрыта. В частности, число одновременных profile hold теперь жёстко ограничено числом 16, что убирает риск истощения ресурсов.

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