¿Qué es un Contrato Inteligente?

Ethereum tiene dos tipos comunes de cuentas: Cuentas de Propiedad Externa (EOA, por sus siglas en inglés) y Cuentas de Contrato Inteligente (SCA, por sus siglas en inglés).

Las EOA son muy similares a las cuentas financieras electrónicas que comúnmente usamos para almacenar fondos e interactuar con aplicaciones. Por ejemplo, los usuarios depositan moneda fiduciaria a través de PayPal e interactúan con varios sitios web, tiendas y aplicaciones para realizar pagos. Los mineros de DeFi generalmente almacenan criptomonedas en sus EOA, interactúan con dApps de DeFi y depositan fondos en dApps para obtener beneficios. Sin embargo, las EOA tienen una característica que las cuentas financieras electrónicas no poseen: los usuarios deben tener su control sobre las EOA verificado a través de la propiedad de claves privadas— sin tus claves, no son tus monedas.

Las SCA son también un tipo de cuenta que está esencialmente asociada con un segmento de código de bytes ejecutable (también conocido como contrato inteligente). El contrato inteligente describe varias lógicas de negocio y sirve como backend para las dApps. Sin embargo, a pesar de tener más restricciones en comparación con los lenguajes de desarrollo Turing completos tradicionales, los contratos inteligentes cuasi-Turing completos aún han sido vulnerables a numerosos ataques, asestando innumerables golpes a la industria de la blockchain.

Ataques Comunes a Contratos Inteligentes

1. Ataque de Reentrada

El ataque más común y notorio es el ataque de reentrada, que fue responsable de la bifurcación de Ethereum que llevó a la creación de Ethereum Classic. En 2016, los hackers ejecutaron un ataque de reentrada en el contrato de The DAO, robando 3,600,000 ETH valorados en más de $150 millones en ese momento. Este ataque, ocurriendo durante las primeras etapas de Ethereum, devastó el ecosistema y destrozó la confianza de los inversores, lo que finalmente llevó a una bifurcación.

Lógica Específica

Aquí hay un ejemplo para ayudarte a entender mejor el principio del ataque de reentrada. El Banco B previamente prestó algo de dinero al Banco A. Un día, el Banco B inicia una transferencia al Banco A, solicitando la transferencia de todo el dinero de vuelta al Banco B. El camino normal es el siguiente:

Paso 1: El Banco B solicita el retiro de fondos

Paso 2: El Banco A transfiere los fondos al Banco B

Paso 3: El Banco A confirma la transferencia exitosa al Banco B

Paso 4: El Banco A actualiza el saldo de la cuenta del Banco B.

Sin embargo, si el Banco B crea una brecha después del Paso 2 y continúa solicitando todo el dinero del Banco A sin confirmación en el Paso 3, entonces el saldo de la cuenta del Banco A en el Banco B permanecerá sin cambios. Esta llamada recursiva vaciará todos los activos del Banco A.

Contratos inteligentes relacionados

El contrato del Banco A incluye dos funciones:

deposit(): Una función de depósito que deposita dinero en el Banco A y actualiza el saldo del usuario;
withdraw(): Una función de retiro que permite a los usuarios retirar todos sus fondos del Banco A.

El contrato de ataque del Banco B implica principalmente un bucle que activa la función de devolución de llamada receive(), la cual a su vez llama a la función withdraw() del contrato del Banco para drenar los activos del Banco A a través de una secuencia de 1 depósito, 1 retiro y llamadas a la función de devolución de llamada receive(), y finalmente actualiza el saldo de B en A. Incluye dos funciones:receive(): Una función de devolución de llamada que se activa cuando se recibe ETH, la cual llama recursivamente a la función withdraw() del contrato del Banco para realizar retiros.
attack(): Primero llama a la función deposit() del contrato del Banco para actualizar el saldo y luego a la función withdraw() para iniciar el primer retiro, y activa la función de devolución de llamada receive() para llamar recursivamente a withdraw() para drenar los activos del contrato del Banco.

Solución

Implementación de un bloqueo de reentrada

