Отчёт Palo Alto Networks Unit 42 о способах обхода passkey вызвал беспокойство у аналитиков, учитывая массовый переход предприятий с паролей на passkey. Однако исследователи подчёркивают: продемонстрированные атаки возможны только после успешного проникновения в систему, а проблемы связаны не столько с дырами в самих passkey, сколько со слабостью процедур вокруг них.
«Исследователи не взломали лежащую в основе криптографию. Они эксплуатировали швы вокруг неё: процессы регистрации, механизмы восстановления и сигналы доверия, которые не проверялись», — говорит Джастин Грайс, генеральный директор консалтинговой фирмы Acceligence. «Это различие важно, потому что оно показывает, где на самом деле находится риск».
Три схемы атаки
В отчёте Palo Alto показаны атаки, которые, по словам компании, «демонстрируют, как вредоносное ПО на скомпрометированном устройстве может злоупотребить процессами регистрации, восстановления и доверия к устройству, чтобы захватить аккаунты, защищённые passkey», а также «как атакующий может пройти аутентификацию без взаимодействия с пользователем, обойти требования проверки пользователя и извлечь все синхронизированные закрытые ключи passkey». Все сценарии объединены под общим названием Pass-ta-key:
- Pass-ta-key — атакующий захватывает аккаунт, защищённый синхронизированным passkey Google, с помощью вредоносного ПО на устройстве жертвы, без повышения привилегий, разблокировки устройства или взаимодействия с пользователем;
- Silver Pass-ta-key — атакующий обманывает Google Cloud Authenticator, заставляя его поверить, что жертва разблокировала устройство биометрией, что ведёт к полному захвату аккаунта без использования устройства жертвы при аутентификации;
- Golden Pass-ta-key — атакующий извлекает все синхронизированные passkey в форме, позволяющей делиться ими или продавать их на чёрном рынке учётных данных.
Аналитики в целом согласны, что обнаруженный изъян значителен, несмотря на допущение, что атакующий уже проник в среду и установил вредоносное ПО. Учитывая, что для проникновения достаточно, чтобы один привилегированный пользователь кликнул по отравленной ссылке или вложению, допущение о предварительном взломе выглядит правдоподобным.
Проблема не в спецификации, а во внедрении
Отчёт говорит не столько об изъянах самих passkey, сколько о недостатке внимания к широкому кругу механизмов вокруг них. В нескольких случаях, отмеченных в отчёте, проблемы возникали «не потому, что стандарт несовершенен, а потому, что внедрения не успели за ним. Это повторяется в безопасности постоянно: спецификация корректна, а экосистема, которая её реализует, неравномерна».
Консультант Брайан Левин из FormerGov советует: «На любом сервисе, где ваша организация является проверяющей стороной, требуйте проверку пользователя и действительно проверяйте флаг user-verified в ответе аутентификации. Исследователи нашли реальные сервисы, принимающие вход без неё, — это тихо превращает многофакторный вход обратно в однофакторный».
Фрэнк Диксон, групповой вице-президент по безопасности в IDC, напоминает, что атака предполагает предварительное успешное проникновение: «Это не взлом passkey из интернета. Это то, что атакующий делает, уже находясь внутри дома. Реальный заголовок такой: “устойчивый к фишингу” перестаёт быть устойчивым в тот момент, когда устройство перестаёт быть чистым». Он советует не относиться к проверке как к опции: «Сделайте её обязательной, проверяйте на сервере каждый раз и приберегите аппаратные ключи, те же YubiKey, для самых важных аккаунтов. Ключ, который никогда не покидает физическое устройство, — это ключ, который никто не сможет массово собрать».
Что делать компаниям
Ор Филькенштейн из Secret Double Octopus считает, что CISO стали беспечны в отношении того, как системы поддерживают passkey: «Стоит посмотреть, как обеспечивается проверка пользователя, как работают регистрация и восстановление, иметь чёткую и соблюдаемую политику в отношении того, синхронизируются ли учётные данные или привязаны к устройству, и иметь какую-то систему ITDR, чтобы быстро смягчать подозрительные устройства и аутентификаторы. В большинстве серьёзных корпоративных сред EDR и управление устройствами снижают вероятность начальных атак, но не закрывают все пути после компрометации».
Дж. Вольфганг Гёрлих из IANS напоминает, что исходная спецификация FIDO2 устранила кражу учётных данных, привязав закрытый ключ к физическому аутентификатору. Синхронизированные passkey вернули портируемость учётных данных и вместе с ней форму риска кражи, описанную в отчёте Palo Alto. «Беспарольная система ровно настолько сильна, насколько силён процесс, который её восстанавливает. Обе серьёзные техники начинаются с принудительной повторной регистрации устройства. Многие команды безопасности никогда не моделировали, не мониторили и не репетировали ответ на это», — говорит он. Его совет — требовать аутентификаторы, привязанные к устройству (аппаратные токены или компьютеры) для всего привилегированного и чувствительного доступа, а для менее рискованного можно допускать кошельки, хотя «подобно тому, как пароли в веб-браузерах давно находятся под риском, passkey в браузерах теперь стоит считать неприемлемым риском».
Источник: csoonline.com