Компрометация системы поддержки Okta вскрыла скрытую зависимость в основе облачной идентификации

Краткое содержание

• Okta подтвердила, что злоумышленник использовал скомпрометированную служебную учётную запись системы поддержки, чтобы получить доступ к файлам, связанным со 134 клиентами, и воспроизвёл артефакты сессий, перехватив пять клиентских сессий; позднее отдельная проверка установила, что злоумышленник также загрузил отчёт с именами и адресами электронной почты всех пользователей затронутой системы поддержки Okta.
• Непосредственным триггером стали похищенные учётные данные, однако практическая ответственность распространяется на меры контроля, которые сделали эти учётные данные полезными: привилегированный доступ службы поддержки, неочищенные диагностические артефакты, неполная интерпретация журналов, переносимые сессии администраторов, запоздалая эскалация между клиентами и процесс уведомления, зависевший от того, помогут ли клиенты поставщику идентификации обнаружить собственную компрометацию.

Самая значимая деталь компрометации системы поддержки Okta в 2023 году заключается не в том, что была взломана служба поддержки, а в том, что служба поддержки находилась достаточно близко к привилегированным операциям с идентификацией, чтобы файл диагностики браузера мог действовать как мандат предъявителя для администратора клиента.

Okta заявила, что её производственный сервис оставался работоспособным и не был скомпрометирован. Эта граница важна. Инцидент не был доказательством того, что злоумышленник взломал основную платформу аутентификации, произвольно подделывал токены Okta или читал тенант каждого клиента. Но эта граница — не лазейка для ухода от ответственности. Клиенты загружали в несвязанный инструмент обработки заявок не инертные скриншоты, а записи браузера, созданные в тот момент, когда администраторы взаимодействовали с контуром управления идентификацией. Некоторые из этих записей содержали живые артефакты сессий.

Когда к репозиторию поддержки был получен доступ, злоумышленник мог перейти из среды поддержки, эксплуатируемой поставщиком, в клиентские тенанты Okta, не повторяя процедуру аутентификации, которая изначально создала эти сессии.

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

Путь поддержки был смежным с производственной средой по топологии системы, но функционально связан с ней через полномочия администраторов клиентов.

Инцидент также делает его тестом экономики каналов связи для сообщений о нарушениях. Три клиента публично описали, что обнаружили активность до того, как Okta завершила собственную кросс-клиентскую диагностику. Их команды защиты потратили время на реконструкцию событий, исключение собственных конечных точек, эскалацию через поддержку и предоставление индикаторов. Эта работа создала информацию, ценную для всех остальных клиентов. Поставщик был единственной стороной, способной сопоставить сообщения по всей системе поддержки, но первая полезная корреляция потребовала времени и зависела от IP-адреса, предоставленного клиентом.

Затраты на подготовку предупреждения были распределены; возможность действовать по нему была сконцентрирована.

Две утечки, а не одна растущая цифра

Публичные сообщения часто сжимают инцидент до утверждения, что Okta сначала заявила о 1 % затронутых клиентов, а затем признала, что затронуты все клиенты. Это сокращение скрывает два разных набора данных и два разных вида риска.

20 октября в своёмпервоначальном публичном уведомленииOkta сообщила, что злоумышленник использовал похищенные учётные данные для доступа к системе управления обращениями в поддержку и просмотра файлов, загруженных определёнными клиентами. Компания предупредила, что файлы HTTP Archive, или HAR, могут содержать cookie-файлы и токены сессий, позволяющие выдавать себя за пользователя. В уведомлении говорилось, что затронутые клиенты были оповещены, что система поддержки отделена от производственного сервиса Okta и что система управления обращениями Auth0/CIC не затронута.

3 ноября вотчёте о первопричинах и мерах по устранениюOkta количественно оценила эту утечку файлов. С 28 сентября по 17 октября злоумышленник получил несанкционированный доступ к файлам, связанным со 134 клиентами Okta, что составляет менее 1 % клиентов компании. Некоторые из них были HAR-файлами, содержащими токены сессий. Okta заявила, что злоумышленник использовал эти токены для перехвата легитимных сессий пяти клиентов. Трое из пяти позднее опубликовали собственные отчёты: 1Password, BeyondTrust и Cloudflare.

29 ноября, воссоздав отчёты, запущенные злоумышленником, Okta раскрыла вторую утечку вобновлённом уведомлении об инциденте. Злоумышленник загрузил отчёт, содержащий имена и адреса электронной почты всех пользователей затронутой системы поддержки клиентов. Затронутая группа охватывала клиентов Workforce Identity Cloud и Customer Identity Solution, за исключением клиентов сред FedRAMP High и Impact Level 4 Министерства обороны США, которые использовали отдельную систему поддержки. Система обращений Auth0/CIC снова была исключена.

По словам Okta, для 99,6 % пользователей из отчёта единственными записанными контактными данными были полное имя и адрес электронной почты. В шаблоне отчёта были и другие поля, но большинство из них были пустыми; Okta заявила, что он не содержал учётных данных пользователей или чувствительных персональных данных.

Эти факты поддерживают четыре точных утверждения:

1. Файлы, связанные со 134 клиентами, были доступны злоумышленнику.
2. Артефакты сессий из некоторых доступных файлов были использованы для перехвата пяти клиентских сессий.
3. Был загружен значительно более широкий отчёт о пользователях поддержки, содержащий имена и адреса электронной почты.
4. Запись в отчёте не означала, что тенант этого человека или его сессия администратора были скомпрометированы.

Более позднее обнаружение расширило утечку контактных данных, а не подтверждённое число перехваченных сессий. Оно также изменило смысл октябрьского уведомления. В первом уведомлении Okta говорилось, что клиент, не оповещённый через другое сообщение, не имеет последствий для своей среды или обращений в поддержку. Если понимать это узко — как утверждение о доступных файлах поддержки и активности в тенанте, — оно могло оставаться согласованным с выводом о 134 клиентах. Если понимать широко — как утверждение о любой утечке данных в системе поддержки, — оно было преодолено ноябрьской реконструкцией отчёта.

