En ciberseguretat sobirana ↑ Aquesta crònica s’inscriu dins l’apartat Digital Security, en la continuïtat de les investigacions realitzades sobre exploits i contramesures de maquinari zero trust.

Què és el clickjacking d’extensions basat en el DOM?

DOM-based extension clickjacking segresta una extensió del navegador (gestor de contrasenyes o wallet) fent un mal ús del Document Object Model. Una pàgina enganyosa encadena iframes invisibles, Shadow DOM i una crida maliciosa a focus() per desencadenar l’autofill en un formulari invisible. L’extensió «creu» que actua sobre el camp correcte i hi aboca secrets — credencials, codis TOTP/HOTP, passkeys, fins i tot claus privades. Com que aquests secrets toquen el DOM, poden ser exfiltrats de manera silenciosa.

Quin nivell de perillositat té?

Aquest vector no és menor: explota la lògica mateixa de l’autofill i actua sense que l’usuari se n’adoni. L’atacant no es limita a superposar un element; força l’extensió a omplir un formulari fals com si res, fent que l’exfiltració sigui indetectable a simple vista.

Flux típic de l’atac

1. Preparació — la pàgina maliciosa integra una iframe invisible i un Shadow DOM que amaga el context real; els camps són ocultats (opacity:0, pointer-events:none).
2. Ham — la víctima clicca un element innocent; redireccions i un focus() maliciós redirigeixen l’esdeveniment cap a un camp controlat per l’atacant.
3. Exfiltració — l’extensió pensa que interactua amb un camp legítim i injecta automàticament credencials, TOTP, passkeys o claus privades al DOM fals; les dades s’exfiltren immediatament.

Aquest mecanisme enganya els senyals visuals, evita proteccions clàssiques (X-Frame-Options, Content-Security-Policy, frame-ancestors) i converteix l’autofill en un canal d’exfiltració invisible. Els overlays tipus Browser-in-the-Browser (BITB) i les manipulacions del Shadow DOM agreugen el risc, fent que les passkeys sincronitzades i les credencials siguin susceptibles de phishing.

Història del Clickjacking (2002–2025)

El clickjacking ha evolucionat durant dècades. El concepte va néixer als primers anys 2000 amb Jeremiah Grossman i Robert Hansen: enganyar un usuari perquè faci clic en un element que no veu realment. Va passar de ser una il·lusió òptica aplicada al codi a una tècnica d’atac habitual (OWASP).

• 2002–2008: Aparició del “UI redressing”: capes HTML i iframes transparents atrapant usuaris.
• 2009: Facebook afectat per likejacking.
• 2010: Aparició del cursorjacking (desplaçar el cursor per enganyar el clic).
• 2012–2015: Exploits via iframes, anuncis maliciosos i malvertising.
• 2016–2019: Tapjacking a mòbils.
• 2020–2024: “Hybrid clickjacking” combinant XSS i phishing.
• 2025: A DEF CON 33, Marek Tóth presenta el salt: DOM-Based Extension Clickjacking, on les extensions injecten formularis invisibles i habiliten exfiltració silenciosa de secrets.

Clickjacking extensions DOM — Anatomia de l’atac

El clickjacking extensions DOM no és una variant trivial: desvia la lògica mateixa dels gestors d’autoemplenament. Aquí, l’atacant no es limita a recobrir un botó amb una iframe; força l’extensió a omplir un formulari fals com si fos legítim.

Desplegament típic d’un atac:

1. Preparació — La pàgina trampa carrega una iframe invisible i un Shadow DOM que oculta el context real.
2. Esquer — L’usuari fa clic en un element aparentment innocu; una crida focus() redirigeix l’esdeveniment cap al camp invisible controlat per l’atacant.
3. Exfiltració — L’extensió creu interactuar amb un camp legítim i injecta identificadors, TOTP, passkeys i fins i tot claus privades directament dins del fals DOM.

Aquesta mecànica distorsiona els senyals visuals, esquiva les defenses clàssiques (X-Frame-Options, CSP, frame-ancestors) i transforma l’autoemplenament en un canal d’exfiltració invisible. A diferència del clickjacking “tradicional”, l’usuari no fa clic en un lloc de tercers: és la seva pròpia extensió la que queda atrapada per la seva confiança en el DOM.

