Secuestro de WalletConnect: drenaje después de la desconexión

— By Boni in Tutorials

Secuestro de WalletConnect: drenaje después de la desconexión

La ilusión de cerrar sesión. Descubra cómo el secuestro de sesiones de WalletConnect permite que plataformas maliciosas mantengan conexiones en segundo plano y agoten activos después de que usted se desconecte.



Comprenda cómo las dApps maliciosas siguen drenando después de desconectarse

  • La arquitectura financiera Web3 opera sobre un límite estructural fundamental entre la identidad del usuario y la ejecución descentralizada. A diferencia de los entornos de Internet heredados del pasado, las aplicaciones descentralizadas (dApps) no alojan, controlan ni administran los datos de su cuenta personal, sus saldos financieros ni sus claves criptográficas privadas. En cambio, los protocolos actúan como motores de solicitudes de ejecución, pasando paquetes de datos estructurales complejos a un marco de billetera independiente y sin custodia donde el usuario conserva la autoridad exclusiva y soberana para autorizar o rechazar cambios de estado. 
  • Este diseño desacoplado transformó significativamente la seguridad del usuario, permitiendo a los participantes explorar granjas de rendimiento, capas de participación líquida e intercambios de activos sin exponer sus frases iniciales privadas directamente a servidores web externos.
  • En la interfaz de este ecosistema de múltiples cadenas se encuentra WalletConnect, un protocolo de comunicaciones de código abierto ampliamente integrado. WalletConnect establece una mensajería cifrada segura de extremo a extremo puente entre aplicaciones descentralizadas y billeteras móviles o de escritorio, lo que permite un enrutamiento fluido de transacciones a través de redes de retransmisión descentralizadas.
  • Sin embargo, esta interfaz sin fricciones ha introducido un importante punto ciego de seguridad profundamente arraigado en la psicología del usuario y los supuestos de desarrollo web frontend.
  • Una gran parte de los participantes de Web3 operan bajo un peligroso mito de seguridad: creen que hacer clic en el botón "Desconectar" en la interfaz de usuario del sitio web de una dApp corta por completo los vínculos criptográficos entre su billetera y la plataforma. Esta suposición es completamente incorrecta.

Si bien el botón altera visualmente la visualización de la página web, a menudo deja la infraestructura subyacente completamente intacta.

  • Si ​​una plataforma es maliciosa o si un atacante externo secuestra los parámetros de su sesión a través de las vulnerabilidades del navegador local, el puente de comunicación seguro permanece completamente operativo en segundo plano.
  • Esta canalización persistente permite operaciones de drenaje automatizadas dirigidas a sus activos mucho después de haber cerrado la pestaña del navegador, apagado el monitor y alejado de su computadora.
WalletConnect Hijacking: Draining After Disconnect

1. La arquitectura subyacente de la comunicación WalletConnect

Para comprender cómo un canal de conexión puede verse comprometido y mantenido en contra de las intenciones explícitas de un usuario, primero debemos examinar la capa de comunicación estructural del protocolo. WalletConnect no es un cadena de bloques libro mayor, una capa de consenso o un custodio de fondos; Opera puramente como un canal de mensajería cifrada. Coordina las comunicaciones entre dos puntos finales distintos: el cliente que solicita una acción (la dApp) y el firmante que ejecuta la acción (su aplicación de billetera).

La inicialización de este puente seguro se basa en un protocolo de enlace criptográfico de varios pasos:

  • Creación de propuesta: La dApp genera una propuesta de sesión única que contiene una cadena alfanumérica de Identificador uniforme de recursos (URI). Esta cadena codifica varios parámetros críticos, incluido un identificador de tema de emparejamiento único, la dirección web de un servidor de retransmisión central y una clave de cifrado simétrica de extremo a extremo.

  • La presentación del apretón de manos: La dApp presenta esta cadena URI al usuario, generalmente formateándola como un código QR visual en una pantalla de escritorio o configurándola como un botón de enlace profundo automatizado en interfaces móviles.

  • El escaneo de billetera: El usuario abre su aplicación de billetera sin custodia y escanea el código QR o toca el enlace móvil, lo que permite que el software de billetera analice los parámetros de configuración.

  • Establecimiento del Túnel: La aplicación de billetera utiliza la clave simétrica analizada para establecer una conexión WebSocket cifrada directamente al puente de red de retransmisión designado, enviando de vuelta una respuesta de aprobación de sesión firmada criptográficamente.

