Ключовете за достъп (passkeys) – модерната алтернатива на паролите има за цел да предпазва потребителите от фишинг – те не могат да бъдат споделяни, откраднати или случайно разкрити. Въпреки това зловреден софтуер на устройството може да ги използва, без изобщо да се налага въвеждане на ПИН код, биометрични данни или друг метод за отключване, като по този начин се заобикаля многофакторната автентификация.

Изследователите от Unit 42 на Palo Alto предупреждават за нови атаки, които се очаква да засегнат потребителите на passkeys. Хакерите могат да злоупотребят с ключовете за достъп, за да компрометират всички идентификационни данни на жертвата в синхронизираната екосистема на Google за ключове за достъп, без изобщо да задействат истинска двуфакторна авторизация (2FA), като биометрични данни или ПИН код.

Изследователите разработиха 3 отделни атаки за превземане на акаунти, като най-тежката от тях води до пълно извличане на всички синхронизирани пароли на жертвата. Има обаче едно важно условие – на устройството трябва да има зловреден софтуер. Това обаче често е лесно постижимо чрез автоматизирани фишинг атаки, като например добре известната ClickFix.

„Непробиваемите“ ключове за достъп на Google могат лесно да бъдат откраднати с помощта на обикновен зловреден софтуер

„Нападателят поема контрола над акаунт, защитен с passkey, синхронизиран с Google, като използва зловреден софтуер, изпълняван на устройството на жертвата, без да се налага повишаване на привилегиите, отключване на устройството или взаимодействие с потребителя.“

предупреждава Unit 42 в новия си доклад

За зловредния софтуер е също толкова лесно да открадне всички пароли, съхранени на компютъра на жертвата, но в такъв случай от жертвата обикновено се изисква да потвърди автентификацията чрез метод за двуфакторна автентификация (2FA), често от отделно устройство като смартфон, което означава, че хакерите не биха придобили незабавно пълен контрол над акаунта. При ключовете за достъп нещата стоят по-различно – много услуги просто се им доверяват и не проверяват дали изобщо е извършена втората проверка.

Как работи атаката?

Атаката се фокусира конкретно върху широко използваната от Google реализация на синхронизираните ключове за достъп. Зловредният софтуер, изпълняван на даденото устройство, може лесно да получи информация за това как се използват ключовете за достъп в акаунта на жертвата.

„Chrome съхранява локално данните за синхронизираните passkeys като част от своя процес на синхронизация.“

обясняват изследователите от Unit 42

Достъпът до тези записи не изисква повишени привилегии. Така атакуващият веднага може да види къде жертвата използва паролите, заедно със свързаните с тях потребителски имена, идентификатори на удостоверенията и криптирания частен ключ.

Google генерира и съхранява самите ключове за достъп в изолирана облачна среда от типа „enclave“, от която те никога не излизат. Устройствата на потребителите получават достъп до тях чрез 2 хардуерно подкрепени (TPM/Secure Enclave) ключа, съхранени на устройството. Когато потребителят влезе в услугата, биометричните данни или ПИН кодът отключват първия ключ – ключът за потребителска верификация (UV). Вторият ключ – ключът за идентичност (ID) доказва, че заявката идва от истинското устройство. И двата ключа се изпращат към облачния автентификатор на Google, който ги проверява и влиза в профила на потребителя, като използва правилния ключ за достъп.

Единственото нещо, което пречи на зловредния софтуер да използва директно двата най-важни ключа е, че те се намират в TPM чипа и никога не напускат чипа в използваема форма, затова зловредният софтуер трябва да поиска от TPM да подписва нещата от негово име. Ключът за идентификация се получава лесно: зловредният софтуер може безпроблемно да генерира ID подписа, като имитира действията на Chrome.

„Chrome създава условия, които му позволяват да поиска подпис, докато работи като потребител без повишени привилегии и без да задейства защитите за отключване на устройството.“

пишат изследователите

При първата атака, наречена Pass-ta-key, изследователите изобщо не са използвали UV ключа. Те инициираха влизане в неуточнена уеб услуга и изпълниха проверката, като просто извличаха ID ключа и го представяха на Google Cloud Authenticator. Подписът от TPM на жертвата беше всичко, което беше необходимо, за да се компрометира онлайн акаунтът.

„Непробиваемите“ ключове за достъп на Google могат лесно да бъдат откраднати с помощта на обикновен зловреден софтуер Постигане на пълно компрометиране

Изследователите отидоха още по-далеч и демонстрираха, че UV ключът също може да бъде хакнат, което води до пълно компрометиране, дори когато се прилагат по-строги изисквания за автентификация.

Втората атака се основава на заблуждаването на Google Cloud Authenticator, като го кара да повярва, че потребителят е отключил устройството си. Вместо да проверява лицето на потребителя, за да получи автентичния UV подпис, зловредният софтуер може просто да принуди устройството да се регистрира отново в Google, като използва командата „device/forget“, което прави съществуващия UV ключ невалиден. Зловредният софтуер създава фалшив нов UV ключ, а Google Cloud Authenticator го приема и регистрира устройството, без да проверява дали е подписан от автентичен хардуерен чип. Тази атака отключва много изключително чувствителни акаунти, включително такива в банкови и федерални системи.

Третата атака е дори по-опасна. Тя позволява на хакерите да откраднат и декриптират всички пароли, синхронизирани с Google.

Google защитава паролите с „главeн ключ“, известен като „тайна на домейна за сигурност“ (SDS), до който няма пряк достъп. Потребителите съхраняват криптирана версия на този ключ, но само облачната услуга на Google може да я декриптира. Ако хакер успее да се сдобие със SDS, той на практика придобива възможността да декриптира всички синхронизирани пароли за този акаунт. Това му позволява да се идентифицира като напълно верифициран потребител и да поеме контрола върху всяка услуга, при която жертвата разчита на пароли. Но как изследователите са се сдобили с SDS? Той неочаквано е бил открит в логовете на Chrome. Най-секретният ключ е бил открит като изтекъл в обикновен текст по време на първоначалната настройка на устройството.

Google премахна тази информация от логовете на Chrome след доклада на Unit 42, но изследователите предупреждават, че SDS все още се изпраща към клиента и остава достъпен в паметта на процеса на Chrome като част от процедурата за възстановяване. Тази уязвимост в SDS все още може да бъде използвана за кражба на синхронизирани пароли.

В крайна сметка макар ключовете да затрудняват някои атаки за кражба на акаунти, те не елиминират риска – атакуващите вероятно ще се преориентират към тези нови, възникващи техники. Основното заключение е, че компрометирането на крайните точки остава критична част от модела на заплахите, се посочва в изследването.