Artículos Relacionados con Vulnerabilidad

El Centro de Noticias de HTX ofrece los artículos más recientes y un análisis profundo sobre "Vulnerabilidad", cubriendo tendencias del mercado, actualizaciones de proyectos, desarrollos tecnológicos y políticas regulatorias en la industria de cripto.

Análisis del Hook de Uniswap v4: Diseño de Arquitectura, Vulnerabilidades Comunes y Prácticas de Protección

Desde el lanzamiento de Uniswap v4 en la red principal, el mecanismo Hook se ha convertido en una de las innovaciones más destacadas en DeFi. Plataformas como Flaunch en Base utilizan Hooks para precios fijos en preventa y liquidaciones automáticas, mientras que protocolos como Bunni v2 los emplean para liquidez programable y modelos de re-staking. Sin embargo, el auge de estos casos de uso también ha traído un aumento significativo en ataques dirigidos a vulnerabilidades en la implementación de los Hooks. Este artículo analiza la arquitectura de seguridad de los Hooks de Uniswap v4. La principal innovación es un contrato único PoolManager que gestiona todos los pools y utiliza un sistema de "flash accounting" (contabilidad temporal), donde los cambios en los saldos se resuelven al final de cada transacción. Cada pool puede vincular de forma permanente un contrato Hook, que se ejecuta en puntos clave como `beforeSwap` o `afterAddLiquidity`. Un aspecto crítico es que los permisos del Hook (qué funciones ejecuta) están codificados en los últimos bits de su dirección de despliegue, lo que requiere un cálculo cuidadoso usando herramientas como HookMiner. Un error común es que funciones de callback como `beforeSwap` no tienen control de acceso por defecto en plantillas como BaseHook, dejándolas expuestas si el desarrollador no lo implementa explícitamente. El análisis de la pila de llamadas, como en un intercambio (`swap`), revela que los Hooks pueden modificar los montos de la operación devolviendo un `delta`. Un Hook "asíncrono" o de "curva personalizada" puede incluso anular completamente la lógica de intercambio de Uniswap, asumiendo todo el riesgo. Aunque el sistema garantiza que el libro mayor final esté equilibrado (`NonzeroDeltaCount == 0`), esto no previene la manipulación maliciosa de los estados subyacentes. El caso de Cork Protocol subraya estos riesgos, mostrando que auditar un Hook requiere tratarlo como un subprotocolo completo, dada su compleja interacción con el PoolManager y el potencial de confusiones entre tipos de tokens en diferentes mercados. En resumen, la seguridad en v4 se ha fragmentado: ya no depende solo del protocolo principal, sino de la correcta implementación de cada Hook individual en cada pool.

marsbitHace 2 días 08:10

Análisis del Hook de Uniswap v4: Diseño de Arquitectura, Vulnerabilidades Comunes y Prácticas de Protección

marsbitHace 2 días 08:10

El cazador cazado: el bot MEV más rentable fue hackeado

**El cazador cazado: El bot de MEV más rentable es hackeado** El conocido bot de MEV en Ethereum, Jaredfromsubway.eth, sufrió un ataque dirigido el sábado, perdiendo más de 7,5 millones de dólares. Según investigaciones, no fue un phishing tradicional ni una explotación de contrato inteligente, sino un sofisticado "ataque de honeypot contra-MEV" diseñado específicamente para explotar la lógica de comportamiento de estos bots. El atacante desplegó durante semanas 66 contratos de tokens falsos y pools de liquidez, disfrazados como activos principales como WETH, USDC o USDT, para crear rutas de arbitraje falsas. El bot, al detectar la aparente oportunidad, ejecutó una transacción que concedió permisos a un contrato controlado por el atacante. Estos permisos no fueron revocados, permitiendo finalmente que el atacante drenara los fondos del bot en una sola transacción. Jaredfromsubway.eth es uno de los bots de MEV más activos e infames de Ethereum, especializado en ataques de "sándwich" para capturar ganancias de los deslizamientos de precio en las transacciones de usuarios. Se estima que ha acumulado decenas de millones en ganancias y estaba relacionado con alrededor del 70% de estos ataques en un período reciente. Este incidente subraya la creciente sofisticación de las amenazas en cripto, demostrando que incluso los actores más agresivos y automatizados ("depredadores") ahora son vulnerables a ataques multidimensionales que explotan sus propias reglas y automatizaciones. Tras el hackeo, una cuenta no oficial en X se hizo pasar por el bot ofreciendo una recompensa falsa, lo que ha generado advertencias de seguridad adicionales.

marsbit06/21 09:24

El cazador cazado: el bot MEV más rentable fue hackeado

marsbit06/21 09:24

Año Uno de las Aplicaciones de IA: ¿Solo sabe decir "sí", ignorando los riesgos? El cuaderno de bitácora del desarrollo de software se abre por completo