Una vez que se completa este protocolo de enlace, ambos puntos finales están conectados de forma segura a través de un tubo de retransmisión activo. El servidor de retransmisión funciona esencialmente como un buzón ciego. Recibe solicitudes de carga útil de la dApp, las transfiere a través de la red según el identificador del tema de emparejamiento y las coloca en la aplicación de billetera del usuario. 

  • El servidor de retransmisión no puede leer ni modificar el contenido de estas cargas útiles porque cada mensaje está completamente cifrado localmente utilizando la clave simétrica compartida durante el protocolo de enlace inicial.
  • Con el lanzamiento de la versión dos del protocolo, estas conexiones se volvieron altamente persistentes para eliminar la fricción del usuario. Para evitar que los usuarios tengan que escanear códigos QR repetidamente cada vez que recargan una página o experimentan una caída menor de la red, la arquitectura moderna mantiene emparejamientos de larga duración. Estos emparejamientos pueden almacenar estados de conexión en múltiples redes blockchain distintas simultáneamente.
  • Si bien esta persistencia estructural creó una experiencia de usuario significativamente más fluida para múltiples cadenas DeFi operaciones, también amplió la superficie de ataque persistente. Dejó un túnel de comunicaciones abierto a largo plazo que funciona continuamente entre las billeteras de los usuarios y las aplicaciones web externas.

2. El engaño de la desconexión: poda superficial versus revocación total

La vulnerabilidad que permite el drenaje persistente posterior a la desconexión no está causada por una falla criptográfica dentro del protocolo de comunicación en sí. En cambio, es una brecha estructural entre cómo las interfaces del navegador manejan los datos de visualización local y cómo las aplicaciones de billetera administran los estados de conexión en segundo plano.

Cuando un desarrollador web crea una interfaz de usuario para una plataforma financiera descentralizada, escribe código para manejar los eventos del ciclo de vida de la conexión de la billetera. Cuando un usuario navega a la esquina superior de la página web y hace clic en el botón "Desconectar billetera", la aplicación ejecuta un script localizado. Este script realiza una serie de tareas básicas de limpieza del lado del cliente:

  • Elimina las claves de sesión de conexión activa guardadas en las cookies del navegador, el almacenamiento de sesión o el caché local.

  • Borra la máquina de estado localizada de la aplicación, eliminando la dirección de billetera y el saldo del usuario de la pantalla activa.

  • Actualiza la interfaz de usuario para mostrar un botón neutral y desconectado que dice "Conectar billetera".

Para el usuario ocasional, esta transformación visual parece una terminación absoluta del enlace. El sitio web ya no muestra sus datos financieros y la conexión parece cortada de forma segura.

  • Sin embargo, esta limpieza es completamente superficial. Borrar la caché del navegador local solo modifica la interfaz del lado del cliente. No envía una instrucción de terminación estructural explícita a través de la red de retransmisión para desmantelar el túnel WebSocket en segundo plano, ni altera los registros de conexión internos mantenidos dentro de la aplicación de billetera móvil del usuario.
  • A menos que el desarrollador de la dApp codifique explícitamente un comando de terminación a nivel de protocolo, o a menos que el usuario abra la configuración de su billetera para purgar manualmente el emparejamiento, la tubería de mensajería en segundo plano permanece abierta en la red de retransmisión. La aplicación de billetera continúa reconociendo el tema de emparejamiento como un canal de comunicación activo y autorizado.
  • Si la dApp fue creada maliciosamente por un estafador, o si su código de interfaz fue posteriormente comprometido por una inyección de un tercero, la plataforma puede continuar enviando cargas útiles de solicitudes de transacciones sin procesar directamente al teléfono del usuario, completamente independientemente de si la pestaña del navegador está abierta, cerrada o vacía.
WalletConnect Hijacking: Draining After Disconnect

