Сегодня, 22 марта 2022 года, в 03:30 UTC мы узнали о компрометации Okta. Мы используем Okta для идентификации сотрудников как часть нашего стека аутентификации. Мы тщательно изучили этот взлом и не считаем, что в результате мы были скомпрометированы. Мы не используем Okta для учетных записей клиентов; клиентам не нужно предпринимать никаких действий, если они сами не используют Okta.
Расследование и действия
Наш понимание заключается в том, что в январе 2022 года хакеры за пределами Okta имели доступ к учетной записи сотрудника службы поддержки Okta и могли выполнять действия, как если бы они были этим сотрудником. На снимке экрана, размещенном в социальных сетях, был виден адрес электронной почты сотрудника Cloudflare, а также всплывающее окно, указывающее, что хакер выдавал себя за сотрудника Okta и мог инициировать сброс пароля.
Мы узнали об этом инциденте через внутреннюю SIRT Cloudflare. SIRT — это наша группа реагирования на инциденты безопасности, и любой сотрудник Cloudflare может предупредить SIRT о потенциальной проблеме. Ровно в 03:30 UTC сотрудник Cloudflare отправил электронное письмо SIRT со ссылкой на твит который был отправлен в 03:22 UTC. В твите указывалось, что Okta потенциально была взломана. Несколько других сотрудников Cloudflare связались с SIRT в течение следующих двух часов.
На следующей временной шкале показаны основные шаги, которые мы предприняли после первого письма в 03:30 UTC в SIRT.
Хронология (время в UTC)
03:30 — SIRT получает первое предупреждение о существовании твитов.
03:38 — SIRT видит, что твиты содержат информацию о Cloudflare (логотип, информация о пользователе).
03:41 — SIRT создает комнату инцидентов для начала расследования и начинает собирать нужных людей.
03:50 — SIRT заключает, что для пользователя, показанного на упомянутом выше снимке экрана, не было соответствующих событий журнала аудита (например, смены пароля).
04:13 — Связался с Октой напрямую и попросил подробную информацию, которая поможет нашему расследованию.
04:23 — Все журналы Okta, которые мы загружаем в нашу систему управления информацией и событиями безопасности (SIEM), проверяются на наличие потенциальных подозрительных действий, включая сброс пароля за последние три месяца.
05:03 — SIRT приостанавливает работу учетных записей пользователей, которые могли быть затронуты.
Мы временно приостановили доступ для сотрудника Cloudflare, чей адрес электронной почты появился на скриншотах хакера.
05:06 — SIRT начинает исследование журналов доступа (IP-адреса, местоположения, многофакторные методы) для затронутых пользователей.
05:38 — Первый твит от Мэтью Принса, признающего проблему.
Поскольку оказалось, что сотрудник службы поддержки Okta, имеющий доступ к таким действиям, как принудительный сброс пароля в учетной записи клиента Okta, был скомпрометирован, мы решили проверить каждого сотрудника, который сбросил свой пароль или изменил свою многофакторную аутентификацию (MFA) в в любом случае с 1 декабря по сегодняшний день. С 1 декабря 2021 года 144 сотрудника Cloudflare сбросили свой пароль или изменили свой MFA. Мы заставили их всех сбросить пароль и сообщили им об изменении.
05:44 — Завершен список всех пользователей, сменивших пароль за последние три месяца. Все учетные записи должны были пройти сброс пароля.
06:40 — Твитнуть от Мэтью Принса о сбросе пароля.
07:57 — Мы получили подтверждение от Okta об отсутствии соответствующих событий, которые могут указывать на вредоносную активность в их консоли поддержки для экземпляров Cloudflare.
Как Cloudflare использует Okta
Cloudflare использует Okta для внутреннего использования в качестве нашего поставщика удостоверений, интегрированного с Cloudflare Access, чтобы гарантировать, что наши пользователи могут безопасно получать доступ к внутренним ресурсам. В предыдущих сообщениях блога мы описали, как мы используем Access для защиты внутренних ресурсов и как мы интегрировали аппаратные токены, чтобы сделать наш процесс аутентификации пользователей более устойчивым и предотвратить захват учетных записей.
В случае компрометации Okta было бы недостаточно просто изменить пароль пользователя. Злоумышленнику также потребуется изменить аппаратный токен (FIDO), настроенный для того же пользователя. В результате было бы легко обнаружить скомпрометированные учетные записи на основе соответствующих аппаратных ключей.
Несмотря на то, что логи доступны в консоли Okta, мы также храним их в наших собственных системах. Это добавляет дополнительный уровень безопасности, поскольку мы можем хранить журналы дольше, чем доступно в консоли Okta. Это также гарантирует, что компрометация платформы Okta не сможет изменить доказательства, которые мы уже собрали и сохранили.
Okta не используется для аутентификации клиентов в наших системах, и мы не храним данные клиентов в Okta. Он используется только для управления учетными записями наших сотрудников.
Основные действия, которые мы предприняли во время этого инцидента:
- Свяжитесь с Октой, чтобы собрать больше информации о том, что известно об атаке.
- Заблокируйте одну учетную запись Cloudflare, показанную на скриншотах.
- Найдите в системных журналах Okta любые признаки компрометации (изменение пароля, изменение аппаратного токена и т. д.). Cloudflare считывает системные журналы Okta каждые пять минут и сохраняет их в нашем SIEM, чтобы, если бы мы столкнулись с подобным инцидентом, мы могли бы оглянуться назад, а не на 90 дней, указанные на панели управления Okta. Вот некоторые типы событий в Okta, которые мы искали:
user.account.reset_password,user.mfa.factor.update,system.mfa.factor.deactivate,user.mfa.attempt_bypassа такжеuser.session.impersonation.initiate. Из сообщений, которые мы получили от Okta до сих пор, неясно, кого мы ожидаем, что субъект системного журнала будет скомпрометирован сотрудником службы поддержки Okta. - Выполните поиск в журналах электронной почты Google Workplace, чтобы просмотреть сбросы паролей. Мы подтвердили, что сбросы паролей соответствуют журналам системы Okta, используя отдельный источник от Okta, учитывая, что они были взломаны, и мы не были уверены, насколько надежными будут их журналы.
- Составьте список учетных записей сотрудников Cloudflare, которые изменили свои пароли за последние три месяца и требуют нового сброса пароля для всех из них. В рамках восстановления своей учетной записи каждый пользователь присоединится к видеозвонку с ИТ-командой Cloudflare, чтобы подтвердить свою личность перед повторным включением своей учетной записи.
Что делать, если вы клиент Okta
Если вы также являетесь клиентом Okta, обратитесь к ним за дополнительной информацией. Мы советуем следующие действия:
- Включите MFA для всех учетных записей пользователей. Сами по себе пароли не обеспечивают необходимого уровня защиты от атак. Мы настоятельно рекомендуем использовать аппаратные ключи, так как другие методы многофакторной проверки подлинности могут быть уязвимы для фишинговых атак.
- Исследуйте и ответьте:
а. Проверьте все изменения пароля и MFA для ваших экземпляров Okta.
б. Обратите особое внимание на поддержку инициированных мероприятий.
в. Убедитесь, что все сбросы паролей действительны, или просто предположите, что все они находятся под подозрением, и принудительно сбросьте новый пароль.
д. Если вы обнаружите какие-либо подозрительные события, связанные с MFA, убедитесь, что в конфигурации учетной записи пользователя присутствуют только действительные ключи MFA. - Убедитесь, что у вас есть другие уровни безопасности, чтобы обеспечить дополнительную безопасность в случае сбоя одного из них.
Заключение
Специалисты Cloudflare по безопасности и ИТ продолжают работать над этой компрометацией. Если появится дополнительная информация, указывающая на компрометацию за пределами январского графика, мы опубликуем дополнительные сообщения с подробным описанием наших выводов и действий.
Мы также связываемся с Okta с рядом запросов на дополнительные журналы и информацию. Если обнаружится что-то, что изменит нашу оценку ситуации, мы обновим блог или напишем дополнительные сообщения.
