Explicación del phishing en hielo: drenajes de aprobación ocultos

El libro de contabilidad engañoso: pasando del robo de credenciales al secuestro de permisos

• En los primeros días de la seguridad Web3, proteger los activos digitales era una batalla relativamente sencilla centrada en proteger las credenciales. Si un inversor memorizaba su frase inicial de 12 palabras, almacenaba sus claves privadas completamente fuera de línea y evitaba descargas de software malicioso, su capital en cadena generalmente se consideraba seguro. 

• Los ataques de phishing tradicionales se basaban en gran medida en el engaño de fuerza bruta: engañar a los usuarios para que escribieran sus frases maestras de recuperación directamente en formularios web falsos.

• Hoy en día, el panorama de amenazas ha experimentado una evolución estructural dramática. Los ciberdelincuentes Web3 avanzados ya no desperdician energía intentando robar sus claves privadas o frases iniciales. En cambio, implementan una técnica altamente sofisticada conocida como Phishing en hielo. 
• En lugar de irrumpir en tu billetera , el phishing en hielo lo engaña para que abra cortésmente la puerta y le entregue el control operativo total de sus activos. Al manipular las interfaces de usuario de los contratos inteligentes, explotar las firmas fuera de la cadena y aprovechar las vulnerabilidades de las firmas ciegas, estas aprobaciones ocultas desvían millones de las cuentas de autocustodia y dejan las claves privadas completamente intactas.

¿Qué es el Ice Phishing?

• El phishing en hielo es un exploit criptográfico en el que un atacante manipula a un usuario para que firme una transacción de contrato inteligente maliciosa o una asignación de token. Esta autorización altera el estado de aprobación del token en la cadena, otorgando al atacante permiso legal completo para gastar los activos de la víctima.

• A diferencia de una transacción típica que mueve fondos instantáneamente del punto A al punto B, el phishing en hielo es una amenaza asincrónica. En el momento en que un usuario firma una aprobación maliciosa, parece que no sucede nada. Ningún token sale de la billetera inmediatamente. En cambio, el atacante espera a que se establezca la firma y luego invoca las funciones de transferencia interna del contrato simbólico en un momento posterior para vaciar limpiamente la cuenta.

1. La mecánica de la trampa en cadena: approve y setApprovalForAll

• Para interactuar con aplicaciones descentralizadas, creadores de mercado automatizados y mercados NFT, los usuarios de Web3 deben interactuar con marcos de asignación de tokens. Debido a que los contratos inteligentes no pueden leer ni mover automáticamente los tokens dentro de su billetera sin permiso, primero debe otorgar al contrato una asignación de gasto específica.

Las campañas de phishing en hielo explotan esta elección de diseño mediante la implementación de aplicaciones descentralizadas fraudulentas (dApps) que alteran los parámetros de las interacciones de tokens de rutina:

• Asignaciones de tokens ERC-20 (approve): Cuando cree que está configurando un intercambio de token de rutina, la dApp maliciosa modifica la carga útil de datos de llamada de la transacción subyacente. En lugar de llamar a una función de intercambio, llama a la función de asignación nativa del token, otorgando a la dirección del contrato del atacante un límite de gasto de tokens de varios billones.

• Barridos del ecosistema NFT (setApprovalForAll): Para los tokens no fungibles, la amenaza es aún más absoluta. Firmar una transacción que contiene un código malicioso setApprovalForAll otorga al atacante pleno poder administrativo sobre toda su colección de tokens dentro de ese contrato específico. Posteriormente, el pirata informático puede extraer de su cuenta todos los objetos coleccionables digitales de alto valor en una ejecución de un solo bloque.

2. La firma invisible: EIP-2612 Permitir phishing

• A medida que los proveedores de billeteras implementaron mejores pancartas de advertencia para señalar aprobaciones sospechosas en la cadena, los servicios agotadores cambiaron hacia la manipulación del marco de firmas fuera de la cadena, específicamente apuntando Permiso EIP-2612 Módulos .

