Por Canuto  

Una nueva investigación académica propone SseRex, el primer sistema de ejecución simbólica diseñado para detectar vulnerabilidades específicas de Solana a nivel de bytecode. En pruebas sobre 8.714 contratos desplegados, la herramienta identificó 467 contratos potencialmente vulnerables y mostró mejores resultados que métodos previos, en un momento en que la seguridad de los programas en Solana sigue bajo fuerte escrutinio.
***

  • SseRex fue evaluado sobre 8.714 contratos de Solana y detectó posibles fallas en 467 de ellos.
  • La herramienta apunta a errores típicos de Solana, como ausencia de verificación de firma, de propietario y llamadas CPI arbitrarias.
  • Según los autores, el enfoque reduce falsos positivos y también puede analizar contratos creados con Anchor.

 

La seguridad de los contratos inteligentes en Solana vuelve a quedar en el centro del debate técnico tras la publicación de SseRex: Practical Symbolic Execution of Solana Smart Contracts, un trabajo firmado por Tobias Cloosters, Pascal Winkler, Jens-Rene Giesen, Ghassan Karame y Lucas Davi. El estudio presenta SseRex, descrito por sus autores como el primer enfoque de ejecución simbólica orientado a detectar vulnerabilidades específicas de Solana directamente sobre bytecode.

El punto de partida no es menor. Según el documento, la expansión de Solana como plataforma para contratos inteligentes ha venido acompañada por incidentes de seguridad relevantes, con pérdidas superiores a USD $523.000.000. Esa combinación de adopción, velocidad y complejidad técnica ha convertido a la red en un blanco atractivo, pero también en un entorno difícil de analizar con las herramientas tradicionales.

Los autores sostienen que buena parte del problema reside en el modelo de cuentas de Solana, distinto al de Ethereum. En esta red, el creador de una transacción puede elegir libremente gran parte del contexto de entrada, por lo que los programas deben validar cuidadosamente firmas, propietarios de cuentas, claves públicas y cuentas derivadas. Cuando esos controles faltan o se implementan mal, aparecen fallas críticas.

En ese marco, SseRex busca detectar cuatro clases de problemas muy asociadas a Solana: ausencia de verificación de propietario, ausencia de verificación de firma, ausencia de verificación de clave y llamadas arbitrarias entre programas, conocidas como cross-program invocations o CPI. La investigación afirma que las herramientas anteriores no cubrían adecuadamente ese espacio, en especial cuando el código fuente no está disponible o cuando los contratos fueron creados con Anchor.

Por qué Solana exige controles distintos

Para lectores menos familiarizados con la arquitectura de Solana, conviene recordar que sus programas no acceden libremente al estado global como ocurre en otras redes. En cambio, reciben todas las cuentas y datos necesarios dentro de cada instrucción. Esa decisión favorece la ejecución concurrente y el alto rendimiento, pero también abre un frente de riesgo: un atacante puede intentar construir un contexto de ejecución malicioso.

El estudio explica tres vectores clásicos. El primero es la ausencia de verificación de firma, que permite a un atacante hacerse pasar por otro usuario si el programa valida una clave pública, pero no confirma que esa cuenta realmente firmó la transacción. El segundo es la ausencia de verificación de propietario, donde el contrato confía en datos de una cuenta sin asegurarse de que esa cuenta pertenezca al programa correcto.

El tercer vector es la CPI arbitraria. En Solana, un programa puede invocar a otro y delegar privilegios durante esa ejecución. Si el contrato acepta un destino CPI controlado por el atacante y no valida adecuadamente la cuenta objetivo, ese atacante puede redirigir la llamada hacia un programa malicioso y actuar con privilegios ajenos. La investigación remarca que fallas sutiles y fáciles de pasar por alto suelen convertirse en la raíz de exploits severos.

El documento también subraya que, aunque Anchor automatiza parte de las verificaciones mediante tipos y macros de Rust, no elimina todos los riesgos. Todavía pueden quedar controles manuales por implementar, como verificar firmantes o dependencias entre autoridades y billeteras. Esa observación es importante porque Anchor ya representa una porción relevante de los contratos desplegados en Solana.

Qué hace SseRex y en qué se diferencia

La ejecución simbólica es una técnica de análisis que explora rutas posibles de ejecución usando variables simbólicas en lugar de valores concretos. En teoría, eso permite rastrear mejor flujos de datos, condiciones y relaciones internas del programa. En la práctica, su uso suele enfrentarse a un problema de explosión de rutas, donde la cantidad de escenarios posibles crece rápidamente hasta volver inviable el análisis.

El aporte de SseRex, según el estudio, consiste en adaptar esa técnica a las particularidades de Solana. Para hacerlo, los investigadores dividieron la herramienta en cuatro fases: levantamiento del bytecode sBPF, preparación simbólica optimizada para programas de Solana, exploración simbólica guiada hacia acciones críticas y análisis de vulnerabilidades mediante oráculos específicos.

Entre las optimizaciones clave aparece la fusión de estados tras la deserialización de cuentas. Ese paso intenta evitar que pequeñas variaciones booleanas, como si una cuenta es firmante o escribible, multipliquen de forma inmanejable la cantidad de estados. Los autores afirman que esa estrategia reduce redundancias enormes durante el análisis inicial.