3. Mecánicas de secuestro de sesiones: XSS, ladrones de información y robo de emparejamiento

  • Debido a que los pares de comunicación modernos están diseñados para sobrevivir a las actualizaciones del navegador y a los reinicios del sistema, los datos criptográficos críticos necesarios para mantener el túnel WebSocket seguro deben guardarse de manera persistente en el hardware local del usuario. En entornos de navegador de escritorio estándar, los metadatos de esta sesión se escriben directamente en el archivo del navegador. Almacenamiento local o Base de datos indexada archivos de configuración. Esto incluye las claves de cifrado simétricas no cifradas, las URL del servidor de retransmisión activo y las cadenas de temas de emparejamiento coincidentes.
  • Esta dependencia de los repositorios de almacenamiento del navegador local abre una vulnerabilidad grave a Secuencias de comandos entre sitios (XSS) inyecciones y dedicadas malware ladrón de información Campañas . Si un atacante identifica una vulnerabilidad en el servidor web principal de una plataforma DeFi o inyecta con éxito código malicioso en una biblioteca de dependencia de código abierto utilizada por el proyecto (como una red de entrega de contenido comprometida o un script de análisis de datos de terceros), un exploit XSS puede ejecutarse silenciosamente dentro de la pestaña del navegador del usuario.
  • En el momento en que el script malicioso se ejecuta dentro del contexto activo de su navegador, lee los directorios de almacenamiento local. Extrae las claves simétricas sin cifrar y los temas de emparejamiento utilizados para comunicarse con su aplicación de billetera.
  • Alternativamente, si se engaña a un usuario para que descargue un archivo malicioso disfrazado de modificación de un videojuego, un robot comercial automatizado o un parche de software fraudulento, el malware ladrón de información barre la computadora local y copia toda la carpeta de la base de datos IndexedDB de todos los navegadores instalados.
  • Con estas claves de conexión criptográficas capturadas, el atacante no necesita comprometer su teléfono móvil físico, piratear su sistema operativo ni adivinar la contraseña de su billetera de hardware. Simplemente importan la clave simétrica robada y los parámetros de emparejamiento a su propio terminal de script personalizado.

Conectan su nodo malicioso directamente a la red pública de retransmisión WalletConnect utilizando su identificador de tema de emparejamiento secuestrado.

  • Debido a que el atacante presenta la configuración de clave criptográfica correcta, la red de retransmisión valida el enlace de inmediato. El atacante ahora posee un puente de comunicación activo y directo con la pantalla del dispositivo móvil de la víctima, lo que le permite enviar solicitudes de firma arbitrarias a cualquier hora del día, evitando por completo el sitio web legítimo de la dApp.

4. El circuito de drenaje continuo: explotación de la fatiga y señalización ciega

  • Una vez que un atacante o un operador de dApp malintencionado ha asegurado un túnel de conexión secuestrado o persistente, implementa herramientas automatizadas de alta frecuencia para explotar al usuario. Debido a que el puente de comunicación permanece autorizado dentro de la aplicación de billetera de la víctima, el atacante puede activar solicitudes de transacciones en tiempo real que se dirigen instantáneamente a la pantalla del teléfono del usuario.
  • La principal metodología de ejecución utilizada por estos sindicatos es la Bucle de solicitud infinito. El script del atacante está configurado para enviar solicitudes de transacciones de alta prioridad al dispositivo de la víctima con una frecuencia extrema.
  • En el momento en que la víctima desbloquea su teléfono inteligente para revisar un correo electrónico, abrir un mensaje o mirar una aplicación de navegación, su aplicación de billetera fuerza instantáneamente una ventana emergente modal de alta prioridad en la pantalla, exigiendo una aprobación de firma inmediata.
  • Si el usuario hace clic en "Rechazar" o intenta descartar la alerta, el script del atacante detecta el rechazo a través de la red de retransmisión y automáticamente envía un mensaje de firma nuevo e idéntico en la pantalla en una fracción de segundo.
  • Esta implacable entrega automatizada crea una intensa Denegación de servicio (DoS) y fatiga cognitiva Efecto . El bombardeo continuo de alertas hace que la aplicación de billetera se ralentice, lo que hace que sea increíblemente difícil para el usuario navegar en su menú de configuración interna para localizar y eliminar el emparejamiento de conexión subyacente.
  • En caso de intensa frustración, o si el usuario es sorprendido mientras hace clic rápidamente en la pantalla para descartar las ventanas emergentes, puede hacer clic accidentalmente en el botón "Confirmar" o "Firmar" en un mensaje malicioso.
  • Además, estas solicitudes secuestradas están cuidadosamente estructuradas para ocultar su verdadera carga útil de transacción. Los atacantes rara vez envían una solicitud de transferencia de token simple y clara que muestre explícitamente los activos que salen de la billetera.
  • En lugar de ello, formatean la solicitud utilizando funciones criptográficas complejas de bajo nivel como personal_sign o crudo eth_sign formatos de firma ciega.
  • Estos mensajes no muestran información legible por humanos, presentando al usuario un bloque masivo e imposible de analizar de números y caracteres hexadecimales.
  • La descripción de texto que acompaña a la solicitud a menudo se falsifica para que diga "Sincronizar billetera de red" o "Verificar identidad de inicio de sesión".
  • En realidad, oculta dentro de ese paquete de datos criptográficos sin procesar hay una instrucción que autoriza una asignación ilimitada de activos, activa una autorización de gasto de token Permit2 sin gas o firma una llamada de movimiento de activos que drena todo el saldo de la billetera en el momento en que se confirma.

