La collaborazione online è sempre più importante e non è un caso che piattaforme come Trello si moltiplichino, diventino vieppiù popolari e di conseguenza anche più appetibili per il cyber crimine che non ha perso l’occasione di mostrare i muscoli.
A gennaio del 2024 un hacker dall’evocativo soprannome di “emo” è riuscito a sottrarre i dati di 15 milioni di account e, a luglio, sono stati resi disponibili in un forum sul dark web.
La debolezza sfruttata e una breve analisi di quanto è accaduto offrono spunti per delineare un facile scenario utile a evitare simili incidenti. Un quadro che ricostruiamo grazie al supporto fornito dall’ICT Security Manager Enrico Morisi.
Indice degli argomenti
Trello e la bellezza fragile delle API
Le API, Application programming interface, sono procedure che consentono la comunicazione tra software (o client) diversi e non di rado diventano delle spine nel fianco della cyber security creando imbarazzo anche tra i colossi come Google.
Sfruttando una falla nell’API di Trello, l’attaccante è riuscito ad associare indirizzi email arbitrari ad account specifici dell’applicazione riuscendo a sottrarre i dati di 15 milioni di utenti e, contemporaneamente, aprendo le porte a possibili attacchi di phishing e mettendo a rischio i dati delle organizzazioni che si sono affidate a Trello per la gestione dei rispettivi carichi di lavoro.
Non è possibile escludere che, grazie all’ingegneria sociale, sia stato amplificato il rischio che i dati sottratti possano essere usati da altri hacker per violare ulteriori risorse delle aziende i cui dati sono stati sottratti.
Perché è successo
Abbiamo due indizi che, però, non fanno una prova. Nel 2017 Trello è stata rilevata da Atlassian per 425 milioni di dollari. Una cifra di tutto rispetto che indica quanto l’online collaboration sia importante e strategica e che, nel medesimo tempo, induce chi ha messo mano al portafoglio a rendere l’investimento profittevole nel minore tempo possibile. Non è del tutto impensabile che, nella fretta di fare crescere Trello, Atlassian abbia privilegiato degli aspetti ritenuti fondamentali tralasciandone altri (la sicurezza, per esempio).
Trello, in particolare, si integra con innumerevoli strumenti per la produttività (tra i quali Slack o Google Calendar) e offre la possibilità agli sviluppatori di creare estensioni.
Questa flessibilità – che è uno dei punti di forza della piattaforma – può avere un costo in termini di sicurezza e Trello, proprio durante lo scorso mese di aprile, ha deciso di applicare alcune restrizioni alla versione gratuita con l’intento di spingere gli utenti a scegliere i piani a pagamento.
Se ne evince che Atlassian abbia voluto fare cassa proprio per investire nella cyber security ma, ancora una volta, quando i buoi erano già scappati.
Cosa devono fare gli utenti di servizi online (non solo quelli di Trello)
Soprattutto, quando si usa una piattaforma web, occorre adottare delle precauzioni pensando al fatto che la stessa può essere violata. Per farlo ci sono diversi metodi.
Enrico Morisi non si limita a elencarli ma apporta il valore aggiunto di una riflessione più vasta:
“L’incident occorso lo scorso gennaio alla piattaforma di project management e collaboration ‘Trello’ di Atlassian, che ha comportato l’esfiltrazione di informazioni, recentemente condivise dal threat actor per pochi spiccioli, evidenzia ancora una volta, in modo esemplare, quanto sia fondamentale promuovere la cultura della sicurezza delle informazioni, che deve essere orientata a invogliare a un cambiamento consapevole del comportamento, non solo del ‘classico’ utente di servizi esposti ad attacchi di phishing ma di tutti, a partire dai professionisti dell’information security.
Elevare la security posture di API pubblicate su Internet a un livello adeguato, adottare opportune linee guida per la gestione delle identità digitali, tenere in seria considerazione le tematiche di privacy e data protection aldilà dei regolamenti vigenti e delle relative misure sanzionatorie previste, e addestrare le persone nel contrasto agli attacchi di social engineering sono tutte attività preventive che si fondano su una solida cultura della sicurezza”.
Queste sono buone norme generali di ampio respiro che non si limitano soltanto a Trello o a un singolo servizio.
Ma, continua Morisi: “Nel caso specifico, il data leak è riconducibile al fatto che è stato possibile, interrogando con processi automatici e verosimilmente supportati dall’IA, una API esposta e accessibile senza la necessità di autenticarsi, combinare indirizzi email già disponibili in preesistenti liste di centinaia di milioni di record (abbinati verosimilmente anche a password) a dati di profilo della piattaforma che, oltretutto, sembrerebbero contenere informazioni sia pubbliche sia private: riuscire ad associare un indirizzo e-mail a un nome, a un cognome e a uno username, rappresenta un risultato estremamente appetibile e che, oltre ad essere facilmente monetizzabile, può essere ampiamente sfruttato, per esempio, per sferrare attacchi di account takeover (mediante credential stuffing o brute force) spear phishing, riuscendo a far leva sul contesto (per il furto di credenziali, la somministrazione di malware, e così via) e doxxing, introducendo un significativo rischio per la privacy.
Se grazie a questi attacchi si riuscissero poi ad ottenere le credenziali per accedere alla piattaforma stessa, si aprirebbe uno scenario ancora più grave, caratterizzato, ad esempio, dall’esfiltrazione di dati estremamente sensibili, riguardanti anche progetti di aziende e organizzazioni, in corso o completati”.
Quello subito da Atlassian è un attacco che ha anche ripercussioni sulla reputazione della stessa azienda: “L’attacco subito da Atlassian potrebbe essere inquadrato nella tipologia “business logic”, nel senso che ha sfruttato un non corretto bilanciamento tra le esigenze di business – ovvero la possibilità di invitare un utente a un dato ‘workspace via e-mail – e quelle di sicurezza, in particolare con riferimento alla API esposta allo scopo. Nel complesso, un duro colpo per la società attaccata, sia in termini di ‘trust’ da parte della clientela sia per le potenziali ripercussioni in ambito economico e legale”, spiega Morisi.
Cosa dovrebbero fare le imprese
Sempre affidandoci all’esperienza di Enrico Morisi, passiamo in rassegna le tecniche e i metodi di mitigazione per le aziende e, a seguire, quelle per i singoli utenti. In entrambi i casi, le indicazioni tendono ad adattarsi a qualsiasi applicativo o servizio e non soltanto a Trello.
“Per quanto riguarda le API esposte, esistono diverse azioni di mitigazione del rischio facenti capo a standard ampiamente riconosciuti e diffusi (per esempio OWASP API Security Top 10) e, nello specifico:
- essere consapevoli della loro esistenza (asset management);
- evitare una ‘eccessiva’ esposizione dei dati;
- implementare sempre adeguati processi di autenticazione e autorizzazione, secondo i principi ‘need to know’ e ‘least privilege’ (4 dei 10 maggiori rischi individuati da OWASP riguardano proprio queste tematiche);
- cifrare i dati in transito ed eventualmente ‘at rest’ con riferimento alla loro classificazione;
- introdurre tecniche di throttling e rate limiting anche se, nel caso specifico, sono state facilmente aggirate facendo ricorso a diversi proxy server, al fine di ruotare le connessioni e mantenere costantemente attivo il processo di interrogazione della API;
- svolgere audit e security test completi e periodici;
- gestire tempestivamente eventuali vulnerabilità;
- implementare soluzioni di gestione e monitoraggio continuo del traffico al fine di individuare comportamenti anomali e procedere di conseguenza (per esempio, API gateway);
- promuovere solide pratiche per lo sviluppo sicuro del software”.
Anche gli utenti, infine, hanno il dovere specifico di agire al riparo da inutili rischi.
Cosa dovrebbero fare gli utenti
I singoli utilizzatori non sono esenti da doveri e responsabilità. Infatti, come spiega Enrico Morisi: “Anche per quanto riguarda gli utenti esistono diversi standard di riferimento (tra queste NIST Guidelines: the four-volume SP 800-63 Digital Identity Guidelines document suite e le relative utilissime FAQ e, in particolare, sarebbe opportuno osservare le seguenti raccomandazioni:
- utilizzare sempre password uniche (mai usate altrove) mai usate prima e di adeguata complessità, orientandosi possibilmente all’uso di passphrase, quindi necessariamente molto lunghe;
- utilizzare un password manager, svolgendo una selezione oculata e consapevole del prodotto, facendo estrema attenzione ai pro e contro, e seguendo, per esempio, le linee guida del NIST;
- adottare, se possibile, soluzioni predittive di Threat Intelligence e provvedere al cambio immediato della password qualora risultino evidenze di compromissione di un dato account;
- introdurre almeno un secondo fattore di autenticazione, privilegiando soluzioni di MFA “phishing resistant”, tenendo sempre ben presente che non rappresentano in alcun modo una “panacea” e potrebbero essere compromesse;
- prediligere, ove possibile, soluzioni come quelle sviluppate e promosse da FIDO Alliance e W3C, orientate all’abbandono delle “famigerate” password;
- configurare opportunamente tutti i servizi usati, in particolare con riferimento alla sicurezza;
- tenere monitorati gli account al fine di rilevare attività sospette, da gestire e segnalare tempestivamente al gestore del servizio;
- non abbassare mai la guardia nei confronti degli attacchi di social engineering, una guerra sempre più ardua, anche a causa della diffusione delle tecnologie di IA.
Un lungo elenco di soluzioni e di accorgimenti che, in definitiva, aiuta a comprendere quanto la cyber security possa essere complessa nel contesto delle numerose tecniche adottate dagli attaccanti.
Ancora prima, occorre essere consapevoli che utenti e organizzazioni hanno tanto la necessità quanto la responsabilità di proteggere account, servizi e dati.
