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

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

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

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

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

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

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

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

Освен сайтове с 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