Дослідник розробив експлойт, який перехоплює автентифікацію через ключі допуску. Експлойт залежить від нетривіальної комбінації наявних умов. Ні самі ключі допуску, ні протокол не виявилися уразливими.
На цьогорічній конференції DEF CON у Лас-Вегасі дослідник кібербезпеки Марек Тот продемонстрував, як зловмисники можуть використовувати атаку clickjack для приховано запуску та перехоплення церемонії автентифікації на основі ключів допуску, — пише ZDNET.
У широкому розумінні це історія про те, як менеджери паролів можуть бути обмануті для розкриття інформації для входу — чи то традиційних облікових даних, таких як ідентифікатори користувачів та паролі, чи артефактів, пов’язаних із ключами допуску — зловмисним акторам.
Чи винні менеджери паролів? Тот — дослідник, який виявив експлойт — припускає, що так, але відповідь складніша.
Повний захист будь-якого автоматизованого процесу неминуче є результатом багаторівневої безпеки. У переважній більшості випадків використання, де цифрова безпека має значення, майже ніколи не існує єдиної “срібної кулі”, яка відбиває хакерів. Залежно від рівнів технологій, які поєднуються для завершення робочого процесу (наприклад, вхід на веб-сайт), відповідальність за безпеку цього процесу розподіляється між сторонами, які контролюють кожен із цих рівнів.
Так, менеджери паролів є одним рівнем у зупинці експлойту. Але оператори веб-сайтів та кінцеві користувачі — сторони, які контролюють інші рівні — повинні бути дуже необачними щодо безпеки заради зручності, щоб експлойт спрацював. Немає сенсу шукати винних. Усі сторони на кожному рівні повинні вжити заходів безпеки.
Основні ідеї ключів допуску
Щоліта індустрія кібербезпеки збирається в Лас-Вегасі на послідовні конференції Black Hat та DEF CON, де дослідники безпеки по черзі представляють свої “великі розкриття”. Протягом року, що передує заходу, ці дослідники працюють над виявленням нових, незареєстрованих уразливостей. Чим більша уразливість і чим більше користувачів постраждало, тим більша увага (і, можливо, фінансова винагорода) чекає дослідника.
Цього року кілька дослідників оголосили про низку проблем, які поставили під сумнів передбачувану перевагу ключів допуску як облікових даних для входу.
На Cybercalm ми багато писали про ключі допуску та про те, чому з точки зору безпеки та технічної перспективи вони набагато кращі за ідентифікатори користувачів та паролі (навіть коли задіяні додаткові фактори автентифікації).
Три основні ідеї ключів допуску:
- Їх неможливо вгадати так, як часто можна вгадати паролі
- Один і той самий ключ допуску не може бути повторно використаний на різних веб-сайтах та програмах (як це можливо з паролями)
- Вас не можуть обманути, щоб ви розкрили свої ключі допуску зловмисникам (як це можливо з паролями)
На жаль, незважаючи на їх перевагу, досвід користування ключами допуску настільки сильно відрізняється від одного веб-сайту та програми до іншої, що ключі допуску ризикують бути глобально відхилені користувачами. Незважаючи на ці бар’єри для впровадження, і в ім’я максимального захисту себе (часто від себе), моя рекомендація залишається: користуйтесь ключами допуску, коли це можливо.
Суть атаки
Хоча експлойт відбувається миттєво, він включає складний набір взаємодій та передумов, які разом створюють серію нетривіальних перешкод для шансів зловмисника на успіх. По суті, експлойт Тота ніколи не краде ключ допуску користувача (одна з основних засад ключів допуску полягає в тому, що їх неможливо вкрасти). Але він по суті краде найкращу альтернативу.
У той момент, коли користувача обманом змушують ненавмисно автентифікуватися на веб-сайті з ключем допуску, експлойт перехоплює пакет інформації, який було виготовлено менеджером паролів користувача за допомогою його ключа допуску до цього сайту. Цей пакет називається PublicKeyCredential, і він схожий на одноразовий “золотий квиток”, який містить все необхідне для входу користувача в свій обліковий запис на легітимному веб-сайті. Як тільки зловмисник отримує цей “золотий квиток”, його можна використати для входу системи зловмисника в обліковий запис жертви, ніби система зловмисника є системою жертви.
І саме це робить цей експлойт.
Після завантаження шкідливого ПЗ в браузер жертви, експлойт — зловмисний міжсайтовий скрипт (XSS) — перехоплює той “золотий квиток” і замість того, щоб представити його для входу на легітимний сайт (як зазвичай робить браузер користувача на запит менеджера паролів), відправляє його на веб-сайт зловмисника. Потім, з цим “золотим квитком” в руках, зловмисник подає той самий квиток зі своєї системи на легітимний веб-сайт, фактично входячи системою зловмисника в обліковий запис користувача на легітимному веб-сайті.
Хто винен?
Але як зазначалося раніше, відкриття Тота залежить від попереднього існування кількох умов, що стосуються веб-сайту, вибору менеджера паролів користувачем, налаштувань цього менеджера паролів та вибору технології оператором веб-сайту для додавання можливості автентифікації з ключем допуску.
Хоча Тот вказує пальцем на менеджери паролів, я вважаю, що оператор веб-сайту був би здебільшого винним, якби справжній зловмисник використав цей експлойт у реальному світі.
Існує два налаштування, які зупиняють атаку і про які повинен знати кожен професійний оператор веб-сайту:
Прив’язка до сесії: коли веб-сервер налаштований на включення спеціального заголовка під час спроби користувача автентифікуватися з ключем допуску, він постійно прив’язує виклик до певного ідентифікатора сесії. Це робиться за допомогою параметра set-cookie:
Set-Cookie: session_id=123456789abcdefg; HttpOnly
Коли параметр HttpOnly включений, ідентифікатор сесії стає невидимим для будь-якого JavaScript — легітимного чи зловмисного. В результаті, навіть якби зловмисний JavaScript переслав перехоплений “золотий квиток” системі зловмисника, він був би безкорисним без відсутнього ідентифікатора сесії.
Цю “прив’язку до сесії” автентифікаційної розмови між веб-сайтом та браузером кінцевого користувача протягом віків вважають основною лінією захисту від такої атаки. Нездатність оператора веб-сайту захистити свої процеси автентифікації за допомогою цієї простої, добре відомої найкращої практики була б розглянута більшістю професіоналів кібербезпеки як вкрай недбала.
Рівні захисту
Але припустімо, як це робить Тот, що оператор веб-сайту катастрофічно проігнорував одну з найважливіших і найвідоміших технік захисту робочого процесу автентифікації. Експлойт Тота все ще включає деякі інші нетривіальні передумови.
Шкідливий скрипт: перша з них включає встановлення шкідливого скрипта в ваш веб-браузер. Тот зазначає, що сайти, які включають значну кількість контенту, створеного користувачами, є улюбленою мішенню зловмисників, оскільки вони можуть додавати скрипти до публікації чи відгуку.
Clickjack-атака: припускаючи, що користувач натрапляє на такий сайт і завантажує шкідливий скрипт у свій браузер, скрипт повинен приховано обманути користувача, щоб він ненавмисно запустив процедуру автентифікації.
Як випливає з фрази, clickjack-атака відбувається, коли зловмисник обманює вас, щоб ви натиснули на елемент, який може бути для вас невидимим. У експлойті Тота зловмисний JavaScript малює вікно браузера з начебто невинним діалогом, як реклама чи форма згоди на cookies — те, що ми бачимо постійно і просто хочемо прибрати з екрана. Однак коли ми натискаємо на цей елемент, щоб позбутися його, ми насправді не усвідомлюємо, що натискаємо на щось інше, що було приховано за ним.
Плюси та мінуси додаткових запитів
Коли прихильники описують ключі допуску як більш безпечні за традиційні облікові дані, вони часто говорять про те, як процес ключа допуску такий же простий, як вхід у телефон за допомогою біометричних даних або PIN-коду.
Однак це головним чином стосується випадків, коли ваш менеджер паролів також налаштований вимагати біометричні дані або PIN для кожної спроби автентифікації. Оскільки деякі користувачі не хочуть, щоб їх турбували цим додатковим рівнем безпеки кожного разу, коли вони входять на веб-сайт, більшість менеджерів паролів дають користувачам можливість пом’якшити це нагадування.
Пригадайте, що експлойт Тота залежить від того, щоб користувача обманом змусили ненавмисно автентифікуватися з веб-сайтом. Якщо ваш менеджер паролів налаштований, як мій — вимагати PIN або біометричні дані для дозволу будь-якої церемонії автентифікації — ви миттєво зрозумієте, що щось не так.
Ядерна опція
Однак навіть коли користувачі нехтують захистом своїх систем, оператори веб-сайтів мають спеціальну “ядерну опцію” в своєму розпорядженні.
Коли сторона, яка покладається на автентифікацію, надсилає згаданий вище виклик менеджеру паролів як частину пакета PublicKeyCredentialRequestOptions, вона також може включити спеціальний прапор під назвою параметр userVerification. Цей параметр допускає три можливі налаштування: Discouraged (Не рекомендується), Preferred (Бажано) та Required (Обов’язково).
Якщо сторона встановлює прапор userVerification на “Required”, менеджер паролів зобов’язаний запитати у користувача біометричні дані, PIN або пароль незалежно від того, як користувач налаштував цей менеджер паролів. Іншими словами, оператор веб-сайту має спосіб примусити користувача отримати запит таким чином, щоб це попередило його про неочікувану поведінку веб-сайту.
Покращення з боку менеджерів паролів
Щоб ваш менеджер паролів робив те, що він робить, ви повинні надати йому такі дозволи, які ви практично ніколи не повинні давати жодному іншому розширенню веб-браузера. Ваш менеджер паролів може не тільки читати весь контент кожної веб-сторінки, яку ви відвідуєте, але й модифікувати його. І завдяки цим дозволам ваш менеджер паролів також може виявити ознаки clickjack-атаки в процесі.
Не дивно, що оновлені версії їхнього програмного забезпечення розробляються або вже випущені:
- Bitwarden впровадив заходи протидії цьому класу атак у найновіших релізах минулого тижня
- 1Password випустив версію 8.11.7 20 серпня 2025 року, яка додає можливість для користувачів отримувати сповіщення та схвалювати або відхиляти дії автозаповнення
- NordPass тепер рендерить іконки з найвищим z-index, запобігаючи накладенню чого-небудь поверх них
- LastPass також посилив свій захист від потенційних clickjack-атак
Висновки
Незважаючи на потенціал для зловмисника перехопити церемонію автентифікації з ключем допуску після виконання нетривіальних передумов, експлойт Тота надає додаткові докази того, що ключі допуску більш безпечні за традиційні облікові дані.
Прив’язка до сесії робить одноразовий “золотий квиток”, згенерований ключем допуску, непридатним для використання із системи зловмисника. Однак це нічого не робить для зупинки вилучення зловмисником ідентифікатора та пароля користувача, коли clickjack-атака Тота стикається зі спробою автентифікації з цими традиційними обліковими даними порівняно з більш чутливими до часу та безпечними ключами допуску.