Un bloqueo de reentrada es un modificador utilizado para prevenir la reentrada, asegurando que una llamada debe completar su ejecución antes de que pueda ser invocada nuevamente. Por ejemplo, dado que el ataque del Banco B requiere llamar a la función withdraw() del contrato del Banco múltiples veces, fallará con la implementación de un bloqueo de reentrada.

Cómo utilizarlo

2. Uso incorrecto de tx.origin

La función principal de tx.origin en un contrato inteligente es recuperar la cuenta original que inició la transacción. Aquí, discutiremos dos variables comunes en los contratos inteligentes: msg.sender y tx.origin. msg.sender recupera la cuenta que llama directamente al contrato inteligente, mientras que en el mundo de la blockchain, debido a las llamadas anidadas y mutuas de diferentes contratos inteligentes (como DeFi Lego), se necesita tx.origin para obtener la cuenta original que inició la transacción. Surge una vulnerabilidad cuando los desarrolladores de dApps solo verifican la seguridad de tx.origin en el código, descuidando la verificación de seguridad de los atacantes que despliegan contratos intermedios para eludir tx.origin y lanzar ataques.

Lógica Específica

Aquí hay un ejemplo para que profundices en el escenario de ataque común. Bill tiene una billetera inteligente que verifica si Bill es el iniciador de una transferencia. En una ocasión, Bill acuñó un NFT en un sitio web de phishing. Eso permitió al sitio web obtener la identidad de Bill e iniciar una transferencia desde su billetera inteligente usando su identidad, resultando en pérdidas de activos. En circunstancias normales, es menos probable que los usuarios caigan en esta trampa, pero al interactuar con dApps usando una billetera, a menudo olvidan revisar las indicaciones de interacción. Por ejemplo, si ambos involucran la función Mint(), los usuarios descuidados pueden caer fácilmente en una trampa de phishing. La lógica de negocio dentro del sitio web de phishing está llena de trampas, por lo que es importante verificar las indicaciones de interacción en busca de errores durante las interacciones regulares.

Contrato de Billetera Inteligente

El contrato de billetera inteligente incluye una función:

transfer(): Una función de retiro que solo puede ser iniciada por el propietario de la billetera, que en este caso es Bill.

Contrato de Ataque de Phishing

En un contrato de ataque de phishing, Mint() induce a los usuarios a transferir fondos a la dirección de un hacker. Incluye una función:

Mint(): Una vez llamada, la función de phishing ejecuta internamente transfer() del contrato Wallet. Dado que el iniciador original es el propio usuario (en este ejemplo, Bill), la verificación require(tx.origin == owner, "Not owner"); no será un problema. Sin embargo, la dirección de destino para la transferencia ya ha sido alterada a la dirección del hacker, resultando en el robo de fondos.

Soluciones

1. Usar msg.sender en lugar de tx.origin

No importa cuántas llamadas de contrato estén involucradas (Contrato A → Contrato B →...→ contrato objetivo), solo se verifica msg.sender, es decir, el llamador directo, para evitar ataques causados por contratos intermedios maliciosos.

2. Verificar tx.origin == msg.sender

Este método puede mantener alejados los contratos maliciosos, pero los desarrolladores necesitan considerar sus propias realidades comerciales, ya que efectivamente aísla todas las demás llamadas de contratos externos.

3. Ataque del Generador de Números Aleatorios (RNG)

Esto se remonta a la tendencia de las dApps de juegos de azar o apuestas alrededor de 2018 y 2019. Típicamente, los desarrolladores utilizan ciertas semillas en contratos inteligentes para generar números aleatorios y seleccionar ganadores durante los sorteos. Las semillas comunes incluyen block.number, block.timestamp, blockhash y keccak256. Sin embargo, los mineros pueden controlar completamente estas semillas, por lo que en algunos casos, los mineros malintencionados pueden manipular las variables para obtener beneficios.

Contratos de Dados Comunes

El contrato de Dados incluye una función:

Bet(): Una función de apuesta donde los usuarios ingresan un número de apuesta y pagan un ETH. Se genera un número aleatorio con múltiples semillas, y si el número de apuesta coincide con el número aleatorio, el usuario gana todo el pozo de premios.

Contrato de Ataque del Minero

Los mineros pueden ganar siempre que precalculen el número aleatorio ganador y lo ejecuten en el mismo bloque. Esto incluye una función:

