I cyber criminali possono sfruttare i webhook usati nella
piattaforma di collaborazione Slack per lanciare attacchi di
phishing. La scoperta è della ricercatrice per la sicurezza Ashley Graves di
AT&T Cybersecurity. Quanto scoperto non è un bug di Slack, il problema riguarda i webhook. Nel caso specifico, sono una funzionalità progettata
per programmare il server in modo da spedire dati attraverso Slack. Il webhook sfrutta le comuni richieste HTTP mediante un payload JSON, che include il messaggio e i dettagli opzionali.
In genere i webhook sono percepiti come un'integrazione a basso rischio. Banalmente, si parte dal presupposto che il webhook richieda la selezione di un canale di destinazione per condividere un messaggio. Inoltre, si presume che l'URL univoco del webhook sia segreto e che il webhook accetti solo dati, evitando il rischio di esporre dati sensibili.
Ashley Graves ha scoperto che tutto questo non è necessariamente vero. Mettendo mano al codice, un aggressore potrebbe bypassare il canale target del webhook aggiungendo la chiave "channel" al payload JSON. Ottenuto l'accesso a un webhook per un canale, diventa semplice usare lo stesso webhook in altri canali. Ad esempio #general, #engineering o un altro canale visibile a un gruppo più ampio di persone. In alcuni casi, questa mossa potrebbe sovrascrivere le autorizzazioni di pubblicazione di un canale riservato ai soli amministratori.
Anche sulla segretezza dell'URL dei webohook c'è da discutere. Esistono 130.989 codici pubblici su GitHub contenenti questi URL. La maggior parte include l'intero valore unico del webhook.
Perché usare i webhook per approfittare proprio di Slack? Perché questa piattaforma viene usata da molte aziende. Perché nelle discussioni potrebbero transitare importanti
informazioni su proprietà intellettuali e i file caricati potrebbero contenere dati riservati. Il guaio è che qualcuno potrebbe recuperare file e conversazioni.
I dati non possono essere esposti tramite webhook. Però un cyber criminale può concatenare i passaggi per ottenere l'accesso alle informazioni e alla messaggistica all'interno di un'area di lavoro. L'attaccante potrebbe partire proprio dai webhook su GitHub. Dovrebbe creare un'app che possa essere installata pubblicamente, e servirsi di un server Web per gestire il flusso OAuth. Sebbene Slack non richieda OAuth, è possibile usare l'API di Slack per accedere ai dati nelle aree di lavoro in cui è installata l'app non autorizzata.
Quando gli utenti tentano di scaricare l'applicazione dannosa, gli verrà chiesta l'approvazione degli OAuth impostati dagli aggressori. L'approvazione viene inviata al client OAuth, che recupera un token di accesso dal server di autorizzazione. Il token può essere utilizzato per ottenere dati fino a quando l'autorizzazione non viene revocata.
Sempre mediante l'app, si può inviare un messaggio al canale #general collegato all'URL del webhook, chiedendo l'installazione di un aggiornamento. Anche qui l'ok dell'utente fa incassare al malintenzionato un token di accesso e gli identificativi dell'utente e del suo team.
Il nocciolo di tutto è il token. Consente di accedere ai dati per conto dell'utente. La buona notizia è che questo accesso è limitato ai permessi del richiedente e all'ambito per il quale è stato approvato. La cattiva notizia è che nessuno degli utenti ha modo di accorgersi di quanto sta accadendo.
L'attacco come descritto sembra macchinoso, in realtà Graves spiega che non è affatto difficile da realizzare. È un codice abbastanza banale da scrivere per chi ha esperienza nella lettura e scrittura di codice. La parte difficile è farsi dare l'autorizzazione dalla vittima, come in tutti gli attacchi di phishing.
La migliore difesa è la diffidenza. Se appaiono messaggi che chiedono l'accesso ai file o alle funzionalità di messaggistica, meglio negarlo. Inoltre, gli amministratori dovrebbero creare una whitelist delle applicazioni autorizzate a scambiare dati con Slack, oppure rivelare le applicazioni OAuth sospette che le persone stanno aggiungendo allo spazio di lavoro.