SalesBleed: exfiltración de datos sin clic en Agentforce vía inyección de prompt

Zenity Labs ha publicado el análisis de una prueba de concepto bautizada SalesBleed que saca datos internos de Salesforce Agentforce sin que la víctima haga nada más que una consulta estándar sobre un lead. El vector es una inyección de prompt indirecta alojada en un formulario público Web-to-Lead, y el canal de salida son consultas DNS. Salesforce ya emitió un parche y no hay explotación confirmada en producción.

El atacante no necesita cuenta ni autenticarse en Salesforce: rellena el formulario público de captación con instrucciones en lenguaje natural escondidas en un campo del lead. Ese registro queda guardado y persiste. Cuando un usuario interno pregunta a Agentforce por él, el subagente General CRM procesa el texto, lo toma como órdenes y va a leer valores del objeto Account. Con esos datos construye la URL de una imagen cuyo nombre de host apunta a un dominio que controla el atacante, y el navegador del usuario o el proceso que resuelve el HTML dispara la consulta DNS. La información sale dentro del propio nombre de host.

El truco está en el parser

Para que la URL cuele hay una discrepancia entre el redactor y el parser del navegador. El dominio usa el TLD .fun y va envuelto con llaves o corchetes: el redactor de Trusted URLs no lo reconoce como URL y lo deja pasar, mientras el navegador sí lo interpreta como la dirección de una imagen y la resuelve. El dato viaja en el nombre de la consulta, sin que haga falta que llegue el cuerpo HTTP ni ningún tipo de respuesta.

Zenity reportó el fallo el 1 de junio, Salesforce publicó el parche el 18 de agosto y el laboratorio confirmó la corrección un día después. La ventana está cerrada para quien actualice, que es lo primero que toca comprobar.

Permisos y egreso, por dónde se corta

La cadena necesita dos cosas para funcionar: que la entrada pública acabe dentro del contexto del agente y que el subagente tenga permiso de lectura sobre Leads y Accounts. Recortar esos permisos de objeto y campo, y no tratar el texto externo como instrucciones, rompe el ataque. Conviene además revisar si el HTML enriquecido se resuelve de forma automática y limitar el egreso DNS y HTTP a dominios aprobados.

En los logs, las pistas son nombres DNS largos con TLD poco habituales como .fun y peticiones a imágenes externas desde el navegador del usuario. Suma revisar las trazas del agente, los tiempos de creación de leads y los registros de identidad para saber con qué actor y con qué permisos se ejecutó el subagente. Los datos personales del caso están en Zenity; la explotación real en clientes, de momento, no.

Lo que se lleva este trabajo es que una allowlist HTTP no cierra la puerta cuando el nombre de consulta DNS también transporta datos, algo que aplica a cualquier agente capaz de generar HTML o URLs con valores del sistema. Y como el lead malicioso sigue ahí, la inyección puede reactivarse con cada consulta posterior sobre ese registro en lugar de dispararse una sola vez.