SalesBleed convirtió los formularios de captación de Salesforce en una vía para robar datos del CRM sin levantar sospechas

Tres vulnerabilidades de Salesforce Agentforce permitían ocultar instrucciones maliciosas en los envíos de Web-to-Lead. Así, los atacantes podían robar información del CRM o distribuir mensajes de phishing a través de los canales internos de Slack.

Zenity Labs bautizó el conjunto de fallos como SalesBleed. Dos de ellos permitían exfiltrar datos sin que el usuario tuviera que hacer clic, una vez que Agentforce procesaba un lead manipulado. El tercero podía hacer que el agente publicara contenido de phishing con su propia identidad de confianza.

Zenity Labs informó de los problemas el 1 de junio. Salesforce confirmó que los tres se habían corregido para el 19 de agosto. Sin embargo, no se han publicado identificadores CVE, puntuaciones de gravedad, rangos de versiones afectadas ni instrucciones detalladas para aplicar las correcciones.

Un formulario público de captación se convirtió en el punto de acceso inicial

Salesforce Web-to-Lead es un mecanismo oficial para recopilar información de posibles clientes y transferirla directamente al CRM de Salesforce. Esa conexión también permitía a personas no autenticadas introducir texto bajo el control del atacante en un lugar donde Agentforce podía encontrarlo más adelante.

Un atacante podía enviar un lead con instrucciones diseñadas cuidadosamente. El contenido permanecía inactivo en el CRM hasta que un empleado pedía a un agente de Agentforce que examinara, resumiera o procesara de algún otro modo el envío.

En ese momento, el agente podía interpretar el contenido incrustado como instrucciones, en vez de tratarlo como datos no confiables. Se trata de una forma de inyección indirecta de prompts: el atacante no se comunica con el agente de IA a través de su interfaz de conversación habitual, sino que inserta órdenes en información que el agente procesará más adelante.

El envío inicial no extraía los registros por sí solo. Para que el lead manipulado entrara en el contexto del agente, era necesaria la intervención de una persona. Sin embargo, una vez que Agentforce lo procesaba, la transferencia de datos podía continuar sin otro clic, aprobación ni acción deliberada del empleado.

Las debilidades en Trusted URLs permitían transmitir datos de forma encubierta

Dos de las vulnerabilidades de SalesBleed afectaban a Trusted URLs, un control de seguridad diseñado para impedir que Agentforce mostrara imágenes o URL alojadas en fuentes no aprobadas.

Según los hallazgos de Zenity Labs sobre las vías de ataque de SalesBleed, el control no reconocía correctamente los dominios de nivel superior. Los investigadores también descubrieron que secuencias de caracteres especialmente diseñadas podían alterar la forma en que se analizaban las URL.

Estas debilidades permitían que el contenido malicioso de Web-to-Lead eludiera las restricciones previstas sobre los destinos. Una vez procesadas las instrucciones, Agentforce podía recuperar información confidencial de las tablas de leads y cuentas del CRM e incluirla en una solicitud saliente.

El mecanismo de exfiltración utilizaba etiquetas de imagen HTML. En lugar de mostrar una imagen normal, la etiqueta enviaba una solicitud a una infraestructura controlada por el atacante e incorporaba información del CRM en esa solicitud. Por tanto, al cargar el recurso externo se transmitían los datos.

La técnica aprovecha el funcionamiento habitual de la web: una aplicación que muestra una imagen debe conectarse al servidor indicado en la fuente de esa imagen. Si se incluyen datos confidenciales en esa URL, el servidor receptor puede obtenerlos de la solicitud entrante.

El ataque también generaba una señal de seguridad engañosa. Agentforce podía informar al usuario de que las políticas de la organización habían bloqueado el contenido, aunque la solicitud saliente ya hubiera expuesto la información. Por tanto, un mensaje tranquilizador en la interfaz no demostraba que la protección hubiera funcionado.

Las vistas previas de enlaces de Slack abrían una segunda vía de exfiltración

Una técnica relacionada afectaba a las organizaciones que utilizaban Agentforce a través de Slack. La plataforma de mensajería recupera automáticamente información de los enlaces para generar vistas previas, un proceso conocido como link unfurling.

SalesBleed abusaba de esta recuperación automática. Los enlaces especialmente manipulados que aparecían en las respuestas de Agentforce podían hacer que Slack enviara solicitudes a una infraestructura controlada por el atacante. Esas solicitudes podían incluir información extraída del CRM de Salesforce.

No hacía falta que ningún empleado abriera el enlace para que se produjera la transferencia. El mecanismo de generación de vistas previas enviaba automáticamente la solicitud de red correspondiente al aparecer el enlace, por lo que la exfiltración no requería clics.