attack(): Una función de ataque de apuesta, donde el minero precalcula el número aleatorio ganador. Como se ejecuta en el mismo bloque, blockhash(block.number - 1) y block.timestamp en el mismo bloque son iguales. Luego, el minero llama a Bet() del contrato de Dados para completar el ataque.

Solución

Utilizar números aleatorios fuera de la cadena proporcionados por proyectos de oráculos

A través de servicios proporcionados por proyectos oracle como Chainlink, se inyectan números aleatorios en cadena a los contratos en cadena para garantizar la aleatoriedad y la seguridad. Sin embargo, los proyectos oracle también conllevan riesgos de centralización, lo que hace necesario contar con servicios oracle más maduros.

4. Ataque de Reproducción

Un ataque de reproducción implica reiniciar una transacción utilizando una firma previamente utilizada para robar fondos. Uno de los ataques de reproducción más conocidos en los últimos años fue el robo de 20 millones de tokens $OP del creador de mercado Wintermute en Optimism, que fue un ataque de reproducción entre cadenas. Dado que la cuenta de billetera multifirma de Wintermute se implementó temporalmente solo en la red principal de Ethereum, el hacker utilizó la firma de la transacción para la implementación de una dirección multifirma de Wintermute en Ethereum para volver a ejecutar la misma transacción en la cadena de Optimism, obteniendo así el control de la cuenta de billetera multifirma en Optimism. Una cuenta de billetera multifirma es esencialmente una cuenta de contrato inteligente, lo que también demuestra una diferencia significativa entre SCA y EOA. Para una EOA, un usuario normal solo necesita una clave privada para controlar todas las direcciones en Ethereum y las cadenas compatibles con EVM (las cadenas de direcciones son exactamente iguales), mientras que una SCA es efectiva solo en una cadena después de ser implementada.

Lógica Específica

Aquí, proporcionamos un ejemplo de un ataque de reproducción típico (ataque de reproducción en la misma cadena). Bill tiene una billetera inteligente que requiere que ingrese su firma electrónica antes de que se pueda ejecutar cada transacción. Ahora que la hacker Lucy ha robado la firma electrónica de Bill, puede iniciar un número ilimitado de transacciones para vaciar la billetera inteligente de Bill.

Ejemplo

Un contrato con vulnerabilidades consta de tres funciones:

checkSig(): Función de verificación ECDSA, asegurando que el resultado de la verificación sea el firmante originalmente establecido.
getMsgHash(): Función para generar hash, que combina to y amount para formar el hash.
transfer(): Función de transferencia, que permite a los usuarios retirar fondos del pool de liquidez. Debido a la falta de restricciones en la firma, la misma firma puede ser reutilizada, permitiendo a los hackers robar fondos continuamente.

Solución

Incluir el nonce en la combinación de la firma para prevenir ataques de repetición. El principio del parámetro es el siguiente:

nonce: Describe la variable del número de transacciones de una EOA en la red blockchain. Tiene orden y unicidad. Con cada transacción adicional, el valor del nonce aumentará en 1. La red blockchain verificará si el nonce de la transacción es consistente con el nonce actual de la cuenta. Por lo tanto, un hacker fracasaría si usa una firma ya utilizada porque el valor del nonce en la combinación de la firma es menor que el valor actual del nonce de la EOA.

5. Ataque de Denegación de Servicio (DoS)

El ataque de Denegación de Servicio (DoS) no es nada nuevo en el mundo tradicional de Web2. Se refiere a cualquier interferencia con un servidor, como enviar una gran cantidad de información basura o disruptiva, obstaculizando o destruyendo completamente la disponibilidad. De manera similar, los contratos inteligentes se ven afectados por tales ataques, que esencialmente buscan hacer que el contrato inteligente funcione incorrectamente.

Lógica Específica

Veamos un ejemplo. El Proyecto A está realizando una oferta pública del token del protocolo, donde todos los usuarios pueden aportar fondos al pool de liquidez (Contrato Inteligente) para comprar cuotas por orden de llegada, y los fondos excedentes serán devueltos a los participantes. La hacker Alice explota el contrato de ataque para participar en la oferta pública. Una vez que el pool de liquidez intenta devolver fondos al contrato de ataque de Alice, se activará un ataque DoS, impidiendo que la acción de devolución se realice alguna vez. Como resultado, una gran cantidad de fondos quedan bloqueados en el contrato inteligente.

