¡Créalo o no, Uniswap v4 pronto conocerá a todos!

Esta vez, el equipo de Uniswap se ha fijado metas ambiciosas y planea introducir muchas nuevas características, incluyendo un número ilimitado de grupos de liquidez y comisiones dinámicas para cada par de intercambio, diseño singleton, contabilidad flash, Hook y soporte para el estándar de token ERC1155. Utilizando el almacenamiento transitorio introducido por EIP-1153, se espera que Uniswap v4 sea lanzado después de la actualización de Ethereum Cancún. Entre las muchas innovaciones, el mecanismo Hook ha ganado amplia atención debido a su potencial poderoso. El mecanismo Hook permite que se ejecute código específico en puntos específicos en el ciclo de vida de un grupo de liquidez, mejorando en gran medida la escalabilidad y flexibilidad de los grupos. Sin embargo, el mecanismo Hook también puede ser un arma de doble filo. Aunque es poderoso y flexible, el uso seguro de Hook también es un desafío significativo. La complejidad de Hook inevitablemente trae nuevos vectores de ataque potenciales. Por lo tanto, esperamos escribir una serie de artículos para introducir sistemáticamente los problemas de seguridad y riesgos potenciales relacionados con el mecanismo Hook, para promover el desarrollo de seguridad de la comunidad. Creemos que estos conocimientos ayudarán a construir Hooks seguros para Uniswap v4. Como artículo de apertura de esta serie, este artículo introduce los conceptos relacionados con el mecanismo Hook en Uniswap v4 y perfila los riesgos de seguridad asociados con el mecanismo Hook.

- 1 - Mecanismo de Uniswap V4

Antes de profundizar, necesitamos una comprensión básica de los mecanismos detrás de Uniswap v4. Según el anuncio oficial [1] y el libro blanco [2], Hooks, la arquitectura singleton y la contabilidad flash son tres características importantes que permiten piscinas de liquidez personalizadas y enrutamiento eficiente a través de múltiples piscinas.

1.1 Gancho

Hooks se refiere a contratos que se ejecutan en diferentes etapas del ciclo de vida de un pool de liquidez. El equipo de Uniswap espera permitir a cualquier persona tomar decisiones de compensación introduciendo Hooks. De esta manera, se puede implementar soporte nativo para comisiones dinámicas, órdenes límite en cadena o creadores de mercado promedio ponderado en el tiempo (TWAMMs) para dividir grandes pedidos. Actualmente, hay ocho Hooks de devolución de llamada, divididos en cuatro pares (cada par contiene una devolución de llamada antes y una después):

• beforeInitialize/afterInitialize
• beforeModifyPosition/afterModifyPosition
• antes del intercambio/después del intercambio
• beforeDonate/afterDonate

A continuación se muestra el flujo del swap Hook introducido en el whitepaper [2].

Figura 1: Flujo de Swap Hook

El equipo de Uniswap demostró la metodología con algunos ejemplos (por ejemplo, Gancho TWAMM [3]), y los participantes de la comunidad también han hecho contribuciones. La documentación oficial [4] también enlaza con el repositorio Awesome Uniswap v4 Hooks [5], que recopila más ejemplos de Gancho.

1.2 Singleton, Contabilidad Flash y Mecanismo de Bloqueo

La arquitectura singleton y la contabilidad flash tienen como objetivo mejorar el rendimiento al reducir costos y garantizar eficiencia. Introduce un nuevo contrato singleton donde todas las piscinas de liquidez se almacenan en el mismo contrato inteligente. Este diseño singleton se basa en un PoolManager para almacenar y gestionar el estado de todas las piscinas. En versiones anteriores del protocolo Uniswap, operaciones como el intercambio o la adición de liquidez implicaban transferencias directas de tokens. La Versión 4 es diferente en que introduce la contabilidad flash y un mecanismo de bloqueo.

👇🏻 El mecanismo de bloqueo funciona de la siguiente manera: 1. Un contrato de locker solicita un bloqueo al PoolManager. 2. El PoolManager agrega la dirección del contrato de locker a la cola de datos de bloqueo y llama a su callback de bloqueo adquirido. 3. El contrato de locker ejecuta su lógica en el callback. Las interacciones con el pool durante la ejecución pueden resultar en incrementos de moneda no nulos. Sin embargo, al final de la ejecución, todos los incrementos deben compensarse a cero. Además, si la cola de datos de bloqueo no está vacía, solo el último contrato de locker puede ejecutar operaciones. 4. El PoolManager verifica el estado de la cola de datos de bloqueo y los incrementos de moneda. Después de la verificación, el PoolManager elimina el contrato de locker.

