Skimming van creditcards - de lange en bochtige weg van het falen van de toeleveringsketen

Onderzoekers van applicatiebeveiligingsbedrijf Jscrambler hebben zojuist een waarschuwend verhaal over supply chain-aanvallen...

…dat is ook een krachtige herinnering aan hoe lang aanvalsketens kunnen zijn.

Helaas, dat is lang alleen in termen van niet de tijd of, niet lang qua technische complexiteit of het aantal schakels in de keten zelf.

Acht jaar geleden…

De high-level versie van het verhaal dat door de onderzoekers is gepubliceerd, wordt eenvoudig verteld en gaat als volgt:

• Begin 2010 bood een webanalysebedrijf genaamd Cockpit een gratis webmarketing- en analyseservice aan. Talrijke e-commercesites gebruikten deze service door JavaScript-code van de servers van Cockpit te halen, waardoor code van derden als vertrouwde inhoud in hun eigen webpagina's werd opgenomen.
• In december 2014 stopte Cockpit met zijn dienst. Gebruikers werden gewaarschuwd dat de service offline zou gaan en dat alle JavaScript-code die ze uit Cockpit hadden geïmporteerd, niet meer zou werken.
• In november 2021 kochten cybercriminelen de oude domeinnaam van Cockpit op. Tot wat we alleen maar kunnen aannemen was een mengeling van verrassing en verrukking, de boeven ontdekten blijkbaar dat ten minste 40 e-commercesites hun webpagina's nog steeds niet hadden bijgewerkt om alle links naar Cockpit te verwijderen, en nog steeds naar huis belden en JavaScript accepteerden code die in de aanbieding was.

Je kunt zien waar dit verhaal naartoe gaat.

Alle ongelukkige voormalige Cockpit-gebruikers die hun logboeken blijkbaar niet goed (of misschien zelfs helemaal niet) hadden gecontroleerd sinds eind 2014, merkten niet dat ze nog steeds probeerden code te laden die niet werkte.

We vermoeden dat die bedrijven wel merkten dat ze geen analysegegevens meer van Cockpit kregen, maar dat ze, omdat ze verwachtten dat de datafeed niet meer zou werken, ervan uitgingen dat het einde van de gegevens het einde betekende van hun cyberbeveiligingszorgen met betrekking tot aan de service en de domeinnaam.

Injectie en bewaking

Volgens Jscrambler, de boeven die het ter ziele gegane domein overnamen en zo een directe route verwierven om malware in te voegen in webpagina's die dat nu nieuw leven ingeblazen domein nog vertrouwden en gebruikten...

... begon precies dat te doen, ongeautoriseerd, kwaadaardig JavaScript injecteren in een breed scala aan e-commercesites.

Dit maakte twee belangrijke soorten aanvallen mogelijk:

• Voeg JavaScript-code in om de inhoud van invoervelden op vooraf bepaalde webpagina's te controleren. Gegevens in input, select en textarea velden (zoals je zou verwachten in een typisch webformulier) werden geëxtraheerd, gecodeerd en geëxfiltreerd naar een reeks "call home"-servers die door de aanvallers werden beheerd.
• Voeg extra velden toe aan webformulieren op geselecteerde webpagina's. Deze truc, bekend als HTML-injectie, betekent dat oplichters pagina's kunnen ondermijnen die gebruikers al vertrouwen. Het is aannemelijk dat gebruikers worden verleid tot het invoeren van persoonlijke gegevens waar die pagina's normaal niet om zouden vragen, zoals wachtwoorden, verjaardagen, telefoonnummers of betaalkaartgegevens.

Met dit paar aanvalsvectoren tot hun beschikking, konden de boeven niet alleen alles wat u in een webformulier op een gecompromitteerde webpagina typte, overhevelen, maar ook aanvullende persoonlijk identificeerbare informatie (PII) najagen die ze normaal niet zouden kunnen achterhalen. stelen.

Door te beslissen welke JavaScript-code moet worden weergegeven op basis van de identiteit van de server die in eerste instantie om de code heeft gevraagd, konden de boeven hun malware aanpassen om verschillende soorten e-commercesites op verschillende manieren aan te vallen.

Dit soort respons op maat, dat eenvoudig te implementeren is door te kijken naar de Referer: header die wordt verzonden in de HTTP-verzoeken die door uw browser worden gegenereerd, maakt het ook moeilijk voor cybersecurity-onderzoekers om het volledige scala aan aanvals-'payloads' te bepalen die de criminelen in petto hebben.

Immers, tenzij u van tevoren de precieze lijst met servers en URL's kent waar de boeven op hun servers naar uitkijken, kunt u geen HTTP-verzoeken genereren die alle waarschijnlijke varianten van de aanval die de criminelen hebben geprogrammeerd, van zich afschudden. in het systeem.

Voor het geval je het je afvraagt, de Referer: header, wat een verkeerde spelling is van het Engelse woord "referrer", dankt zijn naam aan een typografische fout in het oorspronkelijke internet normen document.

Wat te doen?

• Controleer uw webgebaseerde toeleveringsketenlinks. Overal waar u vertrouwt op URL's die door andere mensen zijn verstrekt voor gegevens of code die u aanbiedt alsof het uw eigen URL's zijn, moet u regelmatig controleren of u ze nog kunt vertrouwen. Wacht niet tot uw eigen klanten klagen dat "iets kapot lijkt". Ten eerste betekent dit dat u volledig vertrouwt op reactieve cyberbeveiligingsmaatregelen. Ten tweede is er misschien niets voor de hand liggend voor klanten zelf om op te merken en te melden.
• Controleer uw logboeken. Als uw eigen website gebruik maakt van ingesloten HTTP-links die niet meer werken, dan is er duidelijk iets mis. Of je had die link eerder niet moeten vertrouwen, omdat het de verkeerde was, of je zou hem niet meer moeten vertrouwen, omdat hij zich niet meer gedraagt ​​zoals vroeger. Als u uw logboeken niet gaat controleren, waarom zou u ze dan in de eerste plaats verzamelen?
• Voer regelmatig testtransacties uit. Handhaaf een regelmatige en frequente testprocedure die realistisch gezien dezelfde online transactiereeksen doorloopt die u verwacht dat uw klanten volgen, en volg alle inkomende en uitgaande verzoeken nauwgezet op. Dit helpt u bij het opsporen van onverwachte downloads (bijv. uw testbrowser zuigt onbekend JavaScript aan) en onverwachte uploads (bijv. gegevens die uit de testbrowser worden geëxfiltreerd naar ongebruikelijke bestemmingen).

Als u nog steeds JavaScript koopt van een server die acht jaar geleden buiten gebruik is gesteld, vooral als u deze gebruikt in een service die PII of betalingsgegevens verwerkt, maakt u geen deel uit van de oplossing, maar maakt u deel uit van het probleem …

… dus wees alsjeblieft niet die persoon!

---

Opmerking voor Sophos-klanten. Het "gerevitaliseerde" webdomein dat hier wordt gebruikt voor JavaScript-injectie (web-cockpit DOT jp, als je je eigen logs wilt doorzoeken) wordt geblokkeerd door Sophos as PROD_SPYWARE_AND_MALWARE en SEC_MALWARE_REPOSITORY. Dit geeft aan dat bekend is dat het domein niet alleen wordt geassocieerd met malwaregerelateerde cybercriminaliteit, maar ook betrokken is bij het actief aanbieden van malwarecode.

---