Niebla lenta: un breve análisis del ataque al puente Harmony Horizon

[SlowMist: el puente Harmony Horizon fue atacado] Según el equipo de seguridad de SlowMist, el puente Harmony Horizon fue pirateado. Según el análisis de SlowMist MistTrack, el atacante (0x0d0...D00) obtuvo una ganancia de más de 100 millones de dólares estadounidenses, incluidos 11 tipos de tokens ERC20, 13 100 ETH, 5000 BNB y 640 000 BUSD, y el atacante transfirió la mayor parte de los tokens en la cadena Ethereum Vaya a dos nuevas direcciones de billetera, intercambie los tokens por ETH y luego transfiera todo el ETH a la dirección inicial (0x0d0...D00).La dirección actual (0x0d0...D00) es aproximadamente 85,837 ETH y aún no hay transferencia Al mismo tiempo, el ataque No hay operación de transferencia de fondos en la cadena BNB. SlowMist MistTrack monitoreará continuamente la transferencia de fondos robados.

Otras noticias:

Slow Mist: la cadena Zabu Finance en Avalanche fue pirateada: según la inteligencia del Distrito Slow Mist, el 12 de septiembre, el proyecto Zabu Finance en Avalanche sufrió un ataque de préstamo relámpago.

1. El atacante primero crea dos contratos de ataque y luego convierte WAVAX en tokens SPORE en Pangolin a través del contrato de ataque 1, e hipoteca los tokens SPORE obtenidos al contrato ZABUFarm para prepararse para las recompensas de tokens ZABU posteriores.

2. El atacante tomó prestados tokens SPORE de Pangolin Flash Loan al atacar el contrato 2 y luego comenzó a usar tokens SPORE continuamente para realizar operaciones de "hipoteca/retiro" en el contrato ZABUFarm. Dado que los tokens SPORE deben cobrar una determinada tarifa de manejo durante el proceso de transferencia (cobrada por el contrato SPORE), la cantidad real de tokens SPORE recibidos por el contrato ZABUFarm es menor que el monto de la hipoteca transferida por el atacante. Durante el análisis, notamos que el contrato ZABUFarm registrará directamente el monto de la hipoteca transferida por el usuario cuando el usuario hipoteca, en lugar de registrar la cantidad real de tokens recibidos por el contrato. Esto lleva al hecho de que la cantidad de tokens SPORE realmente recibidos por el contrato ZABUFarm cuando el atacante hipoteca es menor que la cantidad de tokens que el contrato ZABUFarm transfiere al atacante cuando el atacante se retira.

3. El atacante se aprovechó del defecto de contabilidad causado por el problema de compatibilidad entre el contrato ZABUFarm y los tokens SPORE y, por lo tanto, consumió continuamente los fondos SPORE en el contrato ZABUFarm a un valor extremadamente bajo a través de operaciones de "hipoteca/retiro". La recompensa de la hipoteca del contrato ZABUFarm se calcula dividiendo la cantidad total de tokens SPORE hipotecados en el contrato por las recompensas de bloque acumuladas. Por lo tanto, cuando la cantidad total de tokens SPORE en el contrato ZABUFarm se reduce a un valor extremadamente bajo, sin duda ser calculado Un gran valor de bonificación.

4. El atacante obtuvo una gran cantidad de recompensas de tokens ZABU a través del contrato de ataque 1 que se había hipotecado previamente en ZABUFarm y luego vendió los tokens ZABU.

Este ataque fue causado por la incompatibilidad entre el modelo de hipoteca de ZabuFinance y los tokens SPORE. Ha habido muchos ataques causados ​​por tales problemas. El cambio de token real del contrato antes y después de la transferencia, en lugar de depender de la cantidad de tokens de hipoteca pasados ​​por el usuario. [2021/9/12 23:19:21]

SlowMist: en la primera mitad de 2021, ocurrieron un total de 78 incidentes de seguridad de blockchain, con una pérdida total de más de 1.700 millones de dólares estadounidenses: según las estadísticas de SlowMist Blockchain Hacking Event Archives, en la primera mitad de 2021, el todo el ecosistema de blockchain ocurrió en total 78 incidentes de seguridad relativamente conocidos, que involucraron 50 de seguridad DeFi, 2 de seguridad de billetera, 3 de seguridad de cadena pública, 6 de seguridad de intercambio y 17 de otros incidentes relacionados con la seguridad, incluidos 27 en Ethereum, Binance Smart Chain (BSC), 2 casos en Polygon, 1 caso cada uno en Huobi Ecological Chain (HECO), Polkadot Ecosystem y EOS.

Según el seguimiento y análisis de los fondos involucrados por SlowMist AML, el atacante transfirió aproximadamente el 60 % de los fondos a la plataforma de divisas mixtas y aproximadamente el 30 % de los fondos al intercambio. Por la presente, el equipo de seguridad de SlowMist recomienda que los usuarios aumenten su conciencia y vigilancia sobre la seguridad, y elijan proyectos confiables que hayan pasado auditorías de seguridad para participar; las partes del proyecto deben mejorar continuamente sus propios factores de seguridad y solo conectarse en línea después de pasar la auditoría de un profesional de seguridad. agencia de auditoría para evitar pérdidas; Todos los intercambios deben aumentar la supervisión contra el lavado de dinero y tomar más medidas enérgicas contra las actividades ilegales como el lavado de dinero utilizando transacciones de activos encriptados. [2021/7/1 0:20:42]

SlowMist: el atacante volvió a ingresar al contrato Lendf.Me a través de la función "suministro()" para lograr un ataque de reingreso: el equipo de seguridad de SlowMist publicó un artículo para dar seguimiento a las razones específicas y sugerencias de defensa para la "plataforma DeFi Lendf .Me fue hackeado". Según el análisis del artículo, al colocar la transacción en bloxy.info para ver el proceso de transacción completo, se puede encontrar que el atacante realizó dos llamadas a la función "suministro()" en Lendf.Me, pero estas dos llamadas son independientes y en lugar de volver a llamar a la función "suministro()" en la función "suministro()" anterior. Inmediatamente después, durante la segunda llamada de la función "suministro()", el atacante inició una llamada a la función "retirar()" de Lendf.Me en su propio contrato, y finalmente se retiró. El equipo de seguridad de SlowMist dijo que no es difícil analizar que la llamada "retirar()" del atacante se produjo en la función transferFrom, es decir, cuando Lendf.Me llamó a la función gancho "tokensToSend()" del usuario a través de transferFrom. Obviamente, el atacante reingresó al contrato de Lendf.Me a través de la función "suministro()", provocando un ataque de reingreso. [2020/4/19]