Hoy vamos a hablar del Hackeo del pasado 7 Octubre al bridge de Binance y c贸mo se crearon 200M de BNB 芦de la nada禄.
Binance reconoce un ataque en el bridge entre la beacon chain de BNB (BEP2) y la Binance Smart Chain (BEP20). La primera red es la encargada de la gobernanza y la segunda donde los Smart Contracts se despliegan. Los fondos robados, ascienden a 100-110 Millones de $, que hubieran sido muchos m谩s si Binance no decide suspender la red.
Este ataque, podr铆a considerarse de guante blanco, donde el hacker literalmente encontr贸 una aguja en un pajar. Veamos como:
Address del hacker [0x489A8756C18C0b8B24EC2a2b9FF3D4d447F79BEc].
El atacante fonde贸 la cuenta usando ChangeNow, un exchange. Este paso era necesario previo a la realizaci贸n del ataque, ya que se registr贸 como retrasmisor del bridge. Los relayer, o retransmisores son necesarios para la validaci贸n de paquetes de la Beacon Chain a la Binance Smart Chain.
El hacker consigue realizar el ataque emitiendo 2 operaciones que consiguen 芦mintear禄 de la nada 1M de BNB. Para entenderlo bien es necesario fijarnos en la altura del bloque, que resulta muy sorprendente.
Entramos en las transacci贸n del mill贸n de BNB y vemos que apuntan a una altura de bloques muy baja y usa la funci贸n HandlePackage. Esto ya nos empieza a decir que est谩n pasando cosas raras, ya que como vemos en la imagen anterior, la altura de bloque est谩 sobre el n潞 21957XXX.
El resto de transacciones internas hacen referencia a operaciones con Stargate Finance. Aqu铆 vemos que esta Tx apunta a la misma altura de bloque y es de hace 2 a帽os. Vamos a investigar un poco el bloque 3192.
Tx hash: [0x785c11458dd14a2a607ebd03cc6a64df28f34459d52cc0a4ce35329c152a899c].
Bueno, vemos como en ese bloque hay 6 Tx… Vaya, alguna se parece mucho a la del hackeo. Casualmente la que utiliza la misma funci贸n de Handle Package.
驴Os suena verdad? Mismo altura de bloque, misma funci贸n…
Aqu铆 la pregunta es c贸mo fue capaz de validar una prueba del 谩rbol de Merkle. Esto puede darse por una colisi贸n… O puede ser por la forma en la que valida las pruebas de Merkle, donde se utiliza un optimizador de gas muy potente, pero vulnerable…
Este precompilador se utiliza para verificar 谩rboles IAVL. Estos IAVL especifican una serie de operaciones. Los bridges de Binance esperan como argumento 2 de est谩s operaciones (iavl:operations y multistore)
Al parecer IAVL utiliza una funci贸n recursiva para verificar las pruebas del arbol de Merkle (falseables en el output). Las operaciones tienen que ser TRUE para falsear la prueba y que la operaci贸n devuelva un valor en concreto (el hash espec铆fico para el bloque 110217401)
La vulnerabilidad tambi茅n se encontraba en un repositorio central de cosmos. Binance import贸 este repo y con 茅l su vulnerabilidad. El problema es que IBC-go usa una biblioteca diferente para la verificaci贸n de pruebas y por tanto no afect贸 a cosmos, ya que estos no utilizan este precompilador.
Para entendernos, esto lo intenta buscar debido a la manera que est谩 planteado el algoritmo, que dice que cualquiera que con determinado path puede producir un hash 煤nico. Si queremos falsificar una prueba, este hash tendr谩 que permanecer igual. Aqu铆 entra el PAYLOAD.
En una transacci贸n, se env铆a un mensaje desde una cuenta a otra. Esta incluye datos binarios (payload) y el Ether (o moneda nativa de la red). El payload dice que funci贸n del contrato se quiere llamar y el valor de los argumentos a ejecutar en la llamada.
Es decir que si el payload que est谩 hasheado tiene X tama帽o se podr谩 llamar a la funci贸n querida. Eso + la cantidad de tokens es lo que se env铆a en el mensaje.
Y as铆 se false贸 la prueba para hacer el retiro. Con el nuevo nodo creado previo al ataque, un root hash que apunta a una altura de bloque muy antigua y que por la 芦optimizaci贸n del gas禄 del compilador IAVL se pudo realizar.
Una vez exploiteado el puente, los fondos por medio de Multichain_org se redirigen a otras cadenas. Otros muchos se quedan en BSC en protocolos de pr茅stamos como Venus donde se deja el BNB de colateral y se pide stablecoin. Al no ser BNB un token sino una criptomoneda, se intercambia por un ERC20.
Aqu铆 es donde empiezan los problemas porque al dejar BNB 芦falso禄 y estar pidiendo Stablecoin, que en teor铆a, es licito, se est谩n creando assets falsos y malversando las cifras del TVL y por tanto, de los datos On-chain de la cadena. Por suerte, se trata de una cadena 芦Centralizada禄 d贸nde se pudo actuar con suma velocidad y el ladr贸n consigui贸 robar 芦solo禄 $110M repartidos en las cadena de la siguiente imagen. (Datos obtenidos de DeBank)
Adem谩s unos 7 millones han sido bloqueados (blacklisted) para que no se puedan mover de la cartera del hacker. El resto de activos robados, siguen en otras cadenas, en la misma address, por lo que no se han perdido, pero a ver c贸mo se 芦devuelven禄 al origen… y a ver c贸mo se resuelve. 驴Le quitas los fondos a Venus, qu茅 no tiene la culpa de la cagada en el c贸digo de Binance?
La soluci贸n m谩s viable ser铆a la de realizar una mutaci贸n del contrato, se agregue una funci贸n de liquidaci贸n y que Binance compre la posici贸n instant谩neamente para no afectar al precio. Esto supondr铆a que el propio Binance se haga cargo de las perdidas ocasionadas por el exploit de su bridge.
