Kredittkortskimming – den lange og kronglete veien med feil i forsyningskjeden

Forskere ved applikasjonssikkerhetsselskapet Jscrambler har nettopp publisert en advarende historie om forsyningskjedeangrep...

…det er også en kraftig påminnelse om hvor lange angrepskjeder kan være.

Dessverre er det lenge bare i form av tid, ikke lenge når det gjelder teknisk kompleksitet eller antall ledd i selve kjeden.

For åtte år siden…

Høynivåversjonen av historien publisert av forskerne er enkelt fortalt, og den går slik:

• På begynnelsen av 2010-tallet tilbød et nettanalyseselskap kalt Cockpit en gratis nettmarkedsførings- og analysetjeneste. Tallrike e-handelssider brukte denne tjenesten ved å hente JavaScript-kode fra Cockpits servere, og inkorporerte dermed tredjepartskode i sine egne nettsider som pålitelig innhold.
• I desember 2014 la Cockpit ned tjenesten. Brukere ble advart om at tjenesten ville gå offline, og at eventuell JavaScript-kode de importerte fra Cockpit ville slutte å fungere.
• I november 2021 kjøpte nettkriminelle opp Cockpits gamle domenenavn. Til det vi bare kan anta var en blanding av overraskelse og glede, fant skurkene tilsynelatende ut at minst 40 e-handelssider fortsatt ikke hadde oppdatert nettsidene sine for å fjerne koblinger til Cockpit, og fortsatt ringte hjem og godtok JavaScript. kode som ble tilbudt.

Du kan se hvor denne historien går.

Eventuelle ulykkelige tidligere Cockpit-brukere som tilsynelatende ikke hadde sjekket loggene sine ordentlig (eller kanskje til og med i det hele tatt) siden slutten av 2014, la ikke merke til at de fortsatt prøvde å laste inn kode som ikke fungerte.

Vi tipper at disse virksomhetene la merke til at de ikke fikk flere analysedata fra Cockpit, men at fordi de forventet at datastrømmen skulle slutte å fungere, antok de at slutten av dataene var slutten på deres cybersikkerhetsbekymringer. til tjenesten og dens domenenavn.

Injeksjon og overvåking

Ifølge Jscrambler, skurkene som tok over det nedlagte domenet, og som dermed skaffet seg en direkte rute for å sette inn skadelig programvare på alle nettsider som fortsatt stolte på og brukte det nå gjenopplivede domenet ...

…begynte å gjøre akkurat det ved å injisere uautorisert, ondsinnet JavaScript i et bredt spekter av e-handelssider.

Dette muliggjorde to hovedtyper av angrep:

• Sett inn JavaScript-kode for å overvåke innholdet i inndatafeltene på forhåndsbestemte nettsider. Data i input, select og textarea felt (slik som du forventer i et typisk nettskjema) ble trukket ut, kodet og eksfiltrert til en rekke "ring hjem"-servere drevet av angriperne.
• Sett inn flere felt i nettskjemaer på utvalgte nettsider. Dette trikset, kjent som HTML -injeksjon, betyr at skurker kan undergrave sider som brukere allerede stoler på. Brukere kan troverdig bli lokket til å skrive inn personlige data som disse sidene vanligvis ikke ville be om, for eksempel passord, bursdager, telefonnumre eller betalingskortdetaljer.

Med dette paret av angrepsvektorer til rådighet, kunne skurkene ikke bare suge av det du skrev inn i et nettskjema på en kompromittert nettside, men også gå etter ytterligere personlig identifiserbar informasjon (PII) som de normalt ikke ville være i stand til å stjele.

Ved å bestemme hvilken JavaScript-kode som skulle vises basert på identiteten til serveren som ba om koden i utgangspunktet, var skurkene i stand til å skreddersy skadevare for å angripe ulike typer e-handelssider på forskjellige måter.

Denne typen skreddersydde respons, som er enkel å implementere ved å se på Referer: header sendt i HTTP-forespørslene generert av nettleseren din, gjør det også vanskelig for cybersikkerhetsforskere å bestemme hele spekteret av angreps-"nyttelaster" som kriminelle har i ermene.

Tross alt, med mindre du på forhånd vet den nøyaktige listen over servere og URL-er som skurkene ser etter på serverne deres, vil du ikke kunne generere HTTP-forespørsler som rister løs alle sannsynlige varianter av angrepet som de kriminelle har programmert inn i systemet.

I tilfelle du lurer på Referer: header, som er en feilstaving av det engelske ordet "referrer", får navnet sitt fra en typografisk feil på det originale internett standarder dokument.

Hva gjør jeg?

• Se gjennom dine nettbaserte forsyningskjedekoblinger. Hvor du er avhengig av nettadresser levert av andre for data eller kode som du serverer som om det var din egen, må du sjekke regelmessig og ofte at du fortsatt kan stole på dem. Ikke vent på at dine egne kunder skal klage over at "noe ser ødelagt ut". For det første betyr det at du er helt avhengig av reaktive cybersikkerhetstiltak. For det andre er det kanskje ikke noe åpenbart for kundene selv å legge merke til og rapportere.
• Sjekk loggene dine. Hvis ditt eget nettsted bruker innebygde HTTP-lenker som ikke lenger fungerer, er det helt klart noe galt. Enten burde du ikke stole på den koblingen før, fordi den var feil, eller så burde du ikke stole på den lenger, fordi den ikke oppfører seg som den pleide. Hvis du ikke skal sjekke loggene dine, hvorfor bry deg med å samle dem i utgangspunktet?
• Utfør testtransaksjoner regelmessig. Oppretthold en regelmessig og hyppig testprosedyre som realistisk går gjennom de samme online transaksjonssekvensene som du forventer at kundene dine skal følge, og spor alle innkommende og utgående forespørsler nøye. Dette vil hjelpe deg med å oppdage uventede nedlastinger (f.eks. testnettleseren din suger inn ukjent JavaScript) og uventede opplastinger (f.eks. data som eksfiltreres fra testnettleseren til uvanlige destinasjoner).

Hvis du fortsatt henter JavaScript fra en server som ble trukket tilbake for åtte år siden, spesielt hvis du bruker den i en tjeneste som håndterer PII eller betalingsdata, er du ikke en del av løsningen, du er en del av problemet …

...så vær så snill, ikke vær den personen!

---

Merknad for Sophos-kunder. Det "revitaliserte" nettdomenet som brukes her for JavaScript-injeksjon (web-cockpit DOT jp, hvis du ønsker å søke i dine egne logger) er blokkert av Sophos as PROD_SPYWARE_AND_MALWARE og SEC_MALWARE_REPOSITORY. Dette angir at domenet er kjent ikke bare for å være assosiert med malware-relatert nettkriminalitet, men også for å være involvert i aktivt servering av malware-kode.

---