BSC Flash Loan Attack: los tres imitadores

Una serie de ataques comprometieron varios proyectos Binance Smart Chain (BSC) en mayo. Después de PancakeBunny, sus tres proyectos de bifurcaciones, AutoShark, Merlin Labs y PancakeHunny, también fueron atacados con técnicas similares. PancakeBunny sufrió el ataque más costoso de los cuatro, que vio casi $ 45 millones en daños totales. En este artículo, el Dr. Chiachih Wu, Jefe del Equipo de Seguridad blockchain del Grupo Amber, explica los detalles detrás de los ataques a los tres imitadores.

Copycats

AutoShark fue atacado cinco días después de PancakeBunny, seguido por Merlin Labs y PancakeHunny, respectivamente. El siguiente es un análisis de los problemas y posibles técnicas de ataque para estos tres proyectos bifurcados.

En la función SharkMinter.mintFor (), la cantidad de tokens SHARK gratificantes que se acuñarán (es decir, mintShark) se deriva de sharkBNBAmount calculado tokenToSharkBNB () en la línea 1494. Sin embargo, tokenToSharkBNB () hace referencia al saldo actual de flip, lo que lo convierte en un punto vulnerable. Se podría suponer que la cantidad de tokens recibidos en la línea 1492 es igual a la cantidad del saldo invertido. Aún así, un mal actor podría manipular el balance de inversión simplemente enviando algunos tokens de inversión justo antes de la llamada a getReward () y rompiendo indirectamente la lógica de tokenToSharkBNB ().

En la implementación subyacente de tokenToSharkBNB (), hay otra superficie de ataque . Como se muestra en el fragmento de código anterior, _flipToSharkBNBFlip () elimina la liquidez de ApeSwap (línea 1243) o PantherSwap (línea 1262) y convierte los tokens LP en SHARK + WBNB. Más tarde, el generateFlipToken () se invoca para convertir SHARK + WBNB en tokens LP SHARK-BNB.

Dentro de generateFlipToken (), los saldos actuales de SHARK y WBNB de SharkMinter (amountADesired, amountBDesired) se utilizan para generar tokens LP y el cantidad de tokens LP se devuelven a mintFor () como sharkBNBAmount. En base a eso, el mal actor podría transferir SHARK + WBNB a SharkMinter para manipular la cantidad de tokens de SHARK que se van a acuñar también.

La ​​laguna en PancakeHunny es idéntica a la encontrada en AutoShark, en que el mal actor puede manipular la acuñación de recompensas de HUNNY con tokens HUNNY y WBNB.

En comparación con AutoShark y PancakeHunny, _getReward () de Merlin Labs tiene una vulnerabilidad más obvia.

El fragmento de código anterior muestra que el rendimientoFee podría ser manipulado por el equilibrio de TORTA, que afecta indirectamente a la acuñación de recompensas REAL. Sin embargo, el modificador sin contrato se deshace de los préstamos flash.

Incluso sin un contrato de explotación, el mal actor aún podría beneficiarse a través de múltiples llamadas.

Reproducir AutoShark Attack

Para reproducir el truco de AutoShark, primero necesitamos obtener algunos tokens SHARK-BNB-LP de PantherSwap. Específicamente, intercambiamos 0.5 WBNB por SHARK (línea 58) y transferimos el resto de WBNB con esos tokens SHARK a PantherSwap para acuñar tokens SHARK-BNB-LP (línea 64). Más adelante, depositamos esos tokens LP en el contrato StrategyCompoundFLIP de AutoShark (línea 69) para calificar para las recompensas. Tenga en cuenta que, a propósito, solo depositamos la mitad de los tokens LP en la línea 69.

El segundo paso es hacer que getReward () entre en el contrato de SharkMinter . En el fragmento de código anterior, sabemos que la recompensa se puede recuperar mediante la función obtenida () (línea 1658). Además, el 30% de la recompensa (es decir, performanceFee) debe ser mayor que 1,000 (es decir, DUST) para activar SharkMinter.mintFor () en la línea 1668.

Por lo tanto, en nuestro código de explotación, transferimos algunos tokens LP a el contrato StrategyCompoundFLIP en la línea 76 para omitir la verificación performanceFee> DUST y activar la llamada mintFor (). Dado que necesitamos una gran cantidad de WBNB + SHARK para manipular SharkMinter, aprovechamos el WBNB de 100k de PantherSwap a través de una llamada flash-swap en la línea 81.

