Cómo revocar aprobaciones maliciosas y cerrar el camino de drenaje

Revocar aprobaciones maliciosas significa enviar una transacción en la cadena que reescribe la asignación de un token, generalmente estableciéndola en 0 para el gastador que puede llamar a transferFrom sobre tu saldo. Desconectar una billetera de una dApp es solo una acción de interfaz de usuario, por lo que no elimina las aprobaciones de tokens ni detiene a un drenador de billetera que ya tiene permiso de gasto.

Puntos clave

• Una aprobación de token es un permiso permanente en el contrato del token, y persiste hasta que lo cambies en la cadena.
• Para revocar la aprobación, envías una transacción que establece la asignación del gastador en 0 o en una cantidad menor, y pagas gas.
• Las aprobaciones ilimitadas son la versión explosiva de las asignaciones porque un gastador comprometido puede drenar ese saldo de token hasta el límite de la asignación.
• Permit2 puede ocultar riesgos detrás de las firmas: podrías ver solo una aprobación en la cadena para Permit2 mientras que el verdadero peligro es firmar una autorización EIP-712 maliciosa.

Por qué las aprobaciones de tokens pueden ser peligrosas

Una aprobación maliciosa no es “una conexión dApp.” Es un permiso activo en un contrato de token que dice que un gastador específico puede mover tus tokens con transferFrom.ERC-20 las transferencias delegadas funcionan en tres funciones: approve(spender, amount), allowance(owner, spender) y transferFrom(from, to, amount). Una vez que esa asignación existe, el gastador no necesita tu billetera nuevamente. Solo necesita que la asignación siga siendo no cero.

Esa persistencia es todo el problema. Las asignaciones permanecen activas hasta que se cambian explícitamente, por lo que los botones de “desconectar billetera” y las listas de conexión de billetera son una falsa sensación de seguridad. Desconectar elimina la capacidad de un sitio para solicitar tu billetera. No hace nada al estado del contrato de token que realmente autoriza el gasto.

Por eso, el phishing de aprobación funciona: el objetivo del atacante es obtener una aprobación de token (o una firma estilo permiso) una vez, y luego usarla más tarde cuando la víctima ya no está prestando atención.

Las aprobaciones ilimitadas son donde reside el riesgo de cola. Muchas interfaces de usuario predeterminan a “infinito” porque reduce la fricción futura, pero aprobar la cantidad máxima uint256 efectivamente le entrega al gastador un cheque en blanco para ese token. Si el contrato del gastador es malicioso hoy, o se explota más tarde, la asignación es el camino de drenaje.

Para los comerciantes, el modelo mental que se sostiene es “línea de crédito permanente.” Cada aprobación de token es un ítem: token → gastador → límite. Si el lector no puede señalar el contrato exacto que actualmente tiene permiso para llamar a transferFrom (ya sea directamente o a través de Permit2), la exposición real es desconocida. Esta es una de las mecánicas centrales detrás de las estafas de billeteras de criptomonedas y cómo evitarlas.

Cómo funciona la revocación de una aprobación

Revocar no es un interruptor de configuración. Es un cambio de estado en la cadena, lo que significa que cuesta gas y deja un registro de transacción. Mecánicamente, una revocación de aprobación es simplemente reescribir el mapeo de asignaciones en el contrato del token para que la asignación del gastador se convierta en 0 (o un número menor si el objetivo es seguir usando la aplicación con un límite máximo).

Dos detalles operativos importan más de lo que la mayoría de las guías admiten.

Uno es que “eliminar aprobación de token” es específico del token. Revocar USDC para un gastador no hace nada para las aprobaciones de WETH al mismo gastador. El libro mayor de asignaciones es por contrato de token.

El otro es que las actualizaciones de asignación pueden tener un caso de borde de condición de carrera al cambiar una asignación no cero N a otra asignación no cero M. El patrón más seguro es el que Speedrun Ethereum llama “aprobar-a-cero-luego-establecer.” La idea es simple: establece la asignación en 0 primero, espera la confirmación, luego establece la nueva cantidad.