Хорошая коммуникация об инциденте должна определять единицу измерения: организация клиента, пользователь поддержки, файл поддержки, живая сессия, целевой тенант или подтверждённая компрометация ниже по цепочке.

Okta представила ноябрьское обновление как приложение кформе 8-K, поданной в Комиссию по ценным бумагам и биржам США. Это делает раскрытие частью публичного отчётного рекорда компании для инвесторов. Это не превращает заявление компании в вывод SEC, и сам 8-K указывал, что информация была предоставлена, а не считалась поданной для определённых целей ответственности. Это различие важно, потому что наиболее детальное публичное фактическое описание всё равно исходит от Okta и затронутых клиентов, а не от опубликованного решения регулятора.

Артефакт поддержки, позволявший выдавать себя за администратора

HAR-файл полезен, потому что он насыщен информацией. Он фиксирует запросы и ответы браузера, тайминги, URL, заголовки, детали полезной нагрузки и — в зависимости от того, как он экспортирован и очищен, — cookie-файлы или материал авторизации. Эта насыщенность позволяет инженеру поддержки увидеть, что произошло в браузере клиента, не воспроизводя точную среду. Она также создаёт компактную копию данных, которые ранее были распределены по живой сессии.

Собственноеруководство Okta по созданию HARописывает формат как способ воспроизведения ошибок конечных пользователей или администраторов и предупреждает пользователей удалять или скрывать конфиденциальную и личную информацию перед отправкой файла. Текущаядокументация Chrome DevToolsделает риск необычно конкретным: её экспорт с очисткой по умолчанию исключает заголовкиCookie,Set-CookieиAuthorization, тогда как экспорт с чувствительными данными должен быть отдельно включён. Это текущее поведение браузера не следует проецировать назад как доказательство точного интерфейса, который видел клиент в сентябре 2023 года.

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

Соответствующий артефакт в инциденте Okta был не обязательно одноразовым параметромsessionToken, описанным в некоторых потоках входа Okta. Терминологию токенов легко размыть.Руководство разработчика Okta по cookie-файлам сессийобъясняет, что одноразовый токен сессии можно обменять на установку HTTP-cookie сессии, после чего cookie предоставляет доступ к организации Okta и приложениям в рамках запросов браузера. Отчёты клиентов описывали похищенные cookie-файлы или токены аутентификации, связанные с активными сессиями администраторов.

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

Памятка OWASP по управлению сессиямиобъясняет, почему это так серьёзно: после аутентификации идентификатор сессии временно эквивалентен самому сильному методу, использованному для аутентификации пользователя. FIDO2-ключ может сделать крайне трудным проведение нового фишингового входа, но переносимый мандат сессии может позволить злоумышленнику попасть в систему после этой проверки. Это не делает фишинг-устойчивую аутентификацию бесполезной. Это означает, что сила аутентификации и сила сессии — отдельные вопросы контроля.

Руководство NIST по реализации управления сессиямианалогично утверждает, что перехват сессии может быть столь же разрушительным, как и сбой аутентификации, и подчёркивает защищённые секреты сессий, определённые сроки жизни и повторную аутентификацию. В этом инциденте диагностическая запись пересекла границы доверия, в то время как сессия, представленная данными внутри неё, оставалась действительной. Сам факт загрузки HAR-файла не делал автоматически непригодными все встроенные секреты. Okta позднее отозвала раскрытые токены сессий, но отзыв был ответом после того, как соответствующие файлы были идентифицированы.

Более безопасный принцип проектирования — не просто «никогда не используйте HAR». Командам поддержки иногда нужен точный контекст запроса. Принцип в том, чтобы рассматривать диагностическую запись от аутентифицированного администратора как материал учётных данных с момента создания до удаления.

Это подразумевает сбор под учётной записью с минимальными привилегиями, где это возможно, автоматическую локальную очистку, явную идентификацию любых полей, сохранённых потому, что они необходимы для диагностики, шифрование и ограничения доступа при передаче и хранении, короткий срок хранения, журналирование доступа, охватывающее каждый интерфейс, и отзыв или повторную аутентификацию при приёме чувствительной записи.

Загрузка в поддержку не должна быть моментом, когда живая административная сессия становится переносимой.

Клиенты были первыми распределёнными сенсорами

Публичные отчёты клиентов — это больше, чем подтверждающие анекдоты. Они показывают, какие меры контроля сработали, когда телеметрия поддержки поставщика ещё не дала кросс-клиентского вывода.

1Password: неожиданное административное событие

Согласно хронологии Okta, 1Password сообщила о подозрительной активности 29 сентября, и две компании неоднократно встречались до 2 октября. Современныйотчёт 1Password об инцидентеописывал неожиданную административную активность в её среде Okta, а позже добавил, что первый набор журналов доступа к файлам Okta не показал несанкционированного доступа к соответствующему HAR-файлу. После того как Okta подтвердила компрометацию системы поддержки, дополнительные журналы показали, что скомпрометированная служебная учётная запись имела к нему доступ.

Согласно дополнению 1Password, файл существовал под двумя разными идентификаторами объектов в системе вендора поддержки, тогда как первый анализ охватывал только один.

Эта деталь иллюстрирует проблему модели доказательств. Клиент задал естественный вопрос: кто имел доступ к файлу, прикреплённому к этому обращению? Система поддержки могла представлять один и тот же базовый файл через более чем один объект или маршрут. Запрос, технически корректный для одного идентификатора, был неполным для вопроса безопасности. Ошибка заключалась не только в отсутствии сырых событий; это было несоответствие между моделью данных системы и моделью объекта, которой пользовались исследователи.

