На прошлой неделе исследователи из университета штата Висконсин опубликовали
Отчасти проблема происходит из самой сути подобных сервисов с их клиент-серверной моделью, распространяемой в том числе на аддоны сторонних разработчиков. Приложения, расширяющие функциональность корпоративных чатов, также хостятся где-то на сервере у разработчика программы. Это означает, что подробное исследование кода аддона, что является нормальной практикой для корпоративного окружения, невозможно — приходится полагаться на описание функциональности приложения. И даже если удастся провести аудит кода, полный контроль над приложением со стороны разработчика позволяет в любой момент его подменить. Но проблема не только в этом: возможности вредоносного приложения в корпоративном чате мало чем ограничены.
Один примеров недостаточной защищенности пользователей от вредоносных аддонов — это возможность подключать разные сторонние приложения к Slack для расширения функциональности корпоративного чата. Исследователи приводят пример, когда одно предложение загружает файлы на хостинг DropBox, а другое сортирует загруженные файлы и публикует их в Slack, где с ними будет удобно работать. Приложения имеют разные уровни доступа, и только одно из них (апп от Dropbox) может публиковать сообщения от имени пользователя. Но так как взаимодействие между приложениями особо не ограничивается, любой другой апп может воспользоваться правами на публикацию сообщений.
Дальше еще интереснее: удаление аддона не обязательно избавляет вас от его потенциально вредоносной деятельности. Например, публикация сообщений может быть запланирована на будущее, и даже после удаления приложения это действие будет выполнено. Это даже не баги в классическом понимании, а скорее намеренно широкая функциональность чат-сервисов. Авторы исследования предложили несколько сценариев практических атак: отправка сообщений по почте при эксплуатации соответствующего аддона в Slack, взаимодействие с плагином для общения с посетителями корпоративного веб-сайта (естественно, с трансляцией в Slack) с последующей рассылкой фишинговых сообщений, и даже вставка кода в корпоративный репозиторий.
Есть теоретическая возможность перехвата управляющих команд для других приложений. Пример: аддон Zoom для мессенджера Slack, который позволяет организовать встречу участников определенного чата простой командой "/zoom". Авторы исследования выяснили, что ничто не мешает создать вредоносный аддон, управляемый из чата командой "/foo", а потом переименовать "/foo" в "/zoom". В результате все запросы на создание встречи будут направлены вредоносному приложению. Атакующий может незаметно для участников чата приглашать их на конференц-звонки в собственный аккаунт и получать запись этих переговоров. Авторы работы нашли больше тысячи приложений, обращения к которым можно перехватить через специальные команды в чате.
Помимо этих примеров, исследователи также предложили способ чтения любых сообщений из приватных чатов, к которым пострадавший пользователь имеет доступ. Основная проблема такой «расслабленной» модели безопасности в том, что Microsoft Teams и Slack используются в корпоративном окружении и зачастую имеют доступ к другим элементам инфраструктуры. В публикации приводятся рекомендации по усилению защиты, но в целом они сводятся к серьезной переработке правил взаимодействия мессенджеров с приложениями. Администраторы корпоративных чатов могут запретить установку аддонов, но по умолчанию это разрешено. В ответ на запрос журнала Wired компания Microsoft отказалась давать комментарии, а в Slack рекомендовали устанавливать приложения только из официального каталога Slack App Directory, так как они проходят аудит безопасности. Впрочем, как известно по ситуации с расширениями для браузеров, такой аудит далеко не всегда гарантирует полную безопасность приложений.
Что еще произошло:
В свежем исследовании «Лаборатории Касперского»
В свежем обновлении ОС Windows 11 22H2
История со взломом инфраструктуры Uber получила продолжение: в Великобритании
Исправленная