Eso elimina la ventana donde un gastador podría usar potencialmente tanto los valores de asignación antiguos como los nuevos.

Si una billetera o dApp lanza errores como “Fallo al aprobar a cero” o “Fallo al aprobar a nueva cantidad,” generalmente no es una señal de que revocar sea imposible. Es una señal de que el comportamiento de aprobación del token es peculiar o que la interfaz de usuario no está manejando las reglas del token de manera limpia.

La solución es usar una herramienta de asignación diferente o la interfaz de aprobación de tokens de un explorador de bloques, luego intentar nuevamente el mismo cambio en la cadena.

El marco clave se mantiene consistente: revocar es simplemente reescribir el permiso en la cadena. Si el lector no puede identificar al gastador que tiene el permiso, la revocación no puede ser dirigida correctamente.

Revocación paso a paso usando Revoke.cash

Revoke.cash es un flujo de trabajo común porque muestra aprobaciones en un solo panel y permite al usuario enviar la transacción de revocación en la cadena desde la misma pantalla. Los pasos a continuación reflejan el flujo en billetera que documenta Bifrost Wallet, pero la secuencia es en general la misma en todas las billeteras.

1. Abre un navegador de billetera de confianza y navega a Revoke.cash. Usar un navegador dentro de la billetera reduce la posibilidad de aterrizar en un dominio similar debido a anuncios o DMs. 2. Conecta la billetera y selecciona la red correcta. Las aprobaciones son específicas de la cadena, por lo que una aprobación de Ethereum no aparecerá cuando la herramienta esté configurada en Flare, Base u otra cadena EVM. 3.

Abre la vista de aprobaciones de tokens y ordena por riesgo. Comienza con asignaciones ilimitadas y tokens con saldos significativos, ya que esos son los caminos de drenaje de mayor impacto. 4. Identifica al gastador para cada fila arriesgada. El gastador es el contrato que puede llamar a transferFrom. Si el nombre del gastador parece desconocido, trátalo como hostil hasta que se demuestre lo contrario. 5.

Haz clic en revocar para las aprobaciones seleccionadas. Esto envía una transacción que establece la asignación en 0 para ese token y gastador. 6. Confirma la transacción en la billetera y paga gas. Si el gas es alto, revocar las asignaciones más grandes primero sigue siendo un comercio racional de “prima de seguro.” 7. Revisa la lista de aprobaciones después de la confirmación.

La asignación ahora debería mostrarse como 0, o la fila debería desaparecer dependiendo de la interfaz de usuario de la herramienta.

Esta es la respuesta central a cómo revocar aprobaciones: el usuario no está “desvinculando” nada. El usuario está cambiando la asignación en el contrato del token. Si el drenador de billetera ya tiene aprobación, esta es la acción que cierra el camino.

Aprobaciones de Permit y Permit2 a verificar

A finales de 2022 es el punto de inflexión que la mayoría de los usuarios pasó por alto. Uniswap’s Universal Router hizo de Permit2 el camino de aprobación predeterminado, lo que desplazó mucho del “riesgo de aprobación” de las transacciones obvias approve() hacia las firmas EIP-712.

Permit2 es un contrato de aprobación singleton de Uniswap Labs: los usuarios aprueban Permit2 una vez por token, luego las aplicaciones solicitan autorizaciones firmadas que incluyen gastador, cantidad, fecha límite y nonce.

Eso crea dos libros mayores para auditar.

El libro mayor uno son las asignaciones clásicas de ERC-20: token → gastador. Esto es lo que la mayoría de los paneles de “aprobación de token” muestran, y es donde las aprobaciones ilimitadas a contratos aleatorios suelen vivir.