En resumen, el mecanismo de bloqueo evita el acceso concurrente y garantiza que todas las transacciones puedan liquidarse. Los contratos de Locker solicitan bloqueos en secuencia, y luego ejecutan operaciones a través de la devolución de llamada lockAcquired. Las devoluciones de llamada Hook correspondientes se activan antes y después de cada operación de pool. Finalmente, el PoolManager verifica los estados. Esto significa que las operaciones ajustan los saldos netos internos (es decir, delta) en lugar de realizar transferencias instantáneas. Cualquier modificación se registra en los saldos internos del pool, y las transferencias reales se realizan cuando finaliza la operación (es decir, el bloqueo). Este proceso garantiza que no haya tokens pendientes, manteniendo la integridad de los fondos. Debido al mecanismo de bloqueo, las cuentas de propietario externo (EOAs) no pueden interactuar directamente con el PoolManager. En cambio, cualquier interacción debe pasar por un contrato. Este contrato actúa como un locker intermediario, solicitando un bloqueo antes de realizar cualquier operación de pool.

👇🏻 Hay dos escenarios principales de interacción con contratos:

• Un contrato de bloqueo proviene de la base de código oficial, o es desplegado por un usuario. En este caso, podemos ver la interacción como pasando a través de un enrutador.
• Un contrato de bloqueo y Hook están integrados en el mismo contrato, o controlados por una entidad de terceros. Para este caso, podemos ver la interacción como pasando a través de un Hook. Aquí, el Hook desempeña el papel tanto del contrato de bloqueo como de manejar las devoluciones de llamada.

- 2 -Modelo de Amenazas

Antes de discutir los problemas de seguridad relacionados, necesitamos establecer el modelo de amenazas. Principalmente consideramos los siguientes dos casos:

• Modelo de amenaza I: El gancho en sí es benigno pero contiene vulnerabilidades.
• Modelo de amenazas II: El gancho en sí es malicioso.

En las siguientes secciones, discutiremos posibles problemas de seguridad de acuerdo con estos dos modelos de amenazas.

2.1 Problemas de seguridad en el modelo de amenazas I

El Modelo de Amenazas I se enfoca en las vulnerabilidades asociadas con el Propio Hook. Este modelo de amenazas asume que el desarrollador y su Hook no son maliciosos. Sin embargo, las vulnerabilidades conocidas existentes en contratos inteligentes también pueden aparecer en Hooks. Por ejemplo, si un Hook se implementa como un contrato actualizable, puede encontrar problemas relacionados con vulnerabilidades como la de OpenZeppelin UUPSUpgradeable. Dados los factores anteriores, elegimos centrarnos en posibles vulnerabilidades únicas para la versión 4. En Uniswap v4, los Hooks son contratos inteligentes que pueden ejecutar lógica personalizada antes o después de las operaciones principales del pool (incluida la inicialización, la modificación de la posición, el intercambio y la recolección). Aunque se espera que los Hooks implementen una interfaz estándar, también permiten la lógica personalizada. Por lo tanto, nuestra discusión se limitará a la lógica que involucra las interfaces estándar de Hook. Luego intentaremos identificar fuentes potenciales de vulnerabilidades, por ejemplo, cómo los Hooks podrían abusar de estas funciones estándar de Hook.

👇🏻 Específicamente, nos centraremos en los siguientes dos tipos de Ganchos:

• El primer tipo de gancho sostiene los fondos del usuario. En este caso, un atacante podría atacar este gancho para transferir fondos, causando pérdida de activos.
• El segundo tipo de gancho almacena datos críticos del estado en los que confían los usuarios u otros protocolos. En este caso, un atacante podría intentar alterar el estado crítico. Cuando otros usuarios o protocolos utilizan el estado incorrecto, puede haber riesgos potenciales.

