Primer post | ¿La aseguradora que vende seguros de accidentes también sufrió un accidente? Análisis de vulnerabilidad del protocolo de portada

Este artículo fue escrito por el equipo de verificación de seguridad de CertiK y autorizó a Jinse Finance a publicarlo.

Recientemente, algunos perros callejeros aparecieron en la comunidad. Escuché que el hijo de un vecino se escapó asustado cuando vio al perro, pero fue perseguido y mordido por el perro.

Afortunadamente, los padres fueron ingeniosos y pusieron un seguro de accidentes para el niño, y algunas inyecciones de vacuna contra la rabia no costaron mucho.

Como ciudadano de la moneda, si lamentablemente los activos cifrados son robados, pero la parte del proyecto o usted personalmente compraron un seguro, entonces puede estar seguro de que la compañía de seguros reembolsará los activos perdidos.

Pero existe la peor situación: ¿Pero qué pasa si incluso la compañía de seguros tiene un incidente de seguridad y es atacada?

En la noche del 28 de diciembre, hora de Beijing, el equipo de tecnología de seguridad de CertiK descubrió un ataque de vulnerabilidad en la emisión ilimitada de tokens de Cover Protocol.

El atacante prometió y recuperó repetidamente el contrato inteligente del proyecto, lo que desencadenó la operación de acuñación de tokens y emitió infinitamente tokens de Cover, lo que provocó el colapso del precio de los tokens de Cover.

El ataque principal se divide en los siguientes pasos: 

1. El atacante configura los tokens NOCLAIM necesarios para el ataque.

2. El atacante usa tokens NOCLAIM para proporcionar liquidez al Balancer Pool:

    ①Proporcionó un total de 2573 DAI de liquidez al Balancer Pool

    ②El atacante obtuvo aproximadamente 132,688 tokens de prueba de liquidez de Balancer BPT al proporcionar liquidez al Balancer Pool

3. El atacante promete (apuestas) todos los tokens de prueba de liquidez de Balancer obtenidos en el paso anterior al contrato inteligente Blacksmith.sol en el Protocolo de cobertura.

Al apostar, el atacante llama a la función de depósito en el contrato inteligente Blacksmith.sol ubicado en 0xe0b94a7bb45dd905c79bb1992c9879f40f1caed5, como se muestra en la Figura 1:

Economista Dennis Gartman: Bitcoin es completamente ilógico: Jinse Finance informó que el economista Dennis Gartman expresó su descontento con Bitcoin en una entrevista reciente con Bloomberg, afirmando que el banco central no renunciará a su poder fácilmente. Por separado, llamó a Bitcoin "completamente ilógico". [2020/12/22 16:10:11]

Figura 1: La función deposit() en blacksmith.sol

Al llamar a la función de depósito, el atacante promete la prueba de liquidez BPT obtenida al protocolo de cobertura.

Primero lea los datos del pool del token de prueba de liquidez actual en la memoria a través de la línea 118 en la Figura 1, y luego llame a la línea 121 para actualizar los datos del pool actual.

Figura 2: La función updatePool() en blacksmith.sol

Como se muestra en la línea 75 de la Figura 2, los datos del pool del token de prueba de liquidez actual modificado en la función updatePool() son datos almacenados en el almacenamiento, que es lo mismo que la prueba de liquidez actual almacenada en la memoria en deposit() Los datos del grupo del token son dos piezas de datos.

El valor de lpTotal en la línea 84 de la Figura 2 representa el número total de tokens de prueba de liquidez depositados en el contrato actual. Dado que el valor de esta variable es pequeño, el valor de la fórmula pool.accRewardsPerToken en la línea 84 aumentará y el valor actualizado Los valores accRewardsPerToken se almacenan en el almacenamiento.

Figura 3: La función _claimCoverRewards() en blacksmith.sol

A continuación, como se muestra en la línea 318 de la Figura 3, deposit() lanza una cierta cantidad de tokens de cobertura a la persona que llama a la función (msg.sender) llamando a la función _claimCoverRewards().