Esta vía también demuestra por qué los controles centrados exclusivamente en los clics directos desde el navegador pueden pasar por alto las filtraciones de datos asistidas por IA. La conexión externa puede originarse en una integración del lado del servidor o en una plataforma de colaboración, en lugar de en el equipo de un empleado.

No se han publicado dominios del atacante, patrones de solicitud, ejemplos de registros ni otros indicadores de compromiso. Por tanto, las organizaciones no disponen de indicadores específicos de SalesBleed para buscar.

La identidad del agente podía utilizarse para hacer phishing interno

La tercera vulnerabilidad afectaba a la integración de Agentforce con Slack, pero su objetivo era suplantar identidades, no extraer información directamente mediante una imagen o una solicitud de vista previa.

El agente no identificaba al usuario que había iniciado un mensaje. Un atacante podía aprovechar esa falta de atribución mediante un envío malicioso de Web-to-Lead, secuestrar el comportamiento del agente e indicarle que publicara mensajes de phishing en canales internos de Slack.

Los mensajes aparecían con la identidad del agente. Esto es importante porque los empleados pueden confiar más en el contenido publicado por una herramienta de automatización empresarial aprobada que en los mensajes de un usuario desconocido.

Si un destinatario hacía clic en un enlace de phishing y entregaba sus credenciales, el impacto podía extenderse más allá de Salesforce. La identidad comprometida podía dar acceso al correo corporativo, Slack, repositorios de código fuente y otras aplicaciones empresariales disponibles para ese empleado.

Por tanto, el fallo generaba dos niveles de riesgo. El problema inmediato era que Agentforce podía enviar mensajes sin autorización; los daños posteriores dependían de si los destinatarios interagivano con el contenido de phishing y dai permessi associati alle credenziali sottratte.

Prodotti, versioni e gravità restano indeterminati

I percorsi di attacco segnalati coinvolgevano tre componenti collegati:

• Salesforce Agentforce
• Salesforce CRM
• L’integrazione Agentforce–Slack

Non sono state rese note le versioni esatte interessate. Non è chiaro neppure se lo sfruttamento dipendesse da specifiche configurazioni di Agentforce, azioni abilitate, autorizzazioni del CRM, impostazioni di Slack o criteri di Trusted URL.

Per le tre vulnerabilità non sono stati forniti identificativi CVE. Di conseguenza, sulla base delle informazioni disponibili non è possibile stabilire se abbiano uno stato associato a una CVE nel catalogo Known Exploited Vulnerabilities della Cybersecurity and Infrastructure Security Agency degli Stati Uniti.

Non è stata inoltre assegnata alcuna valutazione formale della gravità. L’assenza di un punteggio non riduce le conseguenze dimostrate: due vulnerabilità potevano esporre i record del CRM senza che l’utente dovesse fare clic, mentre la terza poteva sfruttare la fiducia riposta in un agente interno per distribuire messaggi di phishing.

Non sono state diffuse informazioni su eventuali attacchi al di fuori dei test dei ricercatori. Non è quindi noto se gli aggressori abbiano usato SalesBleed contro ambienti di produzione prima che Salesforce completasse le correzioni.

Salesforce dichiara che i problemi sono stati risolti, ma le indicazioni sono limitate

Salesforce ha confermato che tutte e tre le vulnerabilità erano state corrette entro il 19 agosto. L’azienda non ha fornito identificativi specifici delle patch, numeri di versione aggiornati, modifiche alla configurazione o istruzioni per soluzioni temporanee.

I clienti dovrebbero verificare tramite i canali di assistenza e amministrazione Salesforce che il proprio ambiente Agentforce includa le protezioni pertinenti. È particolarmente importante farlo quando Web-to-Lead, l’accesso ai dati del CRM e l’integrazione con Slack sono attivi contemporaneamente.

In assenza di indicatori pubblicati, i responsabili della sicurezza possono esaminare le connessioni in uscita generate in passato quando Agentforce ha elaborato contenuti provenienti da lead esterni. Possono inoltre controllare le attività di Slack che coinvolgono link o messaggi imprevisti di Agentforce, anche se non è stato divulgato alcuno schema di rilevamento definitivo per SalesBleed.

Gli amministratori dovrebbero anche valutare a quanti dati del CRM può accedere Agentforce e quali azioni può eseguire l’integrazione con Slack. Limitare le autorizzazioni dell’agente e monitorare le richieste automatiche in uscita può ridurre l’esposizione nel caso emergesse un percorso analogo di prompt injection.

Il problema alla base di SalesBleed non riguardava soltanto il modello linguistico. L’attacco dipendeva dalla combinazione di input non attendibili nel CRM, debolezze nella convalida delle URL, autorizzazioni dell’agente, rendering HTML e comportamento automatico della rete di Slack. Una volta collegati, questi elementi permettevano a un invio tramite un modulo pubblico di attraversare diversi confini di fiducia all’interno di un ambiente aziendale.