• El estándar EIP-2612 se introdujo para crear una experiencia de usuario más eficiente al permitir aprobaciones de tokens sin gas. En lugar de presentar un informe vivo y costoso cadena de bloques transacción para ajustar una asignación, el usuario firma un mensaje estructurado fuera de la cadena dentro de su cliente de billetera. Esta cadena de firma criptográfica sin procesar se pasa luego a un tercero que paga la tarifa del gas de la red para ejecutar la transacción en cadena.

• En un escenario de phishing en hielo, esta característica se convierte en una vulnerabilidad silenciosa. Los atacantes crean hermosas aplicaciones web clonadas que solicitan a los usuarios que firmen un mensaje de texto simple y sin gas para "verificar la propiedad de la billetera" o "reclamar una recompensa comunitaria". Detrás de la interfaz de usuario, la carga útil es en realidad una cadena de validación de permiso EIP-2612. En el momento en que el usuario hace clic en firmar, el drenaje captura la carga útil de la firma sin procesar, la transmite al libro de contabilidad público de la cadena de bloques para asegurar la asignación y despoja a la cuenta de sus tokens.

3. El punto ciego de la firma ciega: explotación de carteras de hardware

• La última línea de defensa para un participante de Web3 es una billetera de hardware. Sin embargo, ni siquiera el chip de seguridad física más seguro puede salvar a un inversor de un exploit de phishing en hielo si es víctima de Firma ciega.

• La firma ciega ocurre cuando un dispositivo de hardware se ve obligado a autorizar una transacción de contrato inteligente o una carga útil de mensaje complejo que no puede analizar ni mostrar de forma nativa en su pequeña pantalla física. En lugar de mostrar instrucciones de texto claro como "Otorgar derechos de transferencia al contrato X", la billetera de hardware muestra un mensaje de advertencia genérico junto con una cadena larga e ilegible de datos hexadecimales sin procesar.

• Cuando los usuarios encuentran estos campos de datos ilegibles durante eventos de mercado de alta presión, con frecuencia hacen clic en las indicaciones de advertencia en los botones físicos de su hardware por costumbre. Al firmar ciegamente la cadena de datos no verificada, el usuario valida criptográficamente la carga útil de phishing de hielo malicioso, creando una aprobación en cadena irreversible e inapelable que permite que el script de drenaje omita por completo el modelo de seguridad del dispositivo físico.

Matriz de Diseño Técnico: Firmas de Vectores de Drenaje de Aprobación

4. Cómo reconocer y proteger su capital en cadena

Defender su cartera contra sofisticados ataques de phishing en hielo y otros "phishings" requiere un compromiso inflexible con estrictos protocolos de seguridad operativa.

• Datos de simulación de transacciones de auditoría: Las billeteras Web3 modernas y seguras incorporan módulos avanzados de simulación de transacciones. Antes de autorizar cualquier solicitud de transacción, revise cuidadosamente la pantalla de salida de la simulación. Si un sitio web que afirma realizar una función básica genera una advertencia de simulación que indica que su billetera está modificando una asignación, o si solicita una acción que contenga términos como approve o Permit, rechaza la conexión inmediatamente.

• Cargas útiles desconocidas de Never Blind Sign: Trate las indicaciones de firma ciega en sus billeteras de hardware como eventos de seguridad de alto riesgo. Si la pantalla de su dispositivo físico no puede mostrar esquemas de texto claros y legibles que expliquen exactamente dónde se mueven sus tokens y por qué, no presione los botones de confirmación. Actualice el firmware de su dispositivo o utilice rutas de interfaz dApp alternativas y verificadas para garantizar una visibilidad clara de los datos.

• Hacer cumplir las auditorías de permisos de rutina: Las asignaciones de tokens son persistentes; una vez concedidos, permanecen activos en la cadena de bloques para siempre hasta que se modifiquen explícitamente. Utilice aplicaciones independientes de auditoría de asignaciones como Revoke.cash o portales de seguridad de billetera nativa para borrar periódicamente las aprobaciones históricas, garantizando que las plataformas heredadas comprometidas no puedan actuar como una puerta trasera a sus saldos actuales.

Seguimiento de entradas de capital mediante telemetría forense de DEXTools