Niebla lenta: explicación detallada del riesgo de reingreso ERC777 de Uniswap

Prólogo

El 18 de abril, Tokenlon anunció la suspensión de las transferencias de imBTC porque descubrió que un atacante usó la vulnerabilidad de reingreso ERC777 en el contrato de liquidez de Uniswap para arbitrar el ciclo del grupo ETH-imBTC. El método de ataque esta vez es una vulnerabilidad conocida que existe en Uniswap v 1. Consensys descubrió la vulnerabilidad por primera vez en abril de 2019. En ese momento, Consensys solo descubrió el riesgo y no había encontrado un token que pudiera usar este método para atacar. Más tarde, después de que se lanzó imBTC en Uniswap, dado que imBTC se implementa en base a ERC777, al combinar las características de ERC777 y los problemas en el código Uniswap, los atacantes pueden lograr el arbitraje a través de vulnerabilidades de reentrada. A continuación, analizaremos los métodos de ataque y los detalles específicos de este arbitraje en el futuro.

Preparación de conocimientos

El protocolo ERC777 es un protocolo estándar de token en Ethereum. Este protocolo es una versión mejorada del protocolo ERC20 en Ethereum. Las principales mejoras son las siguientes:

1. Use el mismo concepto que enviar ether para enviar token, el método es: enviar (destino, valor, datos)

2. Tanto el contrato como la dirección normal pueden controlar y negarse a enviar qué tokens registrando la función de enlace tokensToSend (la negativa a enviar se realiza revirtiendo en la función de enlace tokensToSend)

3. Tanto el contrato como la dirección normal pueden controlar y rechazar qué tokens se aceptan mediante el registro de la función de enlace tokensReceived (la negativa a aceptar se realiza revirtiendo en la función de enlace tokensReceived)

4. tokensReceived puede enviar tokens y notificar el contrato para aceptar tokens en una transacción a través de la función de enlace, a diferencia de ERC20, que debe completarse a través de dos llamadas (aprobar/transferirDe)

5. Los titulares pueden "autorizar" y "revocar" operadores (operadores: pueden enviar tokens en nombre del titular) Estos operadores suelen ser intercambios (descentralizados), procesadores de cheques o sistemas de pagos automatizados

6. Cada transacción de token contiene campos de datos y de datos de operador, que pueden pasar datos de titulares y operadores, respectivamente.

7. Puede implementar un contrato de proxy que implemente tokensReceived para que sea compatible con direcciones que no implementen la función tokensReceived

Aquí, debemos prestar especial atención al segundo punto, es decir, la función tokenToSend en el estándar ERC 777. De acuerdo con la definición del protocolo ERC777, el token token que sigue este estándar intentará llamar al token cada vez que se realice una transferencia de token. Ocurre La función del remitente tokensToSend, y los titulares de tokens pueden registrar sus propios contratos en el contrato de registro ERC1820 y definir algunas operaciones en esta función de enlace para manejar ciertos procesos en el proceso de transferencia de tokens, como rechazar el envío de tokens u otras operaciones.

Comprender estos puntos clave nos ayudará a comprender el método de ataque específico de este ataque. De ahora en adelante, podemos acelerar un poco y ver qué pasó con Uniswap esta vez.

Análisis detallado

Consulta una de las transacciones del atacante a través de Etherscan 0x32c83905db61047834f29385ff8ce8cb6f3d24f97e24e6101d8301619efee96e

Se puede encontrar que el atacante transfirió imBTC al contrato Uniswap dos veces, la cantidad también es 0.00823084, y luego recibido de Uniswap Dos transacciones de ETH, que parecen ser dos transacciones muy normales, en realidad son corrientes subterráneas y otros misterios. Para comprender mejor los detalles de toda la transacción, necesitamos ver los detalles específicos de la transacción a través de bloxy.info.

Al consultar los detalles de la transacción, encontramos que el atacante primero intercambió algunos imBTC a Uniswap a través de ethToTokenSwapInput y luego use la función tokenToEthSwapInput para intercambiar imBTC por ETH por primera vez, y luego Uniswap primero transfiere el ETH al atacante y luego llama a la función transferFrom de imBTC. Dado que imBTC implementa el estándar ERC777, al llamar a la función trasferFrom de imBTC, imBTC llamará a la función tokensToSend del atacante. Luego, en la función tokensToSend del atacante, el atacante intercambiará imBTC por ETH por segunda vez y luego el proceso finalizará.

Según los detalles de la transacción, parece que no hay ningún problema aquí y seguimos rastreando el código de UniSwap.

