SalesBleed ha trasformato i moduli Web-to-Lead di Salesforce in una via per sottrarre dati dal CRM senza farsi notare

Tre vulnerabilità in Salesforce Agentforce consentivano agli aggressori di nascondere istruzioni malevole nelle richieste inviate tramite Web-to-Lead, creando un percorso per sottrarre informazioni dal CRM o diffondere messaggi di phishing nei canali Slack interni.

Zenity Labs ha dato alle vulnerabilità il nome collettivo SalesBleed. Due consentivano l’esfiltrazione dei dati senza alcuna interazione dell’utente dopo che Agentforce aveva elaborato un lead manipolato; la terza poteva indurre l’agente a pubblicare contenuti di phishing usando la propria identità, considerata attendibile.

Zenity Labs ha segnalato i problemi il 1° giugno. Salesforce ha confermato di averli risolti tutti entro il 19 agosto. Non sono stati però divulgati identificativi CVE, punteggi di gravità, intervalli di versioni interessate o istruzioni dettagliate per la correzione.

Un modulo pubblico per i lead è diventato il punto d’accesso iniziale

Salesforce Web-to-Lead è uno strumento ufficiale che raccoglie informazioni sui potenziali clienti e le trasferisce direttamente nel CRM Salesforce. Questa integrazione offriva anche a persone esterne non autenticate la possibilità di inserire testo controllato dagli aggressori in un punto in cui Agentforce avrebbe potuto trovarlo in seguito.

Un aggressore poteva inviare un lead contenente istruzioni formulate ad arte. Il contenuto restava inattivo nel CRM finché un dipendente non chiedeva a un agente Agentforce di esaminare, riassumere o elaborare in altro modo la richiesta.

A quel punto, l’agente poteva interpretare il contenuto incorporato come un insieme di istruzioni, anziché come dati non attendibili. Si tratta di una forma di prompt injection indiretta: l’aggressore non interagisce con l’agente AI attraverso la normale interfaccia conversazionale, ma inserisce comandi in informazioni che l’agente dovrà elaborare in seguito.

L’invio iniziale non sottraeva di per sé i record. Perché il lead manipolato entrasse nel contesto dell’agente era necessario l’intervento di una persona. Una volta che Agentforce lo aveva elaborato, però, il trasferimento dei dati poteva avvenire senza ulteriori clic, approvazioni o azioni deliberate da parte del dipendente.

Le vulnerabilità negli URL attendibili consentivano di trasmettere dati di nascosto

Due delle vulnerabilità di SalesBleed riguardavano Trusted URLs, un controllo di sicurezza pensato per impedire ad Agentforce di mostrare immagini o URL ospitati su fonti non approvate.

Secondo i risultati di Zenity Labs sui percorsi d’attacco di SalesBleed, il controllo non riconosceva correttamente i domini di primo livello. I ricercatori hanno inoltre scoperto che sequenze di caratteri costruite ad arte potevano alterare il modo in cui gli URL venivano analizzati.

Queste vulnerabilità permettevano ai contenuti Web-to-Lead manipolati di aggirare le restrizioni previste sulle destinazioni. Una volta elaborate le istruzioni malevole, Agentforce poteva recuperare informazioni sensibili dalle tabelle di lead e account del CRM e inserirle in una richiesta in uscita.

Il meccanismo di esfiltrazione usava tag HTML per le immagini. Anziché visualizzare una normale immagine, il tag indirizzava una richiesta verso un’infrastruttura controllata dall’aggressore, includendo nella richiesta informazioni del CRM. Il caricamento della risorsa esterna trasmetteva così i dati.

La tecnica sfrutta il normale funzionamento del web: per visualizzare un’immagine, un’applicazione deve contattare il server indicato nella sorgente dell’immagine. Se nell’URL vengono inseriti dati sensibili, il server che riceve la richiesta può raccoglierli.

L’attacco generava anche un falso segnale di sicurezza. Agentforce poteva comunicare all’utente che le policy aziendali avevano bloccato il contenuto, anche se la richiesta in uscita aveva già esposto le informazioni. Un messaggio rassicurante nell’interfaccia non era quindi una prova affidabile del corretto funzionamento delle protezioni.

Le anteprime dei link in Slack offrivano un secondo canale di esfiltrazione

Una tecnica correlata prendeva di mira le aziende che usavano Agentforce tramite Slack. La piattaforma di messaggistica recupera automaticamente le informazioni sui link per generarne le anteprime: un processo comunemente chiamato link unfurling.

SalesBleed sfruttava questo comportamento automatico. Link appositamente costruiti, inseriti nelle risposte di Agentforce, potevano indurre Slack a inviare richieste a infrastrutture controllate dall’aggressore. Tali richieste potevano contenere informazioni estratte dal CRM Salesforce.

Per avviare il trasferimento non era necessario che un dipendente aprisse il link. Il meccanismo che genera l’anteprima effettuava automaticamente la richiesta di rete non appena il link compariva: l’esfiltrazione avveniva quindi senza alcuna interazione dell’utente.

