Plataforma DeFi Lendf.Me pirateó análisis de detalles y sugerencias de defensa

Prólogo

Según información de SlowMist, la plataforma Ethereum DeFi Lendf.Me sufrió un ataque de vulnerabilidad de reentrada. Después de recibir la inteligencia, el equipo de seguridad de SlowMist analizó inmediatamente el ataque y localizó rápidamente el problema.

De acuerdo con el análisis estadístico preliminar del sistema contra el lavado de dinero (AML) de SlowMist Technology, la pérdida acumulada de Lendf.Me atacado es de aproximadamente 24,696,616 dólares de EE. UU. La moneda robada específica y la cantidad son:

Después de eso, los atacantes continuaron intercambiando las monedas robadas por ETH y otros tokens a través de plataformas DEX como 1inch.exchange, ParaSwap y Tokenlon.

El siguiente es el proceso de análisis detallado.

Detalles del ataque

La dirección del atacante que atacó a Lendf.Me esta vez es 0xa9bf70a420d364e923c74448d9d817d3f2a77822. El atacante atacó a Lendf.Me implementando el contrato 0x538359785a8d5ab1a741a0ba94f26a800759d91d.

Al ver una de las transacciones del atacante en Etherscan: https://etherscan.io/tx/0xae7d664bdfcc54220df4f18d339005c6faf6e62c9ca79c56387bc0389274363b

Descubrimos que el atacante primero depositó 0.00021593 imBTC, pero retiró con éxito 0.00043188 imBTC de Lendf.Me, y la cantidad retirada fue casi el doble de la cantidad depositada. Entonces, ¿cómo obtuvo el atacante el doble del saldo de una transacción corta? Esto requiere que analicemos profundamente cada acción en la transacción para ver qué sucedió.

Jimmy Song: Los pagos futuros se denominarán en BTC: el desarrollador principal de Bitcoin, Jimmy Song, tuiteó que así es como se desarrollará BTC a medida que aumente la demanda. Primero, el destinatario convierte el dinero en BTC cuando lo recibe. Pero a medida que aumentaba el volumen, comenzaron a solicitar adelantos de BTC o contratos de BTC. El pago entonces se denominará en BTC. [2021/1/10 15:47:30]

Al ver la transacción en bloxy.info, podemos conocer el proceso completo de la transacción.

Al analizar el proceso de transacción, no es difícil encontrar que el atacante realizó dos llamadas a la función de suministro () en Lendf.Me, pero estas dos llamadas son independientes, no llamando al suministro nuevamente en la función de suministro anterior () función () .

Inmediatamente después, durante la segunda llamada de la función suministro(), el atacante inicia una llamada a la función retirar() de Lendf.Me en su propio contrato, y finalmente retira

Aquí, no es difícil analizar que la llamada de retiro () del atacante se produce en la función transferFrom, es decir, cuando Lendf.Me llama a la función de enlace tokensToSend () del usuario a través de transferFrom. Obviamente, el atacante volvió a ingresar al contrato de Lendf.Me a través de la función de suministro (), lo que provocó un ataque de reingreso, entonces, ¿cuáles son los detalles específicos del ataque? Sigamos con el código de contrato de Lendf.Me a continuación.

OKEx avanza la opción de usar BCH como garantía hasta las 17:00 del 29 de octubre: según el Weibo oficial de OKEx, con respecto al negocio de préstamos C2C involucrado en el plan de manejo de eventos de bifurcación de BCH, para evitar sanciones adicionales para más usuarios Según la noticia , la plataforma decidió avanzar la opción de BCH como garantía del original "8 de noviembre de 2020 11:00" al "29 de octubre de 2020 17:00". Además, a las 11:00 del 14 de noviembre de 2020, el sistema activará el reembolso forzoso de la moneda. Utilice BCH para hipotecar a los usuarios de USDT para pagar la moneda antes de las 11:00. Si el préstamo no se devuelve para entonces, el El sistema activará el sistema para forzar el reembolso de la moneda. [2020/10/29]

