Avanpost представила новую систему единого входа — Unified SSO (USSO)

Avanpost представила новую систему единого входа — Unified SSO (USSO)

Avanpost представила новую систему единого входа — Unified SSO (USSO)

Компания Avanpost разработала решение для организации единого и удобного входа в корпоративные приложения — Unified SSO. Оно позволяет сотруднику один раз пройти аутентификацию и затем беспрепятственно работать со всеми нужными системами: от десктопных и веб-приложений до инфраструктурных сервисов.

Современные ИТ-системы в компаниях обычно состоят из множества разных сервисов: веб-приложений, VPN, VDI, почты, ERP и так далее.

Как правило, каждое из них требует отдельной аутентификации, что создаёт трудности — особенно при использовании личных устройств (BYOD) или при ограничениях в традиционных SSO-решениях. Подход Avanpost выходит за рамки классического WebSSO или SSO на основе домена — он охватывает весь рабочий ландшафт.

Решение USSO убирает необходимость повторного ввода логинов и паролей. Оно поддерживает разные протоколы аутентификации: OIDC, SAML, RADIUS и пр. В отличие от традиционных подходов, USSO не зависит от конкретной технологии.

Система обеспечивает единый вход не только в браузере, но и на уровне операционной системы. Поддерживается передача сессии между устройствами без повторной авторизации. При этом предусмотрены и усиленные методы защиты: можно использовать аппаратные токены (например, FIDO2), программные механизмы (вроде пуш-уведомлений, усиленного TOTP или QR-кодов через фирменное мобильное приложение), а также стандартные генераторы одноразовых паролей.

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

Для разных ролей в компании это означает следующее:

  • Для сотрудников: меньше необходимости постоянно вводить пароли и проходить 2FA, особенно на рабочих устройствах.
  • Для специалистов по ИБ: полный контроль над аутентификацией на рабочем месте сотрудника и возможность гибко управлять политиками.
  • Для ИТ-отдела: меньше нагрузки, универсальная поддержка разных приложений и понятные инструменты для настройки и мониторинга.

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