Análisis del incidente de ataque de reentrada de OrionProtocol
El 2 de febrero de 2023, Orion Protocol en Ethereum y Binance Smart Chain sufrió un ataque de reentrada debido a una vulnerabilidad en el contrato, con una pérdida total de aproximadamente 2.9 millones de dólares en activos, que incluye 2,844,766 USDT en Ethereum y 191,606 BUSD en Binance Smart Chain.
Análisis del proceso de ataque
El atacante primero desplegó un contrato de Token personalizado y realizó las operaciones de transferencia y autorización relacionadas, preparándose para el ataque posterior. Luego, el atacante utilizó la función swap de Uniswap V2 para realizar un préstamo y llamó al método ExchangeWithAtomic.swapThroughOrionPool de OrionProtocol para intercambiar tokens.
La ruta de intercambio se establece en [USDC, Token del atacante, USDT], donde el Token del atacante se utiliza para ejecutar operaciones de devolución de llamada. Durante el proceso de intercambio, debido a que el contrato del Token del atacante incluye lógica de devolución de llamada, se produce una llamada de nuevo a la función ExchangeWithAtomic.depositAsset a través de Token.Transfer cuando se ejecuta el método ExchangeWithAtomic.swapThroughOrionPool, lo que permite un ataque de reentrada. Esto hace que el monto del depósito se acumule repetidamente, y al final, el atacante completa la ganancia mediante la operación de retiro.
Flujo de fondos
Los fondos iniciales del atacante provienen de la billetera caliente de una gran plataforma de intercambio. De los 1,651 ETH obtenidos por el ataque, 657.5 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 encuentra en la función doSwapThroughOrionPool. Esta función llama a la función _doSwapTokens, que actualiza la variable curBalance después de realizar la operación de transferencia. El atacante aprovecha la lógica de devolución agregada en la función transfer del Token personalizado, lo que provoca que la función depositAsset se llame nuevamente durante el proceso de transferencia, lo que lleva a una actualización incorrecta de la variable curBalance. Esto permite al atacante retirar fondos adicionales a través de la función withdraw después de reembolsar el préstamo relámpago.
Consejos de seguridad
Para prevenir ataques similares, el equipo del proyecto debe tener en cuenta los siguientes puntos:
Al implementar la función de intercambio de tokens, es necesario considerar los riesgos de seguridad que pueden surgir de los diferentes tipos de tokens y rutas de intercambio.
Seguir estrictamente el patrón de codificación "Checks-Effects-Interactions", es decir, primero realizar una verificación de estado, luego actualizar el estado del contrato y finalmente interactuar con contratos externos.
Implementar mecanismos de seguridad como los bloqueos de reentrada para prevenir la ocurrencia de ataques de reentrada.
Para las funciones clave que implican operaciones de fondos, se debe realizar una auditoría de seguridad y pruebas exhaustivas.
Considerar la introducción de medidas de seguridad adicionales como retiros con retraso o firmas múltiples para aumentar la dificultad de los ataques.
Al tomar estas medidas, se puede reducir significativamente el riesgo de ataques a los contratos inteligentes y mejorar la seguridad general del proyecto. En el ecosistema Web3, la seguridad siempre debe ser un factor primordial 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.
8 me gusta
Recompensa
8
5
Compartir
Comentar
0/400
EntryPositionAnalyst
· hace10h
Otro equipo ha sido descuidado y ha aprendido la lección a costa de pérdidas.
Ver originalesResponder0
BearMarketSurvivor
· hace10h
El campo de batalla principal ha sido atacado nuevamente, con pérdidas de 290w.
Ver originalesResponder0
PaperHandSister
· hace11h
Otra vez arruinado, ¿por qué siempre se fijan en las vulnerabilidades de los contratos?
Ver originalesResponder0
NeverVoteOnDAO
· hace11h
Otra vulnerabilidad en el contrato, no se acaba nunca.
OrionProtocol sufrió un ataque de reentrada, con una pérdida de 2.9 millones de dólares en activos.
Análisis del incidente de ataque de reentrada de OrionProtocol
El 2 de febrero de 2023, Orion Protocol en Ethereum y Binance Smart Chain sufrió un ataque de reentrada debido a una vulnerabilidad en el contrato, con una pérdida total de aproximadamente 2.9 millones de dólares en activos, que incluye 2,844,766 USDT en Ethereum y 191,606 BUSD en Binance Smart Chain.
Análisis del proceso de ataque
El atacante primero desplegó un contrato de Token personalizado y realizó las operaciones de transferencia y autorización relacionadas, preparándose para el ataque posterior. Luego, el atacante utilizó la función swap de Uniswap V2 para realizar un préstamo y llamó al método ExchangeWithAtomic.swapThroughOrionPool de OrionProtocol para intercambiar tokens.
La ruta de intercambio se establece en [USDC, Token del atacante, USDT], donde el Token del atacante se utiliza para ejecutar operaciones de devolución de llamada. Durante el proceso de intercambio, debido a que el contrato del Token del atacante incluye lógica de devolución de llamada, se produce una llamada de nuevo a la función ExchangeWithAtomic.depositAsset a través de Token.Transfer cuando se ejecuta el método ExchangeWithAtomic.swapThroughOrionPool, lo que permite un ataque de reentrada. Esto hace que el monto del depósito se acumule repetidamente, y al final, el atacante completa la ganancia mediante la operación de retiro.
Flujo de fondos
Los fondos iniciales del atacante provienen de la billetera caliente de una gran plataforma de intercambio. De los 1,651 ETH obtenidos por el ataque, 657.5 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 encuentra en la función doSwapThroughOrionPool. Esta función llama a la función _doSwapTokens, que actualiza la variable curBalance después de realizar la operación de transferencia. El atacante aprovecha la lógica de devolución agregada en la función transfer del Token personalizado, lo que provoca que la función depositAsset se llame nuevamente durante el proceso de transferencia, lo que lleva a una actualización incorrecta de la variable curBalance. Esto permite al atacante retirar fondos adicionales a través de la función withdraw después de reembolsar el préstamo relámpago.
Consejos de seguridad
Para prevenir ataques similares, el equipo del proyecto debe tener en cuenta los siguientes puntos:
Al implementar la función de intercambio de tokens, es necesario considerar los riesgos de seguridad que pueden surgir de los diferentes tipos de tokens y rutas de intercambio.
Seguir estrictamente el patrón de codificación "Checks-Effects-Interactions", es decir, primero realizar una verificación de estado, luego actualizar el estado del contrato y finalmente interactuar con contratos externos.
Implementar mecanismos de seguridad como los bloqueos de reentrada para prevenir la ocurrencia de ataques de reentrada.
Para las funciones clave que implican operaciones de fondos, se debe realizar una auditoría de seguridad y pruebas exhaustivas.
Considerar la introducción de medidas de seguridad adicionales como retiros con retraso o firmas múltiples para aumentar la dificultad de los ataques.
Al tomar estas medidas, se puede reducir significativamente el riesgo de ataques a los contratos inteligentes y mejorar la seguridad general del proyecto. En el ecosistema Web3, la seguridad siempre debe ser un factor primordial a considerar.