El libro mayor dos es Permit2: token → asignación de Permit2 en la cadena, más las autorizaciones firmadas fuera de la cadena que las aplicaciones solicitan. Permit2 admite tanto el modo de asignación permanente como el modo de transferencia de un solo uso, y sus autorizaciones están limitadas por fecha.

Las fechas límite pueden reducir la exposición de permisos inactivos porque las autorizaciones pueden expirar automáticamente, pero no resuelven el robo de firmas. Las campañas de phishing de aprobación apuntan cada vez más a los mensajes de firma de permiso y Permit2 porque un solo mensaje firmado puede ser suficiente para mover fondos.

La implicación práctica es incómoda pero clara: “No recuerdo haber aprobado nada” no es una señal de seguridad. Un usuario puede estar expuesto después de firmar datos escritos que nunca parecieron una transacción approve() en su historial.

Al limpiar después de un susto, la auditoría debe responder una pregunta por token: ¿qué contrato puede actualmente causar un transferFrom de este token desde esta billetera? A veces es un gastador directo. A veces es Permit2 porque el token está aprobado al singleton y el usuario sigue firmando solicitudes ciegamente.

El hábito que previene incidentes repetidos es el mismo que se cubre en cómo verificar una transacción antes de firmar: trata cada solicitud de firma como autoridad de gasto hasta que se demuestre lo contrario.

Lista de verificación de prevención después de revocar

Después de que las transacciones de revocación se confirmen, el objetivo es dejar de recrear la misma exposición la próxima vez que una interfaz de usuario de intercambio, puente o staking pida permiso. La postura limpia es tratar las aprobaciones como tamaño de posición: el límite debe coincidir con la acción prevista, no con el máximo posible.

1. Prefiere aprobaciones de cantidad exacta cuando la interfaz de usuario lo permita. Las aprobaciones ilimitadas son convenientes, pero también son el modo de falla de mayor impacto si el gastador está comprometido. 2. Si una asignación debe cambiarse de un valor no cero a otro, usa “aprobar-a-cero-luego-establecer.” Es un pequeño hábito operativo que reduce un riesgo conocido de condición de carrera. 3.

Revisa las aprobaciones periódicamente con un rastreador de asignaciones. Las herramientas mencionadas en la guía de seguridad del usuario incluyen Etherscan Token Approvals, Revoke.cash, Debank y Unrekt. 4. Trata las solicitudes de Permit y Permit2 como momentos de alto riesgo. Permit2 utiliza firmas EIP-712 con fechas límite y nonces, pero el phishing de firmas sigue siendo la principal forma en que los usuarios son drenados. 5.

Mantén el modelo de “dos libros mayores” en el escritorio: asignaciones clásicas y Permit2. Revocar a un gastador aleatorio no ayuda si el token aún está aprobado a Permit2 y la billetera sigue firmando autorizaciones de un sitio no verificado.

Aquí es donde la disciplina más amplia de las estafas de billeteras de criptomonedas y cómo evitarlas se vuelve operativa: reducir permisos permanentes, verificar lo que se está firmando y pagar el gas para cerrar líneas antiguas cuando dejan de ser útiles.

La conclusión

He visto a personas hacer la versión costosa de esta limpieza: desconectan un sitio en su billetera, se sienten seguros y luego son golpeados nuevamente porque la asignación en el contrato del token nunca cambió. La única pregunta que importa es si un gastador aún puede llamar a transferFrom en ese token. Si la respuesta es “sí,” el camino de drenaje sigue abierto.

El hábito que mantiene esto barato es tratar las aprobaciones como líneas de margen. Dimensionarlas al comercio, y cuando algo se siente extraño, revocar las ilimitadas primero incluso si el gas es feo. Si Permit2 ha estado en el flujo desde finales de 2022, el segundo hábito es negarse a firmar solicitudes EIP-712 que no puedes leer. Ahí es donde vive el phishing de aprobación ahora.

Fuentes

• Speedrun Ethereum
• Soporte de Bifrost Wallet
• Soporte Ecológico