Cover Image

Gli hacker utilizzano Google Analytics per rubare le carte di credito

23 Giugno 2020 - Tempo di lettura: 14 minuti

Gli hacker utilizzano i server di Google e la piattaforma Google Analytics per rubare le informazioni sulle carte di credito inviate dai clienti dei negozi online.

Un nuovo metodo per bypassare la politica di sicurezza dei contenuti (CSP) utilizzando l'API di Google Analytics divulgata la scorsa settimana è già stato implementato negli attacchi Magecart in corso progettati per trovare i dati delle carte di credito da diverse decine di siti di e-commerce.

Questa nuova tattica sfrutta il fatto che i siti Web di e-commerce che utilizzano il servizio di analisi web di Google per il monitoraggio dei visitatori stanno inserendo nella whitelist i domini di Google Analytics nella loro configurazione CSP (uno standard di sicurezza utilizzato per bloccare l'esecuzione di codice non attendibile nelle app Web).

Una nuova ricerca delle società di sicurezza web Sansec e PerimeterX mostra che l'uso di CSP per prevenire attacchi di scrematura delle carte di credito è inutile sui siti che utilizzano anche Google Analytics (GA) poiché gli attori delle minacce possono usarlo per catturare i dati raccolti sui propri account.

Bypassare CSP utilizzando Google Analytics

Il 17 giugno, PerimeterX ha scoperto e dimostrato "una vulnerabilità facile da riprodurre nella funzionalità principale di CSP quando viene utilizzata per bloccare il furto di credenziali, dati personali e dati di pagamento come le carte di credito".

Invece di bloccare gli attacchi basati sull'iniezione, consentire agli script di Google Analytics avvantaggia gli aggressori in quanto possono utilizzarli per rubare dati. Questo viene fatto tramite uno script di skimmer web appositamente progettato per codificare i dati rubati e consegnarli alla dashboard GA dell'attaccante in un formato crittografato.

Gli autori degli attacchi devono solo utilizzare il proprio ID tag proprietario del modulo UA - ####### - # come "la politica CSP non può discriminare in base all'ID tag" per consentire ai propri script di abusare di GA per invio di informazioni raccolte come credenziali, dati della carta di credito e altro ancora.

"La fonte del problema è che il sistema di regole CSP non è abbastanza granulare", ha  spiegato Amir Shaked, vicepresidente della ricerca di PerimeterX.

Riconoscere e bloccare gli script progettati per abusare di questo difetto "richiede soluzioni di visibilità avanzate in grado di rilevare l'accesso e l'esfiltrazione di dati sensibili dell'utente (in questo caso l'indirizzo e-mail e la password dell'utente)".

Mentre Shaked ha utilizzato GA come esempio di attaccanti che utilizzano host autorizzati in CSP in quanto è il servizio di terze parti più comunemente autorizzato in configurazioni CSP, qualsiasi altro dominio autorizzato che viene compromesso o fornisce una gestione basata sull'account proprio come GA può essere usato come un canale di esfiltrazione.

Dei primi 3 milioni di domini Internet, solo 210.000 utilizzano CSP secondo le statistiche di PerimeterX basate su una scansione HTTPArchive del marzo 2020. 17.000 dei siti Web raggiungibili tramite tali domini stanno inserendo nella whitelist il sito google-analytics.com.

Sulla base delle statistiche fornite da BuiltWith, oltre 29 milioni di siti Web stanno attualmente utilizzando i servizi di analisi web di Google GA, con Baidu Analytics e Yandex Metrika utilizzati anche su oltre 7 milioni e 2 milioni, rispettivamente.

CSP bypassato su decine di siti da attori Magecart

Il team di ricerca sulle minacce di Sansec ha rivelato ieri che stava monitorando una campagna Magecart dal 17 marzo, con gli aggressori che abusavano di questo preciso problema per aggirare CSP su diverse decine di siti di e-commerce che utilizzano Google Analytics.

Gli attori delle minacce alla base di questa campagna hanno fatto un ulteriore passo in avanti assicurandosi che tutti i componenti della campagna stiano utilizzando i server di Google, in quanto hanno consegnato lo skimmer web delle carte di credito ai siti dei loro target tramite la piattaforma di archiviazione aperta di Google firebasestorage.googleapis.com .

"In genere, uno skimmer digitale (alias Magecart) gira su server malvagi nei paradisi fiscali e la sua posizione rivela il suo intento nefasto", ha spiegato Sansec.

"Ma quando una campagna di scrematura viene eseguita interamente su server di Google fidati, pochissimi sistemi di sicurezza la segnalano come sospetta. E, soprattutto, le contromisure popolari come Content-Security-Policy (CSP) non funzionano quando un amministratore del sito si fida di Google."

Il caricatore utilizzato dagli aggressori per iniettare il loro skimmer web ha più livelli di offuscamento e viene utilizzato per caricare un account GA controllato dall'aggressore all'interno di un iFrame temporaneo.

Una volta caricato, lo skimmer monitorerà il sito compromesso per l'input dell'utente e raccoglierà tutte le informazioni sulla carta di credito immesse, le crittograferà e le invierà automaticamente alla dashboard GA dei master.

Gli aggressori possono quindi raccogliere i dati della carta di credito rubati dalla loro dashboard gratuita di Google Analytics e decrittografarli utilizzando una chiave di crittografia XOR.

Come ha scoperto anche Sansec, se i clienti del negozio online compromesso aprissero gli Strumenti per gli sviluppatori dei loro browser, verrebbero contrassegnati e lo skimmer si disabiliterebbe automaticamente.

"Tutto è consentito per impostazione predefinita. CSP è stato inventato per limitare l'esecuzione di codice non attendibile. Ma poiché praticamente tutti si fidano di Google, il modello è difettoso", ha dichiarato il CEO e fondatore di Sansec  Willem de Groot.

Sulla base di questi risultati, CSP è lungi dall'essere infallibile contro gli attacchi alle app Web basati sull'iniezione come Magecart se gli aggressori trovano un modo per sfruttare un dominio / servizio già autorizzato per esfiltrare le informazioni.

"Una possibile soluzione verrebbe dagli URL adattivi, aggiungendo l'ID come parte dell'URL o sottodominio per consentire agli amministratori di impostare regole CSP che limitano l'esfiltrazione dei dati ad altri account", ha concluso Shaked.

"Una direzione futura più granulare per il rafforzamento della direzione del CSP da considerare come parte dello standard CSP è l'applicazione del proxy XHR. Ciò creerà essenzialmente un WAF sul lato client in grado di applicare una politica su cui è consentito trasmettere specifici campi di dati."

intopic.it