⮞ Resum

L’atac combina iframes invisibles, Shadow DOM i focus() per atrapar els gestors d’autoemplenament. Els gestors de contrasenyes injecten els seus secrets no pas al lloc previst, sinó en un formulari fantasma, oferint a l’atacant accés directe a dades sensibles.

Tecnologies de correcció utilitzades

Des de la divulgació pública a DEF CON 33, els venedors han publicat actualitzacions. No obstant això, la majoria són pegats superficials o comprovacions condicionals; cap fabricant ha re-construït l’enginy d’injecció completament.

Imatge resum: aquestes tecnologies van des de pegats estètics fins a solucions Zero-DOM basades en hardware.

Objectiu

Explicar com els venedors han intentat mitigar la fallada, distingir pegats cosmètics de correccions estructurals i destacar enfocaments sobirans Zero-DOM.

Mètodes observats (agost 2025)

Limitacions observades

• Els pegats no modifiquen l’enginy d’injecció, només el seu disparador.
• No s’ha introduït separació estructural entre UI i fluxos de secrets.
• Qualsevol gestor encara lligat al DOM roman exposat estructuralment.

Anàlisi tècnica i doctrinal de les correccions

DOM extension clickjacking és una fallada de disseny estructural: secrets injectats en un DOM manipulable poden ser segrestats tret que el flux d’injecció quedi separat arquitectònicament del navegador.

Què no solucionen les correccions actuals

• Cap venedor ha re-construït l’enginy d’injecció.
• Les mesures principalment limiten l’activació (desactivar autoemplenament, filtres de subdomini, detecció d’elements invisibles) en lloc de canviar el model d’injecció.

Què requeriria una correcció estructural

• Eliminar la dependència del DOM per a la injecció de secrets.
• Aïllar l’enginy d’injecció fora del navegador (hardware o procés segur separatat).
• Usar autenticació hardware (NFC, PGP, enclausura segura) i exigir validació física/indicació explícita de l’usuari.
• Prohibir per disseny la interacció amb elements invisibles o encapsulats.

Tipologia de correccions

Tests doctrinals per verificar patches

Per comprovar si una correcció és realment estructural, els investigadors poden:

• Injectar un camp invisible (opacity:0) dins d’un iframe i verificar el comportament d’injecció.
• Comprovar si les extensions encara injecten secrets a inputs encapsulats o no visibles.
• Verificar si les accions d’autoemplenament són registrables i bloquejades en cas de desajust de context.

No existeix actualment un estàndard industrial àmpliament adoptat (NIST/OWASP/ISO) que reguli la lògica d’injecció d’extensions, la separació UI/secret o la traçabilitat de les accions d’autoemplenament.

Riscos sistèmics i vectors d’explotació

DOM extension clickjacking no és un bug aïllat; és una fallada de disseny sistèmica. Quan el flux d’injecció d’una extensió queda compromès, l’impacte pot expandir-se més enllà d’una contrasenya filtrada i degradar capes completes d’autenticació i infraestructures.

Escenaris crítics

• Accés persistent — un TOTP clonat o tokens de sessió recuperats poden re-registrar dispositius “de confiança”.
• Reproducció de passkeys — una passkey exfiltrada pot funcionar com un token mestre reutilitzable fora del control habitual.
• Compromís SSO — tokens OAuth/SAML filtrats poden exposar sistemes IT complets.
• Exposició supply-chain — extensions mal regulades creen una superfície d’atac estructural a nivell de navegador.
• Robatori d’actius cripto — extensions de moneder que usen DOM poden filtrar seed phrases i claus privades o signar transaccions malicioses.

Exposició regional i impacte lingüístic — Àmbit anglosaxó (notes)

Insight estratègic: l’espai anglosaxó representa una superfície d’exposició significativa; prioritzar Zero-DOM i mitigacions hardware als fulls de ruta regionals. Fonts: ICLS, Security.org, DataReportal.

Moneders cripto exposats

Les extensions de moneder (MetaMask, Phantom, TrustWallet) sovint utilitzen interaccions amb el DOM; sobreposicions o iframes invisibles poden enganyar l’usuari perquè signi transaccions malicioses o exposi la seed phrase. Vegeu §Sovereign Countermeasures per mitigacions hardware.

