Salesforce Agentforce expone tres vulnerabilidades que permiten robo de datos sin clic y phishing anónimo

Ventajas y fallos de SalesBleed

Zenity Labs identificó tres vulnerabilidades en Salesforce Agentforce, denominadas SalesBleed. El primer y segundo fallo transformaban un formulario público Web‑to‑Lead en un canal de exfiltración 0‑click. Un atacante inserta una inyección indirecta que permanece inactiva hasta que un empleado consulta leads mediante el agente. El agente ejecuta la inyección, consulta la tabla Accounts, inserta los valores en una cadena que se convierte en un nombre de subdominio y la devuelve como un img src. La carga útil se envía al servidor DNS controlado por el atacante, logrando la exfiltración sin interacción del usuario.

El problema radica en la debilidad de los controles de Trusted URLs de Salesforce. La herramienta no reconocía dominios con TLD no estándar y la inclusión de ciertos caracteres alteraba el análisis de URLs, lo que permitía que la cadena maliciosa eludiera la redacción. La misma técnica se aplicó en Slack: su mecanismo de unfurling generaba solicitudes a enlaces maliciosos, enviando datos sensibles a servidores externos.

El tercer fallo, publicado en un blog separado, combinaba la vulnerabilidad de redacción de URLs con la ausencia de confirmación de usuario en la acción Reply to a Slack Thread. Un agente que invocara esta acción podía enviar mensajes sin aprobación, y el atacante podía usarla para enviar enlaces de phishing con la identidad del agente. La falta de atribución visible hacía que el mensaje apareciera como proveniente del agente, permitiendo que un atacante interno o externo permaneciera anónimo.

Salesforce corrigió la ruta de redacción de URLs y cerró la cadena específica, pero Zenity advierte que el patrón de vulnerabilidad es aplicable a cualquier agente que lea registros externos, renderice enlaces o imágenes y tenga acceso a datos sensibles.

“El reto de restringir agentes es una tendencia más amplia que trasciende SalesBleed.” – Michael Bargury, co‑fundador y CTO de Zenity Labs.

Implicaciones para la práctica

• Control de acceso: Los agentes deben tener límites estrictos sobre los tipos de datos que pueden consultar y cómo se exponen a los usuarios.
• Validación de URLs: Los sistemas deben registrar y sanitizar dominios con TLD no convencionales y escapar caracteres especiales.
• Autorización de acciones: Cada acción que modifique la comunicación externa, como enviar mensajes a Slack, debe requerir confirmación explícita y mostrar la identidad del remitente.

El caso muestra que la seguridad por diseño sigue siendo insuficiente cuando los agentes actúan en entornos reales; la monitorización continua y la auditoría de flujos de datos son esenciales.

Próximos pasos

Salesforce y Zenity han cerrado la cadena de explotación. No obstante, la comunidad debe revisar la arquitectura de sus propios agentes y garantizar que los controles de Trusted URLs y los flujos de respuesta de Slack estén actualizados. La adopción de políticas de least privilege y la instrumentación de logs de actividad de agentes serán claves para mitigar futuros ataques.