Encontramos un nuevo tipo de método de phishing que se está volviendo popular. En lugar de implementar contratos de phishing (los proveedores de seguridad podrían etiquetarlos), los estafadores están abusando de algunos contratos legítimos para llevar a cabo el ataque.
En este blog, le mostraremos la forma en que los estafadores lo utilizan y brindaremos sugerencias sobre cómo evitar ser víctima de phishing.
Descripción general
Normalmente, los estafadores implementan contratos de phishing para robar tokens de las víctimas. Específicamente, sus contratos de phishing contienen funciones payable y multi-call sospechosas. Los usuarios que visitan sitios web de phishing enviarán ETH o aprobarán tokens a estos contratos. Sin embargo, los proveedores de seguridad y las billeteras pueden detectar y marcar estos contratos de phishing, lo que lleva a la prohibición de las transacciones dirigidas hacia ellos.
Sin embargo, descubrimos que los estafadores abusan de contratos legítimos implementados por proyectos Web3 de buena reputación para sus propósitos de phishing. Y estos contratos legítimos no pueden ser etiquetados como phishing ni bloqueados. Lo denominamos "ROP" en los sitios web de phishing de Web3, ya que NO implementan nuevos contratos, sino que reutilizan contratos existentes y legítimos para el phishing. Esto es similar al ataque ROP (o ataque de reutilización de código) en las áreas tradicionales de seguridad de software.
Específicamente, la programación orientada al retorno (ROP) es una técnica de explotación de seguridad informática que permite a un atacante utilizar fragmentos de código en bibliotecas existentes. En el phishing de Web3, "ROP" se refiere al aprovechamiento de contratos implementados por proyectos legítimos para fines fraudulentos. Este fenómeno fue reportado por primera vez por la cuenta de Twitter @MevRefund en una publicación.
Cómo funcionan los contratos de phishing tradicionales de Web3
En las primeras fases del phishing en Web3, los estafadores configurarán una Cuenta de Propiedad Externa (EOA) y atraerán a los usuarios para que transfieran ETH o aprueben otros tokens a esta cuenta. Sin embargo, este comportamiento ahora es fácilmente detectado por las billeteras y descubierto por los usuarios. Como resultado, los estafadores han recurrido a implementar contratos de phishing. Para el phishing de ETH, los estafadores suelen emplear una función payable con nombres sospechosos como 'Claim' o 'Security Update'. Estos atractivos nombres de funciones inducen a los usuarios a firmar transacciones de phishing y transferir ETH.
Para el phishing de tokens ERC20 y ERC721, los estafadores atraerán a los usuarios para que aprueben sus tokens al contrato de phishing. Posteriormente, se invocará la función Multicall en los contratos de phishing para transferir los tokens de los usuarios. En particular, la función Multicall está diseñada para ejecutar múltiples transacciones internas específicas en una sola llamada. Diferentes esquemas de phishing, por ejemplo, compra de NFT con orden cero, phishing de aprobación ERC20 o phishing de permiso ERC20, utilizan diferentes transacciones de phishing. Esto les permite configurar el parámetro de transacción y aprovechar Multicall para lanzar transacciones de phishing específicas basadas en los esquemas de phishing correspondientes.
Ahora, muchas billeteras Web3 populares han creado sus listas negras de cuentas de phishing. Informan activamente a los usuarios y previenen las transacciones dirigidas hacia estas cuentas fraudulentas.
"ROP" en el phishing de Web3
Para eludir los mecanismos de lista negra de cuentas de phishing, los estafadores recurren a algunas cuentas que no pueden ser añadidas a la lista negra. Específicamente, abusan de los contratos Multicall implementados por proyectos legítimos, aprovechando su funcionalidad para ejecutar transacciones complejas. Dado que estos contratos legítimos no pueden ser etiquetados como cuentas de phishing, los estafadores inducen a los usuarios a aprobar tokens a estos contratos. Dado que estos contratos legítimos pueden ser invocados por cualquiera (sin control de acceso), los estafadores pueden abusar de ellos de inmediato para transferir los tokens de los usuarios. La siguiente figura muestra todo el proceso.
Por ejemplo, Angel Drainer, una conocida banda criminal de phishing, ha aprovechado Uniswap V3: Multicall 2 para lanzar 89 transacciones de phishing. Tenga en cuenta que el contrato multi-call legítimo no estaba destinado a conservar ningún activo. Por lo tanto, está bien que sea invocado por cualquiera en su diseño. Sin embargo, el estafador abusó de este contrato para llevar a cabo el ataque de phishing sin implementar sus contratos de phishing.
Sugerencias
Alentamos a los usuarios a ser cautelosos y examinar cuidadosamente los detalles de las transacciones antes de proceder con cualquier acción, especialmente las transacciones de aprobación. Verifique siempre sus aprobaciones y revoque cualquiera que le resulte sospechosa.
