GhostJacking: logs y agentes de IA

La investigación muestra cómo la telemetría manipulada influye en un agente integrado. Sin CVE ni víctima confirmada.^{[1], [2]}

💡 Explicación en Lenguaje Sencillo (ELI5)

Imagina que una recepcionista bloquea una entrega sospechosa, pero copia la nota del remitente en el registro del incidente. Más tarde, una persona encargada de operaciones verifica un número de ticket real y una carencia auténtica en la política DNS de la configuración de prueba; entonces confía en la dirección elegida por el atacante que aparece en la misma nota y cambia el directorio público que indica a los navegadores y al correo dónde están los servicios de la empresa. El registro era evidencia, no autorización para hacer ese cambio; una política y una aprobación independientes deben controlarlo.^[1]

Conceptos Clave y Términos

GhostJacking: Nombre que Tenet Security da a demostraciones en las que contenido controlado por un atacante en eventos de observabilidad influye en un agente de IA conectado a esas herramientas. Es una etiqueta de investigación, no un CVE.^{[1], [2]}
Indirect prompt injection: Instrucciones insertadas en datos que se pide analizar al modelo, en lugar de proporcionadas directamente por el usuario.^{[1], [2], [4]}
Evento de observabilidad: Un registro, alerta, traza o error que describe actividad del sistema. Algunos campos pueden contener texto aportado por una solicitud externa.^{[1], [2]}
Autorización independiente: Comprobación de políticas fuera del modelo que evalúa al actor, el objetivo, el cambio solicitado y la aprobación antes de que una herramienta realice una acción importante.^{[2], [5]}
CWE-1427: Clase de debilidad de MITRE para la neutralización inadecuada de entradas usadas en prompts de LLM. Es una asignación conceptual de FlawOpen; Tenet, ngCERT y ningún registro CVE la asignaron a GhostJacking.^{[4], [1], [2]}
Severidad editorial: ngCERT califica como altos el riesgo y el daño del aviso. FlawOpen califica este resumen como Medio porque las demostraciones requieren un agente con integraciones y permisos de modificación pertinentes; no hay una víctima con brecha confirmada. Es una valoración editorial, no una puntuación del proveedor.^{[2], [1]}

Mapeos de marcos

Mapeo conceptual de FlawOpen a MITRE CWE; ningún proveedor ni registro CVE asignó este identificador de debilidad a esta demostración de investigación. CWE-1427
OWASP GenAI 2025 — LLM01:2025 Inyección de prompts
OWASP GenAI 2025 — LLM06:2025 Agencia excesiva

Flujo de Ataque Paso a Paso

Paso 1

El agente recibe permiso para investigar

La investigación de Tenet describe agentes de programación u operaciones conectados a herramientas como Cloudflare, Datadog y Sentry. La precondición relevante es que el agente pueda leer contenido externo de eventos y realizar acciones importantes con los permisos que ya tiene.^[1]

Paso 2

Una solicitud queda registrada como evidencia

En la demostración de Tenet con Cloudflare, un WAF bloquea una solicitud, pero el registro conserva texto de un campo controlado por el atacante. Una solicitud bloqueada todavía puede dejar texto no confiable para que un agente lo lea más tarde.^{[1], [2]}

Paso 3

La telemetría plausible supera las defensas contra órdenes explícitas

Tenet informa que sus pruebas rechazaron las órdenes explícitas. En la demostración exitosa con Cloudflare, usó telemetría estructurada similar a la de un escáner, con una referencia de ticket, una cita de cumplimiento y una métrica; el agente verificó algunas afirmaciones y luego confió en valores DNS no verificados controlados por el atacante. Es una demostración de inyección indirecta de instrucciones atribuida a los investigadores, no evidencia de una brecha real en una víctima.^{[1], [2]}

Paso 4

Los permisos existentes convierten la influencia en impacto

Tenet afirma que su demostración controlada hizo que un agente modificara DNS mediante una herramienta integrada de Cloudflare. El resultado depende de los permisos y la configuración del agente; no demuestra que Cloudflare fuera comprometido ni que se atacaran sistemas de clientes.^[1]

Paso 5

Una política separada puede detener el cambio

La aplicación debe tratar la propuesta del modelo como no confiable. Un servicio de autorización del servidor debe comprobar de forma independiente el recurso y el cambio exactos, exigir aprobación de una persona autorizada cuando corresponda y registrar la decisión antes de llamar a la API del proveedor.^{[2], [5]}