SeedNFC HSM — mitigació hardware (concisa)

Contramesura sobirana: SeedNFC HSM ofereix emmagatzematge hardware per claus privades i seed phrases fora del DOM. L’injecció es realitza via canals xifrats NFC↔HID BLE i requereix un desencadenament físic per part de l’usuari, impedint injeccions per redressing o firmes per sobreposició. Vegeu la subsecció técnica de SeedNFC per més detalls d’implementació.

Sandbox vulnerable & Browser-in-the-Browser (BITB)

Els navegadors ofereixen un “sandbox” com a frontera, però el DOM extension clickjacking i les tècniques BITB demostren que les il·lusions d’interfície poden enganyar els usuaris. Un marc d’autenticació fals o una sobreposició poden suplantar proveïdors (Google, Microsoft, bancs) i fer que l’usuari autoritzi accions que alliberen secrets o signen transaccions. Directives com frame-ancestors o certes polítiques CSP no garanteixen bloqueig complet d’aquestes forgeries d’interfície.

Mecanisme de Sandbox URL (tècnic): una solució Zero-DOM robusta lliga cada credencial o referència criptogràfica a una URL esperada (“sandbox URL”) emmagatzemada dins d’un HSM xifrat. Abans d’un autoemplenament o signatura, la URL activa es compara amb la referència de l’HSM; si no coincideixen, el secret no s’allibera. Aquesta validació a nivell d’URL evita exfiltracions encara que les sobreposicions eludeixin la detecció visual.

Detecció i mitigació anti-iframe (tècnic): defenses en temps real inspeccionen i neutralitzen patrons sospitosos d’iframe/overlay (elements invisibles, Shadow DOM anidat, seqüències anòmales de focus(), pointer-events alterats). Les heurístiques inclouen opacitat, context de pila, redireccions de focus i comprovacions d’ancestria d’iframe; la mitigació pot eliminar o aïllar la UI forjada abans de qualsevol interacció.

Per a fluxos d’escriptori, l’enllaç segur entre un dispositiu Android NFC i una aplicació amb HSM permet que els secrets es desxifrin només en RAM volàtil durant una fracció de segon i s’injectin fora del DOM, reduint persistència i exposició en l’host.

BitUnlocker — Atac contra BitLocker via WinRE

Al DEF CON 33 i al Black Hat USA 2025, el grup d’investigació STORM va presentar una explotació crítica contra BitLocker anomenada BitUnlocker. Aquesta tècnica eludeix les proteccions de BitLocker aprofitant falles lògiques en l’entorn de recuperació de Windows (WinRE).

Vectors d’atac

• Parsing de boot.sdi: manipulació del procés de càrrega.
• ReAgent.xml: modificació del fitxer de configuració de recuperació.
• BCD segrestat: explotació de les dades de configuració d’arrencada.

Metodologia

Els investigadors van centrar-se en la cadena d’arrencada i els components de recuperació per:

• Identificar vulnerabilitats lògiques dins de WinRE.
• Desenvolupar exploits capaços d’exfiltrar secrets de BitLocker.
• Proposar contramesures per endurir la seguretat de BitLocker i WinRE.

Impacte estratègic

Aquest atac demostra que fins i tot un sistema de xifrat de disc considerat robust pot ser compromès mitjançant vectors indirectes en la cadena d’arrencada i recuperació. Subratlla la necessitat d’una defensa en profunditat que integri no només la criptografia, sinó també la protecció i la integritat dels entorns d’arrencada i restauració.

Passkeys phishables — Atacs per superposició a DEF CON 33

A DEF CON 33, una demostració independent va mostrar que les passkeys sincronitzades — sovint presentades com a «resistents al phishing» — poden ser exfiltrades silenciosament utilitzant una simple superposició + redirecció. A diferència del clickjacking d’extensions basat en DOM, aquest vector no requereix cap injecció al DOM: abusa de la confiança en la interfície i dels marcs renderitzats pel navegador per enganyar usuaris i capturar credencials sincronitzades.

Com funciona l’atac per superposició (resum)

