Meerkat Finance - BSC - REKT

En retrospectiva, fue inevitable.

Un debut impresionante para el primer gran exploit en BSC, con Meerkat Finance llegando directo al tercer lugar en nuestro leaderboard.

Después de un solo día de operación, Meerkat Finance fue estafado estilo rug pull por 13 millones de BUSD y sobre 73,000 BNB, lo que dió un total de alrededor de $31m.

Hemos estado observando a Binance Smart Chain mientras hace su speedrun a través del verano DeFi de Ethereum. Ahora sus códigos copiados han acumulado suficiente capital, y han entrado en la fase de rug pull.

Las repercusiones presentan una situación interesante.

¿Van a retrotraer CZ y su equipo su chain corporativa? ó ¿dejarán que sus usuarios sufran la pérdida?

Esta suricata estafa deja a los ladrones sin donde esconderse.

¿A dónde pueden huir en una chain tan pequeña? Binance ha cerrado los puentes, y hasta bscscan.com estuvo fuera de servicio por un rato. ¿Fue por exceso de tráfico o un tipo de cortina de humo?

Meerkat Finance primero declaró que fue un hack, pero luego borraron sus cuentas, dejando a los usuarios de BSC con solo ellos mismos, o tal vez con Binance para culpar.

Gracias a 0xdeadf4ce.

• El Deployer de Meerkat Finance actualizó 2 bóvedas del proyecto.
• La dirección del agresor llamó a una función de inicialización permissionless tras los proxys de bóveda, efectivamente permitiendo a cualquiera ser el dueño de la bóveda. [2]
• El agresor posteriormente vacía las bóvedas al llamar una función con firma 0x70fcb0a7 que acepta una dirección de token como input. Una descompilación del smart contract ya actualizado muestra como único uso de la función ser una retirada de fondos con el dueño como beneficiario.

Generalmente, si el contrato tiene una función que deja al dueño recuperar los activos activamente utilizados en la estrategia/bóveda, estás poniendo tu confianza en el equipo del proyecto.

Podrían suspenderlo en cualquier momento.

Por eso los proyectos como Yearn añaden controles como los que aparecen en la imagen debajo, para que el equipo solamente pueda rescatar los fondos que no están en uso activo por la estrategia/bóveda.

Las dos bóvedas afectadas usaban el patrón de OpenZeppelin Transparent Proxy Upgrade, que permite la actualización de la lógica de la bóveda a una nueva implementación por llamar la función upgradeTo(address newImplementation) al nivel Vault proxy.

La implementación previa de la bóveda BUSD se localiza en 0x49509a31898452529a69a64156ab66167e755dfb, la implementación previa de la bóveda WBNB se localiza en 0x3586a7d9904e9f350bb7828dff05bf46a18bb271, ambos son contratos discretos y verificados.

El Deployer de Meerkat Finance llama upgradeTo() dos veces.

• en block 5381239, fijando la implementación de la bóveda WBNB a 0x9d3a4c3acee56dce2392fb75dd274a249aee7d57
• en block 5381246, fijando la implementación de la bóveda BUSD a 0xb2603fc47331e3500eaf053bd7a971b57e613d36

Esto cambió la lógica de la bóveda para introducir dos funciones notables, que no habían sido parte de las implementaciones iniciales.

• init(address owner)
• Según bytecode descompilado esta función fija la dirección en la ranura de almacenamiento 0 a la dirección aportada a la función.

No hay revisión de permiso, haciendo esta función recién añadida la máxima puerta trasera a las bóvedas.

Usar un patrón Initializer específico en proxies transparentes es la práctica adecuada y fue aplicado a las primeras implementaciones de bóveda, así que es bastante cuestionable la intención de añadir el método init() si no fuese para un robo planeado de la bóveda y sus fondos.

• 0x70fcb0a7(address _param1)