Questo percorso mostra anche perché i controlli che si concentrano esclusivamente sui clic effettuati direttamente nel browser possono non rilevare le fughe di dati facilitate dall’AI. La connessione esterna può partire da un’integrazione lato server o da una piattaforma di collaborazione, anziché dalla postazione di un dipendente.

Non sono stati pubblicati domini usati dagli aggressori, schemi di richiesta, esempi di log o altri indicatori di compromissione. Le aziende non dispongono quindi di indicatori specifici di SalesBleed da cercare.

L’identità dell’agente poteva essere sfruttata per il phishing interno

La terza vulnerabilità riguardava l’integrazione tra Agentforce e Slack, ma il suo obiettivo era l’impersonificazione, non l’estrazione diretta tramite una richiesta di anteprima o di caricamento di un’immagine.

L’agente non identificava l’utente che aveva originato un messaggio. Un aggressore poteva sfruttare questa mancata attribuzione con un invio Web-to-Lead malevolo, dirottare il comportamento dell’agente e indurlo a pubblicare messaggi di phishing nei canali Slack interni.

I messaggi sarebbero comparsi con l’identità dell’agente. È un aspetto rilevante, perché i dipendenti potrebbero fidarsi più di contenuti pubblicati da uno strumento aziendale di automazione approvato che di messaggi provenienti da un utente sconosciuto.

Se un destinatario avesse seguito un link di phishing e fornito le proprie credenziali, le conseguenze avrebbero potuto estendersi oltre Salesforce. L’identità compromessa avrebbe potuto consentire l’accesso alla posta aziendale, a Slack, ai repository del codice sorgente e ad altre applicazioni aziendali disponibili per quel dipendente.

La vulnerabilità comportava quindi due livelli di rischio. Il problema immediato era l’invio non autorizzato di messaggi da parte di Agentforce; i danni successivi dipendevano dalla risposta dei destinatari al contenuto di phishing e dai permessi associati alle credenziali sottratte.

Prodotti, versioni e gravità non sono stati specificati

I percorsi d’attacco descritti coinvolgevano tre componenti interconnessi:

• Salesforce Agentforce
• Salesforce CRM
• L’integrazione tra Agentforce e Slack

Non sono state divulgate le versioni esatte interessate. Non è inoltre noto se lo sfruttamento dipendesse da specifiche configurazioni di Agentforce, azioni abilitate, autorizzazioni del CRM, impostazioni di Slack o policy di Trusted URLs.

Per le tre vulnerabilità non sono stati forniti identificativi CVE. Sulla base delle informazioni disponibili, non è quindi possibile stabilire se siano presenti nella Known Exploited Vulnerabilities Catalog della Cybersecurity and Infrastructure Security Agency degli Stati Uniti con uno stato basato su CVE.

Non è stato comunicato nemmeno un punteggio ufficiale di gravità. L’assenza di una valutazione non ridimensiona le conseguenze dimostrate: due vulnerabilità potevano esporre record del CRM senza richiedere un clic da parte dell’utente, mentre la terza poteva sfruttare la fiducia riposta in un agente interno per diffondere messaggi di phishing.

Non sono state rese note informazioni su eventuali attacchi al di fuori dei test dei ricercatori. Non è quindi noto se SalesBleed sia stato usato contro ambienti di produzione prima che Salesforce completasse le correzioni.

Salesforce dichiara di aver risolto le vulnerabilità, ma le indicazioni sono limitate

Salesforce ha confermato di aver risolto tutte e tre le vulnerabilità entro il 19 agosto. L’azienda non ha fornito identificativi delle patch, numeri di versione aggiornati, modifiche di configurazione o istruzioni per soluzioni alternative.

I clienti dovrebbero verificare tramite i canali di assistenza e amministrazione Salesforce che nel proprio ambiente Agentforce siano presenti le protezioni pertinenti. La verifica è particolarmente importante quando Web-to-Lead, l’accesso ai dati del CRM e l’integrazione con Slack sono abilitati contemporaneamente.

In assenza di indicatori pubblicati, i responsabili della sicurezza possono esaminare le connessioni in uscita generate quando Agentforce elaborava contenuti provenienti da lead esterni. Possono inoltre controllare le attività di Slack che coinvolgono link o messaggi Agentforce inattesi, anche se non è stato divulgato alcun metodo di rilevamento specifico e definitivo per SalesBleed.

Gli amministratori dovrebbero anche valutare la quantità di informazioni del CRM che Agentforce può recuperare e le azioni che l’integrazione con Slack può eseguire. Limitare i permessi degli agenti e monitorare le richieste automatiche in uscita può ridurre l’esposizione nel caso emergesse un percorso di prompt injection simile.

Il problema alla base di SalesBleed non riguardava soltanto il modello linguistico. L’attacco sfruttava la combinazione di input CRM non attendibili, vulnerabilità nella convalida degli URL, autorizzazioni dell’agente, rendering HTML e comportamento di rete automatico di Slack. Una volta collegate, queste componenti permettevano a un invio tramite un modulo pubblico di attraversare diversi confini di fiducia all’interno dell’ambiente aziendale.