• Superposició / redirecció: es mostra un marc o una superposició d’autenticació fals que imita una pàgina de login legítima.
• Abús de la confiança del navegador: la UI sembla vàlida, així que els usuaris aproven accions o prompts que alliberen passkeys sincronitzades.
• Exportació sincronitzada: un cop l’atacant accedeix al gestor o al flux sincronitzat, les passkeys i credencials sincronitzades poden ser exportades i reutilitzades.

Sincronitzades vs lligades al dispositiu — diferència clau

• Passkeys sincronitzades: emmagatzemades i replicades via núvol/gestor — còmode però punt únic de fallada i susceptible a atacs d’usurpació d’interfície.
• Passkeys lligades al dispositiu: emmagatzemades en un element segur del dispositiu (hardware) i mai no surten del dispositiu — no són exportables pel núvol i resulten molt més resistents als atacs per superposició.

Proves i evidència

• Demostració d’Allthenticate i repositori viu: yourpasskeyisweak.com.
• Slides i recerca tècnica de DEF CON: Passkeys Pwned — DEF CON 33 (PDF).
• Cobertura de premsa resumint la demostració: MENAFN / PR Newswire.

Passkeys phishables @ DEF CON 33 — Atribució i nota tècnica

Referències:

• yourpasskeyisweak.com
• DEF CON 33 slides (PDF)
• Cobertura de premsa

Senyal estratègic DEF CON 33

DEF CON 33 va cristal·litzar un canvi de supòsits sobre la seguretat del navegador. A continuació, les conclusions concises i orientades a l’acció:

• Els navegadors no són zones de confiança fiables. No tracteu el DOM com un espai segur per secrets.
• Passkeys sincronitzades i secrets injectats al DOM són phisbles. Les tècniques d’overlay poden vèncer credencials sincronitzades.
• Les respostes dels venedors són desiguals; escasses correccions estructurals. Els pegats UI són útils però insuficients.
• Prioritzeu enfocaments hardware Zero-DOM. Fluxos offline i ancoratges hardware redueixen l’exposició i han d’aparèixer als roadmaps.

Contramesures sobiranes (Zero DOM)

Els pegats de venedors redueixen el risc immediat però no eliminen la causa arrel: els secrets que flueixen pel DOM. Zero-DOM significa que els secrets no han de residir, transitar ni dependre del navegador. La defensa duradora és arquitectònica: mantenir credencials, TOTP, passkeys i claus privades dins d’hardware offline i exposar-les breument només en RAM volàtil quan s’activa explícitament.

En disseny Zero-DOM, els secrets s’emmagatzemen en HSMs offline i s’alliberen només després d’una acció física (NFC, HID pair, confirmació local). La desxifració es produeix en RAM volàtil el temps mínim necessari; res no queda en clar al DOM ni al disc.

Aquesta arquitectua elimina la superfície d’injecció en lloc de parchejar-la: sense servidor central, sense contrasenya mestra a extreure i sense text clar persistent al navegador. Les implementacions han d’incloure comprovacions d’URL sandboxed, finestres efímeres de memòria i registres auditable d’activacions per verificar cada operació d’autoemplenament.

PassCypher HSM PGP — Tecnologia Zero-DOM (patentada des de 2015)

Abans de la descoberta pública de DOM extension clickjacking a DEF CON 33, Freemindtronic ja havia adoptat una alternativa arquitectònica: des del 2015 apliquem el principi de no portar mai secrets pel DOM. Aquesta doctrina és la base de l’arquitectura Zero-DOM patentada de PassCypher, que emmagatzema credencials, TOTP/HOTP i claus criptogràfiques en contenidors HSM hardware — mai injectades en un entorn manipulable.

Un avenç en gestors de contrasenyes

• Zero-DOM natiu — cap dada sensible toca el navegador.
• HSM-PGP integrat — contenidors xifrats (AES-256-CBC PGP) amb segmentació de claus patentada.
• Autonomia sobirana — sense servidor, sense base de dades, sense dependències al núvol.

Protecció reforçada BITB

