Loading
_ DESCIFRANDO CONEXIÓN SEGURA...

El encargo de ataque a una app con IA: evidencia e informe

4 tareas · 25 min · Principiante

El módulo 6 ya fijó la regla dura: sin reproducción no hay hallazgo, y fabricar evidencia es fraude. El módulo 7 ya fijó que los datos del cliente no salen a un tercero y que el prompt también es un canal de fuga. Esta sala no repite eso: cierra tres huecos que quedan cuando el encargo es, específicamente, auditar una app con un componente de IA y escribir el informe con un modelo al lado. Qué pasa cuando el modelo le pone a un fallo de diseño propio el nombre de una vulnerabilidad de producto que no existe, qué pasa cuando la misma sesión de un modelo se usa para dos clientes distintos, y quién decide la severidad de un hallazgo cuando el modelo ofrece una etiqueta sin más respaldo que el patrón del título. Se razona sobre el borrador; nada se envía ni se publica.

0 de 4 · 0%

Objetivo de la sala

El módulo 6 ya fijó la regla dura: sin reproducción no hay hallazgo, y fabricar evidencia es fraude. El módulo 7 ya fijó que los datos del cliente no salen a un tercero y que el prompt también es un canal de fuga. Esta sala no repite eso: cierra tres huecos que quedan cuando el encargo es, específicamente, auditar una app con un componente de IA y escribir el informe con un modelo al lado. Qué pasa cuando el modelo le pone a un fallo de diseño propio el nombre de una vulnerabilidad de producto que no existe, qué pasa cuando la misma sesión de un modelo se usa para dos clientes distintos, y quién decide la severidad de un hallazgo cuando el modelo ofrece una etiqueta sin más respaldo que el patrón del título. Se razona sobre el borrador; nada se envía ni se publica.

El hallazgo central del engagement de Astilla es que su chatbot no separa instrucción de dato de usuario —un fallo de diseño propio de esa aplicación, no de ningún producto con versión y parche—. Al redactar, el modelo le añade un identificador de vulnerabilidad de catálogo público, porque «suena más formal» y el título se parece al de otros casos que vio. El problema no es cosmético: un identificador de ese tipo le dice al cliente que existe un parche del fabricante que instalar, cuando la corrección real es rediseñar cómo su aplicación trata el texto que llega al modelo.

Un fallo de arquitectura propia se describe como lo que es —una decisión de diseño que hay que cambiar—, nunca con la etiqueta de una vulnerabilidad de un producto de terceros que no aplica.

Esta tarea se hace en el laboratorio

Una terminal con los archivos del caso, aquí en la página. No instalas nada y no puedes romper nada.

Preparando la estación…

Para responder aquí hace falta una cuenta

Puedes leer toda la sala sin cuenta. Responder y guardar tu avance pide entrar; al volver aterrizas en esta misma sala.

Responde para continuar

El modelo le añade un identificador de vulnerabilidad de catálogo público a un hallazgo que es un fallo de diseño propio de la app de Astilla, sin relación con ningún producto de terceros. ¿Qué se hace?

Ver pista de ayuda

Un identificador de producto implica que hay un parche del fabricante. Aquí la corrección es rediseñar el flujo propio de Astilla, no instalar nada.

Llevas dos engagements activos y usas la misma sesión de modelo para redactar los dos, «para no perder el hilo del estilo». Al revisar el borrador de Astilla aparece un párrafo entero que describe la arquitectura de otro cliente: el modelo arrastró contexto de la conversación anterior y lo mezcló sin avisar. No hace falta que haya subido nada a propósito: la sesión compartida es, ella sola, el canal de la fuga entre dos clientes que nunca debieron verse en el mismo documento.

La regla es simple y se pone antes de escribir la primera línea: una conversación o instancia de modelo por cliente, nunca una que continúe de un informe al siguiente.

Esta tarea se hace en el laboratorio

Una terminal con los archivos del caso, aquí en la página. No instalas nada y no puedes romper nada.

Preparando la estación…

Para responder aquí hace falta una cuenta

Puedes leer toda la sala sin cuenta. Responder y guardar tu avance pide entrar; al volver aterrizas en esta misma sala.

Responde para continuar

El borrador del informe de Astilla incluye un párrafo que describe la arquitectura de otro cliente, porque reutilizaste la misma sesión de modelo para los dos engagements. ¿Qué falló?

Ver pista de ayuda

No hizo falta pegar nada a propósito. Compartir la sesión entre dos clientes ya mezcla lo de uno con lo del otro.

El modelo entrega el hallazgo del chatbot marcado como «Crítico», sin vector de puntuación ni justificación: el título «fuga de instrucciones internas» encaja con el patrón de otros casos críticos que procesó. Pero la severidad depende del impacto real en Astilla —qué hay en esas instrucciones, a qué herramientas conectadas se llega desde ahí, qué puede hacer alguien con eso—, algo que el modelo no conoce de este cliente concreto. Aceptar la etiqueta porque «el modelo lo marcó así» es delegar exactamente la decisión que el módulo 1 ya dijo que no se delega.

La severidad la calcula el operador con el impacto verificado de este engagement, nunca la etiqueta que trae el borrador.

Esta tarea se hace en el laboratorio

Una terminal con los archivos del caso, aquí en la página. No instalas nada y no puedes romper nada.

Preparando la estación…

Para responder aquí hace falta una cuenta

Puedes leer toda la sala sin cuenta. Responder y guardar tu avance pide entrar; al volver aterrizas en esta misma sala.

Responde para continuar

El modelo marca un hallazgo como "Crítico" sin vector de puntuación, porque el título encaja con el patrón de otros casos. ¿Qué corresponde?

Ver pista de ayuda

El modelo reconoce patrones de texto, no el impacto real de este cliente. La severidad la decide quien verificó el alcance de lo que se puede hacer con el hallazgo.

Abre la estación. El borrador del informe de Astilla trae un párrafo que no es de Astilla. Localiza la revisión que confirma de qué cliente es y por qué no puede quedarse.

Esta tarea se hace en el laboratorio

Una terminal con los archivos del caso, aquí en la página. No instalas nada y no puedes romper nada.

Preparando la estación…

Para responder aquí hace falta una cuenta

Puedes leer toda la sala sin cuenta. Responder y guardar tu avance pide entrar; al volver aterrizas en esta misma sala.

Responde para continuar

Un párrafo del borrador describe la arquitectura de otro cliente, no la de Astilla. Abre la revisión de fugas entre clientes, confirma a qué cliente pertenece ese párrafo y escribe el código que acompaña a esa conclusión.

Formato esperado: IAO-____

Ver pista de ayuda

Lee ~/informe/revision-fugas.txt. El párrafo ajeno queda identificado con el nombre del otro cliente; el código está en esa misma línea.

Entra para responder, guardar tu avance y ganar puntos.

Preparando la estación…

16:24
Terminal (user@whoami)
user@whoami:~$
Tab Autocompletar ↑/↓ Historial
bash 5.2.21
Whoami-Labs OS v3.0.1 LTS · build b903d9

Whoami-Labs Pro

Whoami-Labs Pro utiliza cookies

Utilizamos cookies y almacenamiento local para el funcionamiento del sitio y la seguridad de tu sesión y, solo si lo autorizas, analítica. Puedes aceptar, rechazar o personalizar. Política de Cookies · Política de Privacidad