AUSI · UNC / CHARLA PRÁCTICA

CHARLA PRÁCTICA · 4 DEMOS EN VIVO

El enemigo
invisible

¿En quién confía tu sistema?

De un correo falso a un agente de IA comprometido.

Esteban MolinaCloud Architect
La mayor parte de la charla ocurre en las demos.PERSONA · SISTEMA · APLICACIÓN · AGENTE

ANTES DEL PRIMER CASO

¿Qué tienen en común
estos ataques?

Hoy vamos a romper cuatro cosas diferentes.

Pero las cuatro fallan por una razón parecida.

01 CONFIAMOS EN LO QUE PARECE LEGÍTIMO

DEMO EN VIVO

Un correo
convincente.

El mensaje usa una identidad familiar y te apura a actuar. El atacante no necesariamente rompe el sistema: puede conseguir que el usuario abra la puerta.

Problema: confianza del usuario

EJEMPLO ILUSTRATIVO · NO ES UN CORREO REAL
Bandeja de entrada

Verificá tu cuenta

Equipo de soporte<avisos@cuentas-campus.example>

Detectamos actividad inusual en tu cuenta. Para mantener el acceso, revisá tus datos hoy.

Equipo de soporte
Administración de cuentas

02 UN PERMISO TAMBIÉN ES UNA FRONTERA

DEMO EN VIVO

Un permiso
de más.

Docker permite ejecutar procesos en contenedores. Los contenedores aíslan, pero no son una frontera mágica de seguridad.

Problema: autoridad otorgada de más

Least privilege: dar a una identidad solamente los permisos que necesita para su tarea.
REPRESENTACIÓN CONCEPTUAL
HOSTArchivos · procesos · dispositivos
CONTENEDOR
Usuario / procesoPermiso excesivo habilitado
Capacidad no prevista

root. El acceso al host depende de qué permiso concreto se otorgó, no de una falla mágica de Docker.

Docker no está "roto". Estamos aprovechando una configuración o un permiso inseguro. Un fallo de aislamiento y una configuración privilegiada son causas distintas.

03 DATOS QUE TERMINAN SIENDO CÓDIGO

DEMO EN VIVO

Un archivo
que hace más.

Nunca deberíamos asumir que una entrada es segura solamente porque "parece" tener el formato esperado.

Problema: validación insuficiente

ILUSTRACIÓN · ESTE SITIO NO SUBE NI EJECUTA ARCHIVOS
Adjuntar archivo
¿Qué hay dentro?

El nombre y la extensión son solo parte de la validación.

foto.jpgfoto.php
RecibirAlmacenarEjecutar
Reverse shell, en una línea: normalmente nosotros nos conectamos a un servidor. Acá hacemos que sea el servidor quien inicie una conexión hacia nosotros y nos entregue una consola.

LO QUE CONECTA LOS TRES CASOS

La entrada llega.
El permiso importa.

Hasta ahora engañamos a una persona, abusamos de permisos y conseguimos que una aplicación interprete una entrada de forma peligrosa.

01Verificar identidad

Corroborar el pedido por un canal conocido.

02Limitar privilegios

Cada proceso recibe lo que necesita para su tarea.

03Validar antes de usar

El servidor decide qué datos acepta y cómo los trata.

¿Qué pasa si ahora el que interpreta la entrada es una inteligencia artificial?

DE "¿PUEDEN PENSAR?" A "PUEDEN ACTUAR"

Lo que cambió
no es sutil.

1950
Alan Turing"Can machines think?"
2017
Transformers"Attention Is All You Need"
Hoy
LLMs → AgentesHerramientas + acciones
ANTES
humano → computadora
DESPUÉS
humano → modelo → herramientas → sistemas

UN CAMBIO DE CATEGORÍA

Chatbot ≠ Agente

Chatbot

Pregunta
↓
Modelo
↓
Respuesta

Agente

Objetivo
↓
Modelo
↓
Decisión
↓
Herramienta
↓
Acción

¿QUÉ OCURRE CUANDO LA IA PUEDE USAR HERRAMIENTAS?

Una nueva
superficie de ataque.

Usuario → Agente → Herramientas:

🌐 Navegador
📁 Archivos
🔌 APIs
⌘ Terminal
Contenido externo
?
Agente

¿El agente puede distinguir siempre entre DATOS e INSTRUCCIONES?

EL PROBLEMA NO ES COMPLETAMENTE NUEVO

Mezclar datos
e instrucciones.

SQL Injection

La app esperaba: DATOS
Una entrada afecta: INSTRUCCIONES SQL

Prompt Injection

El agente esperaba: CONTENIDO
Se interpreta como: INSTRUCCIONES PARA EL MODELO

No son la misma vulnerabilidad. La analogía sirve para entender un problema común: mezclar datos e instrucciones. La demo de hoy es indirecta: el modelo encuentra instrucciones maliciosas dentro de contenido que estaba procesando (una página web).

¿QUIÉN ESTÁ DANDO REALMENTE LAS INSTRUCCIONES?

Si el agente lee
la web, ¿quién le habla?

Usuario: "Leé esta página y resumila"
abre↓
Agente
contiene texto↓
Página web
La página también contiene instrucciones para el agente.

Si yo le pedí al agente que leyera una web, ¿quién controla todo lo que el agente va a leer?

No necesariamente yo.

04 PROMPT INJECTION + AGENTE

ÚLTIMA DEMO

Resumamos
este sitio.

Una tarea de lectura. Un agente con herramientas. ¿Qué podría salir mal?

EL PEDIDO DEL USUARIO
«Leé esta página y resumí las principales recomendaciones de ciberseguridad.»
Usuario
pide un resumen
Agente
lee contenido

Paso 1 de 6 — el usuario pide una tarea legítima de lectura.

Una instrucción oculta en el HTML intentó dirigir al agente hacia herramientas de creación y ejecución. La aplicación local ejecuta las llamadas que acepta. El fallo de diseño consiste en dar autoridad al contenido externo y ofrecer una capacidad de ejecución para una tarea de resumen.

LO QUE AUMENTA EL IMPACTO

Prompt injection
no actúa solo.

Nunca le pedí al agente que apagara la computadora. Le pedí que trabajara con contenido. El problema apareció porque ese contenido tenía instrucciones y el agente tenía herramientas capaces de ejecutar acciones.

CUATRO ATAQUES. UN MISMO PATRÓN.

¿En qué confiamos
demasiado?

Caso¿En qué confiamos demasiado?
PhishingEn lo que ve el usuario
DockerEn los permisos / la configuración
File UploadEn la entrada recibida
Agente IAEn el contenido que procesa
Trust is a security boundary.
La confianza también es una frontera de seguridad.

EL ATAQUE CAMBIA. EL PRINCIPIO NO.

No confíes
automáticamente.

Verificá qué pueden hacer.
Limitá sus permisos.
Asumí que una entrada puede ser hostil.

Al principio vimos cómo engañar a una persona para que siga una instrucción. Al final vimos cómo un atacante puede intentar engañar a una inteligencia artificial para que haga exactamente lo mismo.

Las tecnologías cambian. El problema de confiar demasiado sigue siendo el mismo.

¿Preguntas?

¡Muchas gracias!

Esteban Molina Cloud Architect
Redes de Esteban Molina