Por Canuto  

Una prueba de penetración identificó una falla crítica en una aplicación financiera construida sustancialmente con Claude: un GUID podía bastar para restaurar el acceso de otro solicitante. El caso muestra por qué un código funcional y rodeado de controles no necesariamente entiende los límites de confianza.
***

  • La aplicación manejaba identificaciones oficiales, datos de verificación, pagos, números de seguro social y registros de co-solicitantes.
  • El sistema trataba el GUID de un solicitante como prueba suficiente para emitir o restaurar un token temporal.
  • Sygnia recomienda supervisar el código generado por IA y exigir pruebas explícitas de autorización en los prompts y las revisiones.

 

Una prueba de penetración encontró una vulnerabilidad crítica en una aplicación de incorporación de clientes construida sustancialmente con Claude. La plataforma pertenecía a una firma de servicios financieros que administra miles de millones de dólares en activos de clientes.

La aplicación gestionaba información especialmente sensible durante el proceso de registro. Entre los datos figuraban identificaciones emitidas por gobiernos, información de verificación de identidad, detalles de pago, números de seguro social y registros de co-solicitantes.

Según un reporte de The Next Web, el fallo permitía que un solicitante accediera al registro de otro solicitante. El problema no surgió porque la aplicación careciera de funciones de seguridad, sino por una decisión equivocada sobre la identidad de quien solicitaba acceso.

El sistema intentaba resolver una necesidad común en los procesos digitales de incorporación. Una persona puede comenzar una solicitud, abandonar el trámite y regresar más tarde, incluso antes de tener una cuenta formal.

Para recuperar el avance sin exigir una contraseña, Claude produjo un modelo de acceso temporal. La debilidad apareció en el punto previo, cuando el sistema determinaba si debía emitir o restaurar un token para el solicitante.

El GUID se convirtió en un secreto portador

La aplicación consideraba suficiente la posesión del identificador único global de un solicitante, conocido como GUID. Con ese dato, el backend podía emitir o restaurar un token temporal vinculado al registro correspondiente.

Sygnia describió el GUID como un “secreto portador” dentro de la implementación. La expresión alude a una credencial que concede acceso a quien la posee, aunque el identificador solo debería servir para ubicar un registro.

Un GUID identifica una solicitud, pero no demuestra que la persona que lo conoce controle la sesión, el dispositivo o la identidad asociada. Tampoco prueba que el solicitante tenga acceso al canal de contacto verificado utilizado durante el proceso.

En consecuencia, cualquiera que obtuviera el GUID de otra persona podía intentar acceder a su información. El alcance incluía nombres, datos de contacto, estado de la solicitud, detalles financieros, información de identidad, datos de pago y números de seguro social.

El riesgo también alcanzaba a los co-solicitantes. Estas personas podían aparecer en el sistema porque otro solicitante las había mencionado, aunque quizá nunca hubieran iniciado una sesión ni entregado directamente sus propios datos.

Los controles existían, pero protegían la decisión equivocada

La implementación incluía varias medidas que normalmente forman parte de una arquitectura defensiva. Sygnia identificó tokens temporales, expiración, limitación de tasas, registros de auditoría, restauración de sesiones y mecanismos para detectar actividad sospechosa.

Cada control tenía una función real, pero ninguno respondía la pregunta central de autorización. El sistema debía establecer qué evidencia debía presentar una persona antes de recibir un token de acceso para una solicitud concreta.

Un token con una duración breve todavía puede causar daños si llega al usuario equivocado. Del mismo modo, un registro de auditoría puede ayudar a investigar un incidente después de que ocurra, pero no evita por sí mismo la entrega indebida de información.

La vulnerabilidad existía antes de la emisión del token. En ese instante, la aplicación ya había aceptado una premisa incorrecta: que conocer un identificador equivalía a demostrar control sobre la solicitud.

El caso ilustra una diferencia importante entre seguridad operativa y autorización. Una plataforma puede limitar intentos, cerrar sesiones y registrar eventos, pero seguir concediendo acceso a una persona que nunca demostró ser la titular legítima.

Por qué las herramientas automáticas pueden pasar por alto el problema

Los escáneres estáticos suelen buscar patrones de programación inseguros y flujos de datos peligrosos. En este caso, el código seguía convenciones conocidas de los frameworks y podía superar revisiones básicas de compilación y funcionamiento.

La falla se encontraba en la arquitectura y en la lógica empresarial. No dependía necesariamente de una función claramente peligrosa, una inyección evidente o un flujo de datos que las herramientas tradicionales pudieran marcar automáticamente.

“Un código funcional no es lo mismo que un código seguro”, afirmó Zach Mead, tester de penetración de Sygnia. Según su explicación, el código generado por IA puede compilar y respetar patrones familiares mientras mantiene supuestos defectuosos sobre confianza, autorización, estado, propiedad o integraciones externas.

La advertencia resulta especialmente relevante para equipos que incorporan asistentes de programación en productos regulados. La velocidad de desarrollo puede ocultar decisiones pequeñas que, combinadas, alteran el modelo de seguridad de toda una aplicación.

La recomendación de Sygnia consiste en tratar la salida generada por IA como no confiable hasta completar una validación independiente. Esa validación debe revisar tanto el código como las suposiciones que definen quién puede acceder a cada recurso.