El código anterior es el código de la función ethToTokenSwapInput de Uniswap. Según el análisis del código, la función ethToTokenSwapInput de Uniswap llamará a la función ethToTokenInput y luego obtendrá primero la cantidad de eth que se puede intercambiar por tokens a través de getInputPrice y luego enviará el eth al usuario. a través de la función de envío, y finalmente Transferir tokens al contrato a través de transferFrom. Pasemos a la función getInputPrice.

Analizando la función getInputPrice, podemos saber que la fórmula para calcular la cantidad de ETH obtenida es

Poniendo esta fórmula en el contexto de la función ethToTokenInput, la fórmula se convierte en

Según esta fórmula, durante un proceso normal de conversión de imBTC a ETH, la reserva de imBTC como denominador es Después el intercambio, debería aumentar, y las reservas de ETH correspondientes se reducirán.

Sin embargo, mirando hacia atrás en el método de operación del atacante, cuando el atacante primero envía imBTC para intercambiar por ETH, Uniswap primero enviará ETH al atacante. En este momento, la reserva de ETH en Uniswap disminuye, y luego Uniswap llama a la función transferFrom (tenga en cuenta que el imBTC del atacante no se ha deducido en este momento), y luego la segunda llamada del atacante en la función transferFrom Cuando ethToTokenSwapInput veces, la fórmula para obtener la cantidad de ETH intercambiada a través de getInputPrice será la siguiente:

Preste atención, en el segundo cálculo de intercambio, solo ha disminuido la reserva de ETH, mientras que imBTC Las reservas de ethToTokenSwapInput no han aumentado, lo que lleva al hecho de que, en comparación con llamar solo a la función ethToTokenSwapInput, el atacante puede cambiar el numerador de la fórmula de cálculo en el proceso de usar imBTC para intercambiar ETH por segunda vez a través del reingreso, mientras que la fórmula El denominador de no cambiará. En comparación con el intercambio normal, el segundo intercambio realizado por el atacante a través del método de reingreso obtendrá una pequeña ganancia, lo que resultará en una ganancia. Al repetir este proceso, se pueden obtener más ETH a través de la misma cantidad de imBTC, lo que resulta en la pérdida de operadores comerciales de Uniswap.

Método de defensa

1. Agregue la función ReentrancyGuard de OpenZeppelin a la función tokenToEthSwapInput de Uniswap para evitar la reentrada.

2. Al realizar el intercambio de tokens, primero deduzca el token del usuario y luego envíe ETH al usuario.

Al mismo tiempo, para este ataque, el equipo de seguridad de SlowMist recomienda:

1. Agregue un mecanismo de bloqueo a los métodos clave de operación comercial, como: ReentrancyGuard de OpenZeppelin

2. Al desarrollar un contrato, use el estilo de escritura de cambiar primero las variables de este contrato y luego hacer llamadas externas

3. Antes de que el proyecto entre en línea, se invita a un excelente equipo de seguridad externo a realizar una auditoría de seguridad integral para descubrir posibles problemas de seguridad tanto como sea posible.

4. Cuando se conectan múltiples contratos, también es necesario verificar la seguridad del código y la seguridad comercial de los contratos de múltiples partes, y considerar completamente los problemas de seguridad bajo la combinación de varios escenarios comerciales.

5. Establezca el interruptor de pausa tanto como sea posible en el contrato, de modo que cuando ocurra un evento de "cisne negro", se pueda detectar a tiempo y detener la pérdida.

6. La seguridad es dinámica, y cada parte del proyecto también necesita capturar inteligencia de amenazas que pueda estar relacionada con su propio proyecto de manera oportuna, e investigar oportunamente los posibles riesgos de seguridad.

Reflexiones finales

El mundo DeFi ha estado alborotado en los últimos dos días. imBTC es el primero en llevar la peor parte del token ERC777, y el protocolo ERC777 también ha sido criticado. Sin embargo, después de leer el análisis, la causa de este ataque es realmente un problema. con imBTC o el protocolo ERC777?

Si Uniswap es compatible con ERC777, usa ReentrancyGuard y primero deduce los tokens del usuario durante el intercambio de tokens y luego envía ETH al usuario, ¿no ocurrirán tales problemas?

Como imBTC es un protocolo de Bitcoin tokenizado en Ethereum, su seguridad no es un problema cuando se ejecuta solo. Las plataformas DeFi de terceros deben considerar completamente la lógica comercial y el acceso de la plataforma al acceder a ella. La compatibilidad entre tokens puede evitar problemas de seguridad innecesarios. debido a la compatibilidad. En lugar de simplemente culpar del problema al protocolo y al proveedor del token.

Tags：

DOGE