Read-Only Reentrancy Attack: $220k robados y +$100M en riesgo Un informático en el lado del mal

Este exploit/vulnerabilidad es el “Read only reentrancy attack” una modalidad del reentrancy que no afecta directamente a la explotación de fondos, sino a los contratos DeFi que interactúen con él o dependan de los datos que este pueda proveer. Esto se traduce en que puede afectar a todos aquellos protocolos y oráculos que dependan de fuentes externas de alguna manera, y más en concreto a protocolos descentralizados de routing de DEXs (como QuickSwap o 1inch).

“Read-only reentrancy”

Fijaos en el siguiente contrato, en el que podréis ver que en la línea 14 el SmartContract es vulnerable a un reentrancy, en la función withdraw().

El esquema de ataque para este contrato sería el típico de un reentrancy, si queréis una explicación en más detalle podéis ir a este artículo en el que Pablo Gonzalez nos explica cómo funcionaba la vulnerabilidad.

Podríamos solucionar el exploit actualizando los datos del balance antes de hacer la llamada; o incluso implementando un “cerrojo”. En este caso usamos una librería de Openzeppelin que nos facilita bastante su implementación.

Pero aun así seguiría siendo vulnerable al “Read only reentrancy”; aunque el “cerrojo” implementado no permite al atacante llevarse fondos al llamar a su función “fallback” (línea 9), éste sí que permite entre medias realizar una llamada a algún contrato DeFi dependiente de los datos del contrato original(el vulnerable), y el contrato llamado no dispondrá los datos actualizados. Un ejemplo de cómo se puede explotar esta vulnerabilidad es el siguiente:

Un ejemplo de mitigación sería actualizar los datos antes de hacer las llamadas, pero esto no siempre es posible, muchas veces necesitaremos obtener datos de otra fuente para poder continuar.

$200k en un ataque a Quick Swap

En este caso, el read only reentrancy ya se cobró una importante víctima el pasado 24 de octubre, el DEX de QuickSwap. En este caso el ciberatacante usó este tipo de reentrancy para manipular el precio de un activo en una pool de liquidez de Curve (otro DEX) que le permitió tomar prestado más cantidad de la normal en el Lending de QuickSwap.

Conclusiones

Este ataque aunque no afecte de una manera directa a los fondos del contrato puede provocar la explotación del mismo o de otros contratos. Es un vector de ataque que en parte se aprovecha de los contratos que usan “cerrojos” para evitar ser vulnerados con un reentrancy “normal”, por ello es incluso más crítico aún.  Sobre todo este exploit afecta de manera importante a todos aquellos contratos que sirvan como fuente de datos, tokens, oráculos, sistemas de reputación basados en tokenomics…