Ряд браузеров не блокирует загрузку вредоносов методом drive-by-download

Ряд браузеров не блокирует загрузку вредоносов методом drive-by-download

Ряд браузеров не блокирует загрузку вредоносов методом drive-by-download

Некоторые браузеры до сих пор допускают атаки вида «drive-by-download» даже из, казалось бы, защищённых мест вроде ифреймов (iframes), изолированных в песочнице. Напомним, что при drive-by-download загрузка вредоносного файла происходит автоматически при посещении сайта (без всякого взаимодействия с жертвой).

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

Новый отчёт исследователей из компании Confiant показывает, что даже защищённая среда вроде изолированных ифреймов не защитит пользователя от drive-by-download при веб-сёрфинге.

Именно с этим столкнулись посетители сайта Boing Boing в январе. За drive-by-download отвечал вредоносный JavaScript-код, внедрённый в страницу взломанного ресурса. В результате этот код размещал на сайте ссылку, которая инициировала загрузку злонамеренного содержимого безо всякого участия пользователя.

После этого исследователи заинтересовались реализацией этого метода в случае с изолированными ифреймами. К счастью, как выяснили специалисты, тот же Chrome 83 блокировал подобные загрузки.

Microsoft Edge, который в качестве базы отныне использует Chromium, тоже показал себя неплохо. У Mozilla Firefox дела идут чуть хуже — браузер не блокирует кросс-сайтовые ифреймы и выдает диалоговое окно для загрузки файла.

Brave тоже не смог заблокировать загрузку потенциально вредоносного содержимого. Safari также пытается загрузить предложенный файл, однако в ходе тестирования браузер от Apple так и не смог довести дело до конца.

Telegram MCP-сервер fast-mcp-telegram пустил атакующих к телеграм-сессии

В fast-mcp-telegram нашли критическую уязвимость под идентификатором CVE-2026-52830: хотели защититься токенами bearer, а в итоге превратили токен в путь к файлу. В результате атакующий может получить доступ к MCP-сессии Telegram по HTTP без валидного закрытого токена.

Fast-mcp-telegram — это MCP-сервер, который подключает телеграм-аккаунты к ИИ-ассистентам и HTTP-клиентам через сессионную модель аутентификации.

В версиях до 0.19.0 включительно проверка токена устроена так: сервер берёт строку из Authorization: Bearer, добавляет к ней .session, склеивает с директорией сессий и проверяет, существует ли такой файл.

Проблема в том, что токен не нормализуется как безопасный идентификатор. Код запрещает некоторые зарезервированные имена, например telegram, но не блокирует слеши, «..», абсолютные пути и другие конструкции.

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

В типичной конфигурации дефолтная сессия лежит в файле ~/.config/fast-mcp-telegram/telegram.session. Прямой токен telegram отклоняется, но обходной вариант вроде ../fast-mcp-telegram/telegram может схлопнуться файловой системой в тот же самый файл. Если файл существует, сервер принимает такой токен и аутентифицирует атакующего как дефолтный телеграм-аккаунт.

После этого злоумышленник может читать и отправлять сообщения, вызывать MTProto API и использовать доступные инструменты, привязанные к этой сессии. Защита на уровне префиксов инструментов тут уже не спасает: она срабатывает после аутентификации, а дверь к аккаунту к тому моменту уже открыта.

Уязвимость затрагивает fast-mcp-telegram до версии 0.19.0 включительно. В версии 0.19.1 разработчики ужесточили проверку и начали обращаться с bearer-токенами как с непрозрачными идентификаторами, а не как с кусками пути.

Администраторам рекомендуют срочно обновиться, ротировать дефолтные и старые session-файлы, а также проверить логи на подозрительные bearer-значения со слешами и «…».

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