Otra mejora es el manejo híbrido de longitudes simbólicas para los datos de cuentas. En vez de usar punteros totalmente simbólicos, que complican mucho al solucionador de restricciones, la herramienta fija tamaños máximos durante la deserialización y luego libera esas restricciones. También salta rutinas de formateo de cadenas cuando solo se usan para logging, porque ese tipo de operaciones tiende a atascar la ejecución simbólica sin aportar valor de seguridad.

La herramienta incorpora además tres estrategias de exploración. Una se enfoca en rutas que alcanzan llamadas CPI, otra intenta seguir el árbol principal de instrucciones del contrato y la tercera explora trayectorias aleatorias para ampliar cobertura. Según el trabajo, las tres se ejecutan de manera rotativa hasta hallar una acción crítica o agotar un límite temporal de 10 minutos por estrategia.

Resultados en miles de contratos y comparación con otras herramientas

La evaluación más amplia de SseRex abarcó 8.714 contratos desplegados en Solana, de los cuales 3.763, equivalentes a 43,2 %, estaban basados en Anchor. Los investigadores afirman que se trata del mayor estudio de vulnerabilidades en Solana hasta la fecha. El análisis se ejecutó en dos máquinas con 240 GB de RAM cada una, procesando contratos en grupos de ocho trabajos paralelos y con un límite de 2 horas por tarea.

Los resultados arrojan 467 contratos reportados con al menos una vulnerabilidad potencial, lo que equivale a cerca de 5,4 % del total analizado. Dentro de ese conjunto, SseRex detectó 374 casos de escritura de cuenta sin validaciones suficientes y 100 casos de CPI arbitraria. Como las categorías pueden superponerse, el total no debe leerse como una suma simple de fallas independientes.

En el detalle, el estudio reporta 117 contratos con ausencia de verificación de propietario, 241 con ausencia de verificación de firma y 33 con ambos problemas combinados. Los autores también realizaron una revisión manual intensiva de una muestra de 30 bugs reportados y concluyeron que 26 eran fallas reales, lo que arroja una tasa de verdaderos positivos de 87 %.

La comparación con herramientas previas es uno de los puntos más fuertes del trabajo. Frente a VRust, un sistema de análisis estático que requiere código fuente, y FuzzDelSol, una herramienta basada en fuzzing, SseRex habría mostrado menos falsos positivos y una cobertura más amplia. El documento destaca que VRust no puede analizar la mayoría de los contratos desplegados porque 98 % no tiene código fuente disponible, mientras que FuzzDelSol tiene problemas con contratos complejos basados en Anchor.

Los autores también usaron como referencia el registro de contratos verificados de Anchor entre abril y noviembre de 2022, con 666 builds de cerca de 120 proyectos. Allí SseRex solo reportó cuatro vulnerabilidades en 120 proyectos. Uno de los casos más relevantes fue sol-did, donde el análisis manual confirmó que una cuenta redimensionada no estaba correctamente verificada, permitiendo cambios arbitrarios en ciertas condiciones.

Casos reales y límites del análisis automatizado

La investigación dedica una sección a estudios de caso que ayudan a entender tanto el valor como las limitaciones de este tipo de herramientas. Uno de ellos es Censo Solana Wallet, antes conocido como Strike Wallet. Allí, SseRex detectó una ausencia de verificación de firma en un programa de billetera multifirma, lo que permitía terminaciones de billeteras sin autorización y también migraciones no autorizadas que podían alterar la cuenta que recibía los reembolsos de renta.

Otro caso fue Elusiv, un protocolo de privacidad en Solana apoyado en pruebas de conocimiento cero y cómputo multipartito. SseRex marcó una ausencia de verificación de firma en una función que inicializa el hashing para una cuenta de compromiso. Sin embargo, el análisis manual concluyó que el impacto práctico era bajo, porque la lógica del contrato hacía poco probable un daño real para usuarios o fondos.

Ese contraste sirve para una lección importante. Una herramienta automática puede identificar conductas técnicamente vulnerables a nivel de bytecode, pero no siempre puede medir con precisión el daño económico o funcional sin entender la lógica de negocio del protocolo. Los propios autores reconocen que algunos reportes son correctos en términos técnicos, aunque su impacto dependa del contexto de despliegue, de si existen activos objetivos o de cómo interactúan otros contratos alrededor.

El paper también recuerda el exploit de Wormhole de 2022 para mostrar los límites de los oráculos genéricos. Allí el problema fue una verificación de clave ausente sobre una cuenta especial del sistema usada para leer instrucciones previas. Según los investigadores, ese tipo de vulnerabilidad no puede detectarse fácilmente con reglas genéricas, porque a nivel de bytecode no hay señales suficientes para saber que el programa esperaba una cuenta del sistema concreta y no otra cualquiera.

En otras palabras, SseRex no resuelve todo el problema de seguridad en Solana, pero sí cubre un vacío relevante. Su principal promesa es operar directamente sobre bytecode, incluir contratos con Anchor y ofrecer hallazgos más precisos en una red donde los errores de validación siguen apareciendo. Los autores aseguran además que liberarán públicamente los componentes de la herramienta en GitHub para fomentar más investigación sobre la seguridad de programas en Solana.

La conclusión del estudio es directa: SseRex representa el primer marco práctico y eficiente de ejecución simbólica para programas de Solana, y sus resultados sugieren que cientos de contratos todavía exponen patrones peligrosos. Para una blockchain que compite por adopción masiva y aplicaciones financieras de alto valor, ese dato no es un detalle técnico menor, sino una advertencia sobre la distancia que aún existe entre escalabilidad y seguridad robusta.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados