Desde el inicio del campo de las finanzas descentralizadas (DeFi), el mundo ha visto mejoras masivas en los sistemas financieros tradicionales rivales. Como probablemente ya sabrá, DeFi tiene potencialmente las claves para la banca de las finanzas no bancarizadas y verdaderamente democratizadoras. Sin embargo, todavía hay algunos obstáculos por delante que podrían ralentizar la adopción generalizada de soluciones financieras descentralizadas. Si bien DeFi está logrando avances significativos, los mismos viejos vectores de ataque siguen acechándonos. Hoy veremos los más destacados.
Si desea obtener más información sobre DeFi, blockchain y criptomonedas en general después de leer este artículo, definitivamente debería considerar inscribirse en Ivan en Tech Academy. En Ivan on Tech Academy, te unirás a más de 30.000 estudiantes ya inscritos y podrás ver algunas de las innumerables historias de éxito de la vida real generadas por la Academia a través de testimonios. ¡Impulsa tu carrera en criptografía aprendiendo de expertos en el campo inscribiéndote en Ivan on Tech Academy!
Ataques de reentrada
Uno de los ataques más devastadores que los desarrolladores de contratos inteligentes deben tener en cuenta son los ataques de reentrada. Ambos pueden agotar su contrato inteligente y abrirse camino en su código.
Los informáticos han definido un procedimiento como “reentrante” si su ejecución “se puede interrumpir en el medio, volver a ingresar y ambas ejecuciones pueden completarse sin errores en la ejecución”.
Con respecto a los contratos inteligentes, pueden realizar llamadas de función a otros contratos. Estos contratos pueden, a su vez, llamar a otros e incluso pueden volver a llamar al contrato original. Cuando esto sucede, podemos decir que se ha producido la reentrada.
Entonces, la reentrada en la superficie no es algo malo. Los problemas solo surgen cuando la reentrada pone un contrato inteligente en un estado inconsistente. Un “estado” es consistente cuando se mantiene el invariante principal. En un contrato inteligente, el principal invariante podría ser que la cantidad de retiros no exceda el suministro de tokens del contrato. Eso debe ser cierto.
Un cajero automático disfuncional
Usemos un cajero automático de banco disfuncional como un ejemplo de reentrada que salió mal. ¿Qué pasaría si un cajero automático solo verificara su saldo después de que retirara su tarjeta? Si la máquina seguía repartiendo dinero hasta que retiraras tu tarjeta, podrías vaciarla antes de que se diera cuenta de que tu saldo había pasado la marca cero.
Afortunadamente para los banqueros adinerados, los cajeros automáticos no funcionan de esta manera. Antes de que pueda sacar dinero, verifica su saldo. Y lo vuelve a verificar después de retirar dinero para actualizar su saldo.
Tampoco se supone que los contratos inteligentes entreguen más dinero del que tienen. Sin embargo, al explotar la reentrada, los piratas informáticos pueden convertir un contrato inteligente en un cajero automático disfuncional.
Llamadas a funciones externas
Así es como lo hacen. Durante la ejecución normal, las llamadas a funciones pueden invocar una función desde el mismo contrato o desde uno diferente. Suponga que un atacante puede controlar un contrato que no es de confianza y obtener un contrato vulnerable para realizar una llamada externa antes de resolver su contabilidad interna. En ese caso, el atacante puede realizar una llamada recursiva a la función original. Una llamada recursiva es una rutina que se llama a sí misma directa o indirectamente.
Y si el contrato vulnerable transferirá fondos antes de establecer su saldo en cero, el atacante puede llamar repetidamente a la función de retiro hasta que agote el contrato.
Es posible realizar múltiples retiros porque el estado del contrato no ha cambiado. El estado sigue siendo constante porque el saldo del atacante aún no se ha puesto a cero. El contrato vulnerable no se ha dado cuenta de que los retiros superan la oferta, por lo que el atacante puede pagarse repetidamente hasta que la ejecución se quede sin gas. ¿Quieres aprender más sobre los vectores de ataque DeFi? Si es así, ¡debería unirse a Ivan en Tech Academy hoy y obtener acceso a docenas de cursos de criptomonedas!
Vulnerabilidades de reentrada
Los ataques de reentrada dependen de llamadas externas inseguras. Y dado que cada llamada que no es una llamada interna se puede clasificar como una llamada externa, ¿cómo sabemos cuáles son seguras?
a) Localizar la llamada externa
Los desarrolladores primero deben determinar si hay llamadas externas. Si solo utilizan llamadas internas, no se preocupe. Sin embargo, deben examinar de cerca el código porque las llamadas externas pueden estar al acecho en lugares inesperados (como campos públicos que son visibles para todos).
b) ¿Se puede enganchar la llamada?
Si encuentran llamadas externas, deben determinar si un atacante puede conectar la llamada. En otras palabras, ¿puede el pirata informático controlar la ejecución de la llamada? Las versiones anteriores de Solidity son vulnerables a engancharse, por lo que los desarrolladores deben examinarlas en busca de vectores de ataque DeFi.
c) Transferir llamadas
Incluso si el contrato externo no está controlado por el atacante, las llamadas transferidas son vulnerables a engancharse.
d) Composabilidad
En la “tierra de Lego” de DeFi de la componibilidad, los piratas informáticos pueden atacar un contrato manipulando uno diferente. No es suficiente tener su propia casa en orden; Los desarrolladores también deben comprender todo el ecosistema DeFi para detectar vulnerabilidades provenientes del exterior.
Dos tipos de ataques de reentrada
Los Ataques de Reentrada son de dos tipos: Ataques de Reentrada de Función Única, que son los más fáciles de prevenir, y el tipo más complejo llamado Ataques de Reentrada de Función Cruzada. No exploraremos sus diferencias aquí, pero un hacker usó este último en el ahora infame truco DAO.
El truco de DAO
En junio de 2016, el DAO sufrió un ataque de reentrada por 3,6 millones de ETH. Ese número ascendería a miles de millones de dólares según los precios ETH de hoy.
Este ataque fue tan masivo que la Fundación Ethereum se vio obligada a revertir el truco ejecutando un hard fork. Pudieron hacerlo y rescatar fondos de los inversores. Sin embargo, una parte de la comunidad afirmó que esta acción violó el principio de inmutabilidad de la criptomoneda. Entonces, continuaron usando la cadena vieja. Y esto, damas y caballeros, es la razón por la que tenemos Ethereum y Ethereum Classic hoy.
Lo que sucedió es que el DAO tenía una función vulnerable que un atacante explotó, usando call.value () para crear una secuencia de llamadas recursivas con un contrato inteligente de proxy. Cada vez que el contrato inteligente de proxy solicitaba un retiro legítimo del DAO, la transferencia activaba una función de respaldo. Entonces, la función de respaldo del proxy solicitaría al DAO otro retiro. Y así el proceso continuó porque el saldo del contrato inteligente de proxy nunca se actualizó.
Prevención de ataques de reentrada
Solidity admite tres formas de transferir ETH entre contratos inteligentes, send (), transfer () y call.value ().
La principal diferencia es su asignación de gas. Las funciones de transferencia () y enviar () se consideran más seguras porque están limitadas a 2,300 gas. Este límite de gas evita las costosas llamadas externas de vuelta al contrato vulnerable. La función call (), sin embargo, es más vulnerable.
En el caso de pirateo de DAO, el uso de las funciones enviar () o transferir () en lugar de call.value () podría haber detenido las llamadas de retiro recursivas debido a la baja asignación de gas. O el contrato podría haberse reescrito para actualizar el saldo del usuario antes de la llamada de transferencia.
Mejores prácticas
Dado que no podemos desterrar todas las llamadas externas como un vector de ataque DeFi, aquí hay algunas mejores prácticas a considerar al proteger los contratos inteligentes de los ataques de reentrada.
- Utilice enviar () o transferir () en lugar de llamar () siempre que sea posible.
- Marque las funciones que no sean de confianza.
Los desarrolladores deben identificar las funciones que no son de confianza nombrándolas. Además, si una función llama a otra función que no es de confianza, también debe denominarse “no de confianza”.
Patrón Cheques-Efectos-Interacciones
El patrón de controles-efectos-interacciones es un preventivo confiable. Define el orden que deben seguir las funciones, como poner a cero el saldo antes de realizar una llamada externa. Sin embargo, este patrón sigue siendo vulnerable debido al potencial de error humano. Así que aquí hay una precaución más:
Mutex
Mutex puede ser necesario cuando se trata de problemas más complejos, como los ataques de reentrada de funciones cruzadas. Es una protección de reentrada que hace que la ejecución falle cuando se detecta el reentrada.
Un mutex coloca un bloqueo en el estado del contrato. Un atacante ya no puede explotar la función de retiro o usar una llamada para transferir para ejecutar un ataque de reentrada de función cruzada con un bloqueo en su lugar. Sin embargo, los desarrolladores deben asegurarse de que haya una forma de liberar el bloqueo. OpenZeppelin tiene un Mutex llamado ReentrancyGuard.
Para obtener más información sobre las mejores prácticas para garantizar la seguridad de los contratos inteligentes, visite Ivan en Tech Academy hoy.
Arbitraje (Arb), préstamos flash y ataques de Oracle de precios
Estos tres se enumeran por separado, pero los atacantes a menudo los usan en combinación entre sí.
Vectores de ataque DeFi – Ataques de préstamo flash
Debido a las pequeñas tarifas que implica su uso, los préstamos flash brindan a casi cualquier persona la oportunidad de acceder instantáneamente a grandes cantidades de capital. El único requisito es que el prestatario deba reembolsar el préstamo dentro del mismo bloque. El requisito de tiempo significa que tienen aproximadamente 10 minutos para hacer todo. Pero se sorprendería de lo que algunos de estos ingeniosos piratas informáticos pueden lograr en tan poco tiempo.
Por lo tanto, para cualquiera que busque crear una oportunidad de arbitraje, simplemente puede obtener un préstamo flash, mover el mercado temporalmente y beneficiarse de un intercambio entre los activos desequilibrados artificialmente.
Los vectores de ataque DeFi valoran los ataques de Oracle
Los ataques de reentrada son una vieja noticia para los desarrolladores, pero la manipulación del oráculo de precios a menudo pasa desapercibida. Por lo tanto, no es sorprendente que los ataques de reentrada hayan disminuido mientras que las vulnerabilidades de precios de Oracle están aumentando.
En estos casos, los atacantes crean oportunidades de arbitraje artificial al participar en un proceso rápido de pedir prestado, intercambiar y depositar grandes cantidades de tokens. Al hacerlo, pueden manipular el precio de un activo en un intercambio descentralizado (DEX). Debido a que otros protocolos también dependerán de ese DEX como un oráculo de precios, todos pueden volverse vulnerables al exploit. A menos que una ballena esté dispuesta a arriesgar sus fondos, este tipo de exploits no serían posibles sin los préstamos flash.
Sin embargo, ¿qué es exactamente un oráculo de precios?
Los oráculos de precios son lo que los protocolos consultan para obtener información sobre el precio de los activos. Y diferentes protocolos pueden obtener su información de precios de diferentes maneras. Pueden obtener datos de precios fuera de la cadena de lugares como intercambios centralizados y llevarlos a la cadena. O pueden permanecer en la cadena y obtener sus precios instantáneamente de un DEX como Uniswap.
Cada una de estas soluciones tiene sus ventajas y desventajas. Los datos fuera de la cadena reaccionan más lentamente a la volatilidad, lo que puede ser algo bueno o no. Y los protocolos deben confiar en un pequeño grupo de personas para enviar los datos a la cadena con precisión.
Los datos en cadena, por otro lado, no son confiables y siempre están actualizados. Sin embargo, los atacantes con préstamos flash pueden manipular los datos de precios.
Mal funcionamiento de Synthetix Oracle
Tomemos el protocolo Synthetix como ejemplo. Synthetix es una plataforma de derivados que solía depender únicamente de un feed de precios fuera de la cadena.
En 2019, su feed citó erróneamente el won coreano y Synthetix lo publicó en la cadena. Un robot comercial, oliendo sangre en el agua, se apoderó rápidamente de él y casi se lleva una ganancia de mil millones de dólares. Afortunadamente, el comerciante devolvió los fondos en lugar de una recompensa por errores, pero este caso demuestra lo rápido que las cosas pueden ir al sur con datos fuera de la cadena.
Por el contrario, puede ser tentador recuperar el precio spot actual en Uniswap u otro DEX y usarlo como fuente. Y, por lo general, estos datos son suficientes porque los arbitrajistas corrigen rápidamente cualquier desviación de precios. Sin embargo, los precios al contado pueden fluctuar enormemente durante breves períodos de tiempo, lo suficiente para que un asistente de Flash Loan haga su magia.
La solución de múltiples fuentes
Algunos desarrolladores tienen la impresión equivocada de que un solo oráculo es el culpable de la manipulación del oráculo de precios.
Si un arbitrajista manipula a Kyber, salta a Uniswap y así sucesivamente. Pero en realidad, cada vez que un protocolo se basa en un oráculo de precio único, está buscando problemas. La solución no es saltar a diferentes oráculos; la respuesta es utilizar múltiples fuentes de información, evitar los tokens sin líquido e incluso considerar el uso de las soluciones de precio promedio ponderado en el tiempo.
Vectores de ataque DeFi – Ataques de arbitraje
Los ataques arbitrales pueden ser un poco controvertidos porque la gente se ha preguntado si son ataques o simplemente una característica de DeFi. Los arbitrajistas sirven tradicionalmente para mantener la liquidez de los mercados. Sin embargo, cuando una ballena o un oportunista con un Flash Loan descomunal se conecta artificialmente con los precios de Oracle para crear una oportunidad de arbitraje artificial, ¿es realmente un ataque? ¿O es solo una toma de ganancias temporal hasta que el ecosistema DeFi se endurezca?
Mientras que algunos creen que esto no es ético o incluso ilegal, otros argumentan que es la mecánica estándar del mercado en funcionamiento. Independientemente de lo que piense, DeFi ha visto un aumento en los ataques de préstamos flash. Hemos sido testigos de que Akropolis, Cheese Bank, Harvest Finance, Origin Protocol y Value DeFi fueron golpeados con ellos en el último mes.
Ataques DeFi – Conclusión
Hemos cubierto los vectores de ataque DeFi más probables en este artículo, pero vale la pena mencionar otros. Si tiene curiosidad acerca de estos, incluyen técnicas como Front Running y Sandwich Attacks, Timestamp Dependence, DOS con una reversión inesperada y Insufficient Gas Griefing, por nombrar algunos. Quizás los exploraremos en artículos futuros, pero hemos cubierto los ataques más probables por ahora.
Y para ser franco, si un protocolo es pirateado en el ecosistema DeFi, a menudo es porque los desarrolladores no lo construyeron correctamente. Después de todo, los piratas informáticos no han tenido que ser tan creativos en 2020. A pesar del hack de Pickle Finance, casi todos los demás hackeos de este año implicaron un préstamo Flash que manipuló un oráculo de precios para lanzar un ataque Arb.
Sin embargo, la buena noticia es que el sistema se endurece cada vez que es pirateado y, con suerte, la comunidad DeFi aprenderá de los errores de 2020. Los ataques seguramente crecerán cada vez más en el futuro. Es por eso que los desarrolladores deben emplear las mejores prácticas al codificar contratos inteligentes, junto con la realización de auditorías de seguridad continuas y recompensas por errores. De lo contrario, los Black Hats con el deseo de desarrollar continuamente su destreza tecnológica para obtener ganancias ilícitas podrían seguir siendo más astutos que los White Hats. Sin embargo, cada pirateo ha hecho que la industria en su conjunto sea más resistente y ha destacado la necesidad de la debida diligencia técnica. ¿Quieres aprender a escribir contratos inteligentes seguros tú mismo? Si planeas convertirte en un desarrollador de blockchain de clase mundial, ¡asegúrate de unirte a Ivan en Tech Academy hoy mismo!
Autor: MindFrac