Ejemplo de contrato de oferta pública

Ejemplo

El contrato de oferta pública incluye dos funciones:

deposit(): función de depósito, que registra la dirección del depositante y la cantidad aportada.
refund(): función de reembolso, con la cual el equipo del proyecto devuelve los fondos a los inversores.

Contrato de ataque DoS

El contrato de ataque DoS incluye una función:

attack(): A pesar de ser una función de ataque, no presenta ningún problema. El problema principal radica en la función de devolución de llamada de pago receive() incorporada en el contrato Hacker, que incluye un juicio de excepciones. Cualquier contrato externo que transfiera fondos al contrato Hacker activará una excepción a través de revert(), impidiendo así que se complete la operación.

Soluciones

1. Evitar que la funcionalidad crítica se bloquee al invocar contratos externos

Eliminar require(success, "Refund Fail!"); de la función refund() del contrato PublicSale mencionada anteriormente, asegurando que la operación de reembolso pueda continuar incluso si falla un reembolso a una sola dirección.

2. Desacoplamiento

En la función refund() del contrato PublicSale mencionada anteriormente, permitir que los usuarios reclamen reembolsos por su cuenta en lugar de distribuir los reembolsos, minimizando así las interacciones innecesarias con contratos externos.

6. Ataque permit

En un ataque de permiso, la Cuenta A proporciona la firma para una parte designada por adelantado, y luego la Cuenta B, al obtener la firma, puede llevar a cabo transferencias de tokens autorizadas para robar una cierta cantidad de tokens. Aquí, discutimos principalmente dos funciones comunes para la autorización de tokens en Contratos Inteligentes: approve() y permit().

En el contrato ERC20 común, la Cuenta A puede llamar a approve() para autorizar una cierta cantidad de tokens para la Cuenta B, permitiendo a esta última transferir esos tokens desde la primera. Además, permit() se introdujo en los contratos ERC20 en EIP-2612, y Uniswap ha lanzado un nuevo estándar de autorización de tokens, Permit2, en noviembre de 2022.

Lógica Específica

Aquí hay un ejemplo. Un día, Bill estaba navegando por un sitio web de noticias de blockchain cuando de repente apareció una ventana emergente de firma de Metamask. Dado que muchos sitios web o aplicaciones de blockchain utilizan firmas para verificar los inicios de sesión de los usuarios, Bill no le dio mucha importancia y completó la firma directamente. Cinco minutos después, sus activos de Metamask fueron vaciados. Bill entonces descubrió en el explorador de blockchain que una dirección desconocida inició una transacción permit(), seguida de una transacción transferFrom() que vació su billetera.

Ejemplo

Las dos funciones son las siguientes:

approve(): Una función de autorización estándar donde la Cuenta A autoriza una cierta cantidad de fondos a la Cuenta B.
permit(): Una función de autorización por firma donde la Cuenta B envía y completa la verificación de firma para obtener la cantidad autorizada de la Cuenta A. Los parámetros incluyen el propietario que otorga la autorización, el gastador autorizado, la cantidad autorizada, la fecha límite de la firma, y los datos de firma v, r, y s del propietario.

Soluciones

1. Prestar atención a cada firma en las interacciones en cadena

A pesar de las medidas que algunos monederos toman para decodificar y mostrar la información de firma de autorización approve(), casi no proporcionan advertencias para el phishing de firmas permit(), lo que aumenta el riesgo de ataques. Por lo tanto, se recomienda encarecidamente inspeccionar rigurosamente cada firma desconocida para asegurarse de si está dirigida a la función permit().

2. Separar el monedero para interacciones regulares del monedero que almacena activos

Esto es extremadamente importante para los usuarios de criptomonedas, especialmente para los cazadores de airdrops, ya que interactúan con innumerables dApps o sitios web todos los días y son propensos a caer en trampas. Almacenar solo una pequeña cantidad de fondos en un monedero para interacciones regulares puede mantener las pérdidas dentro de un rango manejable.

7. Ataque de Honeypot

