Содержание
У Google Password Manager нашли три сценария атаки на passkeys — ключи доступа, которые обычно защищают вход PIN-кодом, отпечатком или Face ID. Исследователи Palo Alto Networks Unit 42 назвали техники Pass-ta-key, Silver Pass-ta-key и Golden Pass-ta-key.
Звучит неприятно, но паниковать рано. Все три сценария требуют, чтобы устройство жертвы уже заразили вредоносным ПО. А если на компьютере сидит malware, проблема давно вышла за рамки одного менеджера паролей.
Атака требует зараженного устройства
Unit 42 описала не удаленный взлом аккаунта из воздуха, а цепочку после заражения компьютера. Вредоносное ПО уже должно работать на машине жертвы и иметь доступ к процессам, через которые браузер и менеджер паролей обрабатывают ключи доступа.
Это важная разница. Passkeys задумали как замену паролям: сервис хранит не ваш секрет, а проверяет криптографическое подтверждение. Обычно вход нужно подтвердить локально — PIN-кодом, биометрией или системной защитой устройства.
В найденных сценариях исследователи смогли обойти эту привычную границу доверия. Не потому, что passkeys «сломались» как идея. Проблема оказалась в том, как отдельные сервисы и синхронизация Google обрабатывали доверенное устройство.
Три техники Pass-ta-key отличаются уровнем риска
В первой технике атакующий с помощью malware выдавал себя за владельца устройства. Google получал запрос на вход так, будто его инициировал сам пользователь, а сервис не всегда требовал дополнительное подтверждение PIN-кодом или биометрией.
Метод сработал не везде. Unit 42 не смогла повторить атаку на GitHub, но добилась входа на eBay. После раскрытия проблемы eBay закрыл уязвимость на своей стороне.
- Pass-ta-key: злоумышленник имитирует действия владельца на уже зараженном устройстве.
- Silver Pass-ta-key: исследователи заставили Google доверять устройству атакующего, без постоянной опоры на компьютер жертвы.
- Golden Pass-ta-key: malware получал главный секрет синхронизации, который защищает сохраненные passkeys.
Третий вариант выглядит самым неприятным. Google Password Manager синхронизирует passkeys между устройствами и использует для этого master secret. Unit 42 выяснила, что при некоторых условиях malware может перехватить этот секрет в момент, когда Chrome временно с ним работает.
После этого атакующий мог скопировать синхронизированные ключи доступа на другой компьютер и использовать их позже. Это уже не разовая сессия на зараженной машине, а перенос доверия на сторону злоумышленника.
Google закрыл часть проблем после раскрытия
Исследователи передали данные Google до публичного описания атак. Компания уже внедрила часть исправлений, а отдельные сервисы, включая eBay, закрыли уязвимые места самостоятельно.
При этом полной публичной точки пока нет. Google не дал отдельный комментарий и не подтвердил, что закрыл все найденные сценарии. Детали исследования также пересказал BleepingComputer.
Для пользователей главный вывод простой, но не в формате инструкции. Passkeys остаются сильнее обычных паролей против фишинга, но не спасают компьютер, на котором уже работает вредоносное ПО. Unit 42 прямо указывает на это ограничение: все три атаки начинались с предварительного заражения устройства.
Google уже выпустил исправления после раскрытия, eBay закрыл свою уязвимость, а GitHub в тестах Unit 42 не поддался первому сценарию Pass-ta-key. Google пока не подтвердил, что устранил все три класса проблем.
