Атаката срещу браузърните добавки с мениджъри на пароли, използваща кликджекинг

На конференцията DEF CON 33 е представен метод на атака срещу браузърски добавки, които вмъкват свои елементи на интерфейса в разглежданата страница. Прилагането на атаката към добавки с мениджъри на пароли може да доведе до изтичане на информация, съхранявана в мениджърите на пароли, като данни за удостоверяване, данни за кредитни карти, лични данни и еднократни пароли за двуфакторна автентикация. Проблемът засяга всички тествани мениджъри на пароли, включително 1Password, Bitwarden, LastPass, KeePassXC-Browser, NordPass, ProtonPass и Keeper.

Методът на атака е базиран на факта, че браузърските добавки вмъкват диалог с искане за автоматично попълване на паролата директно на показаната страница, интегрирайки своите елементи в DOM (Document Object Model) на тази страница. Ако атакуващият има възможността да изпълни своя JavaScript код на страницата, например, експлоатирайки XSS уязвимост на сайта, той може да манипулира всички елементи в DOM, включително и добавките на браузъра.

Сред другото, има възможност да се направи диалогът за потвърждение прозрачен и пространствено да се съвпадне бутона в този диалог с бутона на подставен диалог, създаден от атакуващия, който подтиква потребителя да кликне. Като подобни подставени диалози могат да се използват фалшиви искания за права за работа с Cookies, рекламни банери или формуляри с капча. Разполагайки подставен диалог под прозрачен диалог на мениджъра на паролата и съвпадайки местоположението на бутоните на екрана, може да се постигне, че кликът на потребителя ще бъде върху бутона за потвърждение на попълването на данни за удостоверяване в диалога на мениджъра на паролите, докато потребителят ще смята, че е кликнал, например, на бутона за затваряне на прозореца с реклама.

Атаката се състои в следните стъпки:

• Създаване на натрапчив елемент на страницата, който подтиква към клик.
• Добавяне на страницата на уеб форма за вход или попълване на лични данни.
• Излагане на прозрачност за уеб формата („opacity: 0.001“ в CSS).
• Използване на метода focus() за поставяне на фокус върху полето в формата, което активира диалога за автоматично попълване на мениджъра на пароли.
• Търсене на появилия се диалог на мениджъра на паролите в DOM и поставяне на прозрачност за него.
• Очакване на клик от потребителя върху видим елементарен елемент на страницата, който при подходящо комбиниране на видими и невидими елементи ще доведе до натискане на бутона в прозрачен диалог и попълване на полетата от мениджъра на пароли.
• Извличане на данни от попълнена уеб форма и изпращането им на сървъра на атакуващия.

Тъй като автоматичното попълване на параметрите за автентикация в мениджъра на пароли се активира само за сайтове, на които тези параметри са били запазени, за да се организира атака е необходимо да имате възможност да стартирате свой JavaScript код на атакувания сайт или в поддомейн. По този начин, за атаката е необходимо или да получите поддомен в същия домейн, който и атакувания сайт, или да намерите XSS уязвимост на сайта, която да позволява внедряване на вашия код в съдържанието, което се извежда на потребителя.

Отбелязва се, че много потребители използват един и същ мениджър на пароли за съхранение на входни параметри, така и за генериране на еднократни пароли за двуфакторна автентикация, което позволява да се използва разглежданият метод на атака при автоматично попълване на еднократни пароли. Като пример е демонстрирана атака на сайта issuetracker.google.com, съдържащ XSS уязвимост. За получаване на входните параметри и кода за двуфакторна автентикация е достатъчно да се изпрати на потребителя линк, който експлоатира XSS уязвимостта, и да се постигнат три клика чрез поставяне на фалшиви натрапчиви запитвания (разрешение за обработка на бисквитки, разрешение за персонализация и съгласие с политиката за защита на личните данни).

Освен сайтове с XSS уязвимости, атаката може да бъде извършена върху услуги, които предоставят поддомейни на всеки желаещ — повечето мениджъри на пароли по подразбиране автоматично попълват входните параметри не само за основния домейн, но и за поддомените.

Атаката може да се използва и за извеждане на лични данни на потребителя и данни за кредитни карти, съхранени в мениджъра на пароли. В този случай, за изтичане на такива данни не е необходимо изпълнението на JavaScript код в контекста на чужд сайт; достатъчно е да се примамят жертвите на страница в сайта на атакуващия — при случай на лични данни, попълването на уеб формуляри се извършва в зависимост от техния тип (адрес, номер на кредитна карта, имена), без привързване към домейн. Най-опасно е изтичането на параметрите на кредитните карти, тъй като мениджърите на пароли въвеждат не само номера на картата, но и датата на изтичане и код за проверка.

Изследователят, който е открил проблема, е тествал 11 браузърни разширения с мениджъри на пароли, общо с 39.7 милиона активни инсталации, и всички те се оказали незащитени срещу подобни атаки. Някои производители пуснаха актуализации (NordPass 5.13.24, ProtonPass 1.31.6, RoboForm 9.7.6, Dashlane 6.2531.1, Keeper 17.2.0, Enpass 6.11.6, Bitwarden 2025.8.1), в които опитаха да блокират атаката по заобиколен начин. Други разширения (KeePassXC-Browser, 1Password, iCloud Passwords, Enpass, LastPass, LogMeOnce) все още не са получили корекции. За проверка на проявата на уязвимостта в различните мениджъри на пароли е публикуван комплект тестови страници.

Позицията на разработчиците на 1Password, които не пуснаха корекция, е, че уязвимостта е фундаментална и не е пряко свързана с конкретно браузърно разширение, затова опитите за отстраняването й от страна на разширението само блокират отделни вектори на атака, но не решават самия проблем, който трябва да бъде решен в браузъра или с допълнително потвърждение преди автозапълване на полетата. Споменава се, че в 1Password вече се поддържа извеждането на искане за потвърждение преди автозапълване на платежните параметри и в следващото издание ще бъде добавена опция за извеждане на подобно искане за всички типове автозапълвани данни (заради намаляване на удобството на работа такава опция няма да бъде активирана по подразбиране).

Сред предложените от изследователя методи за защита се споменава проследяване на измененията в стиловете на елементите, вмъкнати в страницата, чрез API MutationObserver, блокиране на промените посредством Shadow DOM в режим 'closed', наблюдение на прозрачността на елементите, използване на API Popover за показване на диалози, проверка на наслагването на слоеве, временно деактивиране на обработката на събития с указател (pointer-events:none) във всички плаващи елементи по време на извеждане на диалога на мениджъра на пароли. В същото време за пълно блокиране на описания клас атаките се препоръчва на ниво браузър да се реализира отделен API за защита от кликджекинга.

Като универсален метод за защита в браузерите на базата на движка Chromium, на потребителите се препоръчва да включат режима за потвърждение на достъпа на добавката до сайта (Настройки на добавката → 'site access' → 'on click'), при който добавката получава достъп до сайта единствено след щракане на иконата в дясната част на адресната лента. Като обходен път за защита също така се споменава деактивирането на автоматичното попълване на формуляри и ръчното копиране на пароли чрез буфера на клипборда, но в този случай възниква проблем с изтичането на данни от общия клипборд и риска да не се забележат опити за фишинг.

Източник: opennet.ru