La IA también puede encontrar los errores que ayuda a crear

Sygnia no descubrió el problema únicamente mediante una revisión manual. La firma ejecutó un modelo de lenguaje sobre partes de la base de código del cliente para buscar límites de confianza débiles y fallas de lógica empresarial.

El modelo identificó directamente el problema relacionado con el token del solicitante. El resultado expone una dualidad: una herramienta de IA puede ayudar a construir una vulnerabilidad y también contribuir a detectarla durante una evaluación.

La misma capacidad plantea riesgos para los defensores y los atacantes. Si un modelo puede señalar límites de confianza ausentes, una persona que obtenga código fuente filtrado o notas de implementación robadas también podría acelerar el análisis.

La firma mencionó que Cisco ha dirigido modelos de pesos abiertos hacia la búsqueda de errores por una razón similar. El uso defensivo y el ofensivo pueden apoyarse en capacidades prácticamente idénticas.

El caso del código vulnerable forma parte de un panorama más amplio descrito por Sygnia. En otra intrusión en la nube investigada por la firma, varias actividades ocurrieron simultáneamente, desde el descubrimiento de credenciales hasta la interrupción operativa.

El ritmo de los agentes cambia la respuesta de seguridad

Durante esa intrusión, los investigadores observaron enumeración de recursos en la nube, revisión de código fuente, exploración de sistemas CI/CD y acceso a bases de datos. Las acciones se ejecutaron con una velocidad que parecía corresponder a varios operadores.

La investigación concluyó que había una sola persona trabajando con agentes. La observación sugiere que la IA no solo modifica cómo se escribe el software, sino también la rapidez con la que un atacante puede convertir una debilidad en una ruta de intrusión.

Ambos casos muestran una aceleración en diferentes etapas del ciclo de seguridad. La IA puede producir código, revisar implementaciones, buscar fallas y coordinar tareas técnicas con una velocidad difícil de igualar mediante procesos completamente manuales.

Ese ritmo aumenta la presión sobre las organizaciones que manejan información financiera o regulada. Una vulnerabilidad que permanece oculta durante el desarrollo puede encontrar una explotación más rápida cuando los atacantes automatizan el reconocimiento y la búsqueda de caminos de acceso.

Sygnia también ha señalado cuatro ataques separados que compartían un único fallo subyacente. La idea central es que una debilidad aparentemente limitada puede repetirse en diferentes entornos cuando las mismas prácticas de desarrollo y autorización se extienden entre aplicaciones.

Qué medidas recomienda Sygnia a los equipos

Sygnia no recomienda prohibir las herramientas de inteligencia artificial. La firma advierte que una prohibición puede trasladar el uso a cuentas personales, donde las organizaciones pierden visibilidad sobre las herramientas, los prompts y los cambios realizados.

Una medida sugerida consiste en marcar las solicitudes de extracción generadas o modificadas sustancialmente por IA. Los equipos también deberían registrar qué herramienta participó y señalar los cambios relacionados con autenticación, pagos, exportaciones de datos o información regulada de clientes.

La firma pone especial énfasis en la forma de redactar los prompts. Pedir “tokens de acceso temporales para solicitantes” no define por sí solo qué evidencia debe exigirse antes de conceder acceso.

Un prompt más seguro debe aclarar que los identificadores de solicitantes no son secretos. También debe exigir una prueba independiente de control sobre la solicitud y pruebas negativas que demuestren que un solicitante no puede obtener el acceso correspondiente a otra persona.

El modelo no inferirá por sí mismo el esquema de riesgo de una institución. Por eso, los requisitos de seguridad deben aparecer explícitamente en las instrucciones, en las especificaciones técnicas y en las pruebas que acompañan al código generado.

Una advertencia sobre el informe y sus implicaciones

El caso requiere una lectura cuidadosa porque corresponde a un informe comercial de un proveedor sobre un cliente no identificado. Sygnia publicó los hallazgos junto con el lanzamiento de nuevos servicios de ciberseguridad basados en IA.

La oferta incluye evaluación de postura de seguridad, gobernanza y pruebas de penetración para aplicaciones de inteligencia artificial. Nadie ha verificado de manera independiente los hallazgos descritos, y ninguna otra firma ha informado sobre este caso específico.

Sin embargo, el mecanismo técnico resulta comprensible y comprobable en términos generales. Un identificador que concede acceso sin demostrar control sobre la identidad representa una debilidad de autorización, sin importar si el código lo escribió una persona o un modelo.

El episodio también se diferencia de otros problemas asociados con asistentes de programación. En algunos casos, la vulnerabilidad reside en la propia herramienta, como un escape de sandbox o una inyección de prompts.

Aquí, el problema llegó a producción dentro de una aplicación creada con ayuda de IA. La falla apareció en un negocio regulado y alrededor de datos que los clientes deben entregar para completar su incorporación.

La lección para las instituciones financieras y tecnológicas no consiste en confiar ciegamente en la automatización ni en rechazarla por completo. Consiste en exigir que cada decisión de acceso tenga una justificación verificable, una prueba negativa y una revisión que examine el modelo de confianza completo.

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