Skimming delle carte di credito: la lunga e tortuosa strada del fallimento della catena di approvvigionamento

I ricercatori della società di sicurezza delle applicazioni Jscrambler hanno appena pubblicato a ammonimento sugli attacchi alla catena di approvvigionamento...

…questo è anche un potente promemoria di quanto possono essere lunghe le catene di attacco.

Purtroppo, è lungo solo in termini di tempo, non molto tempo in termini di complessità tecnica o numero di anelli della catena stessa.

Otto anni fa...

La versione di alto livello della storia pubblicata dai ricercatori è semplicemente raccontata, e va così:

• All'inizio degli anni 2010, una società di analisi web chiamata Cockpit offriva un servizio gratuito di web marketing e analisi. Numerosi siti di e-commerce hanno utilizzato questo servizio prelevando il codice JavaScript dai server di Cockpit, incorporando così il codice di terze parti nelle proprie pagine Web come contenuto attendibile.
• Nel dicembre 2014, Cockpit ha interrotto il servizio. Gli utenti sono stati avvisati che il servizio sarebbe andato offline e che qualsiasi codice JavaScript importato da Cockpit avrebbe smesso di funzionare.
• Nel novembre 2021, i criminali informatici hanno acquistato il vecchio nome di dominio di Cockpit. Con quello che possiamo solo supporre fosse un misto di sorpresa e gioia, i truffatori apparentemente hanno scoperto che almeno 40 siti di e-commerce non avevano ancora aggiornato le loro pagine web per rimuovere qualsiasi collegamento a Cockpit, e stavano ancora chiamando a casa e accettando qualsiasi JavaScript codice che era in offerta.

Puoi vedere dove sta andando questa storia.

Tutti gli sfortunati ex utenti di Cockpit che apparentemente non avevano controllato correttamente i propri log (o forse addirittura per niente) dalla fine del 2014 non si sono accorti che stavano ancora tentando di caricare il codice che non funzionava.

Supponiamo che quelle aziende abbiano notato che non ricevevano più dati di analisi da Cockpit, ma poiché si aspettavano che il feed di dati smettesse di funzionare, presumessero che la fine dei dati fosse la fine dei loro problemi di sicurezza informatica relativi al servizio e al suo nome di dominio.

Iniezione e sorveglianza

Secondo Jscrambler, i truffatori che si sono impossessati del dominio defunto e che hanno così acquisito un percorso diretto per inserire malware in qualsiasi pagina web che ancora si fidava e utilizzava quel dominio ora rianimato...

…ha iniziato a fare esattamente questo, iniettando codice JavaScript dannoso e non autorizzato in un'ampia gamma di siti di e-commerce.

Ciò ha consentito due tipi principali di attacco:

• Inserisci il codice JavaScript per monitorare il contenuto dei campi di input su pagine web predeterminate. Dati in input, select ed textarea campi (come ci si aspetterebbe in un tipico modulo Web) è stato estratto, codificato ed esfiltrato in una serie di server "call home" gestiti dagli aggressori.
• Inserisci campi aggiuntivi nei moduli Web nelle pagine Web selezionate. Questo trucco, noto come Iniezione HTML, significa che i truffatori possono sovvertire le pagine di cui gli utenti già si fidano. Gli utenti possono essere credibilmente indotti a inserire dati personali che quelle pagine normalmente non richiederebbero, come password, compleanni, numeri di telefono o dettagli della carta di pagamento.

Con questa coppia di vettori di attacco a loro disposizione, i truffatori potrebbero non solo sottrarre qualsiasi cosa tu abbia digitato in un modulo web su una pagina web compromessa, ma anche cercare ulteriori informazioni di identificazione personale (PII) che normalmente non sarebbero in grado di rubare.

Decidendo quale codice JavaScript pubblicare in base all'identità del server che ha richiesto il codice in primo luogo, i truffatori sono stati in grado di adattare il loro malware per attaccare diversi tipi di siti di e-commerce in modi diversi.

Questo tipo di risposta su misura, che è facile da implementare osservando il Referer: header inviato nelle richieste HTTP generate dal tuo browser, rende anche difficile per i ricercatori della sicurezza informatica determinare l'intera gamma di "carichi utili" di attacco che i criminali hanno nella manica.

Dopotutto, a meno che tu non conosca in anticipo l'elenco preciso di server e URL che i truffatori stanno cercando sui loro server, non sarai in grado di generare richieste HTTP che scuotono tutte le probabili varianti dell'attacco che i criminali hanno programmato nel sistema.

Nel caso ve lo stiate chiedendo, il Referer: header, che è un errore di ortografia della parola inglese "referrer", prende il nome da un errore tipografico nell'originale internet standard documento.

Cosa fare?

• Esamina i collegamenti della catena di approvvigionamento basati sul Web. Ovunque ti affidi agli URL forniti da altre persone per i dati o il codice che fornisci come se fossero i tuoi, devi controllare regolarmente e frequentemente che puoi ancora fidarti di loro. Non aspettare che i tuoi stessi clienti si lamentino che "qualcosa sembra rotto". In primo luogo, ciò significa che ti affidi interamente a misure di sicurezza informatica reattive. In secondo luogo, potrebbe non esserci nulla di ovvio che i clienti stessi debbano notare e segnalare.
• Controlla i tuoi log. Se il tuo sito Web utilizza collegamenti HTTP incorporati che non funzionano più, allora c'è chiaramente qualcosa che non va. O non avresti dovuto fidarti di quel collegamento prima, perché era quello sbagliato, o non dovresti più fidarti di esso, perché non si sta comportando come prima. Se non hai intenzione di controllare i tuoi registri, perché preoccuparsi di raccoglierli in primo luogo?
• Eseguire transazioni di prova regolarmente. Mantieni una procedura di test regolare e frequente che attraversi realisticamente le stesse sequenze di transazioni online che ti aspetti che i tuoi clienti seguano e monitora attentamente tutte le richieste in entrata e in uscita. Questo ti aiuterà a individuare download imprevisti (ad es. il tuo browser di prova che risucchia JavaScript sconosciuto) e caricamenti imprevisti (ad es. i dati vengono esfiltrati dal browser di prova verso destinazioni insolite).

Se stai ancora acquistando JavaScript da un server che è stato ritirato otto anni fa, soprattutto se lo stai utilizzando in un servizio che gestisce informazioni personali o dati di pagamento, non sei parte della soluzione, sei parte del problema …

…quindi, per favore, non essere quella persona!

---

Nota per i clienti Sophos. Il dominio Web "rivitalizzato" utilizzato qui per l'iniezione di JavaScript (web-cockpit DOT jp, se si desidera cercare nei propri registri) è bloccato da Sophos as PROD_SPYWARE_AND_MALWARE ed SEC_MALWARE_REPOSITORY. Ciò denota che il dominio è noto non solo per essere associato alla criminalità informatica correlata al malware, ma anche per essere coinvolto attivamente nella pubblicazione di codice malware.

---