Wallet drainers: los permisos tras una firma maliciosa

¿Firma, transacción o permiso?

La cartera puede pedirte que firmes un mensaje, envíes una transacción a la cadena o autorices a una dirección para gastar tokens. Comprueba qué acción solicita. En ERC-20, una aprobación en la cadena establece un límite de gasto: una dirección autorizada puede transferir hasta una cantidad determinada de un token mediante transferFrom. La aprobación no transfiere nada por sí misma ni afecta a otros tokens. La especificación ERC-20 define las funciones approve y allowance.

Para los NFT ERC-721, una transacción en la cadena con setApprovalForAll permite a un operador gestionar todos los NFT de esa colección que posea la cuenta, incluidos los que adquiera después mientras siga vigente la aprobación. No abarca otros contratos NFT ni otras redes. Firmar una orden en un mercado es un mecanismo distinto: sus efectos dependen de las condiciones de la orden y de las autorizaciones previas. Consulta la especificación ERC-721.

Un permit es una firma fuera de la cadena que otra persona puede presentar más tarde. ERC-2612 permite establecer un límite de gasto ERC-20 para una dirección, una cantidad, un identificador de un solo uso (nonce) y una fecha límite. Permit2 ofrece modalidades distintas: transferencia única o límite de gasto con plazo. Por lo general, antes requiere aprobar en la cadena el acceso del contrato Permit2 al token. Revisa el token, la dirección autorizada, la red, el importe y la caducidad. Compara ERC-2612 con la explicación de Permit2 de Uniswap.

Cómo funciona una campaña de robo

Una campaña de phishing puede combinar una copia de una página web, una supuesta oportunidad urgente para reclamar o acuñar tokens, la petición de conectar la cartera y una transacción o firma maliciosa. El atacante puede recurrir a software compartido o a proveedores, pero no hay un kit, un reparto de ingresos ni un contrato común a todos los casos. Lo decisivo es lo que autoriza el titular de la cartera en la red correspondiente.

El atacante puede adaptar la solicitud a la cartera, al activo y a la red que detecte. Ethereum, una red compatible con EVM y Solana no comparten un mecanismo universal de aprobación. Una solicitud en una red no autoriza automáticamente transferencias en otra. Comprueba el nombre de la red y la dirección del contrato en la cartera, aunque la página diga que solo te pide una verificación inocua.

También pueden aprovechar permisos que ya concediste. Si una dirección conserva autorización para gastar un token, quizá pueda moverlo más tarde sin pedirte otra aprobación. Una firma nueva podría autorizar otra acción, o el riesgo real podría estar en una aprobación anterior. Por eso conviene revisar los permisos aunque no se mueva ningún activo al conectar la cartera.

Por qué cuesta entender las solicitudes de la cartera

Las carteras no muestran todas del mismo modo las llamadas a contratos y los mensajes estructurados. Algunas ofrecen un resumen útil; otras dejan datos importantes difíciles de interpretar. EIP-712 estructura los datos firmados, pero no vuelve segura cualquier solicitud ni garantiza que la cartera pueda explicar sus efectos. La pantalla es solo una pista: comprueba también el destino, el contrato, la red, el importe y la caducidad.

Una aplicación legítima puede necesitar aprobaciones, permisos u órdenes de mercado. Una página fraudulenta puede solicitar las mismas operaciones, pero con una dirección maliciosa o condiciones desfavorables. Las carteras físicas protegen las claves de firma, pero no pueden decidir si te conviene conceder un permiso. Lo que muestran y su capacidad para explicar una firma varían según el dispositivo, la aplicación y el contrato. No des por segura una solicitud ilegible solo porque aparezca en una pantalla física.

Si no puedes identificar la operación y su alcance, recházala y verifica la página por otra vía. No firmes por la presión de una cuenta atrás ni porque te digan que es «solo una verificación». Si ya aprobaste algo sospechoso, revisa cuanto antes los permisos activos en la red correspondiente. Desconectar la página no revoca una autorización concedida en la cadena.

Solicitudes que conviene examinar

setApprovalForAll da a un operador acceso a los NFT de una colección. Los mercados y otras aplicaciones pueden necesitarlo legítimamente, pero es un permiso amplio. Confirma qué operador y colección figuran en la solicitud y si existe una opción más limitada. Permit2 se aplica a tokens ERC-20; no sustituye en general a las aprobaciones ERC-721.

Los límites de gasto elevados en ERC-20 pueden resultar cómodos en aplicaciones legítimas, pero dejan expuesta una mayor cantidad de ese token si la dirección autorizada es maliciosa o acaba comprometida. Comprueba a quién autorizas y elige un límite menor si tu cartera lo permite. Una cantidad elevada indica riesgo, pero no demuestra que sea un drainer. La guía de MetaMask sobre límites de gasto explica cómo revisar y revocar las aprobaciones compatibles.

Las solicitudes Permit y Permit2 pueden ser útiles, pero exigen atención. Revisa el token, la dirección autorizada, el importe, el identificador de un solo uso o el alcance de la operación, la red y la fecha límite. Otra persona podría presentar después la firma hecha fuera de la cadena. Rechaza la solicitud si no puedes verificar la dirección o si el permiso excede lo necesario. Firmar no significa que ya se haya completado una transferencia.

Las órdenes de mercado pueden incluir varios activos, precios, destinatarios y condiciones. Comprueba qué entregas y qué recibes antes de firmar. La firma autoriza lo que especifique la orden, según las reglas del contrato del mercado y las aprobaciones de tokens pertinentes. No da por sí sola acceso universal a tu cartera. La documentación de OpenSea sobre Seaport muestra estos campos por separado.

Limita lo que una página puede tocar

Separa los activos de mayor valor de la cartera que utilizas con aplicaciones desconocidas. Limita los activos y permisos a los que pueda acceder cada página. Una cartera con poco saldo puede reducir lo que queda al alcance de una dirección maliciosa, pero no convierte en segura una firma perjudicial: aún puedes perder todo lo que haya en ella. Revisa la dirección y los permisos en cada red implicada. Si aprobaste una solicitud con la cartera principal, cambiar de navegador después no anula esa autorización.

Browser.lol puede ejecutar la página de la aplicación lejos de tu navegador habitual y reducir tu exposición directa al código de esa página. No es una cartera ni verifica firmas o gestiona permisos en la cadena. La cartera de tu dispositivo, un firmador físico o una extensión del navegador remoto seguirá mostrando y autorizando la solicitud. Al terminar la sesión de Browser.lol no desaparecen los permisos firmados ni las aprobaciones en la cadena. Si sospechas de una aprobación, sigue las indicaciones de MetaMask para revocarla en la red afectada. Revocar cuesta gas y no deshace transferencias ya completadas.