El código fuente no está disponible, la fuente descompilada queda limitada a verificar que el caller es igual a la ranura de almacenamiento 0 definida en el método init() y retirando balanceOf() en el contrato token aportado con param1, usando la dirección de la bóveda como objetivo de query. Ambas funciones no son parte de las implementaciones previas de la bóveda.

Al comparar el tamaño del bytecode de las implementaciones anteriores y actuales, se puede decir que la nueva es sólo 1/4 del tamaño de la lógica previa.

Dado que las actualizaciones fueron realizadas por el Deployer de Meerkat Finance la situación más probable, considerando todos los aspectos de los datos on-chain, es un “rug pull” intencional, aunque queda la probabilidad menor de la corrupción de una clave privada.

Al momento actual, los fondos han sido parcialmente divididos entre varias direcciones y enviados a lo que, al parecer, pertenece al Binance Bridge alojado por el Binance exchange.

El Binance.org Bridge se encuentra actualmente suspendido, probablemente para evitar que los fondos sean enviados a otras chains con facilidad.

Cronología (04.03.2021)

Mar-04-2021 08:53:10 AM +UTC El Deployer de Meerkat Finance actualiza la bóveda WBNB al contrato 0x9d3a4c3acee56dce2392fb75dd274a249aee7d57

Mar-04-2021 08:53:31 AM +UTC El Deployer de Meerkat Finance actualiza la bóveda BUSD al contrato 0xb2603fc47331e3500eaf053bd7a971b57e613d36

Mar-04-2021 08:54:31 AM +UTC El agresor llama al método 0x70fcb0a7 en la bóveda BUSD para retirar 13,968,039 BUSD

Mar-04-2021 08:54:55 AM +UTC El agresor llama al método 0x70fcb0a7 en la bóveda WBNB para retirar 73,635 WBNB

Los mismos juegos se juegan en chains distintas, pero el equilibrio de poder es diferente. Con CZ observando y los puentes quemándose, los ladrones no tienen donde esconderse.

Incluso dentro del grupo Meerkat_Rugpull en Telegram, los miembros del chat no se ponían de acuerdo en cómo querían que Binance manejara la situación.

¿Podría Binance retrotraer la chain y reembolsar a sus usuarios?

La respuesta no queda muy clara - los 21 validadores misteriosos podrían en teoría arreglar un reembolso, pero es improbable. Solo alimentaria los problemas de CeDeFi y crearía más trabajo para los (seguramente ya bastante estresados) abogados de BSC.

Binance habría planificado desde antes cómo lidiar con tal situación. La manera en que manejen este caso va a sentar el precedente.

Aunque no es el primer rug pull multimillonario en BSC, es el primero desde el alza de PancakeSwap y los aumentados números de usuarios que vinieron con ella.

Ignorando la improbable situación de que alguien de Binance se ofrezca a organizar un distribuidor merkle para devolver los fondos, el dinero ha desaparecido.

Resulta entonces que los protocolos en BSC no son más seguros que en Ethereum.

CZ no te va a salvar. Sus transacciones son más baratas pero no hay desarrollo original.

¿Qué será de esta chain corporativa una vez que llegue Eth L2?”

REKT sirve como plataforma pública para autores anónimos, nos deslindamos de la responsabilidad por las opiniones y contenidos alojados en REKT.

dona (ETH / ERC20): 0x3C5c2F4bCeC51a36494682f91Dbc6cA7c63B514C

aviso legal:

REKT no es responsable ni culpable de ninguna manera por cualquier Contenido publicado en nuestro Sitio Web o en conexión con nuestros Servicios, sin importar si fueron publicados o causados por Autores ANÓN de nuestro Sitio Web, o por REKT. Aunque determinamos reglas para la conducta y publicaciones de los Autores ANÓN, no controlamos y no somos responsables por cualquier contenido ofensivo, inapropiado, obsceno, ilegal o de cualquier forma objetable, que se pudiera encontrar en nuestro Sitio Web o Servicios. REKT no es responsable por la conducta, en línea o fuera de línea, de cualquier usuario de nuestro Sitio Web o Servicios.