Rünnak brauserilaienditele, mis kasutavad paroolihaldureid, rakendades clickjacking-tehnikat.

DEF CON 33 konverentsil esitati rünnakumeetod brauserilaienditele, mis lisavad oma kasutajaliidese elemendid vaadatavale lehele. Rünnaku rakendamine paroolihalduritega võib viia salvestatud teabe, nagu autentimisandmed, krediitkaardi üksikasjad, isikuandmed ja ühekordsed paroolid kahefaktorilise autentimise jaoks, lekke tekkimisele. Probleem puudutab kõiki testitud paroolihaldureid, sealhulgas 1Password, Bitwarden, LastPass, KeePassXC-Browser, NordPass, ProtonPass ja Keeper.

Rünnakumeetod põhineb sel, et brauserilaiendid lisavad parooli automaatse täitmise nõudega dialooge otse näidatavale lehele, integreerides oma elemendid selle lehe DOM-i (Document Object Model). Kui ründajal on võimalus käivitada oma JavaScripti kood lehel, näiteks XSS-haavatavuse ärakasutamise kaudu, siis saab ta manipuleerida kõigi DOM-i elementidega, sealhulgas brauserilaienditega.

Lisaks on võimalus muuta kinnituse dialoog läbipaistvaks ja ruumiliselt sobitada nupud selle dialooge nupu, mille ründaja on loonud ja mis kutsub kasutajat klikkima. Sellisteks vale dialoogideks võivad olla vale Cookie'i õiguste nõudmised, reklaambännerid või CAPTCHA vormid. Asetades vale dialooge parooli halduri läbipaistva dialooge alla ja sobitades nuppude asukohad ekraanil, on võimalik saavutada, et kasutaja klikib parooli halduri dialooge autentimise parameetrite kinnitamiseks, kuigi kasutaja arvab, et klikkis näiteks reklaamivenna sulgemisnupule.

Rünnak koosneb järgmistest sammudest:

• Lehe peale pealetükkiva elemendi loomine, et stimuleerida klikkimist.
• Lehe peale sisenemise või isikuandmete täitmise veebivormi lisamine.
• Veebivormi läbipaistvuse seadmine („opacity: 0.001” CSS-is).
• focus() meetodi kasutamine, et keskenduda sisestusvälja vormis, mis käivitab parooli halduri automaatse täitmise dialooge.
• Parooli halduri dialooge otsimine DOM-is ja selle läbipaistvuse seadmine.
• Ootamine, et kasutaja klikib nähtavale pealetükkivale elemendile leheküljel, mis õigesti nähtavate ja nähtamatute elementide ühendamisel viib nupu vajutamiseni läbipaistvas dialoogis ning paroolihalduri väljade täitmiseni.
• Andmete väljapakkumine täidetud veebivormist ja nende edastamine ründaja serverisse.

Kuna paroolihalduri autentimisparameetrite automaatne täitmine aktiveeritakse ainult saidile, kus need parameetrid on salvestatud, on rünnaku korraldamiseks vajalik käivitada oma JavaScript-kood rünnataval saidil või selle alamdomeenil. Seega on rünnaku teostamiseks vajalik saada alamdomeen samast domeenist, mis rünnatav sait, või leida saidilt XSS-haavatavus, mis võimaldab oma koodi kasutaja nähtavasse sisu sisestada.

On märgatud, et paljud kasutajad kasutavad ühte paroolihaldurit nii sisselogimisparameetrite salvestamiseks kui ka ühekordsete paroolide genereerimiseks kahefaktorilise autentimise jaoks, mis võimaldab arutletud rünnakumeetodi kasutamist ühekordsete paroolide automaatse täitmise korral. Näitena demonstreeritakse rünnakut veebisaidile issuetracker.google.com, millel on XSS-haavatavus. Sisselogimisparameetrite ja kahefaktorilise autentimise koodi saamiseks piisab kasutajale lingi saatmisest, mis kasutab ära XSS-haavatavust, ja kolme kliki saavutamisest valepealetükkivate päringute kaudu (küpsiste töötlemise lubamine, isikupärastamise lubamine ja privaatsuspoliitika nõusoleku andmine).