En la industria blockchain, un ataque de honeypot se refiere a un tipo de contratos de tokens maliciosos desplegados por equipos de proyectos. El contrato solo otorga al equipo del proyecto el permiso para vender, mientras que los usuarios regulares solo pueden comprar en lugar de vender, sufriendo así pérdidas.

Lógica Específica

Aquí hay un ejemplo. En un anuncio en Telegram, el Proyecto A informa a los usuarios que el token ha sido desplegado en la red principal y está disponible para negociar. Como el token solo se puede comprar y no se puede vender, el precio seguía subiendo al principio, y los usuarios que temen perderse la oportunidad siguen comprando. Después de algún tiempo, cuando los usuarios descubren que no pueden vender, el equipo del proyecto aprovecha la oportunidad y vende los tokens, causando que el precio se desplome.

Ejemplo

Función principal:

_beforeTokenTransfer(): Una función interna llamada durante las transferencias de tokens, que solo puede tener éxito cuando es llamada por el propietario; las llamadas de otras cuentas fallarán.

Solución

Utilizar herramientas de escaneo de seguridad

a. Token Sniffer para tokens de Ethereum

b. Ave Check para tokens en otras cadenas

c. Sitios web de mercado con herramientas de detección integradas como Dextools

Evitar operar con tokens que tengan puntuaciones bajas.

8. Ataque de Front-Running

El front-running surgió originalmente en los mercados financieros tradicionales, donde la asimetría de información permitía a los intermediarios financieros obtener beneficios tomando acciones rápidas basadas en información específica de la industria. En la industria blockchain, el front-running se deriva principalmente del front-running en cadena, que implica manipular a los mineros para priorizar la inclusión de las transacciones propias en la cadena con el fin de obtener beneficios.

En el ámbito de la blockchain, los mineros pueden obtener beneficios manipulando las transacciones que incluyen en los bloques, por ejemplo, excluyendo ciertas transacciones y reordenando otras. Este beneficio se puede medir con el Valor Extraíble por el Minero (MEV, por sus siglas en inglés). Antes de que la transacción de un usuario se añada a la red principal de Ethereum, la mayoría de las transacciones se agregan en el mempool. Los mineros buscan en este mempool transacciones con precios de gas más altos y priorizan su inclusión para maximizar sus ganancias. Generalmente, las transacciones con precios de gas más altos son más fácilmente incluidas por los mineros. Mientras tanto, algunos bots de MEV también rastrean el mempool en busca de transacciones rentables.

Lógica Específica

A continuación se presenta un ejemplo. Bill descubre un nuevo token popular con fluctuaciones significativas de precio. Para asegurar el éxito de las transacciones de tokens en Uniswap, Bill establece un rango de deslizamiento excepcionalmente amplio. Desafortunadamente, el bot de MEV de Alice detecta esta transacción en el mempool y rápidamente aumenta la tarifa de gas, iniciando una transacción de compra antes que la de Bill e insertando una transacción de venta después de la de Bill dentro del mismo bloque. Después de la confirmación del bloque, esto causa pérdidas significativas por deslizamiento para Bill, mientras que Alice se beneficia de una operación de arbitraje de comprar bajo y vender alto.

Ejemplo

La función es la siguiente:

solve(): Una función de adivinanza donde cualquiera puede enviar una respuesta, y si la respuesta enviada coincide con la respuesta objetivo, el remitente puede recibir 10 ethers.

Proceso: Bill encuentra la respuesta correcta.
Alice monitorea el mempool, esperando que alguien envíe la respuesta correcta.
Bill llama a solve() para enviar la respuesta y establece el precio del gas en 100 Gwei.
Alice ve la transacción enviada por Bill y descubre la respuesta. Ella establece un precio de gas más alto que el de Bill, 200 Gwei, y llama a solve().
La transacción de Alice es empaquetada por el minero antes que la de Bill.
Alice gana una recompensa de 10 ethers.

Solución

Las tres funciones principales son las siguientes:

commitSolution(): Una función para enviar resultados, colocando la respuesta enviada por el usuario solutionHash, el tiempo de envío commitTime y el estado revealed en la estructura Commit.
getMySolution(): Una función para obtener resultados, permitiendo a los usuarios ver sus respuestas enviadas e información relacionada, incluyendo la respuesta enviada por el usuario solutionHash, el tiempo de envío commitTime y el estado revealed.
revealSolution(): Una función para reclamar recompensas por adivinar el acertijo, permitiendo a los usuarios reclamar recompensas después de proporcionar la respuesta y la contraseña que establecieron.