1Password сообщила, что никакие пользовательские данные или чувствительная информация не были доступны злоумышленнику и что активность была ограничена её экземпляром Okta. Её отчёт описывал, как злоумышленник изменил и повторно включил соединение, связанное с производственным Google-провайдером идентификации 1Password, а затем не смог использовать его для доступа к среде Google. Эти факты показывают и охват, и предел перехваченной сессии администрирования идентификации. Злоумышленник мог исследовать или изменять конфигурацию идентификации, но дальнейший доступ по-прежнему зависел от архитектуры клиента, скорости реакции и других мер контроля.

BeyondTrust: отказ политики, обход через API и устойчивая эскалация

Вописании инцидента BeyondTrustдаётся самая чёткая поминутная картина пути поддержки через файлы. 2 октября по запросу поддержки Okta администратор BeyondTrust создал и загрузил HAR-файл по не связанному с безопасностью вопросу поддержки. Файл содержал API-запрос и cookie сессии. В течение 30 минут злоумышленник попытался использовать сессию администратора с IP-адреса в Малайзии, связанного с анонимизирующими сервисами.

Нестандартная политика доступа BeyondTrust требовала управляемого устройства с Okta Verify для консоли администратора, поэтому первоначальный доступ к консоли был отклонён. Затем злоумышленник использовал аутентифицированную сессию через API Okta, где, по словам BeyondTrust, те же ограничения политики не применялись, и создал учётную запись задней двери с именем, похожим на служебную учётную запись. BeyondTrust обнаружила активность, отключила учётную запись и отозвала доступ до того, как задняя дверь могла быть использована. Компания сообщила об отсутствии доказательств дальнейшего доступа к её системам или клиентам.

Здесь можно отдельно увидеть несколько мер контроля. FIDO2 защищала первоначальную аутентификацию администратора, но сама по себе не привязывала результирующую сессию к устройству администратора. Политика состояния устройства блокировала интерактивный маршрут консоли, но не ограничивала эквивалентно маршрут API. Поведенческие детекции зафиксировали сессию, появившуюся без ожидаемой истории аутентификации, использование прокси, редкий административный отчёт и создание учётной записи, похожей на привилегированную. Затем люди-операторы завершили сессию до того, как попытка закрепиться стала полезной.

BeyondTrust также стала внешним сенсором для Okta. Компания связалась с Okta 2 октября, запросила эскалацию 3 октября, встречалась с персоналом поддержки и безопасности, запросила более полные журналы и продолжала утверждать, что доказательства указывают на компрометацию внутри организации поддержки Okta. 13 октября она предоставила подозрительный IP-адрес, который, как позже сказала Okta, позволил провести решающий поиск. Это была дорогостоящая исследовательская работа, выполненная клиентом, потому что клиент мог видеть эффект в своём тенанте, тогда как Okta могла видеть общую причину в своей среде поддержки.

Cloudflare: быстрое сдерживание, затем неполная ротация

В первомоктябрьском отчёте Cloudflare об инцидентеговорилось, что компания обнаружила 18 октября активность, связанную с токеном административной сессии, взятым из обращения в поддержку Okta. Злоумышленник скомпрометировал две учётные записи сотрудников Cloudflare в платформе Okta. Cloudflare заявила, что обнаружила активность более чем за 24 часа до уведомления Okta и локализовала событие до того, как злоумышленник закрепился или достиг данных клиентов, систем клиентов или производственной сети.

Ответ Cloudflare опирался на собственную телеметрию и сегментацию. Компания рекомендовала отслеживать сессии без соответствующей аутентификации, новых или повторно активированных пользователей, изменения учётных записей и разрешений, изменения MFA, переопределения политик и доступ поставщиков в цепочке поставок. Это не универсальные пункты чек-листа в контексте этого инцидента. Они отображаются на разрыв между действительной сессией и действительным действием пользователя. Если сессия начинается в одном месте и воспроизводится в другом, сервис может видеть разрешённый cookie, тогда как клиент видит невозможную последовательность.

Затем Cloudflare превратила сам артефакт поддержки в объект контроля. Её проектHAR Sanitizerудалял связанные с сессией cookie-файлы и токены на стороне клиента и, в некоторых случаях диагностики, мог удалять подпись токена, сохраняя диагностически полезную структуру. Это важная модель устранения последствий, потому что она снижает ценность файла до того, как он попадает в распоряжение поставщика. Она не требует, чтобы каждый репозиторий поддержки, учётная запись сотрудника и запрос журнала работали безупречно, чтобы предотвратить повторное использование токенов.

Случай Cloudflare также показывает, что быстрое первоначальное сдерживание — не то же самое, что полное устранение угрозы. В феврале 2024 года Cloudflare раскрыла отдельныйинцидент в День благодарения, в котором злоумышленник использовал один токен доступа и три учётных данных служебных учётных записей, взятые во время октябрьской компрометации Okta. Cloudflare признала, что не выполнила ротацию этих четырёх учётных данных. С 14 ноября злоумышленник имел доступ к её самостоятельно размещённой среде Atlassian, просматривал внутреннюю документацию и ограниченный объём исходного кода и безуспешно пытался достичь консольного сервера в ещё не введённом в эксплуатацию дата-центре.

Cloudflare заявила, что данные клиентов, системы клиентов и глобальная конфигурация сети не были затронуты.

Это более позднее событие меняет анализ ответственности, не перекладывая весь инцидент на клиента. Okta контролировала систему поддержки, в которой были раскрыты учётные данные. Cloudflare контролировала инвентаризацию и ротацию секретов, которые раскрытый файл поставил под угрозу. Как только Cloudflare узнала, что её артефакт поддержки был похищен, у неё была практическая возможность выполнить ротацию каждого секрета в этом артефакте. Пропуск четырёх учётных данных из тысяч создал второй используемый путь.

