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

Эту брешь обнаружил на прошлой неделе Франс Розен (Frans Rosén), консультант Detectify по вопросам ИБ. Получив от исследователя уведомление о баге, связанном с обработкой междоменных коммуникаций, компания выплатила ему вознаграждение в размере $3 тыс.

Основной причиной данной уязвимости является отсутствие проверки достоверности таких свойств, как evt.origin и evt.source. Это позволило Розену получить доступ к внутренним функциям Slack. «Отсутствие валидации явно говорило о возможности порезвиться — к примеру, вызвать функции, использующие postMessage для этого окна, из другого окна под моим контролем», — пишет исследователь в блоге Detectify.

Исследуя код, Розен также обнаружил, что функции вызова, в частности /call конечной точки, не проверяют источник сообщений. Проштудировав длинный список HTML-событий на сервисе, эксперт остановился на reconnect_url, возможности смены используемого WebSocket-URL. Создав собственный WebSocket, самый примитивный, способный лишь отвечать на запросы, Розен обнаружил, что он может прослушивать трафик, отслеживая отправку токен-параметра. Этот токен, XOXS, свойственен лишь Slack и обеспечивает «полный и всеобъемлющий доступ к вашему Slack-аккаунту», как выразился исследователь.

Если злоумышленнику удастся убедить жертву кликнуть по ссылке на вредоносной странице, откроется новое окно, и пользователя перенаправят на его или ее экземпляр Slack. Поскольку /call не верифицирует источник, Розен смог перенаправить пользователя на текущий экземпляр Slack. Такая возможность позволяет атаковать любого пользователя, даже в других группах.

Венцом атаки, по крайней мере того этапа, на котором Slack можно заставить выдать токен пользователя, является использование функции postMessage, отвечающей за обмен информационными сообщениями между двумя окнами или фреймами в разных доменах. С помощью postMessage Розену удалось сбросить URL сокета и осуществить вызов goodbye для прерывания соединения.

Исследователь полагал, что восстановления соединения будет достаточно для слива токена на его собственный WebSocket, однако он быстро понял, что сбросить вызов с сокета Slack технически невозможно. Здесь-то и вступил в игру вызов goodbye. «Метод с goodbye подошел идеально, так как соединение восстановилось автоматически, но уже с использованием URL моего сокета и отправкой мне xoxs-токена (что эквивалентно получению полного доступа к вашему Slack-аккаунту)», — заявил Розен в комментарии Threatpost. После этого исследователю удалось изменить запрос и получить параметр для локального дампа токена после быстрого соединения с его собственным WebSocket.

По словам Розена, основной проблемой Slack являлось отсутствие верификации источника при использовании postMessage. «Для надежной работы с postMessage необходима проверка источника каждого сообщения, — поясняет эксперт журналистам. — В данном случае, когда я начал разбираться во всем этом, мне стало ясно, что возможности, которые я использовал для отправки сообщений в окно Slack, не должны были быть доступными из какого-либо источника».

Функция postMessage заставляет Slack взаимодействовать с функцией вызова, пока длится этот вызов. В отсутствие валидации источника вредоносная страница исследователя тоже имела возможность взаимодействовать со всплывающим окном вызова. «Так оно и было, пока они это не пропатчили», — говорит Розен.

Эксперт не преминул отметить, что операторы Slack выпустили заплатку очень оперативно; по его словам, по скорости реакции на подобные уведомления этот сервис не уступает другим «ударникам»: Dropbox, Uber, Zenefits. Розен сообщил в компанию о баге, воспользовавшись ее страницей на HackerOne, 17 февраля. ИБ-служба Slack отозвалась спустя 33 минуты, а через пять часов патч был готов. На HackerOne уязвимость была помечена как пропатченная 21 февраля.

Представители Slack на запрос Threatpost о комментарии пока не ответили. Судя по записи на HackerOne, после установки патча ИБ-специалисты компании провели расследование и обнаружили, что этот вектор атаки злоумышленники ни разу не использовали.

Категории: Аналитика, Уязвимости