Código Fuente: Vulnerable vs. Seguro

Estos fragmentos son ilustrativos y no pertenecen al código vulnerable o corregido de ninguno de los productos mencionados. El patrón inseguro da acceso directo a una herramienta de modificación al agente que lee texto de eventos no confiable. El patrón protegido separa propuesta y ejecución: un servicio independiente consume una aprobación de un solo uso vinculada al actor y al cambio exactos y aplica la política antes de llamar al proveedor. La identidad del actor procede del contexto autenticado del servidor, no de un campo controlado por quien llama; el modelo no puede elegirla. Una instrucción en el prompt no es, por sí sola, un control de autorización. El código de producción también debe validar esquemas, titularidad del tenant y del recurso, vencimiento de la aprobación, protección contra repetición, persistencia de auditoría y errores del proveedor.^{[1], [2], [5]}

IMPLEMENTACIÓN VULNERABLE

// Integración insegura ilustrativa; no es código fuente de Cloudflare, Datadog, Sentry ni Tenet.
async function investigate(event: EventRecord) {
  return agent.run({
    context: event.message,
    tools: [cloudflare.updateDnsRecord]
  });
}

PARCHE SEGURO Y ROBUSTO

// Límite de control ilustrativo; el modelo puede proponer, pero no autorizar ni aplicar.
type DnsProposal = { zoneId: string; name: string; value: string };

async function proposeDnsChange(event: EventRecord): Promise<DnsProposal> {
  return agent.propose({ evidence: markUntrusted(event.message) });
}

async function applyDnsChange(
  proposal: DnsProposal,
  approvalId: string
) {
  const actorId = auth.requireAuthenticatedActorId();
  const validatedProposal = DnsProposalSchema.parse(proposal);
  const approval = await approvals.consumeOnce(approvalId, { actorId });
  if (!approval || approval.actorId !== actorId ||
      approval.zoneId !== validatedProposal.zoneId ||
      approval.name !== validatedProposal.name ||
      approval.value !== validatedProposal.value ||
      !policy.canChangeDns(actorId, validatedProposal.zoneId, validatedProposal.name)) {
    throw new Error('DNS change is not independently authorized');
  }
  // Deniega por defecto si no se puede registrar la decisión de autorización antes de la mutación.
  await audit.record({ actorId, approvalId, action: 'dns-change', decision: 'authorized' });
  try {
    await cloudflare.updateDnsRecord(validatedProposal);
  } catch (error) {
    await audit.record({ actorId, approvalId, action: 'dns-change', outcome: 'provider-failed' });
    throw error;
  }
  await audit.record({ actorId, approvalId, action: 'dns-change', outcome: 'succeeded' });
}

Lista de Verificación de Seguridad para Ingeniería

✓Marque como no confiables todos los campos de registros, alertas, trazas, errores y tickets influenciables externamente al construir el contexto del agente; conserve su origen durante las transformaciones.^{[1], [2]}
✓Use credenciales de solo lectura para agentes de investigación de forma predeterminada. Sitúe los cambios de DNS, nube, repositorios e implementación detrás de un servicio independiente que aplique políticas.^{[1], [5]}
✓Autorice cada acción fuera del modelo según el actor autenticado, tenant, recurso, cambio exacto y política actual; no trate la confianza del modelo ni la disponibilidad de una herramienta como aprobación.^{[2], [5]}
✓Para cambios de alto impacto, exija aprobación humana vinculada al diff exacto, recurso, actor y vencimiento breve; use la aprobación una sola vez y rechace repeticiones o propuestas modificadas.^{[2], [5]}
✓Añada pruebas de regresión con telemetría no confiable que incluya referencias y hechos plausibles junto con un cambio propuesto conflictivo y sin verificar; compruebe que el agente puede resumir el evento, pero que no se llama a ninguna API de modificación sin autorización independiente.^[1]
✓Alerta sobre intentos de escritura desde flujos de investigación y conserve el evento original, la propuesta del modelo, la decisión de política, el aprobador y la respuesta del proveedor para revisar incidentes.^[1]
✓Verifique los permisos reales de cada integración y el alcance del token. Un identificador público de cliente no es automáticamente un secreto privilegiado; pruebe las acciones del token concreto antes de llamarlo credencial expuesta.^{[1], [2]}

Fuentes

← AI Security Directory →