Cloudflare публично признала этот провал и описала гораздо более масштабные меры по усилению защиты, включая ротацию более 5 000 производственных учётных данных и обширную криминалистическую проверку. Ответственность следует за контролем на каждом этапе, а не за единым ярлыком, прикреплённым к первоначальному взлому.

Последовательность обнаружения и уведомления

Последовательность важна, потому что злоумышленник сохранял доступ, пока клиенты уже сообщали о симптомах.

Согласно хронологии Okta от 3 ноября, несанкционированный доступ злоумышленника продолжался с 28 сентября по 17 октября. 1Password сообщила о подозрительной активности 29 сентября. Okta начала расследование в тот же день, но первоначально подозревала вредоносное ПО или фишинг у 1Password. BeyondTrust сообщила о подозрительной активности 2 октября. Третий клиент сообщил 12 октября. BeyondTrust предоставила подозрительный IP-адрес 13 октября. 16 октября Okta использовала этот индикатор для идентификации служебной учётной записи, связанной с ранее не наблюдавшимися событиями в журналах системы поддержки.

17 октября Okta отключила служебную учётную запись, завершила её сессии, изучила доступные файлы и отозвала токены, встроенные в идентифицированные HAR-файлы.

Okta заявила, что пробел в журналах затем усложнил определение масштаба. 18 октября она обнаружила, что в журналах системы поддержки отсутствуют последние часы доступа злоумышленника. Повторный запрос вернул более полную запись. 19 октября она обнаружила дополнительные загруженные файлы, отозвала вновь идентифицированные встроенные токены, определила Cloudflare как пятого целевого клиента и уведомила зарегистрированные контакты по безопасности среди своей клиентской базы о том, затронуты ли их организации тогдашним известным инцидентом. Публичное уведомление последовало 20 октября.

Информация о первопричине и мерах по устранению была направлена зарегистрированным контактам по безопасности 2 ноября и опубликована 3 ноября.

Расширение от 29 ноября стало результатом другого метода расследования. Okta вручную воссоздала отчёты, которые запускал злоумышленник, и сравнила результирующие размеры файлов с телеметрией загрузок. Шаблонный отчёт, созданный с первоначальными фильтрами исследователей, был меньше, чем зарегистрированная загрузка. Когда фильтры были удалены, вывод был значительно больше и лучше соответствовал телеметрии. Okta заключила, что злоумышленник загрузил нефильтрованный список пользователей системы поддержки. Этот метод был разумен и в итоге продуктивен.

Его позднее появление также показывает, почему определение масштаба инцидента должно с самого начала сочетать журналы доступа на уровне объектов, параметры отчётов, размер вывода, маршрут пользовательского интерфейса, поведение учётной записи и независимую реконструкцию.

Хронология выявляет по меньшей мере четыре задержки с разными причинами:

• Задержка гипотезы: первый отчёт клиента первоначально был списан на компрометацию на стороне клиента.
• Задержка корреляции: несколько отчётов клиентов не были немедленно объединены в инцидент системы поддержки.
• Задержка интерпретации телеметрии: исследователи искали события, связанные с обращениями, тогда как злоумышленник использовал вкладку «Файлы» системы, которая генерировала другой тип событий и другой идентификатор записей.
• Задержка реконструкции масштаба: широта загруженного отчёта о пользователях поддержки была выведена только после воссоздания нефильтрованного вывода и сопоставления размера файла.

Называть все четыре одним «задержкой уведомления» было бы неточно. Okta не могла дать полное уведомление до того, как поняла событие, но она контролировала расследование и канал связи с клиентами. Как только отдельные высокоуверенные отчёты клиентов указали на один и тот же рабочий процесс поддержки, она также контролировала решение о выпуске предупредительного уведомления до того, как все детали были урегулированы. Cloudflare и BeyondTrust публично критиковали темп или призывали к более быстрым действиям. Их критика — доказательство опыта клиентов, а не доказательство юридического нарушения обязательств.

Канал уведомления также имел структурную слабость: система поддержки была одновременно и частью инцидента, и обычным маршрутом для эскалации клиентов. Клиент, утверждающий, что сама поддержка скомпрометирована, не должен полагаться только на обычное обращение в поддержку, чтобы достичь командного центра инцидента поставщика. Поставщикам нужен отдельный внешний канал безопасности с полномочиями объединять сообщения из разных тенантов. Клиентам нужны актуальные зарегистрированные контакты по безопасности, которые не упираются в непросматриваемый почтовый ящик.

Обе стороны нуждаются в формулировках серьёзности, которые различают «в нашем тенанте наблюдается подозрительная активность» и «ваша среда поддержки может быть общим источником».

Триггер, первопричина и способствующие условия

Подтверждённым триггером было использование скомпрометированных учётных данных служебной учётной записи. Okta заявила, что служебная учётная запись хранилась в системе поддержки и имела разрешения просматривать и обновлять обращения клиентов в поддержку. В ходе расследования Okta обнаружила, что сотрудник вошёл в личный профиль Google в Chrome на управляемом Okta ноутбуке и что имя пользователя и пароль служебной учётной записи были сохранены в личной учётной записи Google сотрудника.

Okta назвала компрометацию личной учётной записи Google сотрудника или личного устройства наиболее вероятным путём раскрытия учётных данных. «Наиболее вероятно» — не то же самое, что криминалистически доказано. Публичная запись не устанавливает, какая личная учётная запись или устройство были скомпрометированы, как это произошло, кто получил учётные данные и был ли злоумышленник, ответственный за вторжение в систему поддержки, тем же субъектом, стоящим за каждым более поздним использованием раскрытых учётных данных клиентов. Никакая авторитетная публичная атрибуция не называет злоумышленника, атаковавшего систему поддержки.

