Autor: Sun

Traducción: JP

Comunidad Discord

Este artículo está publicado en XREX y WTF Academy

• Recapitulación
  • El 20220913, un Bot MEV fue explotado por un atacante y todos los activos en el contrato fueron transferidos, con una pérdida total de aproximadamente $140K.
  • El atacante envía una transacción privada a través del nodo validador BNB48, similar a Flashbot, sin poner la transacción en el mempool público para evitar ser adelantado (Front-running).
• Análisis
  • TXID del atacante. Podemos ver que el contrato del Bot MEV no estaba verificado, lo que significa que no era de código abierto. ¿Cómo se aprovechó de esto el atacante?
  • Usando phalcon para verificar, desde la parte del flujo de funciones dentro de esta transacción, el bot MEV transfirió 6 tipos de activos a la billetera del atacante. ¿Cómo se aprovechó de esto el atacante?
  • Al ver el proceso de invocación de la llamada a función, detectamos que la función pancakeCall fue llamada exactamente 6 veces.
    • Desde: 0xee286554f8b315f0560a15b6f085ddad616d0601
    • Contrato del atacante: 0x5cb11ce550a2e6c24ebfc8df86c5757b596e69c1
    • Contrato del Bot MEV: 0x64dd59d6c7f09dc05b472ce5cb961b6e10106e1d
  • Expandamos uno de los pancakeCall para analizarlo, podemos ver que la devolución de llamada al contrato del atacante lee el valor de token0() como BSC-USD, y luego transfiere BSC-USD a la billetera del atacante. Viendo esto, podemos saber que el atacante puede tener el permiso o usar una vulnerabilidad para mover todos los activos en el contrato del Bot MEV, el siguiente paso que necesitamos averiguar es ¿cómo lo usa el atacante?
  • Debido a que se mencionó anteriormente que el contrato del Bot MEV no es de código abierto, aquí podemos usar la Lección 1 que introdujo la herramienta decompiladora Dedaub. Analicemos y veamos si podemos encontrar algo. Primero copiamos los bytecodes del contrato desde Bscscan y los pegamos en Dedaub para decompilarlo. Como se muestra en la figura de abajo, podemos ver que el permiso de la función pancakeCall está configurado como público, y todos pueden llamarla. Es normal y no debería ser un gran problema en la devolución de llamada de un Flash Loan, pero puedes ver en el lugar enmarcado en rojo que ejecuta una función 0x10a, y luego veamos hacia abajo.
  • La lógica de la función 0x10a es como se muestra en la figura de abajo. Puedes ver el punto clave en el lugar enmarcado en rojo. Primero lee qué token está en token0 en el contrato del atacante y luego lo lleva a la función de transferencia transfer. En la función, el primer parámetro de la dirección del receptor address(MEM[varg0.data]) está en pancakeCall varg3 (_data) que puede ser controlado, así que el problema clave de vulnerabilidad está aquí.

• Mirando de nuevo el payload del atacante llamando a pancakeCall, los primeros 32 bytes del valor de entrada en _data es la dirección de la billetera del beneficiario.

• Escribiendo PoC
  • Después de analizar el proceso de ataque anterior, la lógica de escribir el PoC es llamar al pancakeCall del contrato del bot MEV y luego introducir los parámetros correspondientes. La clave es _data para especificar la dirección de la billetera receptora, y luego el contrato debe tener las funciones token0, token1 para satisfacer la lógica del contrato. Puedes intentar escribirlo tú mismo.
  • Respuesta: PoC.

• Traza de Foundry

  • Las trazas de función de la transacción también se pueden listar usando Foundry, de la siguiente manera:

  cast run 0xd48758ef48d113b78a09f7b8c7cd663ad79e9965852e872fdfc92234c3e598d2 --quick --rpc-url https://rpc.ankr.com/bsc

• Depuración de Foundry

  • También puedes usar Foundry para depurar transacciones, de la siguiente manera:

  cast run 0xd48758ef48d113b78a09f7b8c7cd663ad79e9965852e872fdfc92234c3e598d2 --quick --debug --rpc-url https://rpc.ankr.com/bsc

Flashbots: Reyes del Mempool

Mercados MEV Parte 1: Prueba de Trabajo

Mercados MEV Parte 2: Prueba de Participación

Mercados MEV Parte 3: Pago por Flujo de Órdenes