5. Desconexión a nivel de frontend versus billetera

Para determinar exactamente dónde existen los límites de la seguridad de las comunicaciones, revise esta comparación de tipos de terminación:

Tipo de DesconexiónRealidad de la seguridad en cadena
Limpieza frontalSolo borra el almacenamiento de la interfaz del navegador local.
Revocación de billeteraCorta permanentemente la tubería criptográfica en segundo plano.

6. La superficie de ataque a largo plazo: sesiones de comunicación versus asignaciones en cadena

  • Para construir un marco de seguridad totalmente resistente, debe separar su comprensión de la Capa de comunicación del Capa de estado en cadena. Una vulnerabilidad importante en la gestión de activos de los usuarios surge de combinar un puente de comunicación abierto con un puente activo. contrato inteligente asignación para gastos.
  • Una sesión de WalletConnect pertenece estrictamente al capa de comunicación. Es el conducto digital que transmite notificaciones de solicitudes de un lado a otro entre una interfaz web y su hardware local.
  • Si una sesión está activa, la dApp puede enviar mensajes de firma a su pantalla, pero no tiene poder para alterar sus saldos de blockchain sin su firma.
  • Si la sesión finaliza correctamente, la tubería se derriba por completo, lo que significa que la dApp pierde toda capacidad de comunicarse con su dispositivo o aparecen ventanas emergentes en su pantalla.

Por el contrario, una aprobación simbólica pertenece al capa de estado de blockchain.

  • Cuando autorizas un ERC-20 approve() o ejecutar un permiso de gasto EIP-712 Permit2 durante una sesión de conexión activa, está escribiendo una instrucción permanente directamente en los datos del contrato inteligente de ese token específico.
  • Esta instrucción registra que una dirección de contrato inteligente externa designada tiene el derecho legal de retirar tokens de su cuenta utilizando el Función transferFrom() .
  • Esta separación estructural significa que incluso si abres tu billetera y eliminas por completo una sesión activa, cualquier asignación de tokens que autorizó mientras esa sesión estaba activa permanece completamente escrita en el libro mayor de blockchain.

El contrato inteligente malicioso no necesita un puente de sesión abierto para agotar su billetera.

  • Debido a que el permiso de aprobación en cadena ya está confirmado, el atacante puede interactuar con el contrato de token directamente desde su propia consola de script, sacando sistemáticamente activos de su billetera sin mostrar otra alerta en su teléfono.
  • Lograr una verdadera seguridad de los activos requiere abordar ambos elementos: eliminar manualmente las tuberías de conexión persistentes y revocar sistemáticamente las asignaciones de tokens abiertos.
WalletConnect Hijacking: Draining After Disconnect

7. Capas de Seguridad Arquitectónica

Comprender la mecánica específica de cada capa de seguridad ayuda a prevenir vulnerabilidades de drenaje de activos posteriores a la interacción:

Perfil de capaAlcance del Riesgo Operacional
Canal de sesiónDicta comunicación activa y generación de solicitudes.
Asignación de tokensDicta acceso móvil de activos en cadena sin firmar.

8. Guía de mitigación: Cómo proteger sus canales criptográficos

Debido a que las implementaciones de interfaz predeterminadas a menudo están diseñadas en torno al borrado superficial de la caché, debe tomar un control proactivo de los estados de su sesión. Utilice este manual de seguridad operativa para garantizar que su billetera permanezca completamente aislada de amenazas de conexión persistentes:

Aplicar la purga de sesiones en el lado de la billetera

  • Nunca asuma que cerrar una pestaña del navegador o cerrar sesión en un sitio web corta su conexión. Cada vez que complete una sesión comercial o salga de una aplicación DeFi, abra físicamente su aplicación de billetera.

Navega hasta el Configuración o Aplicaciones conectadas menú , seleccione el Sesiones de WalletConnect registra y revisa los emparejamientos activos.

Ubique el protocolo específico con el que terminó de interactuar y seleccione manualmente Desconectar.

  • Esta acción obliga a tu billetera a transmitir un mensaje explícito session_delete mensaje a la red de retransmisión, invalidando permanentemente el tema de emparejamiento y bloqueando el enrutamiento de cualquier solicitud futura a su dispositivo.