Раскрытие учётных данных объясняет, как начался доступ, но не полностью объясняет продолжительность или воздействие инцидента. Несколько способствующих условий превратили одни учётные данные в событие идентификации с участием многих клиентов:

Многоразовые нечеловеческие учётные данные имели широкий доступ к обращениям.Служебная учётная запись могла просматривать и обновлять обращения в поддержку. Публичное описание не утверждает, что каждый доступ требовал фишинг-устойчивой аутентификации, одобрения в момент времени или секрета, привязанного к устройству. Похищенных имени пользователя и пароля было достаточно для создания рабочей сессии в системе поддержки.

Личный профиль браузера мог хранить рабочее служебное учётное данное.Последующая политика Okta заблокировала личные профили Google в Chrome на управляемых ноутбуках. Тот факт, что это было мерой устранения, указывает на то, что предыдущая конфигурация допускала пересечение личной границы синхронизации с управляемым рабочим устройством.

Чувствительные артефакты клиентов попадали в репозиторий поддержки.Okta предупреждала клиентов очищать HAR-файлы, но файлы с живым материалом сессий присутствовали. Предупреждение оставляет исполнение на усмотрение администратора, находящегося под давлением необходимости решить проблему. Рабочий процесс поддержки не гарантировал надёжно, что опасные поля удаляются перед загрузкой.

Злоумышленник мог воспроизводить полномочия администратора из другой сети.Артефакты сессий оставались действительными и переносимыми достаточно долго, чтобы быть использованными. Меры контроля у некоторых клиентов обнаруживали географическую, устройственную или поведенческую прерывность, но базовая сессия всё равно могла аутентифицировать активность через API.

Система поддержки предоставляла семантически несогласованные маршруты аудита.Открытие файла через обращение в поддержку и открытие его через вкладку «Файлы» генерировали разные события и идентификаторы. Исследователи следовали ожидаемому маршруту, тогда как злоумышленник использовал другой. Журнал безопасности полезен только в том случае, если каждый маршрут к одному и тому же защищённому объекту можно сопоставить.

Кросс-клиентская эскалация была медленной.Доказательства клиентов изначально оценивались в рамках отдельных обращений. Okta обладала общим обзором, необходимым, чтобы спросить, не следуют ли, казалось бы, несвязанные события в тенантах за недавними HAR-загрузками в ту же платформу поддержки.

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

Первопричину поэтому лучше сформулировать как цепочку контроля, а не как ошибку сотрудника: рабочее учётное данное пересекло личную область синхронизации; учётное данное дало долговременный полезный доступ к чувствительному репозиторию поддержки; предоставленные клиентами артефакты сохранили повторно используемые полномочия; мониторинг и расследование не сразу сопоставили все пути доступа; и меры контроля сессий позволили секретам пост-аутентификации путешествовать дальше, чем администраторам, которые их создали. Удаление любого из этих условий могло уменьшить исход.

Удаление нескольких сделало бы первоначальную кражу значительно менее ценной.

Кто обладал возможностью предотвратить, обнаружить, ограничить или сократить вред

Ответственность становится яснее, когда её привязывают к возможности контроля.

Okta контролировала служебную учётную запись, политику браузера сотрудников, конфигурацию системы поддержки, доступ, предоставленный вендору поддержки, хранение и обработку загрузок клиентов, мониторинг на стороне поставщика, корреляцию инцидентов, кросс-тенантный отзыв токенов и уведомление клиентов. Поэтому она была в наилучшем положении для предотвращения первоначального доступа к системе поддержки, обнаружения аномального использования служебной учётной записи, идентификации каждого маршрута файлов, аннулирования затронутых сессий и предупреждения всей клиентской базы.

Тот факт, что платформа обращений размещалась третьей стороной, не устраняет роль Okta.

Okta выбирала и настраивала сервисные отношения и была стороной, которой клиенты доверяли рабочий процесс загрузки. Еёформа 10-K за 2024 финансовый годописывала систему поддержки клиентов как размещённую сторонним поставщиком услуг и признавала, что инцидент нанёс ущерб репутации и отношениям с клиентами, негативно повлиял на финансовые результаты и может создать дополнительные обязательства. Это корпоративные раскрытия рисков, а не количественные выводы об убытках клиентов.

Неидентифицированный вендор системы поддержки контролировал части базового продукта, объектной модели и доставки журналов. Публичные доказательства показывают, что разные маршруты доступа к файлам генерировали разные события и что журналы изначально были неполными, но они не устанавливают контракт вендора, не указывают, какая сторона настраивала эти функции, какие предупреждения существовали и нарушил ли вендор конкретное обязательство. Приписывание вендору процента вины вышло бы за пределы публичной записи.

Клиенты контролировали уровень привилегий учётной записи, использованной для сбора диагностики, решение об очистке файла, политики своего тенанта Okta, независимые журналы и детекции, сроки жизни сессий, мониторинг поведения администраторов, сегментацию ниже по цепочке и ротацию учётных данных после уведомления. BeyondTrust продемонстрировала, что нестандартная политика устройств и поведенческая аналитика могут ограничить воспроизведённую сессию. Cloudflare продемонстрировала, что сетевая сегментация может защитить производство, а затем продемонстрировала, что неполная инвентаризация секретов может оставить отложенный путь открытым.

1Password продемонстрировала ценность оповещений о неожиданных административных отчётах и быстрого пересмотра конфигурации.

Разработчики браузеров и диагностических инструментов контролируют настройки по умолчанию. Очищенный экспорт, исключающий cookie-файлы и заголовки авторизации, снижает зависимость от того, что пользователи помнят о ручном редактировании JSON. Портал поддержки может отклонять известные паттерны учётных данных, показывать предварительный просмотр на уровне полей, карантинировать неочищенные загрузки или принимать намеренно частичный трейс. Эти меры несовершенны, потому что токены могут появляться в необычных заголовках, URL или телах, а очистка может удалить факт, необходимый для отладки.

