Revisión del incidente de vulnerabilidad Multichain y resumen de la operación de rescate de los hackers éticos
El 18 de enero de 2022, el sistema de monitoreo de transacciones anómalas detectó un ataque contra el proyecto Multichain. Debido a que la función anySwapOutUnderlyingWithPermit() no implementó correctamente el mecanismo de verificación, los tokens autorizados por los usuarios para ese proyecto pudieron ser retirados por los atacantes.
A pesar de que el equipo del proyecto intentó varios métodos para alertar a los usuarios afectados, todavía hay muchos usuarios que no respondieron a tiempo, lo que permitió a los atacantes continuar con el ataque y obtener ganancias.
Para proteger a las posibles víctimas, el equipo de BlockSec ha decidido tomar medidas de respuesta de emergencia. Esta operación de rescate se dirige a las cuentas afectadas en Ethereum, transfiriendo los fondos de las cuentas relevantes a una cuenta de múltiples firmas establecida específicamente para ello. Para garantizar la transparencia de la acción, el hash del documento del plan relacionado se hace público a la comunidad. La operación de rescate comenzó el 21 de enero de 2022 y terminó el 11 de marzo de 2022.
La respuesta de emergencia enfrenta numerosos desafíos técnicos y no técnicos. Este artículo revisa todo el proceso, compartiendo experiencias y reflexiones, con la esperanza de ayudar a la seguridad del ecosistema DeFi.
Resumen breve
Ha surgido una intensa competencia entre los dos grupos, los hackers de sombrero blanco y los atacantes, en el uso de Flashbots, y las tarifas pagadas han aumentado rápidamente.
Flashbots no siempre son efectivos. Algunos atacantes optan por usar mempool, implementando ataques con estrategias astutas.
Algunos atacantes llegaron a un acuerdo con el equipo del proyecto, devolviendo parte de las ganancias y reteniendo parte como recompensa, logrando "blanquearse" exitosamente. Este fenómeno ha suscitado controversia en la comunidad sobre la equidad de los incentivos.
Los hackers de sombrero blanco pueden declarar sus acciones públicamente a la comunidad sin revelar información sensible, ganándose la confianza de la comunidad.
La colaboración de todas las partes de la comunidad puede hacer que las acciones de rescate sean más rápidas y efectivas.
Resumen de la situación de ataque y rescate
Resultado general
En el rango de observación ( 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, pagaron tarifas de Flashbots 295.970554 ETH( representa el 61.27%)
21 cuentas de ataque ganaron 1433.092224 ETH, pagaron tarifas de Flashbots 148.903707 ETH( representa el 10.39%)
Tendencia de cambios en las tarifas de Flashbots
Las tarifas de transacción de ataque inicial de Flashbots son 0, lo que indica que el atacante aún no ha utilizado Flashbots. Posteriormente, la proporción de tarifas aumentó rápidamente, alcanzando incluso el 80%-91% en ciertas alturas de bloque, reflejando la intensa competencia por los derechos en la cadena.
Implementación de la operación de rescate y los desafíos enfrentados
La idea básica de la operación de rescate
Monitorear cuentas de posibles víctimas
Al descubrir la transferencia de WETH, utilizar una vulnerabilidad del contrato para transferirlo a la billetera multi-firma del hacker ético.
Requisitos clave:
Transacción de transferencia efectiva a la víctima
Construir correctamente una transacción de rescate
Ataque exitoso de front-running de transacciones
El principal desafío radica en las transacciones de los atacantes que hacen front-running. Aunque se pueden usar Flashbots, es necesario considerar la estrategia de configuración de tarifas. Al mismo tiempo, debido a la competencia, Flashbots no siempre son la mejor opción.
Situación competitiva
Intentar proteger 171 cuentas de posibles víctimas, de las cuales:
10 auto-protecciones
14 rescates exitosos
147 rescates fallidos
Las razones del fracaso involucran la competencia entre 3 cuentas de rescate y 16 cuentas de ataque.
Lecciones aprendidas
Configuración de tarifas de Flashbots
La estrategia conservadora no funciona bien, los competidores a menudo adoptan estrategias más agresivas:
Un atacante establece la proporción entre el 70% y el 86%
Un hacker ético estableció la proporción entre el 79% y el 81%
Parece un juego de suma cero, donde se necesita encontrar un equilibrio entre reducir costos y ganar competitividad.
Estrategia de ordenación de transacciones Mempool
Debido a la intensa competencia, Flashbots no siempre es efectivo. Enviar transacciones normales a través del mempool y programarlas en la posición adecuada también puede lograr el objetivo.
Un atacante logró obtener 312 ETH utilizando esta estrategia, sin tener que pagar tarifas de Flashbots. La clave está en programar la transacción de ataque después de la transacción de transferencia y lo más cerca posible.
Otras reflexiones
La distinción entre el sombrero blanco y el atacante
No siempre es fácil de distinguir. Una cuenta fue inicialmente marcada como atacante, luego negoció con el equipo del proyecto para devolver parte de las ganancias, reteniendo 50 ETH como recompensa, y finalmente fue reclasificada como sombrero blanco. Este fenómeno ha suscitado controversias sobre la equidad de los incentivos.
Competencia entre los sombreros blancos
Es necesario establecer un mecanismo de coordinación para reducir/evitar la competencia entre los hackers éticos, evitando el desperdicio de recursos y el aumento de costos.
Sugerencias para mejorar las operaciones de rescate
El hacker ético anuncia su comportamiento a la comunidad sin revelar información sensible.
Flashbots/mineros proporcionan un canal verde para los white hats de confianza
El equipo del proyecto asume los costos de Flashbots
El equipo del proyecto adopta un mecanismo de alerta de usuario más conveniente.
El equipo del proyecto toma las medidas de emergencia necesarias en el código.
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
6
Compartir
Comentar
0/400
FOMOSapien
· hace2h
Los hackers de sombrero blanco son realmente confiables.
Ver originalesResponder0
BearMarketBro
· 08-02 18:26
Los chicos son realmente flojos, ni siquiera se escapan del Rug Pull.
Ver originalesResponder0
SilentObserver
· 08-02 18:25
Es un problema de código otra vez, ay.
Ver originalesResponder0
BlockchainThinkTank
· 08-02 18:20
Según la experiencia, se debe tener cuidado con este tipo de vulnerabilidades, un riesgo típico de autorización. ¡Espero que los jóvenes aprendan la lección!
Ver originalesResponder0
FancyResearchLab
· 08-02 18:15
Otra función de permiso que enseña a las personas, esto lo conozco bien.
Ver originalesResponder0
Blockblind
· 08-02 18:10
Aún se necesita confiar en los hackers éticos para salvarnos.
Análisis del incidente de vulnerabilidad de Multichain: desafíos y lecciones de la operación de rescate de sombrero blanco
Revisión del incidente de vulnerabilidad Multichain y resumen de la operación de rescate de los hackers éticos
El 18 de enero de 2022, el sistema de monitoreo de transacciones anómalas detectó un ataque contra el proyecto Multichain. Debido a que la función anySwapOutUnderlyingWithPermit() no implementó correctamente el mecanismo de verificación, los tokens autorizados por los usuarios para ese proyecto pudieron ser retirados por los atacantes.
A pesar de que el equipo del proyecto intentó varios métodos para alertar a los usuarios afectados, todavía hay muchos usuarios que no respondieron a tiempo, lo que permitió a los atacantes continuar con el ataque y obtener ganancias.
Para proteger a las posibles víctimas, el equipo de BlockSec ha decidido tomar medidas de respuesta de emergencia. Esta operación de rescate se dirige a las cuentas afectadas en Ethereum, transfiriendo los fondos de las cuentas relevantes a una cuenta de múltiples firmas establecida específicamente para ello. Para garantizar la transparencia de la acción, el hash del documento del plan relacionado se hace público a la comunidad. La operación de rescate comenzó el 21 de enero de 2022 y terminó el 11 de marzo de 2022.
La respuesta de emergencia enfrenta numerosos desafíos técnicos y no técnicos. Este artículo revisa todo el proceso, compartiendo experiencias y reflexiones, con la esperanza de ayudar a la seguridad del ecosistema DeFi.
Resumen breve
Ha surgido una intensa competencia entre los dos grupos, los hackers de sombrero blanco y los atacantes, en el uso de Flashbots, y las tarifas pagadas han aumentado rápidamente.
Flashbots no siempre son efectivos. Algunos atacantes optan por usar mempool, implementando ataques con estrategias astutas.
Algunos atacantes llegaron a un acuerdo con el equipo del proyecto, devolviendo parte de las ganancias y reteniendo parte como recompensa, logrando "blanquearse" exitosamente. Este fenómeno ha suscitado controversia en la comunidad sobre la equidad de los incentivos.
Los hackers de sombrero blanco pueden declarar sus acciones públicamente a la comunidad sin revelar información sensible, ganándose la confianza de la comunidad.
La colaboración de todas las partes de la comunidad puede hacer que las acciones de rescate sean más rápidas y efectivas.
Resumen de la situación de ataque y rescate
Resultado general
En el rango de observación ( del 18 de enero de 2022 al 20 de marzo de 2022 ), la situación general es la siguiente:
Tendencia de cambios en las tarifas de Flashbots
Las tarifas de transacción de ataque inicial de Flashbots son 0, lo que indica que el atacante aún no ha utilizado Flashbots. Posteriormente, la proporción de tarifas aumentó rápidamente, alcanzando incluso el 80%-91% en ciertas alturas de bloque, reflejando la intensa competencia por los derechos en la cadena.
Implementación de la operación de rescate y los desafíos enfrentados
La idea básica de la operación de rescate
Requisitos clave:
El principal desafío radica en las transacciones de los atacantes que hacen front-running. Aunque se pueden usar Flashbots, es necesario considerar la estrategia de configuración de tarifas. Al mismo tiempo, debido a la competencia, Flashbots no siempre son la mejor opción.
Situación competitiva
Intentar proteger 171 cuentas de posibles víctimas, de las cuales:
Las razones del fracaso involucran la competencia entre 3 cuentas de rescate y 16 cuentas de ataque.
Lecciones aprendidas
Configuración de tarifas de Flashbots
La estrategia conservadora no funciona bien, los competidores a menudo adoptan estrategias más agresivas:
Parece un juego de suma cero, donde se necesita encontrar un equilibrio entre reducir costos y ganar competitividad.
Estrategia de ordenación de transacciones Mempool
Debido a la intensa competencia, Flashbots no siempre es efectivo. Enviar transacciones normales a través del mempool y programarlas en la posición adecuada también puede lograr el objetivo.
Un atacante logró obtener 312 ETH utilizando esta estrategia, sin tener que pagar tarifas de Flashbots. La clave está en programar la transacción de ataque después de la transacción de transferencia y lo más cerca posible.
Otras reflexiones
La distinción entre el sombrero blanco y el atacante
No siempre es fácil de distinguir. Una cuenta fue inicialmente marcada como atacante, luego negoció con el equipo del proyecto para devolver parte de las ganancias, reteniendo 50 ETH como recompensa, y finalmente fue reclasificada como sombrero blanco. Este fenómeno ha suscitado controversias sobre la equidad de los incentivos.
Competencia entre los sombreros blancos
Es necesario establecer un mecanismo de coordinación para reducir/evitar la competencia entre los hackers éticos, evitando el desperdicio de recursos y el aumento de costos.
Sugerencias para mejorar las operaciones de rescate