El número de tokens de cobertura acuñados está relacionado con las tres variables pool.accRewardsPerToken, CAL_MULTIPLIER y miner.rewardWriteoff.

Tenga en cuenta que el valor de pool.accRewardsPerToken aquí usa los datos del grupo almacenados en la memoria, no el valor actualizado usando la función update() en la Figura 2.

Al mismo tiempo, se sabe por la función de depósito en la Figura 1 que la actualización del valor de miner.rewardWriteoff ocurre después de que se completa la ejecución de la función _claimCoverRewards().

Por lo tanto, en el diseño original, el valor actualizado de miner.rewardWriteoff debe usarse para calcular la cantidad de tokens de cobertura que deben acuñarse. Aquí, los datos no actualizados de miner.rewardWriteoff se usan incorrectamente, lo que da como resultado la cantidad real de tokens acuñados. los tokens de cobertura son mayores que el número de tokens acuñados. El número aumentó, lo que eventualmente condujo a la emisión de tokens.

Una vez que la promesa es exitosa, el atacante llama a la función de retiro () en el contrato inteligente de blacksmith.sol para recuperar el BPT prometido y obtener tokens de cobertura acuñados adicionales para completar el ataque.

Al comparar la tabla de saldo de tokens después de ejecutar la función de depósito() y la función de retiro(), podemos encontrar que después de llamar a este conjunto de funciones de depósito y retiro, el atacante puede obtener alrededor de 704 tokens COVER.

Después del depósito ():

Después de retirar():

Al ejecutar repetidamente las funciones de depósito y retiro, el atacante puede hacer que la función Blacksmith acumule infinitamente tokens y transfiera los tokens a su propia dirección, obteniendo así una ganancia.

Después del ataque, al cierre de esta edición, la portada oficial de Herrero ha migrado a una versión segura:

Dirección del herrero vulnerable:

Dirección del herrero después de la corrección temporal:

0x1d5fab8a0e88020309e52b77b9c8edf63c519a26

El contrato de herrero reparado temporalmente prohíbe temporalmente todas las operaciones de compromiso y retiro para evitar que el atacante continúe atacando.  

En este ataque, el atacante obtuvo una ganancia total de 4,4 millones de dólares estadounidenses, o alrededor de 29 millones de yuanes.

Otros atacantes utilizaron esta vulnerabilidad para lanzar ataques similares, por ejemplo, el proyecto oficial Grap.finance participó en el ataque utilizando esta vulnerabilidad y ganó 4350 tokens ETH.

Pocas horas después del ataque, el funcionario del proyecto Grap.finance se atribuyó la responsabilidad del ataque a través de Twitter y afirmó que había devuelto todas las ganancias a Cover Protocol.

Para garantizar que los activos digitales no sufran pérdidas por razones no técnicas, la parte del proyecto debe comprar un seguro para los productos del proyecto de manera oportuna, aumentar el plan de seguridad de la parte del proyecto y los inversores, y asegurarse de que las pérdidas causados ​​por los ataques pueden ser compensados ​​de manera oportuna.

Como la principal empresa de auditoría del mundo, CertiK ha realizado actualmente más de 369 auditorías de seguridad, ha auditado más de 198 000 líneas de código y ha protegido más de 10 000 millones de dólares en activos cifrados.

Recientemente, CeritK lanzó el plan de protección de fondos descentralizados CertiKShield.

CertiKShield no solo puede brindar protección para el proyecto y los miembros de su comunidad, sino que al mismo tiempo, como una empresa de seguridad cuyo negocio principal es la auditoría, CertiK garantiza que nuestros proyectos de seguros tengan mayor seguridad.

En comparación con las compañías de seguros puras, CertiKShield es un seguro construido en el campo de la seguridad con el respaldo de la tecnología de seguridad y el énfasis del equipo en la seguridad y una serie de garantías, y tiene un gran espacio para el crecimiento y el desarrollo.

Tags：

AAVE