Ricordate Magecart?
Nel novembre dello scorso anno, ricercatori di sicurezza hanno scoperto che il malware infame, noto per la raccolta dati della carta di credito da forme checkout, [wplinkpreview url =”https://sensorstechforum.com/sites-magecart-malware-reinfected/”]potrebbe ri-infettare anche dopo clean-up.
Ora, Magecart è attiva ancora una volta nelle campagne noti in cui 277 siti e-commerce sono stati infettati in attacchi supply chain. Che cosa significa questo?
Nuove campagne Magecart Rilevato
I ricercatori di sicurezza da RiskIQ e Trend Micro sono imbattuto in un nuovo sottogruppo conosciuto come Magecart Gruppo 12 che sta infettando siti web mirati con l'inserimento del codice di scrematura in una terza parte libreria JavaScript. Questa tecnica carica il codice dannoso in tutti i siti web che utilizzano la biblioteca.
Ulteriori ricerche in queste attività ha rivelato che il codice di scrematura non è stato iniettato direttamente nei siti web di e-commerce, ma ad un terzo libreria JavaScript da Adverline, una società di pubblicità online francese, che abbiamo prontamente contattato. Adverline ha gestito l'incidente e ha immediatamente effettuato le operazioni di bonifica necessarie nel rapporto con il CERT La Poste, detto i ricercatori Trend Micro nella loro relazione.
ricercatori RiskIQ sono stati anche il monitoraggio da vicino il gruppo Magecart. Apparentemente, Gruppo 12 creato la sua infrastruttura nel settembre dello scorso anno, domini sono stati registrati, I certificati SSL sono stati istituiti attraverso LetsEncrypt, e il backend di scrematura è stata installata. Gli hacker utilizzano anche un piccolo frammento con un URL codificato base64 per la risorsa che viene decodificato in fase di esecuzione e iniettato nella pagina, rapporto evidenzia di RiskIQ.
Il gruppo è riuscito a compromettere siti web mirati attraverso Adverline alla fine del 2018.
Va notato che il codice di scrematura del Magecart Gruppo 12 è leggermente diverso, con "un tocco interessante”- si protegge da deobfuscation e analisi eseguendo un controllo di integrità su se stessa.
Per quanto riguarda lo script di iniezione effettiva, arriva in due fasi, entrambi progettati per eseguire un controllo autonomo dell'integrità. Ecco come le due fasi si svolgono, come ha spiegato by RiskIQ:
– Tutta la prima fase viene eseguita come una funzione, che è definita globalmente (questo è importante)
– Il secondo stadio è codificato e riempito con dati spazzatura, cui è scritto in un nuovo oggetto div
– Questi dati secondo stadio viene poi unpadded, decodificato, ed eventualmente eseguiti
– Il codice eseguito afferra un riferimento ad essa (che è stato istituito globalmente) ed è sottoposto a una funzione di hashing che è l'implementazione di JavaScript hashCode di Java.
– Se il controllo convalida viene eseguita la fase successiva.
Per fortuna, Adverline ha già risolto il problema rimuovendo il codice maligno dalla libreria JavaScript colpite.