Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
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().
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:
Figura 1: Read-Only Reentrancy Attack: $220k robados y +$100M en riesgo
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.
Figura 3: Esquema de vulneración de un contrato usando “Reentrancy”
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:
1. Contrato Attacker, llama a la función withdraw() del contrato Vulnerable.
2. Vulnerable, para devolver los fondos tiene que llamar a fallback() de Attacker.
a. Llama a fallback() porque así se envía el ETH en este caso.
b. Podría ser cualquier tipo de llamada externa
3. Attacker desde fallback() llama a lendMe() en DeFi, dependiente de los datos de Vulnerable.
4. DeFi lee los datos de Vulnerable pero estos están desactualizados y realizará acciones que no debería.
Figura 5: Diagrama explotación vulnerabilidad “Read only reentrancy”
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.
Figura 6: Protocolos con riesgo, por ChainSecurity
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...
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 |
Seguiremos hablando de este tipo de ataques que cada día van a ser más peligrosos en nuestros servicios digitales con la llegada masiva de la Web3.
Más artículos de Web3, Blockchain & SmartContracts
- Blockchain & SmartContracts: Una serie para aprender
- BlockChain & SmartContrats: Primer SmartContract con Solidity
- Blockchain & SmartContracts: Cómo probar y desplegar un SmartContract en Ethereum
- WWW, Web 1.0, Web 2.0, Web 3.0, Web3 y ¿Web 4.0?
- Metaverso, multiverso y las tierras digitales en que vivimos en forma de avatar
- Los Fan Tokens vs. las Criptomonedas y los NFTs: Level 101
- Tokenomics: Las criptomonedas y las "Proof-of-work": Level 101
- Los NFTs y el registro mundial de los dueños de activos digitales en el Metaverso
- BitCoin: Blockchain y su investigación
- BlockChain & SmartContrats: El Internet descentralizado y el almacenamiento off-chain en IPFS
- Reentrancy Attack: Cómo te roban criptomonedas por un bug en tu SmartContract
- BlockChain & SmartContract: Bugs que pueden dejar tu SmartContrat "fuera de juego"
- Blockchain & SmartContracts: Patrones y buenas prácticas de seguridad
- Blockchain & SmartContracts: Herramientas de Auditoría de Seguridad de SmartContracts
- BlockChain & SmartContracts: Ataque de phishing a tx.origin y robo de criptomonedas
- BlockChain & SmartContracts: Ataques de Ice Phishing
- Blockchain & SmartContracts: Herramientas de análisis dinámico
- ZIION: Una distribución Linux para auditar SmartContracts (& BlockChain)
- Dominios Web3 en Etherenum Name Service y la trazabilizad de las transacciones Blockchain
- BlockChain & SmartContracts: Actualizar SmartContracts como los grandes protocolos
- Jumping level up (from) web2 (to) web3: Vulnerabilities & SCAMs - SmartContracts
- 20 millones (Euros) en Tokens de Optimism perdidos por no saber cómo funcionan los Wallets Multifirma
- BlockChain & SmartContracts: Cómo crear una DApp de la Web3 con Python (y Flask)
- Pentesting SmartContracts: From Web2.0 to Web3
- Tokenomics 101: Una explicación con gráficos
- Read-Only Reentrancy Attack: $220k robados y otros +$100M en riesgo
No hay comentarios:
Publicar un comentario