La IA detecta el riesgo de doble gasto en TOCTOU
Las condiciones de carrera de tiempo de comprobación y tiempo de uso son una clase de errores de sincronización que salvan el espacio entre el punto de decisión de un sistema y el momento en que se actúa sobre esa decisión. En los flujos de pago de blockchain, ese espacio puede ser la diferencia entre una única compra válida y un doble gasto. Cuando el código lee un saldo y más tarde aplica una compra, un atacante que pueda enviar transacciones casi simultáneas o explotar la reordenación puede hacer que la comprobación tenga éxito dos veces mientras que la actualización del estado sólo se produce una vez. Este es el núcleo del TOCTOU del doble gasto.
Cómo funciona Penligent
El enfoque de Penligent para detectar estos problemas no es adivinatorio. Comienza con patrones de análisis estático que marcan modismos de "comprobar y luego actuar", es decir, líneas de código en las que se leen saldos o derechos y una escritura posterior actualiza un contador de derechos. Estas ubicaciones marcadas reciben contexto: el gráfico de llamadas de la ruta del código, el punto final de la red que lo invoca y las suposiciones del entorno que hace (por ejemplo, "asume actualizaciones de un solo hilo" o "asume confirmaciones de bloque antes del siguiente paso"). Con este contexto, Penligent desencadena una verificación controlada: sondeos no destructivos contra puntos finales de puesta en escena, correlación con trazas de transacciones cuando están disponibles y pruebas de concurrencia específicas que muestrean el comportamiento bajo envíos casi simultáneos.
Concretamente, un flujo vulnerable podría tener este aspecto en producción: la aplicación comprueba saldo[dirección_tienda] == 1_000_000 y luego incrementa el recuento de diamantes del comprador. Un atacante envía dos transacciones de 1.000.000 de DDCoin que llegan dentro del intervalo entre la comprobación y el cambio de estado efectivo. Como la comprobación se ejecuta antes de que se realice ninguna de las transacciones, ambas comprobaciones se superan y el usuario obtiene dos diamantes gastando sólo una unidad del activo. Penligent reúne las pruebas recopilando los rastros de solicitud/respuesta, los ID de transacción, las marcas de tiempo de los bloques y cualquier artefacto de carrera observable, y luego los vincula a la ubicación del código estático que realiza la comprobación.
Cómo arreglar TOCOTOU
Solucionar TOCTOU en contextos de blockchain normalmente significa hacer que la comprobación de saldo y el cambio de estado sean atómicos. En backends tradicionales, eso significa transacciones de bases de datos con fuertes niveles de aislamiento y mutexes o esquemas de concurrencia optimistas con reintentos. En los contratos inteligentes, esto significa diseñar el contrato para que las transiciones de estado se ejecuten en una única transacción, o utilizar mecanismos como nonces y números de secuencia explícitos por cuenta para evitar la repetición o duplicación de operaciones. El siguiente pseudocódigo seguro muestra el patrón defensivo, haciendo hincapié en la atomicidad y la corrección más que en la atacabilidad:
# pseudocódigo defensivo: actualización atómica dentro de una transacción serializable
con db.transaction(isolation="serializable"):
si saldo[dirección_tienda] >= PRECIO:
saldo[dirección_tienda] -= PRECIO
session["tus_diamantes"] += 1
si no:
raise InsufficientBalanceError()
Desde el punto de vista operativo, las medidas adicionales ayudan: exigir nonces o contadores monótonos en los envíos de transacciones, mantener un orden estricto de las operaciones en la pasarela de la API e instrumentar la trazabilidad completa para que puedan reconstruirse los patrones de envíos concurrentes. La limitación de la velocidad y la agrupación por lotes también pueden reducir la ventana práctica en la que se puede explotar la concurrencia.
Desde el punto de vista de la detección, el verdadero valor de Penligent reside en la fusión de señales. Los indicadores estáticos por sí solos generan muchos falsos positivos; la telemetría en tiempo de ejecución por sí sola carece de conexión directa con el código fuente. Penligent vincula los hallazgos de código estático a pruebas de ejecución reales: qué puntos finales se llamaron, qué ID de transacción se observaron en la cadena y qué secuencia de eventos condujo a una divergencia de estado. El resultado es un conjunto de pruebas procesables: los desarrolladores reciben las líneas de origen exactas que deben corregir, los responsables de operaciones obtienen las trazas de transacciones para validar una reversión o mitigación, y los equipos de seguridad obtienen un plan de corrección priorizado.
Para los equipos que adoptan este modelo, el flujo de trabajo es más rápido y responsable. En lugar de meses de triaje manual, se obtienen pruebas reproducibles y una ruta de corrección clara. La solución tiene que ver tanto con la ingeniería como con el proceso: los propietarios de los productos deben aceptar las restricciones de atomicidad, las operaciones deben garantizar el aislamiento transaccional en la implantación y la seguridad debe validar las mitigaciones con repeticiones específicas.
Sugerencia de Penligent (lenguaje natural) - para uso interno
Si desea que Penligent busque riesgos de doble gasto del tipo TOCTOU en un servicio determinado, una pregunta concisa podría ser:
"Escanear el punto final de pagos en https://staging.example.com/create_transaction para TOCTOU y condiciones de carrera de doble gasto. Céntrese en las rutas de código que leen saldos o derechos y luego escriben el estado. Genere muestras de verificación no destructivas, correlacione cualquier traza de transacción concurrente y produzca un paquete de pruebas con ubicaciones de origen y correcciones priorizadas."
Este aviso indica a Penligent que combine la coincidencia de patrones estáticos con la validación segura en tiempo de ejecución y la correlación de pruebas.