Proceso:

Bill encuentra la respuesta correcta.
Bill llama a commitSolution() para enviar la respuesta correcta.
En el siguiente bloque, Bill llama a revealSolution(), proporcionando la respuesta y la contraseña que estableció para reclamar la recompensa.

En commitSolution(), Bill envía una cadena encriptada, manteniendo los datos en texto plano enviados solo para sí mismo. En este paso, también se registra el tiempo del bloque de envío commitTime. A continuación, en revealSolution(), se verifica el tiempo del bloque para evitar el adelantamiento dentro del mismo bloque. Dado que llamar a revealSolution() requiere el envío de la respuesta en texto plano, este paso tiene como objetivo evitar que otros eviten commitSolution() y llamen directamente a revealSolution(). Después de una verificación exitosa, la recompensa se distribuirá si se comprueba que la respuesta es correcta.

Conclusión

Los contratos inteligentes juegan un papel crucial en la tecnología blockchain y ofrecen numerosas ventajas. En primer lugar, permiten una ejecución descentralizada y automatizada, garantizando la seguridad y fiabilidad de las transacciones sin terceros. En segundo lugar, los contratos inteligentes reducen los pasos intermediarios y los costos, mejorando la eficiencia de las transacciones.

A pesar de tantos beneficios, los contratos inteligentes también se enfrentan al riesgo de ataques que pueden causar pérdidas financieras a los usuarios. Como tal, algunos hábitos son esenciales para los usuarios en la cadena. En primer lugar, los usuarios siempre deben elegir cuidadosamente las dApps para interactuar y revisar exhaustivamente el código del contrato y las reglas relacionadas. Además, deben actualizar y utilizar regularmente carteras seguras y herramientas de interacción de contratos para mitigar el riesgo de ataques de hackers. Además, es aconsejable almacenar sus fondos en múltiples direcciones para minimizar las posibles pérdidas por ataques a contratos.

Para los actores de la industria, garantizar la seguridad y estabilidad de los contratos inteligentes es igualmente importante. La primera prioridad debe ser fortalecer la auditoría de los contratos inteligentes para identificar y rectificar posibles vulnerabilidades y riesgos de seguridad. En segundo lugar, los actores de la industria deben mantenerse informados sobre los últimos desarrollos de blockchain relacionados con ataques a contratos y tomar medidas de seguridad en consecuencia. Por último, pero no menos importante, también deben mejorar la educación del usuario y la concienciación sobre seguridad en cuanto al uso correcto de los contratos inteligentes.

En conclusión, con los esfuerzos concertados de usuarios y actores de la industria, los riesgos de seguridad que plantean los contratos inteligentes pueden mitigarse significativamente. Los usuarios siempre deben seleccionar cuidadosamente los contratos y salvaguardar los activos personales, mientras que los actores de la industria deben intensificar la auditoría de contratos, mantenerse al tanto de los avances tecnológicos y mejorar la educación del usuario y la concienciación sobre seguridad. Juntos, impulsaremos el desarrollo seguro y fiable de los contratos inteligentes.

Referencias:

Solidity by Example：https://solidity-by-example.org/

Blockchain Know-how of SlowMist：https://mp.weixin.qq.com/mp/appmsgalbum?__biz=MzU4ODQ3NTM2OA==&action=getalbum&album_id=1378673890158936067&scene=173&from_msgid=2247498135&from_itemidx=1&count=3&nolastread=1#wechat_redirect

Chainlink - Top 10 DeFi Security Best Practices：https://blog.chain.link/defi-security-best-practices/#post-title

WTF - Solidity 104 Contract Security：https://www.wtf.academy/solidity-104/

Vulnerabilities in DeFi Smart Contracts in 4 Categories with 38 Scenarios：https://www.weiyangx.com/381670.html

OpenZeppelin：https://github.com/OpenZeppelin/

KRC20: بروتوكول الرموز المبتكر الذي يدفع تطوير نظام كاسبا البيئي