Análisis de incidentes de ataque de reentrada de OrionProtocol
El 2 de febrero de 2023 por la tarde, Orion Protocol en Ethereum y Binance Smart Chain sufrió un ataque de reentrada debido a una vulnerabilidad en el contrato, con pérdidas de aproximadamente 2.9 millones de dólares, que incluían 2,844,766 USDT en Ethereum y 191,606 BUSD en Binance Smart Chain.
Análisis del proceso de ataque
El atacante primero creó un contrato de Token y realizó las operaciones de transferencia y autorización relacionadas, preparándose para el ataque posterior. Luego, el atacante tomó prestado mediante el método swap de UNI-V2 y llamó al método swapThroughOrionPool del contrato ExchangeWithAtomic para intercambiar tokens. La ruta de intercambio se estableció como USDC → Token creado por el atacante → USDT.
Durante el proceso de intercambio, debido a que el contrato del Token creado por el atacante contiene una función de callback, al ejecutar el método ExchangeWithAtomic.swapThroughOrionPool, se continúa llamando al método ExchangeWithAtomic.depositAsset a través de Token.Transfer, lo que provoca un ataque de reentrada. Esto hace que el monto del depósito se acumule continuamente, y finalmente el atacante completa la ganancia mediante la operación de retiro.
Flujo de fondos
Los fondos iniciales del atacante provienen de la cuenta de la billetera caliente de una plataforma de intercambio. De las 1,651 ETH obtenidas, 657.5 ETH aún permanecen en la dirección de la billetera del atacante, mientras que el resto ha sido transferido a través de un servicio de mezcla.
Análisis de Vulnerabilidades
El problema central de la vulnerabilidad se presenta en la función doSwapThroughOrionPool. Esta función llama a la función _doSwapTokens, en la cual la operación de transferencia de tokens ocurre antes de que se actualice curBalance. Un atacante aprovecha la función de callback añadida en la función transfer de un Token personalizado, llamando nuevamente a la función depositAsset antes de que se actualice curBalance, lo que provoca una actualización incorrecta de curBalance. Finalmente, tras reembolsar el préstamo relámpago, el atacante extrae los fondos al llamar a la función withdraw, completando así el ataque.
Sugerencias de prevención
Al diseñar el contrato, se deben considerar los riesgos potenciales que pueden surgir de la variedad de Tokens y rutas de intercambio.
Seguir la norma de codificación "primero juzgar, luego actualizar variables, y finalmente realizar llamadas externas" (modelo Checks-Effects-Interactions) puede aumentar efectivamente la seguridad del contrato.
Al implementar la función de intercambio de tokens, es importante prestar especial atención al riesgo de ataques de reentrada, se puede considerar el uso de mecanismos como el bloqueo de reentrada para protección.
Para las funciones clave que implican operaciones de fondos, se recomienda realizar una auditoría y pruebas de seguridad exhaustivas, incluyendo la simulación de diversos casos límite y escenarios anómalos.
Realizar auditorías de seguridad de contratos de forma regular y actualizar y reparar de manera oportuna las vulnerabilidades potenciales.
Al adoptar estas medidas, se puede reducir significativamente el riesgo de que los contratos inteligentes sean atacados, mejorando así la seguridad general del proyecto. En el ecosistema Web3, la seguridad siempre es uno de los factores más importantes a considerar.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
12 me gusta
Recompensa
12
6
Republicar
Compartir
Comentar
0/400
GasFeeCrier
· hace16h
¿No haces bien la protección del contrato? ¡Te lo mereces!
Ver originalesResponder0
AirdropBuffet
· 08-12 21:06
Otra vez un contrato inteligente se cayó~
Ver originalesResponder0
ZenMiner
· 08-12 21:05
¿Por qué no me buscan para auditar con un agujero tan grande?
Ver originalesResponder0
HallucinationGrower
· 08-12 21:00
Otra oportunidad de Rug Pull
Ver originalesResponder0
TokenStorm
· 08-12 20:57
Ay, el script ya está escrito, solo falta un paso.
OrionProtocol sufrió un ataque de reentrada, perdiendo 2.9 millones de dólares en encriptación.
Análisis de incidentes de ataque de reentrada de OrionProtocol
El 2 de febrero de 2023 por la tarde, Orion Protocol en Ethereum y Binance Smart Chain sufrió un ataque de reentrada debido a una vulnerabilidad en el contrato, con pérdidas de aproximadamente 2.9 millones de dólares, que incluían 2,844,766 USDT en Ethereum y 191,606 BUSD en Binance Smart Chain.
Análisis del proceso de ataque
El atacante primero creó un contrato de Token y realizó las operaciones de transferencia y autorización relacionadas, preparándose para el ataque posterior. Luego, el atacante tomó prestado mediante el método swap de UNI-V2 y llamó al método swapThroughOrionPool del contrato ExchangeWithAtomic para intercambiar tokens. La ruta de intercambio se estableció como USDC → Token creado por el atacante → USDT.
Durante el proceso de intercambio, debido a que el contrato del Token creado por el atacante contiene una función de callback, al ejecutar el método ExchangeWithAtomic.swapThroughOrionPool, se continúa llamando al método ExchangeWithAtomic.depositAsset a través de Token.Transfer, lo que provoca un ataque de reentrada. Esto hace que el monto del depósito se acumule continuamente, y finalmente el atacante completa la ganancia mediante la operación de retiro.
Flujo de fondos
Los fondos iniciales del atacante provienen de la cuenta de la billetera caliente de una plataforma de intercambio. De las 1,651 ETH obtenidas, 657.5 ETH aún permanecen en la dirección de la billetera del atacante, mientras que el resto ha sido transferido a través de un servicio de mezcla.
Análisis de Vulnerabilidades
El problema central de la vulnerabilidad se presenta en la función doSwapThroughOrionPool. Esta función llama a la función _doSwapTokens, en la cual la operación de transferencia de tokens ocurre antes de que se actualice curBalance. Un atacante aprovecha la función de callback añadida en la función transfer de un Token personalizado, llamando nuevamente a la función depositAsset antes de que se actualice curBalance, lo que provoca una actualización incorrecta de curBalance. Finalmente, tras reembolsar el préstamo relámpago, el atacante extrae los fondos al llamar a la función withdraw, completando así el ataque.
Sugerencias de prevención
Al diseñar el contrato, se deben considerar los riesgos potenciales que pueden surgir de la variedad de Tokens y rutas de intercambio.
Seguir la norma de codificación "primero juzgar, luego actualizar variables, y finalmente realizar llamadas externas" (modelo Checks-Effects-Interactions) puede aumentar efectivamente la seguridad del contrato.
Al implementar la función de intercambio de tokens, es importante prestar especial atención al riesgo de ataques de reentrada, se puede considerar el uso de mecanismos como el bloqueo de reentrada para protección.
Para las funciones clave que implican operaciones de fondos, se recomienda realizar una auditoría y pruebas de seguridad exhaustivas, incluyendo la simulación de diversos casos límite y escenarios anómalos.
Realizar auditorías de seguridad de contratos de forma regular y actualizar y reparar de manera oportuna las vulnerabilidades potenciales.
Al adoptar estas medidas, se puede reducir significativamente el riesgo de que los contratos inteligentes sean atacados, mejorando así la seguridad general del proyecto. En el ecosistema Web3, la seguridad siempre es uno de los factores más importantes a considerar.