Но инструмент с безопасным поведением по умолчанию меняет экономику: исключительным выбором должно быть сохранение полномочий, а не их удаление.

Клиенты за пределами инцидента также имели ограниченную роль получателей информации о рисках. Ноябрьский отчёт создал справочник людей, которые, вероятно, администрируют Okta. Okta заявила, что на тот момент у неё не было прямых доказательств активной эксплуатации контактных данных, но предупредила о повышенном риске фишинга и социальной инженерии. FINRA позднее выпустилапредупреждение по кибербезопасности, призвав членские фирмы оценить подверженность, пересмотреть использование провайдера и следить за нацеливанием на персонал администраторов и поддержки. Предупреждение было рекомендацией о потенциальном злоупотреблении ниже по цепочке, а не доказательством того, что каждый перечисленный пользователь был атакован.

Зависимость от поставщика идентификации включает восстановление и поддержку

Организации принимают облачного поставщика идентификации, чтобы централизовать политику аутентификации, управление жизненным циклом и доступ к многим приложениям. Централизация может улучшить безопасность: сильные аутентификаторы могут применяться последовательно, завершение учётных записей может распространяться быстро, а события идентификации могут регистрироваться в одном месте. Та же концентрация меняет режимы отказа. Сессия администратора на уровне идентификации может повлиять на многие нижестоящие приложения, а операционные системы поставщика становятся частью цепочки доверия клиента.

Компрометация 2023 года раскрыла три формы зависимости.

Во-первых, клиенты зависели от Okta в отношении действительности активной сессии. Как только Okta приняла похищенный артефакт, аппаратный ключ на стороне клиента не мог ретроактивно доказать, что человек, предъявляющий cookie, всё ещё тот, кто касался ключа. Клиенты могли добавить контекст через политику устройств и сети, но Okta контролировала такие функции продукта, как привязка сессий и глобальный отзыв.

Во-вторых, клиенты зависели от Okta в отношении доказательств о репозитории поддержки. Клиент мог видеть невозможное действие администратора, но не то, кто загрузил его вложение из системы обращений поставщика. 1Password и BeyondTrust нуждались в журналах Okta, чтобы связать событие в тенанте с файлом поддержки. Поставщик, в свою очередь, зависел от телеметрии клиентов, чтобы обнаружить, какие события поддержки были вредоносными. Доказательства были разделены организационными границами.

В-третьих, клиенты зависели от последовательности уведомлений и устранения последствий Okta. Только Okta могла идентифицировать всех 134 клиентов с доступными файлами, отозвать соответствующие встроенные токены Okta в масштабе, воссоздать широкий отчёт о пользователях поддержки и сказать незатронутым клиентам, что было проверено. Эта концентрация делает скорость ценной для всей клиентской популяции. День, потраченный на обработку каждого сообщения как изолированной проблемы конечной точки, — это не только стоимость поставщика; он продлевает окно неопределённости для каждого тенанта, чьи файлы поддержки могут быть раскрыты.

Во время инцидента не существует простой замены. Замена поставщика идентификации — крупный проект, включающий интеграции приложений, сопоставления групп, правила жизненного цикла, аутентификаторы, процессы службы поддержки и поведение пользователей. Мультипровайдерное переключение может создать собственные проблемы безопасности и согласованности.

Реалистичный противовес — не мгновенная замена вендора, а ограниченная зависимость: независимая телеметрия, локальные полномочия для доступа к высокорисковым приложениям, короткие и контекстуальные сессии администраторов, учётные записи break-glass, не зависящие от того же контура управления, протестированная ротация учётных данных и способность поддерживать критически важные сервисы, пока поставщик идентификации или его канал поддержки находится под расследованием.

Экономика канала эскалации

Сообщение о нарушениях безопасности — это информационный рынок с плохими стимулами. Клиент, видящий одно аномальное административное событие, изначально не может знать, является ли это вредоносным ПО на конечной точке, инсайдером, похищенной сессией браузера, компрометацией поставщика или ложным срабатыванием. Расследование потребляет дефицитное время операторов. Эскалация поставщику может означать повторные встречи и запросы журналов. Выгода от такой настойчивости может достаться в основном другим клиентам, если отчёт выявит общую причину.

Отчёт BeyondTrust — конкретный пример. Компания исключила свои собственные системы, утверждала, что среда поддержки, вероятно, скомпрометирована, запрашивала эскалацию и более подробные журналы и предоставила IP-индикатор. Отчёт Okta приписывает этому индикатору идентификацию ранее не наблюдавшегося событий, связанных со скомпрометированной служебной учётной записью. Частные затраты одного клиента принесли пользу обнаружения для всего провайдера.

Стимулы поставщика также трудны. Объявление кросс-клиентского инцидента слишком рано может создать ненужные ротации, нагрузку на поддержку и репутационный вред. Ожидание определённости может оставить злоумышленника активным и переложить затраты на обнаружение обратно на клиентов. Ответ — не автоматическое публичное раскрытие после любого странного входа. Это градуированная система эскалации, которая может выпускать конфиденциальные предупредительные уведомления, сохранять неопределённость в формулировках и указывать действия, которые клиенты должны предпринять до того, как атрибуция будет окончательной.

Ноябрьская утечка контактного отчёта добавляет ещё один слой. Сам справочник поддержки идентифицировал имена, адреса электронной почты, компании и, в некоторых записях, метаданные о ролях людей, которые, вероятно, имеют привилегированные обязанности идентификации. Даже без паролей это снижает стоимость поиска для злоумышленника. Убедительному звонящему больше не нужно угадывать, кто администрирует платформу идентификации. Okta прямо предупредила, что многие пользователи поддержки являются администраторами и что те же учётные записи использовались для входа в систему поддержки и организацию Okta клиента.