El año de la IA aplicada: ¿Solo "sí" y sin considerar riesgos? El diario de navegación del desarrollo de software se abre por completo. El rápido aumento del uso de IA para generar código, con menos supervisión, introduce riesgos ocultos en código aparentemente correcto, lo que puede provocar pérdidas de datos o activos. El proyecto de código abierto **Narwhal AI Code Risks**, de Narwhal-Lab (Universidad de Pekín), recopila casos reales, señales tempranas y rutas de riesgo típicas para ayudar a los desarrolladores a identificar peligros. Un ejemplo claro es el incidente de configuración del oráculo cbETH de Moonwell, donde un error semántico en un precio (1.12 USD en lugar de ~2200 USD) pasó todas las revisiones y causó una pérdida de ~1.78 millones de dólares. El riesgo no siempre se muestra con errores; a menudo, el código funciona pero su semántica es errónea. La IA ya no solo completa código, sino que modifica configuraciones, gestiona dependencias y actúa mediante agentes, creando cadenas de acciones más largas y difíciles de rastrear. Los riesgos se clasifican en 7 categorías: cadena de suministro, vulnerabilidades a nivel de código, configuración de nube/infraestructura, riesgos de agentes, riesgos en dominios verticales, propiedad intelectual/cumplimiento y factores humanos. El proyecto organiza la información en tres niveles: `cases/` (eventos reales verificados), `inferred/` (señales tempranas por confirmar) y `scenarios/` (patrones de riesgo claros). Su objetivo es convertir casos de riesgo en conocimiento reutilizable para que desarrolladores, investigadores y fabricantes de herramientas puedan detectar y prevenir problemas similares, creando un registro de navegación abierto para la era del desarrollo con IA.

marsbit06/16 04:55

Año Uno de las Aplicaciones de IA: ¿Solo sabe decir "sí", ignorando los riesgos? El cuaderno de bitácora del desarrollo de software se abre por completo

marsbit06/16 04:55

Cuatro preguntas sobre la vulnerabilidad de Zcash Orchard: ¿Fue explotada? ¿Se pueden recuperar los fondos? ¿Es verificable la oferta? ¿Hay otras?

El reciente fallo en el protocolo Orchard de Zcash ha planteado cuatro cuestiones clave sobre la seguridad y la integridad de la red. En primer lugar, aunque no se puede descartar por completo, se considera improbable que la vulnerabilidad haya sido explotada debido a su detección proactiva por investigadores especializados y la rápida respuesta de los desarrolladores. En segundo lugar, se cree que los fondos legítimos en Orchard son recuperables, aunque los usuarios más cautelosos pueden optar por trasladarlos, asumiendo riesgos adicionales como la pérdida de privacidad o dependencia de configuraciones de confianza. Actualmente, los usuarios no pueden verificar de forma independiente si el suministro total de ZEC ha sido manipulado. Sin embargo, la próxima actualización de red, Ironwood, solucionará este problema al sellar el grupo Orchard, impidiendo nuevas entradas y permitiendo solo salidas controladas. Esto restaurará la capacidad de cualquier nodo para verificar que se cumple el límite de suministro del protocolo. Por último, revisiones exhaustivas continuas por múltiples equipos, asistidas por herramientas de IA avanzadas, no han detectado otras vulnerabilidades de falsificación similares, lo que aumenta la confianza en la solidez del sistema. En conclusión, aunque se evalúa que los fondos y el suministro actuales son seguros, la actualización Ironwood es crucial para devolver a los usuarios la capacidad de verificación autónoma, fundamento de la credibilidad a largo plazo de Zcash.

marsbit06/15 07:53

Cuatro preguntas sobre la vulnerabilidad de Zcash Orchard: ¿Fue explotada? ¿Se pueden recuperar los fondos? ¿Es verificable la oferta? ¿Hay otras?

marsbit06/15 07:53

Respuesta del cofundador de ZEC a la vulnerabilidad de Orchard: sin rastros de robo por ahora, se cerrará el pool de Orchard

El cofundador de ZEC responde a la vulnerabilidad de Orchard: Sin rastros de robo por ahora, se cerrará el pool de Orchard Recientemente se descubrió una vulnerabilidad de seguridad en el módulo Orchard de Zcash. El equipo evaluó cuatro preguntas clave: 1. **¿Se ha explotado la vulnerabilidad?** Es poco probable. Fue descubierta proactivamente por un investigador especializado, no por una explotación. El equipo actuó rápidamente para contenerla. No hay evidencia de movimientos sospechosos típicos de un ataque. 2. **¿Se pueden recuperar los fondos legítimos en Orchard?** Sí, si la vulnerabilidad no fue explotada. En el improbable caso de que se crearan fichas falsas, el mecanismo de salida limitaría el total retirable al monto depositado originalmente. Los usuarios pueden optar por trasladar sus fondos, pero deben sopesar las implicaciones de privacidad y riesgos operativos. 3. **¿Pueden los usuarios verificar la oferta total de ZEC?** Actualmente no, debido a esta vulnerabilidad. Sin embargo, la próxima actualización de red **Ironwood** resolverá esto. Cerrará permanentemente el pool de Orchard, permitiendo solo la salida de fondos por los canales existentes, cuyo límite total es igual a los depósitos legítimos originales. Después, cualquiera podrá verificar de forma independiente que no hay inflación de la oferta. 4. **¿Hay otras vulnerabilidades de falsificación?** Tras una exhaustiva auditoría por múltiples equipos, incluyendo el uso de herramientas de IA avanzadas, no se han encontrado otras vulnerabilidades similares. Esto aumenta la confianza en que no existen fallas de este tipo sin descubrir. **Conclusión:** El riesgo de explotación es bajo, los fondos de los usuarios están seguros y no se han encontrado otras vulnerabilidades similares. La actualización Ironwood restablecerá la capacidad de los usuarios para verificar de forma independiente la oferta total de monedas, un pilar fundamental para la credibilidad a largo plazo de Zcash.

