Condividere (non) è un atto di cura: in che modo le credenziali condivise lasciano campo libero alle violazioni
Sommario
Introduzione
Sia che si tratti di un portale di accesso all'online banking, di software open source o semplicemente del sistema operativo, la moderna dipendenza dalla tecnologia ha reso obbligati sia i professionisti del settore tecnologico che il pubblico in generale al codice di altre persone. L'esigenza di coerenza e praticità ci ha indotto a sfruttare funzioni come le librerie di codice, in quanto la scrittura da zero di ogni parte di codice da zero non è scalabile.
Quanto più gli ambienti diventano complessi, tanto più è importante individuare punti in cui sia possibile automatizzare e riutilizzare gli strumenti già disponibili.
Tuttavia, l'utilizzo del codice di queste librerie predefinite da parte di uno sviluppatore come base per il proprio codice crea "problemi di fiducia", ossia richiede un livello di fiducia che un professionista della sicurezza potrebbe considerare rischioso. Quanto più a fondo nel codice sorgente si nasconde una vulnerabilità, tanto più è difficile individuarla, sempre ammesso innanzitutto che si sappia cercare quell'ago nel pagliaio digitale.
Nel nostro processo di sviluppo, abbiamo incontrato un esempio di questi cosiddetti problemi di fiducia. L'utilizzo apparentemente di routine di uno dei nostri servizi esterni ha portato alla scoperta di varie opportunità di attacco grave. Dopo averne dato comunicazione al fornitore, i problemi identificati sono stati risolti. In questo post, illustreremo ciò che abbiamo trovato, spiegheremo come lo abbiamo trovato ed esamineremo le modalità secondo cui i criminali informatici potrebbero utilizzarlo a proprio vantaggio.
Diamo uno sguardo
Durante un test di ottimizzazione di routine, uno dei nostri ingegneri DevOps ha creato un nuovo container per uno strumento di test di terze parti. Ha quindi eseguito il comando molto comune: apt get update && apt get install XXXX -y.
Dopo l'immissione del comando, volevamo vedere che cosa avveniva sul nostro endpoint durante il processo di creazione. A tale scopo, abbiamo eseguito il semplice comando di elencazione dei processi ps sul nostro endpoint e ci siamo imbattuti in questa riga molto interessante:
Potevamo utilizzare le credenziali identificate per eseguire l'autenticazione a un sito contenente centinaia di build di clienti.
La presenza di una chiave non crittografata era allarmante, ma la spiegazione poteva trovarsi in un controllo utente appropriato, ad esempio se il token fosse stato per utilizzo dell'app. In questo caso, non era evidentemente così. Il nome utente fornito conteneva la stringa "default", il che non è mai un buon segno.
Abbiamo quindi deciso di andare un po' più a fondo e abbiamo provato a utilizzare le credenziali per eseguire l'autenticazione all'API, operazione che ci ha consentito effettuare query su numerose informazioni potenzialmente sensibili. Abbiamo scoperto che l'utente "default" era senza dubbio molto "default": non era dedicato per l'uso di Akamai, ma era utilizzato dall'intera base di clienti dell'applicazione.
Qualsiasi criminale, armato di questo segreto non crittografato, avrebbe potuto utilizzarlo per recuperare dati sensibili, ad esempio risultati di test interni, registrazioni video, screenshot e flussi di esecuzione di script interni, relativi alla maggior parte dei clienti dell'applicazione (Figura 1).
Fig. 1: Example of improperly accessed sensitive customer data
La straordinaria quantità di dati esposti e la caratteristica della vulnerabilità di essere in così bella vista ci hanno indotto ad andare ancora più a fondo nel codebase per vedere cos'altro si poteva trovare.
Condividere non è sempre un atto di cura
Dopo aver identificato un segreto condiviso che poteva essere utilizzato in modo gravemente improprio dall'applicazione, abbiamo deciso di cercare di individuare altri segreti del genere. Dopo alcune ricerche ben mirate all'interno del codice sorgente dell'applicazione, ci siamo imbattuti in altri tre segreti:
- Una chiave privata di Coralogix
- Una chiave API di Google
- Un token ngrok
Esaminiamo ciascuno di questi segreti e le relative potenzialità di abuso.
Coralogix: una chiave privata (molto pubblica)
Uno dei segreti che abbiamo identificato nel codebase delle nostre applicazioni è stata una chiave privata che, avendo attirato la nostra attenzione, ci ha indotto a cercare un eventuale nome utente che potesse essere collegato ad essa. Siamo riusciti a trovare un nome utente poche righe dopo la chiave, come parte di una funzione di registrazione. Abbiamo utilizzato altri indizi lasciati indietro e abbiamo scoperto che la chiave privata appartiene a un framework di registrazione Coralogix.
Le credenziali erano integrate nel codice sorgente, il che significa che erano anche condivise da clienti diversi. Ciò poteva significare un'altra potenziale perdita di dati, ma fortunatamente questo utente/criminale disponeva di privilegi minimi e gli era consentito solo scrivere messaggi di registro nel framework.
Sebbene non altrettante potente come la primitiva precedente, una primitiva di scrittura può comunque consentire l'inserimento di alcuni vettori interessanti nell'ambiente del vendor: un criminale può inserire messaggi di registro contraffatti nell'ambiente del vendor o tentare di inserire registri dannosi per eseguire attacchi, ad esempio, di tipo XSS (Cross-Site Scripting) o SQL (Structured Query Language).
Chiave API di Google
OAuth è un meccanismo di autorizzazione utilizzato da tutte le operazioni di Google. Le applicazioni e i siti possono offrire agli utenti la possibilità di accedere ad altre app e siti con il loro account Google tramite OAuth. Per abilitare questa opzione attraverso il codice, gli sviluppatori hanno bisogno di vari parametri che possono ottenere dall'account Google degli utenti, ossia google_name e google_secret.
Durante l'esplorazione del codice, abbiamo trovato un riferimento all'API Google. In genere, se vediamo una chiave "google api", non vediamo altro, ma non questa volta. Questa volta abbiamo trovato anche la chiave "google api", ovvero l'identificatore univoco google_client e (cosa più sconcertante) l'identificatore google_secret. Con tutti i tre i valori, gli autori degli attacchi informatici possono richiedere un link di autenticazione da Google come vendor. Questo link può essere utilizzato come parte di una campagna di phishing per indurre le vittime a concedere ai criminali l'autorizzazione al proprio Workspace.
Potenziale exploit di phishing
I criminali possono creare un'e-mail di phishing contenente un link a un sito identico a quello del vendor ma con una modifica fondamentale: il link per accedere con Google è il link ottenuto dal criminale utilizzando i dettagli dell'API di Google del vendor (Figura 2).
Fig. 2: Malicious Google login page appears to be legitimate
Effettuando l'accesso, la vittima concede all'autore dell'attacco l'autorizzazione al suo intero account Google Workspace. Con l'accesso a dati così sensibili come un'identità di Google, le possibilità di un malintenzionato sono enormi. L'exploit gli consentirebbe infatti di manipolare qualsiasi aspetto dell'account Google Workspace della vittima, ad esempio compromettere l'e-mail, eseguire il download di file e molto altro ancora. Queste operazioni potrebbero essere molto utili nell'ambito di un attacco di social engineering alle organizzazioni.
ngrok
Il tunneling di rete è una soluzione pressoché universale per il trasferimento sicuro dei dati, in grado di fornire a un criminale un tesoro ricco di opportunità malevole in caso di compromissione. Nell'installazione dell'applicazione compromessa, abbiamo scoperto molti parametri correlati al tunneling, tra cui una configurazione ngrok , che ci ha indotto a ulteriori indagini. Le stesse funzioni che favoriscono una migliore collaborazione tra gli sviluppatori sono esattamente ciò che le rende interessanti per un attore di minacce.
Ngrok è un servizio specializzato nella fornitura di una piattaforma per il tunneling delle informazioni attraverso i server. Ngrok semplifica notevolmente l'esposizione dei servizi a Internet, consentendo un debug più veloce e cicli di feedback di sviluppo più efficienti. Purtroppo, se un criminale prende il controllo del tunnel, questa semplicità diventa anche sua disposizione.
Richiamando un semplice comando ps, il criminale può visualizzare l'ID univoco e il token di autenticazione dell'azienda. Questo ID univoco non è modificabile e rimarrà lo stesso per tutti gli altri utilizzi dell'applicazione su altri endpoint. Gli autori degli attacchi possono utilizzare questi parametri per inviare l'ID e il token al server online di un vendor per ricevere i dettagli ngrok dell'azienda (Figura 3).
Fig. 3: Ngrok token received from the vendor’s server
Ciò significa che dopo l'accesso iniziale i criminali possono copiare l'ID univoco e il token della vittima e utilizzarli per leggere i dati inviati/ricevuti dall'applicazione della vittima (Figura 4).
Fig. 4: Example of data being read from ngrok tunnel
Conclusione
Le minacce non sono esclusivamente esterne. In effetti accettiamo volentieri alcune minacce a livello interno. Molte persone ritengono che il software open source sia il pericolo maggiore a causa della fiducia che gli concediamo, ma gli strumenti di terze parti possono rappresentare per le aziende una sfida ancora più grande rispetto all'open source.
In seguito alle nostre scoperte, abbiamo comunicato i problemi evidenziati in questo blog al vendor interessato, che ha quindi provveduto alla loro correzione. Nonostante ciò, sono sempre dietro l'angolo nuove falle della sicurezza.
Riteniamo che in questo caso, e in molti altri, la supervisione della sicurezza sia altrettanto importante quanto formare gli sviluppatori ad adottare di un approccio orientato alla sicurezza. Questi due elementi possono aiutare a garantire che i servizi gestiti non causino problemi alle aziende.