Read-Only Reentrancy Attack: $220k robados y +$100M en riesgo

En el pasado hemos hablado sobre el “Reentrancy attack”, un tipo de vulnerabilidad que puede tener muy graves consecuencias sobre nuestros SmartContracts. El uso de este ataque es muy conocido en la comunidad de Web3 y rara es la vez que un contrato que ha sido previamente auditado es desplegado conteniendo esta vulnerabilidad. Pero, ¿y si os dijera que existe un exploit que se aprovecha de los contratos que previenen los ataques de reentrancy, una vulnerabilidad que ha pasado desapercibida por la comunidad durante bastante tiempo?

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().

Figura 2: Contrato vulnerable al Reentrancy

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.

Figura 4 Contrato vulnerable al “Read only reentrancy”

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.

Si queréis profundizar en detalle en cómo se realizó el ataque, podéis leerlo en este artículo. Además según ChainSecurity (firma que ha auditado protocolos como el de Curve o Compound) en reportes recientes de sus auditorías unos $100M estarían en riesgo por esta vulnerabilidad.

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…

Figura 7: Libro dedicado a «Bitcoin: La tecnología Blockchain y su investigación» de Yaiza Rubio y Félix Brezo