Несколько месяцев назад была обнаружена уязвимость, с помощью которой хакеры могут взламывать корпоративные средства обмена сообщениями. Воспользоваться этой уязвимостью не сложнее, чем пару раз щёлкнуть мышью, при её успешной эксплуатации можно получить доступ ко внутренней сети компании, к аккаунтам её сотрудников в социальных сетях, таких, как Twitter, и, обычно, к командам в Yammer и Slack.
Я придумал для моей находки имя и логотип. Примите как данность.
Проблема, о которой идёт речь, всё ещё существует. Это — не тот случай, когда всё можно моментально привести в порядок. За последние несколько месяцев я связался с десятками компаний и затронутых уязвимостью поставщиков услуг, в рамках их программ отлова багов, для того, чтобы исправить ситуацию. Из-за огромного количества организаций, на которых это распространяется, я не в состоянии связаться со всеми. Следуя рекомендациям некоторых уважаемых мною людей и с разрешения затронутых проблемой организаций, я публикую этот материал для того, чтобы все, кого это касается, могли бы немедленно принять меры. Сейчас я расскажу о том, что я назвал Ticket Trick.
Дверь: зарегистрируйтесь, используя корпоративный почтовый ящик
Популярные площадки для организации бизнес-коммуникаций, такие, как Slack, Yammer и Facebook Workplace, требуют, чтобы сотрудники компаний регистрировались с использованием корпоративных почтовых ящиков. Как только сотрудник щёлкнет по ссылке для подтверждения адреса, отправленной на его рабочую почту, он сможет присоединиться к группе компании в сервисе и получить доступ к внутренним средствам связи с другими членами группы.
Slack: пользователи, почтовый ящик которых открыт на одном и том же корпоративном домене, могут, по умолчанию, присоединяться к команде. Это можно заменить на SSO или установить в режим подключения только по приглашениям
Yammer: любой, у кого есть корпоративный почтовый ящик, может присоединиться к команде компании
Facebook Workplace: тот, у кого есть корпоративный почтовый ящик, может присоединиться к команде
Ключи от двери: служба поддержки или функция создания обращений из сообщений электронной почты
▍Метод №1: система отслеживания ошибок
Я начал исследование с GitLab. Любой, у кого есть действующий почтовый ящик на @gitlab.com, может присоединиться к их команде в Slack.
Подключение к команде GitLab в Slack
В то же время, GitLab предлагает возможность создания сообщений об ошибках путём отправки их… на уникальный адрес, созданный на @gitlab.com. Видите, к чему всё идёт?
GitLab — одна из многих систем отслеживания ошибок, которая предоставляет возможность создания сообщений об ошибках с помощью электронной почты
Я, ради интереса, попытался присоединиться к их команде в Slack, используя почтовый адрес, выданный мне для создания сообщений об ошибках.
Регистрация в gitlab.slack.com
Сразу после регистрации я обновил мой список обращений, и увидел, что к моему проекту, в виде нового обращения об ошибке, добавилось письмо подтверждения адреса.
Письмо для подтверждения адреса
Только что добавленное сообщение об ошибке содержало «волшебную ссылку», необходимую для того, чтобы подключиться к команде GitLab на Slack:
Письмо со ссылкой для подтверждения адреса
Я щёлкнул по ссылке для того, чтобы проверить, сработает ли она. Она сработала. Мне предложили список каналов, к которым я могу присоединиться. Я немедленно удалил учётную запись и сообщил о проблеме в GitLab.
Отредактированный скриншот со списком каналов
Команда GitLab ответила на моё сообщение тем же воскресным вечером, когда я его им отправил.
Реакция на сообщение об уязвимости
Они немедленно поменяли режим подключения к их команде на Slack, сделав возможным подключение только по приглашению. Кроме того, они приняли дополнительные меры для того, чтобы сообщить своим клиентам об опасности подобного функционала.
▍Метод №2: служба поддержки
Не так много веб-сайтов имеют общедоступный баг-трекер, поэтому я решил копнуть глубже для того, чтобы выяснить, существует ли некий более распространённый вектор атаки. Как оказалось — существует, и встречается он гораздо чаще, чем я мог ожидать: это служба поддержки клиентов.
Электронные письма, отправленные по адресам вида support@company.com иногда оказываются в онлайновых порталах поддержки, таких, как Zendesk, Kayako, (Fresh)Desk, WHMCS, или в подобных системах собственной разработки. В результате я решил с этим поэкспериментировать и узнать, может ли взломщик как-нибудь вытащить из системы поддержки клиентов нужную ему ссылку подтверждения адреса электронной почты.
Большинство порталов поддержки может быть интегрировано с технологией единого входа: аутентифицированный пользователь будет автоматически входить в службу поддержки. Это повышает удобство работы. Более половины проверенных мной сайтов не требовало проверки электронного адреса. Это означает, что кто угодно может зарегистрироваться в системе с любым адресом электронной почты и читать любые заявки в службу поддержки, созданные с помощью этого адреса. Онлайн-видеоплатформа Vimeo была одной из многих компаний, которые не требовали верификации.
В результате я зарегистрировал аккаунт на Vimeo, используя тот же адрес электронной почты, который Slack использует для отправки ссылок подтверждения адреса электронной почты: feedback@slack.com.
Регистрация в Vimeo с использованием адреса feedback@slack.com
Используя удобную возможность Slack Find Your Workspace, я нашёл команду Vimeo в Slack и зарегистрировался с электронным адресом support@vimeo.com.
Регистрация в vimeo.slack.com с использованием адреса support@vimeo.com
Тем временем с адреса feedback@slack.com ушло письмо на support@vimeo.com, содержащее ссылку для подтверждения адреса.
Когда support@vimeo.com получает письмо, оно классифицируется как тикет обращения в техподдержку, созданный с адреса feedback@slack.com… а это — именно тот адрес, с которым я зарегистрировался.
Потом я заглянул в службу поддержки Vimeo для того, чтобы проверить мои тикеты.
Служба поддержки Vimeo
Там оказалось одно обращение, которое содержало ту самую ссылку подтверждения адреса, которая была мне нужна для того, чтобы присоединиться к команде Vimeo.
Ссылка подтверждения адреса
Команда Vimeo немедленно отреагировала на мой отчёт о найденной ошибке, мне выдали $2000 в рамках их программы поиска багов (#220102, ожидает раскрытия).
Эта уязвимость касается всех веб-сайтов, в которые интегрирован портал поддержки, не предусматривающий подтверждение адреса электронной почты. Однако, всё оказалось ещё хуже.
Я обнаружил ещё две дыры в Kayako и Zendesk, которые дали мне обойти процесс подтверждения адреса почты при их обычных настройках. Это позволило мне успешно выполнять атаку даже в тех случаях, когда служба SSO была отключена и требовалось подтверждение адреса электронной почты. Я сообщил об этих проблемах первого июня, в рамках программ ответственного раскрытия информации об уязвимостях. Оба проекта всё исправили.
Далее, веб-сайты, которые требуют подтверждения адреса после регистрации, но не после его последующего изменения, также уязвимы.
Увеличение масштабов проблемы
Если компания не использует Slack и в ней считают, что они в безопасности… вероятно, всё не так уж и хорошо, учитывая то, насколько распространённой оказалась обнаруженная мной уязвимость. Например, другие инструменты для организации делового общения, такие как Yammer, также подвержены этой атаке.
Мне удалось подключиться ко внутренней сети Yammer, принадлежащей компании, название которой не раскрываю
А так как мы можем читать письма, отправленные на адреса вида support@, мы можем видеть и ссылки для сброса паролей, отправленные на эти адреса. Как оказалось, немало компаний использует именно этот адрес для регистрации в сторонних сервисах и социальных сетях вроде Twitter.
Это означает, что атакующий, кроме того, может захватить любой аккаунт, связанный с адресом вида support@.
Сброс пароля в Twitter
Мне удалось захватить несколько учётных записей в Twitter с более чем миллионом подписчиков
В некоторых случаях с этими электронными адресами так же были связаны привилегированные учётные записи на сайтах компаний. Регистрируясь с адресом no-reply@company.com, можно было перехватить токен сброса пароля для support@company.com и получить доступ к привилегированным учётным записям, которые давали доступ ко всей информации о клиентах.
Если ни один из вышеперечисленных методов не работал, у атакующего оставалась возможность читать существующие и будущие тикеты в службу поддержки, созданные с использованием почты, и отвечать на них. Мой друг однажды отправил письмо на адрес службы поддержки компании, так как что-то работало не так. Разбираясь с этой проблемой, я выяснил, что некая компания оказалась уязвимой, поэтому я зарегистрировался в системе с использованием её адреса, перешёл в раздел «my support cases» и увидел, как там появилось письмо. Я смог читать письма, которые были отправлены в службу поддержки от тех пользователей, у которых не было учётной записи в этой службе, смог на них отвечать. В результате подобной атаки пользователи, которые думают, что общаются со службой поддержки, на самом деле, переписываются с хакером.
Ответы компаний и владельцев сервисов
Мне было любопытно узнать, как именно каждая компания будет устранять обнаруженную мной уязвимость. Вот что в итоге получилось.
Компании, на которые это повлияло сильнее всего, реагировали на мои обращения весьма профессионально. Некоторые даже решили выдать вознаграждение за обнаруженную уязвимость в размере $8000. Иногда я получал отрицательные ответы, а некоторые меня просто игнорировали.
Администрация системы отслеживания ошибок GitLab (#218230, раскрыто) быстро приняла меры, а именно, теперь адреса, открытые на домене компании, не пользуются доверием, кроме того, изменены некоторые настройки Slack. Далее, они внесли изменения в документацию для того, чтобы их пользователи не делали тех же ошибок.
Я сообщил о проблеме в Slack (#239623, ожидает раскрытия) для того, чтобы выяснить, можем ли мы это предотвратить на более высоком уровне. Несмотря на то, что они напрямую не отвечают за эту уязвимость, она влияет на немалое число их клиентов.
В Slack отнеслись к проблеме серьёзно и изменили свой no-reply-адрес таким образом, чтобы он включал в себя случайный токен. Это позволяет надёжно предотвращать подобные атаки на ПО служб поддержки. Проблема, однако, всё ещё актуальна для служб отслеживания ошибок и других систем, интегрированных с электронной почтой. Несмотря на то, что это — не уязвимость самого сервиса Slack, я получил от компании щедрую награду в $1500.
Компания Slack добавила рандомизированные токены к своему no-reply адресу для того, чтобы предотвратить атаки на службы поддержки
Кроме того, я попытался связаться с Yammer чтобы сообщить об этой проблеме. Сначала ответа я не получил. Две недели спустя я отправил следующее письмо, на которое ответили, сообщив, что переслали его команде Yammer вместе с описанием уязвимости. До сих пор они не предприняли никаких упреждающих мер для того, чтобы решить проблему на более высоком уровне, как сделали в Slack.
Атакующие всё ещё могут присоединиться к рабочим пространствам Yammer с использованием обнаруженной мной уязвимости
Я связался с Kayako и Zendesk в рамках их программ поиска уязвимостей (#235139, раскрыто), сообщив о возможности обхода SSO. Компании эту проблему решили и выдали мне, соответственно, $1000 и $750.
FAQ
Как узнать, что это может повлиять на нашу компанию?
Эта уязвимость актуальна в том случае, если тикеты службы поддержки можно создавать с помощью сообщений электронной почты, и в том случае, если тикеты доступны пользователям с неподтверждёнными адресами электронной почты. Кроме того, она существует в общедоступных баг-трекерах, или в том случае, если система, отвечая на сообщения пользователей, предоставляет им уникальные адреса в домене компании для отправки сообщений, которые попадают потом в тикеты, в посты на форумах, в частную переписку или в учётную запись пользователя.
Если компания подвержена этой уязвимости, как с ней справиться?
Я видел несколько подходов к решению этой проблемы. Компании вроде AirBnb, LinkedIn и GitHub предоставляют адреса на другом домене, вроде reply.linkedin.com или mail.github.com. Эти адреса нельзя использовать для регистрации в сервисах вроде Yammer или Slack. GitLab обновил документацию, включив в него этот совет для предотвращения подобных атак в службах отслеживания ошибок.
Некоторые решили отключить функционал, связанный с электронной почтой, портал поддержки или систему единого входа. Другие реализовали подходящую систему проверки почтовых адресов. Кроме того, не рекомендуется регистрироваться в службах вроде Twitter, Slack или Zendesk с использованием корпоративных адресов вида support@.
Если наш общедоступный сервис или система бизнес-коммуникаций подвержены этой уязвимости, как с ней бороться?
Вы можете реализовать дополнительные меры безопасности для тех, кто регистрируется в вашей системе, используя почтовые ящики служб поддержки клиентов, но обычно это непрактично и неэффективно. Например, в Facebook Workplace реализован более удачный подход, так как они отправляют письма со случайно сгенерированных адресов вроде notification+ajivdw9kpwld@fbworkmail.com. О том, каким будет подобный адрес, атакующий догадаться не может. В ответ на моё обращение Slack также решил реализовать подобный функционал.
Почему вы раскрываете эту информацию, ведь сотни компаний всё ещё уязвимы?
Большое количество уязвимых компаний приводит к невозможности проинформировать их все. Имеется риск подвергнуться искам от компаний, которые не обращались за советами в области безопасности. Я связался лишь с небольшим количеством компаний, подверженных уязвимости, и с поставщиками услуг, которые реализуют общедоступные программы ответственного раскрытия уязвимостей. Открытие этой информации сейчас было непростым решением, это может привести к взломам, но история учит нас, что скрывать информацию о ошибках ещё хуже.
Итоги
- Внутренние системы безопасности компаний обычно гораздо более уязвимы, чем внешние. Исследования таких систем показывают, что сотрудники выкладывают пароли, конфиденциальные сведения компаний и данные о клиентах в каналах обмена сообщениями, к которым есть доступ у любого, кто присоединился к команде компании в подобной системе.
- Нельзя останавливаться в деле поиска уязвимостей. Их появления можно ожидать где угодно. Описанная здесь проблема существовала многие годы на сотнях сайтов, которые проверяли профессионалы в области безопасности, но, насколько мне известно, никто эту проблему не заметил.
- Большие компании не имеют понятия о том, чем именно занимаются их сотрудники. Я обсуждал обнаруженную уязвимость с CISO огромной компании, занимающейся обработкой платежей. Он уверил меня, что это для них — не проблема, так как их сотрудники не должны пользоваться Slack. У них есть собственная внутренняя система для подобных дел. Я доказал ему, что он не прав, подключившись к 8 каналам Slack, которые были открыты, на свой страх и риск, самими сотрудниками. Этими каналами пользовались 322 человека по всему миру. В итоге мне досталась награда в $5000.
- Если вы хотите узнать, к каким командам Slack вы можете присоединиться, используя корпоративный адрес электронной почты, воспользуйтесь функцией Find Your Team.
Уважаемые читатели! А ваша компания подвержена уязвимости Ticket Trick?
Автор: ru_vds
