A DEF CON 33 konferencián bemutatásra került egy támadási módszer, amely a böngészőbővítmények által az aktuális weboldalra beszúrt kezelőfelületelemeket célozza meg. A támadás alkalmazása jelszókezelők bővítményeire az ilyen programokban tárolt információk, például az autentikációs adatok, hitelkártya adatok, személyes adatok és a kétfaktoros hitelesítéshez használt egyszeri jelszavak kiszivárgásához vezethet. A probléma minden tesztelt jelszókezelőt érint, beleértve az 1Password, Bitwarden, LastPass, KeePassXC-Browser, NordPass, ProtonPass és Keeper alkalmazásokat.
A támadási módszer azon alapul, hogy a böngészőbővítmények közvetlenül az aktuális weboldalra egy jelszó automatikus kitöltésére vonatkozó párbeszédablakot helyeznek, integrálva elemeiket az adott weboldal DOM-jába (Document Object Model). Ha a támadó képes JavaScript kódot végrehajtani az oldalon, például XSS sebezhetőséget kihasználva, akkor manipulálhatja az összes DOM elemet, beleértve a böngészőbővítményeket.
Többek között lehetőség van a megerősítő párbeszédablak áttetszővé tételére, valamint a párbeszédablak gombját egy támadó által létrehozott, hamis párbeszédablak gombjával térben összeilleszteni, amely a felhasználót kattintásra ösztönzi. Ilyen hamis párbeszédablakokként használhatók a süti kezeléséhez szükséges jogosultságok hamis kérdései, reklámok vagy captcha űrlapok. Ha a jelszókezelő párbeszédablakját áttetszővé tesszük, és a gombok elhelyezkedését egybeillesztjük a képernyőn, elérhetjük, hogy a felhasználó kattintása a jelszókezelő párbeszédablakában található autentikációs adatok megerősítésére szolgáló gombra essen, feltéve, hogy a felhasználó azt hiszi, hogy például egy reklámablak bezárására kattintott.
A támadás a következő lépésekből áll:
- Kényszerítő elem létrehozása az oldalon, amely kattintásra ösztönöz.
- Web-űrlap hozzáadása a belépéshez vagy a személyes adatok kitöltéséhez.
- Áttetszőség beállítása az űrlap számára ("opacity: 0.001" a CSS-ben).
- A focus() módszer alkalmazásával a fókusz beállítása az űrlap egy mezőjére, amely aktiválja a jelszókezelő automatikus kitöltés párbeszédablakát.
- A DOM-ban megjelenő jelszókezelő párbeszédablak keresése és áttetszőség beállítása számára.
- A felhasználó kattintásának várakozása egy látható, zavaró elemre az oldalon, amely a látható és láthatatlan elemek megfelelő összekapcsolásával nyomásra készteti a gombot egy átlátszó párbeszédablakban, és kitölti a jelszókezelő által biztosított mezőket.
- Adatok kinyerése a kitöltött webformából és elküldése a támadó szerverére.
Mivel a jelszókezelőben az hitelesítési paraméterek automatikus kitöltése csak azokhoz a webhelyekhez aktiválódik, ahol ezeket a paramétereket korábban elmentették, a támadás megszervezéséhez lehetőség kell, hogy legyen saját JavaScript-kódot futtatni a támadott webhelyen vagy annak egyik alkönyvtárában. Így a támadáshoz vagy ugyanazon a tartományon belül kell alkönyvtárat szerezni, mint a támadott webhely, vagy XSS-sebezhetőséget kell találni a webhelyen, amely lehetővé teszi saját kódunk beillesztését a felhasználónak megjelenített tartalomba.
Megjegyzendő, hogy sok felhasználó egyetlen jelszókezelőt használ belépési paramétereik tárolására és egyszeri jelszavak generálására a kétfaktoros hitelesítéshez, amely lehetővé teszi a vizsgált támadási módszer alkalmazását az egyszeri jelszavak automatikus kitöltésekor. Példaként bemutatásra került a támadás a issuetracker.google.com webhelyen, amely XSS-sebezhetőséget tartalmaz. A belépési paraméterek és a kétfaktoros hitelesítéshez szükséges kód megszerzéséhez elegendő elküldeni a felhasználónak egy, az XSS-sebezhetőséget kihasználó linken keresztül, és három kattintásra kényszeríteni hamis zavaró lekérdezések helyettesítésével (a Cookie-k feldolgozásának engedélyezése, a személyre szabás engedélyezése és a magánélet védelméről szóló irányelv elfogadása).
Az XSS-sebezhetőséggel rendelkező webhelyek mellett a támadások olyan szolgáltatásokra is irányulhatnak, amelyek bárkinek aldomain-eket biztosítanak – a legtöbb jelszókezelő alapértelmezett konfigurációja nemcsak a fő domain, hanem a subdomain-ek belépési paramétereinek automatikus kitöltését is végrehajtja.
A támadás arra is alkalmazható, hogy a jelszókezelőben tárolt felhasználói személyes adatokat és bankkártya-paramétereket meghatározzon. Ehhez nem szükséges JavaScript-kód futtatása másik weboldalon, elég, ha a célpontot az támadó weboldalára csalogatják – a személyes adatok esetében a web-űrlapok kitöltése a típusuk (cím, bankkártya száma, név) alapján történik, anélkül, hogy domain. A legveszélyesebb a bankkártya-paraméterek kiszivárgása, mivel a jelszókezelők nemcsak a kártyaszámot, hanem a lejárati dátumot és a biztonsági kódot is megadják.
A problémát felfedő kutató 11 jelszókezelő böngészőbővítményt tesztelt, összesen 39,7 millió aktív telepítéssel, és mindegyik sebezhető volt az ilyen típusú támadásokkal szemben. Néhány gyártó frissítéseket adott ki (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), amelyek megpróbálták blokkolni a támadás végrehajtását. Más bővítmények (KeePassXC-Browser, 1Password, iCloud Passwords, Enpass, LastPass, LogMeOnce) még nem kaptak javítást. A különböző jelszókezelőkben megjelenő sebezhetőség ellenőrzésére publikáltak egy tesztoldalcsomagot.
A javítást nem kiadó 1Password fejlesztőinek álláspontja szerint a sebezhetőség alapvető és nem közvetlenül kapcsolódik egy adott böngészőbővítményhez, ezért a bővítmény oldalán tett megoldási kísérletek csak egyes támadási vektorokat blokkolnak, de magát a problémát nem szüntetik meg, amit a böngészőben vagy külön megerősítés kérésével kell megoldani az űrlapok automatikus kitöltése előtt. Megemlítik, hogy az 1Password már támogatja a fizetési paraméterek automatikus kitöltése előtti megerősítő kérés megjelenítését, és a következő verzióban lehetőség lesz hasonló kérés megjelenítésére minden automatikusan kitöltött adatfajról (a munkafolyamat kényelmének csökkenése miatt ezt az opciót nem aktiválják alapértelmezés szerint).
A kutató által javasolt védekezési módszerek között szerepel a weboldalon megjelenő elemek stílusának változásainak nyomon követése a MutationObserver API segítségével, a zárt módban működő Shadow DOM-on keresztüli változások blokkolása, az elemek átlátszóságának figyelemmel kísérése, a Popover API alkalmazása dialógusok megjelenítésére, a rétegek átfedésének ellenőrzése, továbbá az eseménykezelés ideiglenes letiltása (pointer-events: none) minden lebegő elem esetében, amikor a jelszókezelő dialógusa megjelenik. E módszerek teljes blokkolásához a támadások függvényében javasolt a böngésző szintjén egy külön API megvalósítása a védelem érdekében. a klikkjacking ellen.
A Chromium alapú böngészők számára univerzális védekezési módszerként ajánlott a bővítmények weboldalhoz való hozzáférése engedélyezésének megerősítési módjának bekapcsolása (Bővítmény beállításai → „site access” → „on click”), amely során a bővítmény csak a címsor jobb oldalán található ikonra kattintás után nyer hozzáférést az oldalhoz. Alternatív védelmi megoldásként említést nyer a űrlapok automatikus kitöltésének letiltása és a jelszavak manuális másolása a vágólapra, azonban ezzel együtt felmerül a közös vágólap adatainak kiszivárgásának problémája és a phishing kísérletek észlelésének veszélye.
Forrás: opennet.ru