Именно здесь экономика каналов связи при сообщениях о нарушениях встречается с безопасностью идентификации. Контактность необходима: поставщикам нужен надёжный человек для уведомления, а клиентам — надёжное место для сообщения о нарушениях. Но концентрированный контактный справочник — также разведывательные данные. Он должен быть минимизирован, сегментирован, контролироваться и защищаться в соответствии с полномочиями людей, которых он идентифицирует. Уведомление не должно зависеть от одного адреса, раскрытого в том же инциденте.

Организация может поддерживать зарегистрированный контакт по безопасности, отдельно аутентифицированное сообщение на портале и внешний аварийный канал с чёткими правилами проверки того, что сообщение действительно приходит от поставщика.

Эффективный дизайн эскалации поставщика сделал бы пять возможностей наблюдаемыми:

• Маршрут безопасности, независимый от обычной обработки обращений, с полномочиями агрегировать сообщения из разных клиентов.
• Подтверждение получения и признание серьёзности, которое сообщает отправителю, достигло ли обращение операторов реагирования на инциденты.
• Запросы доказательств, сохраняющие идентификаторы объектов, временные метки и полный маршрут доступа, а не только обычный вид обращения.
• Уровень предупредительных уведомлений, который может сказать, что подозревается, что подтверждено и что клиенты должны сохранить или ротировать.
• Итоговое заявление о воздействии, определяющее популяцию, объект данных и уверенность, стоящие за каждой цифрой.

Эти возможности снижают частные затраты на сообщение и увеличивают шансы поставщика найти общий паттерн до того, как третий клиент станет решающим сигналом.

Устранение последствий: что изменилось и что остаётся трудно проверить

В отчёте Okta от 3 ноября перечислены четыре завершённых шага. Компания отключила скомпрометированную служебную учётную запись. Она использовала конфигурацию Chrome Enterprise, чтобы заблокировать сотрудникам вход в личные профили Google на управляемых Okta ноутбуках. Она добавила правила мониторинга и обнаружения для системы поддержки. Она выпустила функцию раннего доступа, привязывающую токены сессий администраторов к сетевому расположению и требующую повторной аутентификации после обнаруженного изменения сети.

Обновление от 29 ноября добавило меры контроля для клиентов. Okta рекомендовала фишинг-устойчивые аутентификаторы для администраторов, привязку сессий администраторов на основе изменения автономной системы и более строгие таймауты консоли администратора. Компания объявила о максимальной сессии по умолчанию в 12 часов и таймауте бездействия в 15 минут с развёртыванием до января 2024 года. Она также призвала клиентов пересмотреть проверку службы поддержки перед сбросом паролей или факторов.

Эти меры направлены на продолжительность воспроизведения и риск социальной инженерии, хотя изменение ASN — это сигнал риска, а не криптографическая привязка к устройству.

Легитимные мобильные или удалённые пользователи могут менять сети, тогда как злоумышленник может найти инфраструктуру в том же сетевом контексте.

8 февраля 2024 года Okta опубликовалауведомление о закрытии расследования. В нём говорилось, что Stroz Friedberg завершила независимое расследование и не нашла доказательств вредоносной активности за пределами предыдущих выводов Okta. Okta заявила, что уведомила регуляторов и правоохранительные органы, предоставила затронутым клиентам индивидуальные отчёты о воздействии, пересмотрела безопасность Центра помощи и изменила подготовку администраторов и хранение данных. Она также указала на нулевые постоянные привилегии для администраторов, MFA с повышением уровня для защищённых действий в консоли администратора, блокировку анонимизаторов через динамические зоны, более широкую привязку IP и ограничения сетевых зон для доступа через API.

Эти меры охватывают несколько уровней:

• Меры контроля триггера: отключение учётной записи и блокировка входа в личные профили.
• Меры контроля обнаружения: новый мониторинг системы поддержки и независимая криминалистическая проверка.
• Меры контроля сессий: сетевая привязка, более короткий срок жизни и повторная аутентификация для защищённых действий.
• Меры контроля привилегий: ограниченное по времени назначение административных ролей.
• Меры контроля подверженности: изменения в подготовке и хранении данных в Центре помощи.
• Меры контроля клиентов: отчёты о воздействии, индикаторы и рекомендации по конфигурации.

Сильнейшие изменения снижают полезные полномочия злоумышленника после кражи секрета. Более короткие сессии, повторная аутентификация для опасных действий, временные роли администраторов и сетевые ограничения API сужают окно. Модель HAR Sanitizer идёт ещё раньше, делая захваченный файл инертным до загрузки. Вместе предотвращение и сдерживание более убедительны, чем единое обещание, что хранилище поддержки безопасно.

Публичная проверка остаётся ограниченной. Okta не опубликовала независимый криминалистический отчёт; она сделала отчёт доступным клиентам и партнёрам. Уведомление о закрытии не раскрывает пересмотренный срок хранения системы поддержки, точную конструкцию аутентификации служебных учётных записей, пороги мониторинга, проверяются ли чувствительные загрузки автоматически или очищаются, как коррелируются все идентификаторы файловых объектов или как быстро высокоуверенные сообщения клиентов должны достигать кросс-клиентской команды по инцидентам.

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

Это не означает, что меры контроля отсутствовали или были неэффективны. Это означает, что внешние читатели могут подтвердить, что Okta заявила о внедрении мер, но не могут независимо оценить конфигурацию или долговечность каждой меры. Зрелая запись подотчётности превратила бы больше таких утверждений в проверяемые доказательства: метрики охвата аудита, инвентаризация служебных учётных записей и политика аутентификации, диапазоны хранения файлов поддержки, учения по времени эскалации, учения по отзыву токенов и red-team тесты альтернативных маршрутов доступа к файлам.