Análisis de código

Después de una serie de procesamientos, la función supply() de Lendf.Me llamará a una función doTransferIn para depositar la moneda provista por el usuario en el contrato y luego asignar cierta información de la variable de mercado. Mirando hacia atrás en el proceso de ataque que acabamos de mencionar, el atacante llamó a la función de retiro() para retirar efectivo a través de la reentrada en la segunda función de suministro(), es decir, en la segunda función de suministro(), después de la línea 1590 La operación no se ejecutará antes de retirar (), y el código después de la línea 1590 continuará ejecutándose después de que se ejecute retirar (). Las operaciones aquí conducen a un aumento en el saldo disponible del atacante.

Analicemos en profundidad la función supply()

De acuerdo con la figura anterior, podemos ver que al final de la función suministro(), se actualizará el saldo del mercado y del usuario, antes de eso, el saldo del usuario será preadquirido al comienzo de la función y guardado en localResults.userSupplyCurrent, de la siguiente manera:

Al asignar un valor a la variable localResults, la información de transferencia del usuario se almacenará temporalmente en esta variable primero, y luego el atacante ejecuta la función retirar () en este momento. Veamos el código de la función retirar ():

Hay dos puntos clave aquí:

1. Al inicio de la función, el contrato obtiene primero las variables de mercado y oferta Saldo de almacenamiento.

2. Al final de la función de retiro (), existe la misma lógica para actualizar la información del saldo del usuario del mercado (supplyBalance), y el valor actualizado es el saldo después de deducir el monto del retiro del usuario.

De acuerdo con la lógica de retiro normal, cuando el retiro () se ejecuta solo, el saldo del usuario se deducirá y actualizará normalmente, pero debido a que el atacante incrusta el retiro () en el suministro (), el saldo del usuario se actualiza en la función de retiro () Después el saldo (supplyBalance), el siguiente código que se ejecutará en la función supply(), es decir, después de la línea 1590, el saldo del usuario se actualizará nuevamente y el valor utilizado para la actualización se guardará al comienzo de la anterior función supply() El depósito original del usuario en localResults más el valor de la primera llamada del atacante al depósito de la función supply().

Bajo tal operación, aunque el saldo del usuario se haya deducido después del retiro, la lógica de la siguiente función de suministro () sobrescribirá el valor cuando el usuario no haya deducido el monto del retiro nuevamente, haciendo que el atacante realice la operación de retiro, pero en lugar de deducir el saldo, hizo que el saldo aumentara. De esta forma, el atacante puede retirar efectivo en una cantidad exponencial hasta que se retira Lendf.Me.

Consejos de defensa

En respuesta a este ataque, el equipo de seguridad de SlowMist recomienda:

1. Agregue un mecanismo de bloqueo a los métodos clave de operación comercial, como: ReentrancyGuard de OpenZeppelin

2. Al desarrollar un contrato, use el estilo de escritura de cambiar primero las variables de este contrato y luego hacer llamadas externas

3. Antes de que el proyecto entre en línea, se invita a un excelente equipo de seguridad externo a realizar una auditoría de seguridad integral para descubrir posibles problemas de seguridad tanto como sea posible.

4. Cuando se conectan múltiples contratos, también es necesario verificar la seguridad del código y la seguridad comercial de los contratos de múltiples partes, y considerar completamente los problemas de seguridad bajo la combinación de varios escenarios comerciales.

5. El contrato debe configurar el interruptor de pausa tanto como sea posible, de modo que cuando ocurra un evento de "cisne negro", se pueda detectar a tiempo y detener la pérdida.

6. La seguridad es dinámica, y cada parte del proyecto también necesita capturar inteligencia de amenazas que pueda estar relacionada con su propio proyecto de manera oportuna, e investigar oportunamente los posibles riesgos de seguridad.

Adjunto OpenZeppelin ReentrancyGuard: 

https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/ReentrancyGuard.sol

Tags：

Binance Download