En la devolución de llamada flash-swap, pancakeCall (), intercambiamos la mitad del WBNB por SHARK y enviar el TIBURÓN con los 50.000 WBNB restantes al contrato de SharkMinter para manipular la acuñación de recompensas.

El siguiente paso es activar getReward () cuando el SharkMinter recibe los tokens WBNB + SHARK para acuñar una gran cantidad de TIBURÓN a la persona que llama .

El último paso es convertir SHARK en WBNB, pagar el préstamo relámpago y marcharse con los tokens WBNB restantes.

En nuestro experimento, el actor malo comienza con 1 WBNB. Con la ayuda de préstamos flash, se beneficia de la devolución de más de 1000 WBNB en una transacción.

Reproducir el ataque PancakeHunny

La teoría detrás del ataque PancakeHunny es similar al ataque AutoShark. En resumen, necesitamos enviar una gran cantidad de HUNNY + WBNB a HunnyMinter antes de activar getReward (). Sin embargo, el contrato de token HUNNY tiene un mecanismo de protección llamado antiWhale para evitar transferencias de grandes cantidades. Por lo tanto, los préstamos flash no funcionan aquí.

Para omitir antiWhale, creamos varios contratos secundarios e iniciamos múltiples llamadas a CakeFlipVault.deposit () a través de dichos contratos.

En el fragmento de código de explotación anterior, los tokens LP reunidos en línea 116 se dividen en 10 partes y se transfieren a 10 contratos Lib en la línea 122 seguidos de llamadas Lib.prepare () para cada uno de ellos.

Dentro de Lib.prepare (), aprobamos () el CakeFlipVault para gastar los tokens LP y invocar CakeFlipVault.deposit () para habilitar las llamadas getReward () posteriores para acuñar tokens HUNNY de recompensa.

Después de preparar 10 contratos Lib, el contrato principal itera cada uno de ellos para: 1) intercambiar WBNB por la cantidad máxima permitida de HUNNY; 2) transferir WBNB + HUNNY a HunnyMinter; 3) activar getReward () a través de lib.trigger (); y 4) cambiar HUNNY de nuevo a WBNB.

Al final, el mal actor con 10 WBNB gana alrededor de 200 WBNB de 10 ejecuciones de operaciones de 10 contratos Lib.

Reproduciendo Merlin Labs Attack

Como se mencionó anteriormente, Merlin Labs tiene el modificador noContract para deshacerse de los ataques de préstamos flash. Sin embargo, podríamos usar un script para desencadenar el ataque con múltiples transacciones iniciadas desde una dirección EOA (cuenta de propiedad externa). La única diferencia es que alguien puede adelantar la transacción del mal actor para robar las ganancias.

Similar al ataque AutoShark, necesitamos preparar suficientes LINK y WBNB (línea 23), usarlos para acuñar WBNB-LINK-LP tokens (línea 34) y depositar tokens LP en el contrato VaultFlipCake (línea 38).

Las acciones restantes son:

  1. Intercambiar WBNB por CAKE (línea 42).
  2. Manipular la acuñación de MERL enviando CAKE al contrato VaultFlipToCake (línea 50).
  3. Activación de getReward () en la línea 55 (se acuña una gran cantidad de tokens REAL).
  4. Cambiando REAL de nuevo a WBNB y repitiendo los pasos anteriores varias veces.

Como se mencionó anteriormente, si Si alguien ejecuta el paso 3 justo después del paso 2, esa persona podría eliminar una gran cantidad de REAL.

En nuestro experimento, el mal actor comienza con 10 WBNB y se aleja con alrededor de 165 WBNB repitiendo los cuatro pasos 10 veces. [19659036] Acerca de Amber Group

Amber Group es un proveedor de servicios de cripto finanzas líder a nivel mundial der opera en todo el mundo y las 24 horas del día con presencia en Hong Kong, Taipei, Seúl y Vancouver. Fundado en 2017, Amber Group atiende a más de 500 clientes institucionales y ha negociado acumulativamente más de $ 500 mil millones en más de 100 intercambios electrónicos, con más de $ 1,5 mil millones en activos bajo administración. En 2021, Amber Group recaudó $ 100 millones en fondos de la Serie B y se convirtió en el último unicornio de FinTech valorado en más de $ 1 mil millones. Para obtener más información, visite www.ambergroup.io.