Revisión y reflexión sobre la acción de rescate de emergencia de Web3
El 18 de enero de 2022, nuestro sistema de monitoreo de transacciones anómalas detectó un ataque al proyecto AnySwap (, es decir, Multichain ). Debido a una vulnerabilidad en la función anySwapOutUnderlyingWithPermit(), los tokens autorizados por los usuarios a este proyecto podían ser robados por los atacantes.
A pesar de que el equipo del proyecto ha tomado diversas medidas para recordar a los usuarios afectados (, como enviar recordatorios de transacción ), muchos usuarios no retiraron a tiempo su autorización, lo que permitió a los atacantes seguir obteniendo ganancias.
Dado que el ataque aún está en curso, el equipo de BlockSec ha decidido tomar medidas de respuesta de emergencia para proteger a las posibles víctimas. Nos enfocamos principalmente en las cuentas afectadas en Ethereum, transfiriendo los fondos relevantes a una cuenta de múltiples firmas establecida específicamente para este propósito. Para garantizar la transparencia de la acción, haremos pública la hash del documento del resumen del plan ( no contenido ) a la comunidad, lo que nos permitirá distinguir nuestras acciones de las de los atacantes sin revelar detalles. La operación de rescate comenzó el 21 de enero de 2022 y concluyó el 11 de marzo.
Los esfuerzos de emergencia se enfrentan a numerosos desafíos técnicos y no técnicos. Ahora que la acción ha terminado, podemos revisar todo el proceso y compartir experiencias y conocimientos relevantes con la comunidad, con la esperanza de que puedan contribuir a la seguridad del ecosistema DeFi.
Resumen breve
El uso generalizado de Flashbots ha llevado a una intensa competencia entre los hackers éticos y los atacantes, así como dentro de cada uno de sus grupos, y las tarifas pagadas también han crecido rápidamente con el tiempo.
Flashbots no son infalibles, algunos atacantes optan por utilizar el mempool, implementando ataques de manera astuta al organizar transacciones de ataque exitosas.
Algunos atacantes llegaron a un acuerdo con el equipo del proyecto, devolviendo parte de las ganancias y reteniendo una parte como recompensa, logrando así "blanquear" el dinero. Esta práctica ha suscitado controversia en la comunidad.
Los hackers de sombrero blanco pueden actuar públicamente hacia la comunidad sin revelar información sensible, este método de construcción de confianza es efectivo.
La colaboración de todas las partes de la comunidad puede hacer que el rescate sea más rápido y efectivo, como la cooperación entre los hackers éticos para reducir la competencia ineficaz.
A continuación, discutiremos desde cuatro aspectos: primero, revisaremos la situación general del evento, luego presentaremos los métodos de rescate y los desafíos enfrentados, después compartiremos nuestras experiencias durante la acción, y finalmente, haremos algunas recomendaciones.
Resumen de la situación de ataque y rescate
Resultado general
El rango de tiempo que observamos es del 18 de enero de 2022 al 20 de marzo de 2022. La situación general es la siguiente:
9 cuentas de rescate protegieron 483.027693 ETH, de las cuales se pagaron tarifas de Flashbots 295.970554 ETH( ocupando el 61.27%)
21 cuentas de ataque obtuvieron ganancias de 1433.092224 ETH, pagaron tarifas de Flashbots de 148.903707 ETH( representa el 10.39%)
Es importante tener en cuenta que, debido a algunas situaciones complejas (, como el hecho de que los atacantes devuelvan parte de las ganancias tras negociar con el proyecto, estos datos son solo estadísticas aproximadas.
) Tendencia de cambios en las tarifas de Flashbots
Los "white hats" necesitan competir con los atacantes para enviar transacciones de Flashbots y llevar a cabo el rescate, los costos pagados reflejan el nivel de competencia. Hemos contabilizado la proporción de tarifas de Flashbots de las transacciones de ataque y rescate por bloque de transacción.
Al principio, algunas tarifas de Flashbots para ataques a transacciones eran 0, lo que indica que los atacantes aún no estaban utilizando Flashbots. Luego, la proporción de tarifas aumentó rápidamente, alcanzando incluso el 80% y el 91% en ciertos bloques. Esto indica que se ha transformado en una carrera armamentista de tarifas por el derecho a ser incluido en Flashbots.
Las acciones de rescate que implementamos y los desafíos que enfrentamos
) La idea básica de la operación de rescate
Hemos monitoreado un grupo de cuentas potencialmente afectadas que han autorizado WETH a un contrato problemático. Cuando se transfiere WETH a estas cuentas, aprovechamos una vulnerabilidad del contrato para transferirlo a una billetera multi-firma de sombrero blanco. La clave es cumplir con los siguientes tres puntos:
Localizar eficazmente la transacción de transferencia al víctima ### transacción de transferencia (
Construir correctamente la transacción de rescate ) rescate transacción (
Éxito al adelantarse a las transacciones de los atacantes ) u otros terceros (, transacciones de ataque ).
Los dos primeros puntos no representan un obstáculo para nosotros, porque tenemos un sistema para monitorear el mempool y herramientas para construir automáticamente transacciones de rescate. Pero el tercer punto sigue siendo un desafío.
Aunque teóricamente se puede ganar un front-running con Flashbots, en la práctica no es fácil. Primero, los atacantes también pueden usar Flashbots, y la tasa de éxito depende de la altura de la oferta. En segundo lugar, la competencia feroz significa que Flashbots no siempre es la mejor opción, también enviamos transacciones normales a través de mempool. Por último, también competimos con otros "white hats", y ciertos comportamientos de algunos supuestos "white hats" son en realidad bastante sospechosos.
( situación competitiva
Intentamos proteger 171 cuentas de posibles víctimas independientes. De ellas, 10 revocaron a tiempo la autorización para autoprotegerse, y de las 161 restantes, solo logramos rescatar 14. Los fracasos involucraron 3 cuentas de rescate y 16 cuentas atacantes.
Durante el proceso de rescate, fuimos derrotados 12 veces por otros competidores, incluidos 2 cuentas de rescate y 10 cuentas de ataque.
Nuestra estrategia es bastante conservadora, tendemos a establecer tarifas de Flashbots más bajas para proteger los intereses de las víctimas. A menos que ya haya transacciones de ataque exitosas que utilicen Flashbots, no proactivamente usaremos o aumentaremos las tarifas. Sin embargo, esta estrategia no ha sido efectiva, ya que los oponentes suelen ser más agresivos:
Un atacante estableció la proporción de tarifas en un 70%
Un hacker de sombrero blanco estableció la proporción de tarifas en 79% y 80%
Otro hacker ético estableció la proporción de tarifas en 81%
El atacante luego aumentó la proporción de tarifas al 86%
Esto parece ser un juego de suma cero, donde es necesario modelar y explorar los patrones de comportamiento de las partes involucradas. En la práctica, es un desafío encontrar la estrategia óptima para ganar la competencia mientras se busca reducir costos al mínimo.
La intensa competencia significa que Flashbots no siempre puede funcionar. Al enviar transacciones normales a través del mempool, si se pueden programar en la posición adecuada ) justo después de la transacción de transferencia ###, también se puede lograr el objetivo.
Un atacante utilizó esta estrategia para obtener 312 ETH de ganancias, sin tener que pagar tarifas de Flashbots. Por ejemplo:
Bloque 14051020: la transacción de la víctima está en 65, la transacción del ataque está en 66
Bloque 14052155: la transacción de la víctima se encuentra en 161, la transacción de ataque se encuentra en 164
Esta ingeniosa estrategia combina practicidad e inspiración, lo que merece atención.
Otras reflexiones
( Definición de hackers éticos y atacantes
Identificar a un white hat no siempre es sencillo. Por ejemplo, una cuenta fue marcada inicialmente como atacante, pero tras negociaciones con el equipo del proyecto, se acordó retener 50 ETH como recompensa y devolver las demás ganancias, y luego fue reclasificada como white hat.
Este fenómeno no es la primera vez que aparece, su equidad en el mecanismo de incentivos ha generado controversia en la comunidad.
) Competencia entre hackers éticos
Es necesario que la comunidad establezca un mecanismo de coordinación para reducir la competencia entre los hackers de sombrero blanco. Esta competencia no solo malgasta recursos, sino que también eleva los costos de rescate. Por ejemplo, nosotros y otras tres organizaciones de hackers de sombrero blanco intentamos proteger simultáneamente a 54 víctimas ### involucrando 450 ETH###. Sin un mecanismo de coordinación, es difícil para los hackers de sombrero blanco renunciar o detener esta competencia.
( mejorar las operaciones de rescate
Los hackers de sombrero blanco pueden realizar acciones públicamente en la comunidad sin revelar información sensible, y esta práctica es efectiva.
Las diversas partes de la comunidad pueden colaborar para mejorar la eficiencia de rescate:
Flashbots/mineros proporcionan un acceso preferencial a los sombreros blancos de confianza
El equipo del proyecto asume los costos de Flashbots
El equipo del proyecto adopta un mecanismo de alerta para usuarios más conveniente
El equipo del proyecto ha incorporado medidas de emergencia en el código.
A través de los esfuerzos conjuntos de todas las partes, podemos enfrentar mejor los desafíos de seguridad en el ecosistema Web3 y proteger los intereses de los usuarios.
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.
18 me gusta
Recompensa
18
7
Republicar
Compartir
Comentar
0/400
WinterWarmthCat
· hace3h
El fallo es demasiado grave, frens.
Ver originalesResponder0
SellLowExpert
· hace4h
Otra vez hay que reducir pérdidas para el bail-in.
Ver originalesResponder0
SchrodingerAirdrop
· 08-06 16:46
Prevenir es lo más importante.
Ver originalesResponder0
ShibaSunglasses
· 08-05 22:39
Análisis de casos clásicos de Hacker
Ver originalesResponder0
LiquiditySurfer
· 08-05 22:28
La ayuda fue oportuna y muy profesional.
Ver originalesResponder0
MidnightTrader
· 08-05 22:25
La prevención siempre es más importante que el rescate
Ver originalesResponder0
SmartContractWorker
· 08-05 22:18
El código del contrato debe ser revisado más de una vez.
Registro de ataques y defensas en Web3: Experiencias y lecciones de la operación de rescate de AnySwap
Revisión y reflexión sobre la acción de rescate de emergencia de Web3
El 18 de enero de 2022, nuestro sistema de monitoreo de transacciones anómalas detectó un ataque al proyecto AnySwap (, es decir, Multichain ). Debido a una vulnerabilidad en la función anySwapOutUnderlyingWithPermit(), los tokens autorizados por los usuarios a este proyecto podían ser robados por los atacantes.
A pesar de que el equipo del proyecto ha tomado diversas medidas para recordar a los usuarios afectados (, como enviar recordatorios de transacción ), muchos usuarios no retiraron a tiempo su autorización, lo que permitió a los atacantes seguir obteniendo ganancias.
Dado que el ataque aún está en curso, el equipo de BlockSec ha decidido tomar medidas de respuesta de emergencia para proteger a las posibles víctimas. Nos enfocamos principalmente en las cuentas afectadas en Ethereum, transfiriendo los fondos relevantes a una cuenta de múltiples firmas establecida específicamente para este propósito. Para garantizar la transparencia de la acción, haremos pública la hash del documento del resumen del plan ( no contenido ) a la comunidad, lo que nos permitirá distinguir nuestras acciones de las de los atacantes sin revelar detalles. La operación de rescate comenzó el 21 de enero de 2022 y concluyó el 11 de marzo.
Los esfuerzos de emergencia se enfrentan a numerosos desafíos técnicos y no técnicos. Ahora que la acción ha terminado, podemos revisar todo el proceso y compartir experiencias y conocimientos relevantes con la comunidad, con la esperanza de que puedan contribuir a la seguridad del ecosistema DeFi.
Resumen breve
El uso generalizado de Flashbots ha llevado a una intensa competencia entre los hackers éticos y los atacantes, así como dentro de cada uno de sus grupos, y las tarifas pagadas también han crecido rápidamente con el tiempo.
Flashbots no son infalibles, algunos atacantes optan por utilizar el mempool, implementando ataques de manera astuta al organizar transacciones de ataque exitosas.
Algunos atacantes llegaron a un acuerdo con el equipo del proyecto, devolviendo parte de las ganancias y reteniendo una parte como recompensa, logrando así "blanquear" el dinero. Esta práctica ha suscitado controversia en la comunidad.
Los hackers de sombrero blanco pueden actuar públicamente hacia la comunidad sin revelar información sensible, este método de construcción de confianza es efectivo.
La colaboración de todas las partes de la comunidad puede hacer que el rescate sea más rápido y efectivo, como la cooperación entre los hackers éticos para reducir la competencia ineficaz.
A continuación, discutiremos desde cuatro aspectos: primero, revisaremos la situación general del evento, luego presentaremos los métodos de rescate y los desafíos enfrentados, después compartiremos nuestras experiencias durante la acción, y finalmente, haremos algunas recomendaciones.
Resumen de la situación de ataque y rescate
Resultado general
El rango de tiempo que observamos es del 18 de enero de 2022 al 20 de marzo de 2022. La situación general es la siguiente:
Es importante tener en cuenta que, debido a algunas situaciones complejas (, como el hecho de que los atacantes devuelvan parte de las ganancias tras negociar con el proyecto, estos datos son solo estadísticas aproximadas.
![])https://img-cdn.gateio.im/webp-social/moments-502b402f7119932988948ba461367a19.webp(
) Tendencia de cambios en las tarifas de Flashbots
Los "white hats" necesitan competir con los atacantes para enviar transacciones de Flashbots y llevar a cabo el rescate, los costos pagados reflejan el nivel de competencia. Hemos contabilizado la proporción de tarifas de Flashbots de las transacciones de ataque y rescate por bloque de transacción.
Al principio, algunas tarifas de Flashbots para ataques a transacciones eran 0, lo que indica que los atacantes aún no estaban utilizando Flashbots. Luego, la proporción de tarifas aumentó rápidamente, alcanzando incluso el 80% y el 91% en ciertos bloques. Esto indica que se ha transformado en una carrera armamentista de tarifas por el derecho a ser incluido en Flashbots.
![]###https://img-cdn.gateio.im/webp-social/moments-30d2c3346816e15ab7c89a6a25d0ad83.webp(
Las acciones de rescate que implementamos y los desafíos que enfrentamos
) La idea básica de la operación de rescate
Hemos monitoreado un grupo de cuentas potencialmente afectadas que han autorizado WETH a un contrato problemático. Cuando se transfiere WETH a estas cuentas, aprovechamos una vulnerabilidad del contrato para transferirlo a una billetera multi-firma de sombrero blanco. La clave es cumplir con los siguientes tres puntos:
Los dos primeros puntos no representan un obstáculo para nosotros, porque tenemos un sistema para monitorear el mempool y herramientas para construir automáticamente transacciones de rescate. Pero el tercer punto sigue siendo un desafío.
Aunque teóricamente se puede ganar un front-running con Flashbots, en la práctica no es fácil. Primero, los atacantes también pueden usar Flashbots, y la tasa de éxito depende de la altura de la oferta. En segundo lugar, la competencia feroz significa que Flashbots no siempre es la mejor opción, también enviamos transacciones normales a través de mempool. Por último, también competimos con otros "white hats", y ciertos comportamientos de algunos supuestos "white hats" son en realidad bastante sospechosos.
( situación competitiva
Intentamos proteger 171 cuentas de posibles víctimas independientes. De ellas, 10 revocaron a tiempo la autorización para autoprotegerse, y de las 161 restantes, solo logramos rescatar 14. Los fracasos involucraron 3 cuentas de rescate y 16 cuentas atacantes.
![])https://img-cdn.gateio.im/webp-social/moments-d22626977feebe325b02c899454022c7.webp###
Lecciones aprendidas
( Configuración de tarifas de Flashbots
Durante el proceso de rescate, fuimos derrotados 12 veces por otros competidores, incluidos 2 cuentas de rescate y 10 cuentas de ataque.
Nuestra estrategia es bastante conservadora, tendemos a establecer tarifas de Flashbots más bajas para proteger los intereses de las víctimas. A menos que ya haya transacciones de ataque exitosas que utilicen Flashbots, no proactivamente usaremos o aumentaremos las tarifas. Sin embargo, esta estrategia no ha sido efectiva, ya que los oponentes suelen ser más agresivos:
Esto parece ser un juego de suma cero, donde es necesario modelar y explorar los patrones de comportamiento de las partes involucradas. En la práctica, es un desafío encontrar la estrategia óptima para ganar la competencia mientras se busca reducir costos al mínimo.
![])https://img-cdn.gateio.im/webp-social/moments-3a365a505b5c5ac87a42a6d277af23ff.webp###
( Ordenación de transacciones en Mempool
La intensa competencia significa que Flashbots no siempre puede funcionar. Al enviar transacciones normales a través del mempool, si se pueden programar en la posición adecuada ) justo después de la transacción de transferencia ###, también se puede lograr el objetivo.
Un atacante utilizó esta estrategia para obtener 312 ETH de ganancias, sin tener que pagar tarifas de Flashbots. Por ejemplo:
Esta ingeniosa estrategia combina practicidad e inspiración, lo que merece atención.
Otras reflexiones
( Definición de hackers éticos y atacantes
Identificar a un white hat no siempre es sencillo. Por ejemplo, una cuenta fue marcada inicialmente como atacante, pero tras negociaciones con el equipo del proyecto, se acordó retener 50 ETH como recompensa y devolver las demás ganancias, y luego fue reclasificada como white hat.
Este fenómeno no es la primera vez que aparece, su equidad en el mecanismo de incentivos ha generado controversia en la comunidad.
) Competencia entre hackers éticos
Es necesario que la comunidad establezca un mecanismo de coordinación para reducir la competencia entre los hackers de sombrero blanco. Esta competencia no solo malgasta recursos, sino que también eleva los costos de rescate. Por ejemplo, nosotros y otras tres organizaciones de hackers de sombrero blanco intentamos proteger simultáneamente a 54 víctimas ### involucrando 450 ETH###. Sin un mecanismo de coordinación, es difícil para los hackers de sombrero blanco renunciar o detener esta competencia.
( mejorar las operaciones de rescate
Los hackers de sombrero blanco pueden realizar acciones públicamente en la comunidad sin revelar información sensible, y esta práctica es efectiva.
Las diversas partes de la comunidad pueden colaborar para mejorar la eficiencia de rescate:
A través de los esfuerzos conjuntos de todas las partes, podemos enfrentar mejor los desafíos de seguridad en el ecosistema Web3 y proteger los intereses de los usuarios.
![])https://img-cdn.gateio.im/webp-social/moments-adbfab235ed4a4c2a3ef7a58915c4deb.webp###