Aproveche la simulación de transacciones avanzada

  • Evite el uso de billeteras heredadas que actúan como simples pantallas de firma de paso. Migre su capital activo a billeteras de seguridad que cuentan con funciones integradas modelos de verificación de dominio y motores de simulación de transacciones previas a la firma.
  • Las billeteras seguras modernas utilizan API de validación de dominio avanzadas para verificar la autenticidad de una solicitud de sesión entrante. Si un dominio de phishing intenta secuestrar una sesión imitando una marca popular, el motor de validación señala la discrepancia del origen y alerta al usuario.

Además, asegúrese de que su billetera elegida reproduzca los datos de las transacciones entrantes en una bifurcación de blockchain local antes de mostrar la pantalla de firma.

  • Un motor de simulación robusto descompondrá datos de llamadas complejos e ilegibles en una declaración visual clara: mostrando exactamente qué tokens dejarán su dirección y qué permisos se otorgarán al contrato externo si ejecuta la firma.
  • Si una dApp afirma ser una confirmación de inicio de sesión inofensiva, pero el motor de simulación advierte que la firma autoriza una asignación de activos abierta, rechace la solicitud al instante.

Implementar una segmentación estricta de billetera

Aplicar un completo estrategia de contención del radio de explosión en todo su perfil de activos digitales.

Nunca conecte una billetera de almacén principal que contenga sus ahorros a largo plazo o activos de alto valor a aplicaciones web basadas en navegador.

  • Mantenga su patrimonio principal asegurado en dispositivos de hardware de almacenamiento en frío aislados que se mantienen completamente limpios durante las sesiones de interacción web del día a día.
  • Implemente billeteras activas distintas y de bajo saldo o direcciones de quemador desechables específicamente para interactuar con redes DeFi activas, interactuar con protocolos experimentales o reclamar distribuciones de tokens promocionales.
  • Si un emparejamiento de sesión en una cuenta desechable es secuestrado mediante un script malicioso, la pérdida potencial permanece estrictamente limitada a esa zona de pruebas específica, manteniendo su patrimonio principal completamente seguro.

9. Telemetría en tiempo real e integración de DEXTools

  • En el entorno multicadena moderno y altamente automatizado, mantener una claridad absoluta sobre los permisos de sus contratos inteligentes y los fondos de liquidez activos es un requisito de supervivencia esencial. Cuando reequilibra grandes asignaciones de capital o interactúa con pares de tokens recién implementados en capas de intercambio descentralizadas, confiar en enlaces no verificados o conexiones persistentes del navegador expone sus activos a vulnerabilidades de ejecución inmediata y riesgos iniciales.
  • DEXTools proporciona la telemetría analítica crítica en tiempo real necesaria para verificar la integridad programática y los parámetros de seguridad de cualquier grupo de tokens antes de autorizar una conexión de billetera o ejecutar una firma de transacción. Al ingresar la dirección del contrato de cualquier activo directamente en el avanzado Explorador de pares de DEXTools, puede evaluar instantáneamente los volúmenes de operaciones en vivo, interrogar las auditorías automatizadas de seguridad de los contratos inteligentes, verificar las duraciones de los bloqueos del fondo de liquidez y auditar las distribuciones de los titulares de billeteras. Esta visibilidad precisa y en tiempo real le permite navegar de forma segura por el ecosistema descentralizado, manteniendo su patrimonio digital aislado de redes persistentes y agotadoras. Puedes acceder 

Herramientas DEX aquí ¡y comience a operar hoy!


Descargo de responsabilidad: Este artículo tiene fines informativos únicamente y no constituye asesoramiento de inversión, asesoramiento financiero, asesoramiento comercial ni ningún otro tipo de asesoramiento. DEXTools no recomienda comprar, vender ni mantener ninguna criptomoneda o token. Los usuarios deben realizar su propia investigación y consultar con un asesor financiero calificado antes de tomar cualquier decisión de inversión. Las inversiones en criptomonedas son volátiles y de alto riesgo. DEXTools no es responsable de las pérdidas incurridas.

Cómo revocar aprobaciones de tokens (Wallet Security 2026) Cómo revocar aprobaciones de tokens: guía de seguridad paso a paso Guía para principiantes de KuCoin: Spot, Earn y Trading Bot Guía de auditoría de contratos inteligentes: cómo leer un informe de auditoría
Originally published by DEXTools News. © 2026 DEXTools News (STRADEXT DEFI SOLUTIONS, S.L.). Reproduction or republication without written permission is prohibited.