Lisaks XSS-haavatavustega saitidele saab rünnakut teostada teenuste suhtes, mis pakuvad kõigile soovi korral alamdomeene — enamik paroolihaldureid täidab vaikimisi sisselogimisparameetreid mitte ainult põhidomeeni, vaid ka alamdomeenide jaoks.

Rünnakut saab kasutada ka kasutaja paroolihalduri salvestatud isikuandmete ja krediitkaardi andmete tuvastamiseks. Sellisel juhul ei ole sarnaste andmete lekimiseks vajalik JavaScripti koodi täitmine ründava saidi kontekstis; piisab, kui meelitada ohver ründaja saidi lehele – isikuandmete puhul toimub veebivormide täitmine nende tüübi (aadress, krediitkaardi number, nimi) alusel, ilma sidumata. domeenigaKõige ohtlikum on krediitkaardi andmete lekke võimalus, kuna paroolihaldurid sisestavad mitte ainult kaardi numbri, vaid ka kehtivusaja ja kontrollkoodi.

Probleemi avastanud uurija testis 11 paroolihalduri brauserilaiendit, millel kokku oli 39,7 miljonit aktiivset paigaldust, ja kõik need osutusid sellesuguste rünnakute vastu kaitsetuks. Mõned tootjad on välja andnud uuendusi (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), mille kaudu püütakse rünnaku teostamine blokeerida. Teised laiendused (KeePassXC-Browser, 1Password, iCloud Passwords, Enpass, LastPass, LogMeOnce) jäävad endiselt parandamata. Tõrke tuvastamiseks erinevates paroolihaldurites on avaldatud proovilehede komplekt.

1Passwordi arendajate seisukoht, kes ei ole parandust välja andnud, on see, et haavatavus on fundamentaalne ja ei ole otseselt seotud konkreetse brauserilaiendiga; seetõttu blokeerivad paranduse katsed ainult üksikute rünnaku vektorite kõrvaldamise, kuid ei lahenda tegelikku probleemi, mida tuleks lahendada brauseris või nõudmisega eraldi kinnituse saamiseks enne automaatset väljade täitmist. Mainitakse, et 1Password toetab juba kinnituse taotlemise väljastamist enne maksetingimuste automaatset täitmist ja järgmises väljalaskes lisatakse valik sellise taotlemise kuvamiseks kõigi automaatselt täidetavate andmete tüüpide jaoks (minimaalset mugavust arvestades ei aktiveerita sellist võimalust vaikimisi).

Uuringu autoriga pakutud kaitsemeetodite seas mainitakse lehe elementide stiilimuutuste jälgimist API MutationObserver abil, lukustades muudatused läbi Shadow DOM „closed” režiimis, elementide läbipaistvuse jälgimist, API Popover kasutamist dialoogide kuvamiseks, kihtide kattuvuse kontrollimist, samuti kõigi rippmenüü elementide osutiga sündmuste töötlemise ajutist keelamist (pointer-events:none) parooli halduri dialooge esitades. Seejuures on täieliku blokeerimise saavutamiseks vajalik. rünnakute vastu soovitatakse rakendada eraldi API tasemel brauserit. klikkide jälgimise vastu.

Universaalse kaitsemeetodina Chromiumi mootoril põhinevates brauserites soovitatakse kasutajatel lubada lisandmooduli saidi juurdepääsu kinnitamise režiim (Lisa seaded → „saidile juurdepääs” → „kliki pealt”), mille käigus saab lisandmoodul saidile juurdepääsu ainult pärast ikoonile klikkimist aadressiriba paremal pool. Kaitse möödaminnes mainitakse ka vormide automaatse täitmise keelamist ja paroolide käsitsi kopeerimist lõikelauale, kuid sellega kaasneb oht andmete lekitamiseks ühisele lõikelauale ning tõenäosus mitte märgata kalavarustust.

Allikas: opennet.ru