Análisis del incidente de ataque de reentrada de OrionProtocol
Resumen del evento
Según los datos de monitoreo en cadena, el 2 de febrero de 2023 a las 15:40:20 UTC, OrionProtocol sufrió un ataque de reentrada en Ethereum y Binance Smart Chain debido a una vulnerabilidad en el contrato. El atacante obtuvo ganancias de 2,844,766 USDT de la red de Ethereum y 191,606 BUSD de Binance Smart Chain, totalizando aproximadamente 2.9 millones de dólares.
Análisis del proceso de ataque
Detalles del ataque en la cadena de Ethereum
Token personalizado
Durante el proceso de intercambio, debido a la función de callback incluida en el contrato Token creado por el atacante, el atacante puede llamar repetidamente a la función ExchangeWithAtomic.depositAsset a través del método Token.Transfer durante la ejecución de ExchangeWithAtomic.swapThroughOrionPool. Esto provoca que el monto del depósito se acumule continuamente, y finalmente el atacante completa su ganancia a través de 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 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 actualiza la variable curBalance después de ejecutar la transferencia de tokens, sin seguir el patrón de "Comprobaciones-Efectos-Interacciones" (Checks-Effects-Interactions). Un atacante aprovecha el mecanismo de retroalimentación agregado en la función transfer del Token personalizado, llamando repetidamente a la función depositAsset antes de que se actualice curBalance, lo que resulta en un cálculo incorrecto del saldo.
Sugerencias de prevención
Al diseñar contratos que involucren funciones de intercambio de tokens, el equipo del proyecto debe considerar los riesgos de seguridad que pueden surgir de las múltiples tipos de tokens y rutas de intercambio.
Seguir estrictamente la norma de codificación "verificación-efecto-interacción", es decir, primero realizar la verificación de condiciones, luego actualizar las variables de estado y finalmente ejecutar llamadas externas.
Para las funciones que pueden tener riesgo de reentrada, utiliza mecanismos de protección como bloqueos de reentrada.
Añadir una verificación de saldo antes y después de las operaciones clave para garantizar la atomicidad y consistencia de las transacciones.
Realizar auditorías de código y pruebas de seguridad de forma regular para detectar y corregir vulnerabilidades potenciales a tiempo.
Considerar la implementación de límites en la cantidad de transacciones o en la frecuencia de las transacciones para reducir las pérdidas causadas por un ataque único.
Al adoptar estas medidas, el proyecto puede mejorar significativamente la seguridad del contrato y reducir el riesgo de sufrir ataques similares. En el ecosistema Web3 de rápido desarrollo, la seguridad siempre debería ser la principal consideración.
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.
11 me gusta
Recompensa
11
4
Compartir
Comentar
0/400
BearMarketGardener
· Hace22m
Otra reentrada, ¡todas las verduras han sido arrasadas!
Ver originalesResponder0
Token_Sherpa
· hace9h
ugh... otro día, otro ataque de reentrada. ¿Cuándo aprenderán los desarrolladores a verificar los efectos y las interacciones? smh
OrionProtocol sufre un ataque de reentrada de 2.9 millones de dólares: análisis de vulnerabilidades y recomendaciones de prevención.
Análisis del incidente de ataque de reentrada de OrionProtocol
Resumen del evento
Según los datos de monitoreo en cadena, el 2 de febrero de 2023 a las 15:40:20 UTC, OrionProtocol sufrió un ataque de reentrada en Ethereum y Binance Smart Chain debido a una vulnerabilidad en el contrato. El atacante obtuvo ganancias de 2,844,766 USDT de la red de Ethereum y 191,606 BUSD de Binance Smart Chain, totalizando aproximadamente 2.9 millones de dólares.
Análisis del proceso de ataque
Detalles del ataque en la cadena de Ethereum
Token personalizado
Durante el proceso de intercambio, debido a la función de callback incluida en el contrato Token creado por el atacante, el atacante puede llamar repetidamente a la función ExchangeWithAtomic.depositAsset a través del método Token.Transfer durante la ejecución de ExchangeWithAtomic.swapThroughOrionPool. Esto provoca que el monto del depósito se acumule continuamente, y finalmente el atacante completa su ganancia a través de 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 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 actualiza la variable curBalance después de ejecutar la transferencia de tokens, sin seguir el patrón de "Comprobaciones-Efectos-Interacciones" (Checks-Effects-Interactions). Un atacante aprovecha el mecanismo de retroalimentación agregado en la función transfer del Token personalizado, llamando repetidamente a la función depositAsset antes de que se actualice curBalance, lo que resulta en un cálculo incorrecto del saldo.
Sugerencias de prevención
Al diseñar contratos que involucren funciones de intercambio de tokens, el equipo del proyecto debe considerar los riesgos de seguridad que pueden surgir de las múltiples tipos de tokens y rutas de intercambio.
Seguir estrictamente la norma de codificación "verificación-efecto-interacción", es decir, primero realizar la verificación de condiciones, luego actualizar las variables de estado y finalmente ejecutar llamadas externas.
Para las funciones que pueden tener riesgo de reentrada, utiliza mecanismos de protección como bloqueos de reentrada.
Añadir una verificación de saldo antes y después de las operaciones clave para garantizar la atomicidad y consistencia de las transacciones.
Realizar auditorías de código y pruebas de seguridad de forma regular para detectar y corregir vulnerabilidades potenciales a tiempo.
Considerar la implementación de límites en la cantidad de transacciones o en la frecuencia de las transacciones para reducir las pérdidas causadas por un ataque único.
Al adoptar estas medidas, el proyecto puede mejorar significativamente la seguridad del contrato y reducir el riesgo de sufrir ataques similares. En el ecosistema Web3 de rápido desarrollo, la seguridad siempre debería ser la principal consideración.