Tenga en cuenta que los hooks fuera de estos dos alcances no se discuten aquí. Dado que no hay casos de uso reales de Hook en el momento de escribir esto, tomaremos información del repositorio Impresionante Uniswap v4 Hooks. Después de un estudio exhaustivo del repositorio Impresionante Uniswap v4 Hooks (hash de confirmación 3a0a444922f26605ec27a41929f3ced924af6075), identificamos varias vulnerabilidades graves. Estas vulnerabilidades se derivan principalmente de interacciones arriesgadas entre el hook, PoolManager y terceros externos, y se pueden dividir en dos categorías: problemas de control de acceso y problemas de validación de entrada. Los hallazgos específicos se muestran en la tabla a continuación:

En resumen, identificamos 22 proyectos relevantes (excluyendo aquellos no relacionados con Uniswap v4). Entre estos proyectos, creemos que 8 (36%) tienen vulnerabilidades. De los 8 proyectos vulnerables, 6 tienen problemas de control de acceso y 2 son vulnerables a llamadas externas no confiables.

2.1.1 Problemas de Control de Acceso

En esta parte de la discusión, nos centramos principalmente en los problemas que las funciones de devolución de llamada en v4 pueden causar, incluidas las 8 devoluciones de llamada y la devolución de bloqueo. Por supuesto, hay otros casos que necesitan verificación, pero varían según el diseño y actualmente están fuera del alcance. Estas funciones solo deben poder ser llamadas por el PoolManager, no por otras direcciones (incluidas EOAs y contratos). Por ejemplo, en el caso de que las recompensas se distribuyan desde las claves del pool, las recompensas podrían reclamarse incorrectamente si las funciones correspondientes fueran accesibles por cuentas arbitrarias. Por lo tanto, establecer mecanismos sólidos de control de acceso es crucial para los hooks, ya que pueden ser invocados por partes distintas de los propios pools. Al gobernar estrictamente los permisos de acceso, las piscinas de liquidez pueden reducir significativamente los riesgos asociados con interacciones no autorizadas o maliciosas con hooks.

2.1.2 Problemas de Validación de Entrada

En Uniswap v4, debido al mecanismo de bloqueo, los usuarios deben obtener un bloqueo a través de un contrato antes de ejecutar cualquier operación de grupo. Esto asegura que el contrato con el que se está interactuando actualmente sea el último contrato de bloqueo. Sin embargo, aún existe un escenario potencial de ataque de llamadas externas no confiables debido a una validación de entrada inadecuada en algunas implementaciones de Hook vulnerables:

• Primero, el gancho no verifica la piscina con la que el usuario tiene la intención de interactuar. Esta podría ser una piscina maliciosa con tokens falsos que ejecutan lógica dañina.
• En segundo lugar, algunas funciones clave de gancho permiten llamadas externas arbitrarias.

Las llamadas externas no confiables son extremadamente peligrosas ya que pueden conducir a varios tipos de ataques, incluidos los bien conocidos ataques de reentrada. Para atacar estos ganchos vulnerables, el atacante puede registrar un grupo malicioso con tokens falsos para sí mismos, luego invocar el gancho para ejecutar operaciones en el grupo. Cuando interactúa con el grupo, la lógica del token malicioso secuestra el flujo de control para mala conducta.

2.1.3 Contramedidas para el Modelo de Amenazas I

Para evitar tales problemas de seguridad relacionados con los hooks, es fundamental ejecutar adecuadamente el control de acceso necesario en funciones externas/públicas sensibles y validar las entradas para verificar las interacciones. Además, los guardias de reentrancia pueden ayudar a asegurar que los hooks no se vuelvan a ingresar durante los flujos lógicos estándar. Al implementar salvaguardias de seguridad adecuadas, las pools pueden reducir los riesgos asociados con tales amenazas.

2.2 Problemas de seguridad en Threat Model II

En este modelo de amenazas, asumimos que el desarrollador y su gancho son maliciosos. Dada la amplia cobertura, nos enfocamos únicamente en problemas de seguridad relacionados con la versión 4. La clave radica en si los ganchos proporcionados pueden manejar transferencias de usuarios o autorizaciones de criptomonedas. Dado que el método de acceso a los ganchos determina los permisos que pueden otorgarse a los ganchos, categorizamos los ganchos en dos tipos basados en esto:

• Hooks administrados: El gancho no es un punto de entrada. Los usuarios deben interactuar con el gancho a través de un enrutador (posiblemente proporcionado por Uniswap).
• Ganchos independientes: El gancho es un punto de entrada que permite a los usuarios interactuar con él directamente.