Стандарт контроля для обращений в поддержку идентичности

Инцидент предполагает практический стандарт, который поставщики идентичности и их клиенты могут разделить.

Собирайте меньше полномочий.Создавайте трейсы из учётной записи с наименьшими привилегиями, способной воспроизвести проблему. Предпочитайте тестовый тенант или кратковременную сессию поддержки. Записывайте только окно сбойного запроса. Если cookie-файлы, заголовки авторизации или тела не требуются, удалите их до создания или экспорта файла.

Сделайте очистку локальной и включённой по умолчанию.Клиент должен иметь возможность просмотреть, что будет удалено и какая диагностическая ценность остаётся. Чувствительный экспорт должен требовать явного исключения, объяснения и плана истечения. Портал поддержки должен сканировать распространённые формы учётных данных и отклонять или помещать в карантин рискованную загрузку, а не просто показывать общее предупреждение.

Относитесь к принятым чувствительным файлам как к активным секретам.Если поддержке действительно нужен живой артефакт сессии, рабочий процесс должен устанавливать короткое окно обработки, ограничивать названный персонал, предотвращать массовый просмотр, регистрировать все пути доступа и инициировать отзыв, когда этап обращения завершён. Клиент должен получить квитанцию с идентификацией файла, классом чувствительности, ожидаемым временем удаления и действиями, требуемыми после загрузки.

Коррелируйте объекты, а не события интерфейса.Открыт ли файл из обращения, вкладки «Файлы», отчёта, API или инструмента администратора — телеметрия должна разрешаться в один и тот же базовый объект и клиента. Поиск по безопасности должен охватывать чтения, предпросмотры, экспорты, копии, генерацию отчётов и доступ к метаданным. Размер файла и параметры отчётов должны сохраняться, чтобы исследователь мог воссоздать вывод.

Обнаруживайте полномочия без аутентификации.Руководство Okta по системному журналуобъясняет, как клиенты могут искать по пользователю, IP-адресу и внешнему идентификатору сессии и просматривать события сессий, аутентификации, MFA и восстановления. Урок для клиента — оповещать, когда привилегированные действия появляются без ожидаемой последовательности аутентификации, из новой сети, через необычный клиент или против редко используемой административной функции. Успешная сессия не должна подавлять контроль за тем, что сессия делает.

Привязывайте и перепроверяйте высокорисковые сессии.Сетевой, устройственный и поведенческий контекст может идентифицировать воспроизведение. Защищённые действия должны требовать свежего доказательства. Роли администраторов должны быть временными, где возможно. API-маршруты не должны молча предоставлять менее ограниченную замену маршруту консоли, заблокированному политикой устройств.

Инвентаризируйте каждый секрет в диагностических доказательствах.После раскрытия файла ротируйте не только очевидный cookie Okta, но и API-токены, учётные данные служебных учётных записей, секреты нижестоящих приложений и URL, несущие учётные данные. Более поздний инцидент Cloudflare показывает, что почти полная ротация недостаточно полна, когда пропущенное учётное данное достигает чувствительной системы совместной работы.

Сохраняйте независимые пути восстановления.Поддерживайте доступ break-glass, контакты безопасности поставщика и журналы вне основного пути идентификации. Тестируйте, как критически важные приложения ведут себя, когда центральные сессии идентификации должны быть массово отозваны. Цель — не дублировать всю платформу идентификации, а не допустить, чтобы скомпрометированный поставщик был единственным источником доказательств и восстановления.

Тренируйте маршрут сообщений.Клиенты должны знать, как пометить подозреваемую компрометацию поставщика, а поставщики должны практиковать объединение сообщений, поступающих под разными номерами обращений. Контакт по безопасности — это мера контроля только если он мониторится, аутентифицируется и уполномочен на эскалацию.

Ответственность после завершения сессии

Производственный сервис Okta не был взломан, и публичная запись не поддерживает утверждение, что каждый клиентский тенант был доступен злоумышленнику. Эти ограничения должны оставаться на виду. Как и подтверждённый вред: несанкционированный доступ к файлам поддержки у 134 клиентов, пять перехваченных клиентских сессий, широкий контактный отчёт о пользователях поддержки, затраты клиентов на последующие расследования и ротации и по меньшей мере одно более позднее вторжение, использовавшее учётные данные, которые клиент не выполнил ротацию после первоначальной утечки.

Триггер инцидента был будничным по сравнению с системами, которых он достиг: служебное учётное данное, сохранённое через личный профиль браузера. Его последствия были сформированы архитектурой. Учётное данное открыло репозиторий, содержащий созданные клиентами копии аутентифицированной активности. Журналы репозитория представляли доступ к файлам по-разному в зависимости от маршрута навигации. Активные сессии можно было воспроизводить вдали от администраторов, которые их создали. Клиенты видели аномальные эффекты первыми, тогда как поставщик обладал единственным обзором, способным доказать общую причину.

Это и есть центральный вывод об ответственности. Обеспечение идентичности не может останавливаться на производственном сервисе аутентификации. Оно должно распространяться на каждый операционный процесс, который может собирать, сохранять, воспроизводить, отзывать или объяснять полномочия администратора. Поддержка не находится за пределами границы идентичности, когда её обычный рабочий продукт содержит секреты идентичности.

Более поздние меры контроля Okta закрыли важные части цепочки, и её раскрытие в итоге стало необычно подробным об ошибках расследования. Отчёты клиентов также показали, что многоуровневая политика, независимая телеметрия и быстрый ответ существенно снизили воздействие. Поэтому урок не в том, что облачная идентичность по своей сути ненадёжна, а в том, что концентрированному доверию должны соответствовать концентрированные доказательства, быстрая эскалация и меры контроля сессий, которые остаются сильными после завершения процедуры входа.