Revisión de la acción de rescate de emergencia de la cadena de bloques: experiencias y enseñanzas
El 18 de enero de 2022, nuestro sistema de monitoreo de transacciones anormales detectó un ataque contra el proyecto AnySwap (, es decir, Multichain ). Debido a una vulnerabilidad en la función del contrato, los tokens autorizados por los usuarios para este proyecto podían ser extraídos por los atacantes. A pesar de que el equipo del proyecto intentó advertir a los usuarios, muchos no pudieron revocar la autorización a tiempo, lo que permitió que los atacantes siguieran obteniendo ganancias.
Para proteger a las posibles víctimas, el equipo de BlockSec ha decidido tomar medidas de respuesta de emergencia. Hemos transferido los fondos de las cuentas afectadas en Ethereum a una cuenta multi-firma establecida específicamente para este propósito. Para garantizar la transparencia, haremos público el hash del documento del plan de acción ( que no contiene el contenido ) a la comunidad. La operación de rescate comenzó el 21 de enero de 2022 y finalizó el 11 de marzo.
La asistencia de emergencia enfrenta numerosos desafíos técnicos y no técnicos. Ahora que la acción ha terminado, revisaremos todo el proceso, compartiremos experiencias relevantes y esperamos que esto ayude a la seguridad del ecosistema DeFi.
Principales hallazgos:
El amplio uso de Flashbots ha llevado a una intensa competencia entre los hackers éticos y los atacantes, así como dentro de cada uno de sus grupos. Las tarifas pagadas a Flashbots han crecido rápidamente con el tiempo.
Flashbots no siempre son efectivos. Algunos atacantes recurren a mempool y, mediante estrategias ingeniosas, logran llevar a cabo ataques.
Algunos atacantes llegaron a un acuerdo con el equipo del proyecto para devolver parte de las ganancias y retener una parte como recompensa, logrando así "blanquearse". Esta práctica ha generado controversia en la comunidad.
Los hackers de sombrero blanco pueden revelar sus acciones a la comunidad sin divulgar información sensible, y esta práctica ha demostrado ser efectiva en la práctica.
La colaboración de todas las fuerzas de la comunidad puede hacer que el rescate sea más rápido y efectivo, como la cooperación entre los hackers éticos, reduciendo la competencia inútil.
A continuación se discutirá desde cuatro aspectos: revisión general del evento, métodos de rescate y desafíos, lecciones aprendidas y recomendaciones.
Resumen de la situación de ataques y rescates
Resultado general
En nuestro ámbito de observación ( del 18 de enero de 2022 al 20 de marzo de 2022, la situación general de ataques y rescates es la siguiente:
9 cuentas de rescate protegieron 483.027693 ETH, pagaron tarifas de Flashbots 295.970554 ETH) representa el 61.27%(.
21 cuentas de ataque obtuvieron 1433.092224 ETH, pagaron tarifas de Flashbots 148.903707 ETH) representa el 10.39%(.
Es necesario tener en cuenta que, debido a que algunos atacantes han negociado con el equipo del proyecto la devolución de parte de las ganancias, las etiquetas de las direcciones pueden cambiar, y los datos estadísticos son solo para referencia.
) Tendencia de cambios en las tarifas de Flashbots
Para evaluar el grado de competencia, contabilizamos el porcentaje de las tarifas de Flashbots de transacciones de ataque y rescate por bloque.
Los costos de transacción de ataque inicial de Flashbots son 0, lo que indica que los atacantes aún no han utilizado Flashbots. Luego, la proporción de costos aumenta rápidamente, alcanzando en algunos bloques incluso el 80%-91%. Esto refleja una carrera armamentista de costos provocada por la competencia por el derecho a ser incluido en la cadena de bloques de Flashbots.
Implementación y desafíos de la operación de rescate
) Método de rescate
La idea básica del rescate es monitorear las cuentas potencialmente afectadas y transferir inmediatamente a una billetera multifirma de sombrero blanco cuando se transfiera WETH. La clave es cumplir con los siguientes requisitos:
Localización efectiva de la transacción de transferencia a la víctima Bloquear ### transacción de transferencia Bloquear (
Construir correctamente una transacción de rescate
Transacciones de atacantes que ejecutaron con éxito un ataque de carrera
Los dos primeros puntos no nos constituyen un obstáculo, pero el tercer punto sigue siendo un desafío. Aunque teóricamente se puede usar Flashbots para adelantarse, en la práctica no es fácil. También utilizamos mempool para enviar transacciones ordinarias, y debemos considerar la posición y el orden de las transacciones en el mempool. Además, también debemos enfrentar la competencia de otros "hackers éticos".
) Situación competitiva
Intentamos proteger 171 cuentas potencialmente afectadas, de las cuales 10 revocaron la autorización por sí solas. De las 161 restantes, solo logramos rescatar 14. Las razones del fracaso incluyen la competencia con 3 cuentas de rescate y 16 cuentas de ataque.
Adoptamos una estrategia más conservadora para establecer las tarifas de Flashbots, con el fin de proteger lo mejor posible los intereses de las víctimas. Sin embargo, esta estrategia no ha sido efectiva, ya que los oponentes suelen ser más agresivos, y la proporción de tarifas ha llegado a ser del 70% al 86%.
Parece un juego de suma cero, que requiere buscar un equilibrio entre la reducción de costos y la obtención de la competencia.
Debido a la intensa competencia de Flashbots, no siempre es efectivo. Enviar transacciones comunes a través de mempool también es una opción viable, la clave es programar la transacción en la posición adecuada - justo después de la transacción de transferencia.
Un atacante ha logrado obtener 312 ETH utilizando esta estrategia sin tener que pagar las tarifas de Flashbots. Este ingenioso método merece atención y estudio.
) Distinguir entre el sombrero blanco y el atacante
Identificar a los hackers de sombrero blanco no siempre es intuitivo. Algunas cuentas que inicialmente fueron marcadas como atacantes, luego "se blanquean" al negociar con el equipo del proyecto para devolver parte de las ganancias. Esta práctica ha generado controversia en la comunidad.
Competencia entre sombreros blancos
Es necesario establecer un mecanismo de coordinación para reducir la competencia entre los Bloquear de sombrero blanco, evitando el desperdicio de recursos y el aumento de costos. En esta acción, múltiples organizaciones de sombrero blanco intentaron al mismo tiempo proteger a un mismo grupo de víctimas, lo que agravó el aumento de tarifas de Flashbots.
Optimización de la acción de rescate
Sugerencia:
El sombrero blanco declara públicamente su comportamiento sin revelar información sensible, para ganar la confianza de la comunidad.
Flashbots/mineros proporcionan un canal verde para los sombreros blancos confiables
El equipo del proyecto asume los costos de Flashbots
El equipo del proyecto mejoró el mecanismo de alerta para los usuarios
El equipo del proyecto ha incorporado medidas de emergencia en el código.
En resumen, la colaboración de todas las partes de la comunidad puede hacer que el rescate sea más rápido y eficaz. Esta experiencia tiene un importante valor de referencia para el manejo de situaciones similares en el futuro.
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
4
Compartir
Comentar
0/400
RiddleMaster
· hace5h
Otra vez he perdido bastante moneda.
Ver originalesResponder0
HodlKumamon
· 07-19 18:16
¡El sombrero blanco ha salvado a los tontos~
Ver originalesResponder0
TokenEconomist
· 07-18 22:22
en realidad, este es un clásico problema de principal-agente en defi... información asimétrica + respuesta tardía del usuario = exploits inevitables
Ver originalesResponder0
MondayYoloFridayCry
· 07-18 22:21
¿Para qué sirve este análisis? Mejor correr directamente.
Cadena de bloques de acción de rescate de emergencia: Experiencias y lecciones del incidente de ataque de AnySwap
Revisión de la acción de rescate de emergencia de la cadena de bloques: experiencias y enseñanzas
El 18 de enero de 2022, nuestro sistema de monitoreo de transacciones anormales detectó un ataque contra el proyecto AnySwap (, es decir, Multichain ). Debido a una vulnerabilidad en la función del contrato, los tokens autorizados por los usuarios para este proyecto podían ser extraídos por los atacantes. A pesar de que el equipo del proyecto intentó advertir a los usuarios, muchos no pudieron revocar la autorización a tiempo, lo que permitió que los atacantes siguieran obteniendo ganancias.
Para proteger a las posibles víctimas, el equipo de BlockSec ha decidido tomar medidas de respuesta de emergencia. Hemos transferido los fondos de las cuentas afectadas en Ethereum a una cuenta multi-firma establecida específicamente para este propósito. Para garantizar la transparencia, haremos público el hash del documento del plan de acción ( que no contiene el contenido ) a la comunidad. La operación de rescate comenzó el 21 de enero de 2022 y finalizó el 11 de marzo.
La asistencia de emergencia enfrenta numerosos desafíos técnicos y no técnicos. Ahora que la acción ha terminado, revisaremos todo el proceso, compartiremos experiencias relevantes y esperamos que esto ayude a la seguridad del ecosistema DeFi.
Principales hallazgos:
El amplio uso de Flashbots ha llevado a una intensa competencia entre los hackers éticos y los atacantes, así como dentro de cada uno de sus grupos. Las tarifas pagadas a Flashbots han crecido rápidamente con el tiempo.
Flashbots no siempre son efectivos. Algunos atacantes recurren a mempool y, mediante estrategias ingeniosas, logran llevar a cabo ataques.
Algunos atacantes llegaron a un acuerdo con el equipo del proyecto para devolver parte de las ganancias y retener una parte como recompensa, logrando así "blanquearse". Esta práctica ha generado controversia en la comunidad.
Los hackers de sombrero blanco pueden revelar sus acciones a la comunidad sin divulgar información sensible, y esta práctica ha demostrado ser efectiva en la práctica.
La colaboración de todas las fuerzas de la comunidad puede hacer que el rescate sea más rápido y efectivo, como la cooperación entre los hackers éticos, reduciendo la competencia inútil.
A continuación se discutirá desde cuatro aspectos: revisión general del evento, métodos de rescate y desafíos, lecciones aprendidas y recomendaciones.
Resumen de la situación de ataques y rescates
Resultado general
En nuestro ámbito de observación ( del 18 de enero de 2022 al 20 de marzo de 2022, la situación general de ataques y rescates es la siguiente:
9 cuentas de rescate protegieron 483.027693 ETH, pagaron tarifas de Flashbots 295.970554 ETH) representa el 61.27%(. 21 cuentas de ataque obtuvieron 1433.092224 ETH, pagaron tarifas de Flashbots 148.903707 ETH) representa el 10.39%(.
Es necesario tener en cuenta que, debido a que algunos atacantes han negociado con el equipo del proyecto la devolución de parte de las ganancias, las etiquetas de las direcciones pueden cambiar, y los datos estadísticos son solo para referencia.
![])https://img-cdn.gateio.im/webp-social/moments-502b402f7119932988948ba461367a19.webp(
) Tendencia de cambios en las tarifas de Flashbots
Para evaluar el grado de competencia, contabilizamos el porcentaje de las tarifas de Flashbots de transacciones de ataque y rescate por bloque.
Los costos de transacción de ataque inicial de Flashbots son 0, lo que indica que los atacantes aún no han utilizado Flashbots. Luego, la proporción de costos aumenta rápidamente, alcanzando en algunos bloques incluso el 80%-91%. Esto refleja una carrera armamentista de costos provocada por la competencia por el derecho a ser incluido en la cadena de bloques de Flashbots.
![]###https://img-cdn.gateio.im/webp-social/moments-30d2c3346816e15ab7c89a6a25d0ad83.webp(
Implementación y desafíos de la operación de rescate
) Método de rescate
La idea básica del rescate es monitorear las cuentas potencialmente afectadas y transferir inmediatamente a una billetera multifirma de sombrero blanco cuando se transfiera WETH. La clave es cumplir con los siguientes requisitos:
Los dos primeros puntos no nos constituyen un obstáculo, pero el tercer punto sigue siendo un desafío. Aunque teóricamente se puede usar Flashbots para adelantarse, en la práctica no es fácil. También utilizamos mempool para enviar transacciones ordinarias, y debemos considerar la posición y el orden de las transacciones en el mempool. Además, también debemos enfrentar la competencia de otros "hackers éticos".
) Situación competitiva
Intentamos proteger 171 cuentas potencialmente afectadas, de las cuales 10 revocaron la autorización por sí solas. De las 161 restantes, solo logramos rescatar 14. Las razones del fracaso incluyen la competencia con 3 cuentas de rescate y 16 cuentas de ataque.
![]###https://img-cdn.gateio.im/webp-social/moments-d22626977feebe325b02c899454022c7.webp(
Lecciones aprendidas
) Configuración de tarifas de Flashbots
Adoptamos una estrategia más conservadora para establecer las tarifas de Flashbots, con el fin de proteger lo mejor posible los intereses de las víctimas. Sin embargo, esta estrategia no ha sido efectiva, ya que los oponentes suelen ser más agresivos, y la proporción de tarifas ha llegado a ser del 70% al 86%.
Parece un juego de suma cero, que requiere buscar un equilibrio entre la reducción de costos y la obtención de la competencia.
![]###https://img-cdn.gateio.im/webp-social/moments-3a365a505b5c5ac87a42a6d277af23ff.webp(
) Arrangements de transacciones Mempool
Debido a la intensa competencia de Flashbots, no siempre es efectivo. Enviar transacciones comunes a través de mempool también es una opción viable, la clave es programar la transacción en la posición adecuada - justo después de la transacción de transferencia.
Un atacante ha logrado obtener 312 ETH utilizando esta estrategia sin tener que pagar las tarifas de Flashbots. Este ingenioso método merece atención y estudio.
![]###https://img-cdn.gateio.im/webp-social/moments-cb547989448abc96498684cb89da8860.webp(
Otras reflexiones
) Distinguir entre el sombrero blanco y el atacante
Identificar a los hackers de sombrero blanco no siempre es intuitivo. Algunas cuentas que inicialmente fueron marcadas como atacantes, luego "se blanquean" al negociar con el equipo del proyecto para devolver parte de las ganancias. Esta práctica ha generado controversia en la comunidad.
Competencia entre sombreros blancos
Es necesario establecer un mecanismo de coordinación para reducir la competencia entre los Bloquear de sombrero blanco, evitando el desperdicio de recursos y el aumento de costos. En esta acción, múltiples organizaciones de sombrero blanco intentaron al mismo tiempo proteger a un mismo grupo de víctimas, lo que agravó el aumento de tarifas de Flashbots.
Optimización de la acción de rescate
Sugerencia:
En resumen, la colaboración de todas las partes de la comunidad puede hacer que el rescate sea más rápido y eficaz. Esta experiencia tiene un importante valor de referencia para el manejo de situaciones similares en el futuro.
![]###https://img-cdn.gateio.im/webp-social/moments-adbfab235ed4a4c2a3ef7a58915c4deb.webp(