Des del 2020 PassCypher HSM PGP integra EviBITB, un motor que detecta i neutralitza en temps real iframes i overlays maliciosos (Browser-in-the-Browser). Opera serverless i pot funcionar en modes manual, semi-automàtic o automàtic, millorant notablement la resistència contra atacs BITB i clickjacking d’extensions.

Implementació immediata

L’usuari no necessita configuracions complexes: instal·leu l’extensió PassCypher HSM PGP des del Chrome Web Store o l’add-on d’Edge, activeu l’opció BITB i obtindreu protecció Zero-DOM sobirana.

Característiques clau

• Autoemplenament blindat — sempre via sandbox URL, mai en clar dins el navegador.
• EviBITB integrat — destrucció d’iframes i overlays maliciosos en temps real (manual / semi / automàtic).
• Eines criptogràfiques — generació i gestió de claus segmentades (AES-256 + PGP).
• Compatibilitat — funciona amb qualsevol web mitjançant l’extensió; no requereix plugins addicionals.
• Arquitectura sobirana — zero servidor, zero base de dades, zero DOM.

SeedNFC + HID Bluetooth — Injecció segura dels wallets

Les extensions de moneder prosperen en el DOM i els atacants exploten aquesta feblesa. Amb SeedNFC HSM, la lògica canvia: l’enclau mai allibera claus privades o seed phrases. Durant la inicialització o restauració d’un moneder, el sistema usa emulació Bluetooth HID — com un teclat hardware — sense clipboard, sense DOM i sense rastre per a claus privades o credencials.

Flux operatiu (anti-DOM, anti-clipboard):

• Custòdia — SeedNFC HSM xifra i emmagatzema la seed/cla privada (mai l’exporta).
• Activació física — l’usuari autoritza contactless via l’app Android NFC.
• Injecció HID BLE — el sistema tecleja la seed o el fragment necessari directament al camp del moneder, fora del DOM i del clipboard.
• Protecció BITB — l’usuari pot activar EviBITB dins l’app per neutralitzar overlays maliciosos durant l’onboarding o recuperació.
• Efemeritat — la RAM conté temporalment les dades durant l’entrada HID i s’esborra immediatament.

Casos d’ús típics

• Onboarding o recuperació de moneders (MetaMask, Phantom) sense exposar la clau al navegador.
• Operacions sensibles a escriptori amb validació física per part de l’usuari via NFC.
• Còpia de seguretat offline multi-actiu: HSM emmagatzema seed phrases i claus mestres per reutilització sense exportació.

Escenaris d’explotació i vies de mitigació

Les revelacions de DEF CON 33 són una alerta; les amenaces evolucionaran més enllà dels pegats. Cal vigilar els següents escenaris:

• Clickjacking impulsat per IA: LLMs generaran overlays i trampes Shadow DOM en temps real, fent phishing + DOM hijack a gran escala.
• Tapjacking híbrid mòbil: piles d’aplicacions, gestos invisibles i interaccions en segon pla per validar transaccions o exfiltrar OTPs a mòbil.
• HSMs post-quàntics: la mitigació a llarg termini requerirà ancoratges hardware i gestió de claus resistent a ordinadors quàntics — moure el límit de seguretat cap a HSMs certificats i fora del navegador.

Síntesi estratègica

DOM extension clickjacking demostra que navegadors i extensions no són entorns d’execució de confiança per secrets. Els pegats redueixen risc però no eliminen l’exposició estructural.

Camí sobirà — tres prioritats

• Governança: tractar extensions i motors d’autoemplenament com infraestructura crítica — controls de desenvolupament estrictes, auditories obligatòries i normes de divulgació d’incidents.
• Canvi arquitectònic: adoptar dissenys Zero-DOM perquè els secrets no transitin pel navegador; exigir activació física per operacions d’alt valor.
• Resiliència hardware: invertir en ancoratges hardware i en fulls de ruta HSM post-quàntics per eliminar punts únics de fallada en models cloud/sync.

Glossari

• DOM (Document Object Model): estructura interna de la pàgina al navegador.
• Clickjacking: tècnica que enganya l’usuari perquè faci clic en elements ocults o disfressats.
• Shadow DOM: subarbre encapsulat que aïlla components.
• Zero-DOM: arquitectura de seguretat on els secrets mai toquen el DOM, eliminant el risc d’injecció.