Figura 2: Ejemplo de gancho malicioso

2.2.1 Ganchos Administrados

En este caso, los activos de criptomonedas de los usuarios (incluidos los tokens nativos y otros tokens) se transfieren o se aprueban al enrutador. Dado que el PoolManager realiza controles de saldo, los ganchos maliciosos no pueden robar directamente estos activos con facilidad. Sin embargo, aún existen posibles superficies de ataque. Por ejemplo, el mecanismo de gestión de tarifas en la versión 4 podría ser manipulado por un atacante a través de ganchos.

2.2.2 Ganchos Independientes

Cuando los ganchos se utilizan como puntos de entrada, la situación se vuelve más compleja. Aquí, dado que los usuarios pueden interactuar directamente con el gancho, se le otorga más poder al gancho. En teoría, el gancho puede ejecutar cualquier operación deseada a través de dichas interacciones. En la versión 4, la verificación de la lógica del código es extremadamente crítica. El problema principal es si la lógica del código puede ser manipulada. Si el gancho es actualizable, esto significa que un gancho que parece seguro puede volverse malicioso después de una actualización, lo que representa riesgos significativos. Estos riesgos incluyen:

• Proxies actualizables (que pueden ser atacados directamente)
• La lógica con autodestrucción. Puede ser atacada junto con la llamada selfdestruct y create2.

2.2.3 Contramedidas para el Modelo de Amenazas II

Un punto esencial es evaluar si los ganchos son maliciosos. Específicamente, para los ganchos gestionados, debemos prestar atención al comportamiento de gestión de tarifas; mientras que para los ganchos independientes, el enfoque principal es si son actualizables.

- 3 - Conclusión

En este artículo, primero describimos brevemente los mecanismos centrales relacionados con los problemas de seguridad del gancho Uniswap v4. Luego propusimos dos modelos de amenazas y esbozamos brevemente los riesgos de seguridad asociados. En futuros artículos, realizaremos análisis en profundidad sobre los problemas de seguridad bajo cada modelo de amenaza. ¡Mantente atento!

Referencias

[1] Nuestra Visión para Uniswap V4
https://blog.uniswap.org/uniswap-v4

[2] Borrador del libro blanco de Uniswap v4
https://github.com/Uniswap/v4-core/blob/main/whitepaper-v4-draft.pdf

[3] Gancho TWAMM de Uniswap v4
https://blog.uniswap.org/v4-twamm-hook

[4] Ejemplos de gancho
https://docs.uniswapfoundation.org/hooks/hook-examples

[5] Impresionantes ganchos de Uniswap v4
https://github.com/fewwwww/awesome-uniswap-hooks

[6] UUPSUpgradeable Vulnerability Post-mortem
https://forum.openzeppelin.com/t/uupsupgradeable-vulnerability-post-mortem/15680

Acerca de BlockSec BlockSec es una empresa líder en seguridad blockchain a nivel global fundada en 2021 por expertos de renombre en la industria de la seguridad. La empresa se dedica a mejorar la seguridad y usabilidad para el mundo Web3 para promover la adopción generalizada de Web3. Para lograr esto, BlockSec ofrece servicios de auditoría de seguridad de contratos inteligentes y cadenas EVM, un sistema de desarrollo, pruebas e intercepción de hackers llamado Phalcon para propietarios de proyectos, una plataforma de seguimiento e investigación de fondos llamada MetaSleuth, así como complementos de eficiencia para constructores web3 llamados MetaDock. Actualmente, la empresa ha atendido a más de 300 clientes, incluidos proyectos conocidos como MetaMask, Compound, Uniswap Foundation, Forta, PancakeSwap, y ha recibido dos rondas de financiamiento por un total de decenas de millones de dólares de instituciones de inversión como Oasis Capital, IDG Capital y Distributed Capital. Página principal：www.blocksec.com

Twitter：https://twitter.com/BloquearSecTeam

Phalcon: https://phalcon.xyz/

MetaSleuth: https://metasleuth.io/

MetaDock: https://blocksec.com/metadock

Descargo de responsabilidad:

1. Este artículo es reimpreso de [BloquearSec]. Todos los derechos de autor pertenecen al autor original [BloquearSec]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Aprenderequipo y lo manejarán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.