Foresight News06/15 03:51

Respuesta del cofundador de ZEC a la vulnerabilidad de Orchard: sin rastros de robo por ahora, se cerrará el pool de Orchard

Foresight News06/15 03:51

En solo 5 segundos y con una conversación: ¿El 'mecanismo de seguridad más fuerte' de Claude Fable 5 ha sido vulnerado por un equipo de investigadores chinos?

En 5 segundos y con una sola conversación, un equipo internacional liderado por investigadores chinos ha vulnerado los mecanismos de seguridad del modelo Fable 5 de Anthropic. Este modelo, de alto nivel ("Mythos"), incorpora un nuevo clasificador de seguridad para bloquear solicitudes de riesgo en áreas como ciberseguridad o biología. Ataques tradicionales como inyección de prompts o role-play habían fracasado. El equipo, dirigido por Yutao Wu de la Universidad Deakin, explotó un fenómeno denominado "Colapso Interno de Seguridad" (ISC), descrito en su investigación de marzo. El ataque no utiliza prompts maliciosos externos, sino que aprovecha un fallo estructural en la arquitectura común de "clasificador + modelo". Cuando un agente de IA ejecuta tareas complejas y de múltiples pasos (como completar datos faltantes para que un script funcione), puede internalizar un contexto donde genera contenido riesgoso para cumplir con el objetivo, sin que el clasificador inicial lo detecte. El método TVD (Tarea, Validador, Datos) demuestra este riesgo: con una tarea profesional legítima, datos incompletos y un validador que solo verifica formato/completitud, el agente puede autocompletar información peligrosa (ej., en bioquímica o seguridad) para que la tarea "pase la validación". El flujo de tráfico confirmó que la salida dañina provenía directamente de Fable 5, no del modelo de respaldo Opus 4.8. La vulnerabilidad no es específica de Fable 5. El benchmark ISC-Bench, con 84 plantillas en 9 áreas, ha probado más de 60 modelos líderes (incluidos modelos de Apple para móviles), mostrando tasas de éxito significativas. El trabajo subraya que los clasificadores de seguridad estáticos en la frontera del sistema son insuficientes para riesgos que emergen internamente durante la ejecución autónoma de agentes en flujos de trabajo largos. El equipo avanza en la construcción de infraestructuras de seguridad más robustas para la próxima generación de sistemas de IA.

marsbit06/15 03:21

En solo 5 segundos y con una conversación: ¿El 'mecanismo de seguridad más fuerte' de Claude Fable 5 ha sido vulnerado por un equipo de investigadores chinos?

marsbit06/15 03:21

La Revelación del Robo en Raydium: Un Nuevo Riesgo en DeFi, Oculto en Contratos Antiguos y Olvidados

El incidente de Raydium, donde se perdieron aproximadamente 1,34 millones de dólares debido a la explotación de antiguos pools de liquidez del market maker automatizado V3, ha revelado una vulnerabilidad crítica en DeFi: los contratos inteligentes obsoletos y olvidados, que permanecen activos en la cadena de bloques, se están convirtiendo en objetivos de ataque. Este caso no es aislado. Desde marzo de 2025, se han registrado al menos 8 incidentes similares, con pérdidas totales de unos 22,5 millones de dólares, vinculados a contratos antiguos o infraestructura descuidada. El problema fundamental no es un error de código, sino un fallo en la gestión del ciclo de vida de los contratos: los proyectos no los desactivan completamente tras su retirada. Estos "contratos zombis", aunque no son utilizados por los usuarios principales, conservan activos y permisos de llamada. Al estar fuera del foco de mantenimiento, son objetivos fáciles. El ataque a Raydium explotó precisamente la falta de mecanismos de verificación en su viejo contrato V3. La solución requiere reconocer este riesgo como una categoría independiente y establecer un proceso estandarizado de desactivación segura. Esto debe incluir: eliminar permisos de administrador, retirar todos los activos, deshabilitar funciones clave, actualizar la documentación, realizar auditorías post-cierre, monitorear continuamente y notificar claramente a la comunidad. La seguridad de DeFi depende tanto de gestionar el presente como de cerrar adecuadamente su pasado.

Foresight News06/13 06:20

La Revelación del Robo en Raydium: Un Nuevo Riesgo en DeFi, Oculto en Contratos Antiguos y Olvidados

Foresight News06/13 06:20

活动图片