Kreditkortskimming – den lange og snoede vej med forsyningskædesvigt

Forskere hos applikationssikkerhedsfirmaet Jscrambler har netop offentliggjort en Advarsel om forsyningskædeangreb...

…det er også en stærk påmindelse om, hvor lange angrebskæder kan være.

Desværre er det lang blot i form af tid, ikke lang med hensyn til teknisk kompleksitet eller antallet af led i selve kæden.

For otte år siden…

Højniveauversionen af ​​historien udgivet af forskerne er ganske enkelt fortalt, og den lyder sådan her:

• I begyndelsen af ​​2010'erne tilbød et webanalysefirma ved navn Cockpit en gratis webmarketing- og analysetjeneste. Adskillige e-handelswebsteder brugte denne tjeneste ved at hente JavaScript-kode fra Cockpits servere og inkorporerede således tredjepartskode på deres egne websider som pålideligt indhold.
• I december 2014 lukkede Cockpit sin tjeneste. Brugere blev advaret om, at tjenesten ville gå offline, og at enhver JavaScript-kode, de importerede fra Cockpit, ville holde op med at fungere.
• I november 2021 købte cyberkriminelle Cockpits gamle domænenavn. Til hvad vi kun kan antage var en blanding af overraskelse og glæde, fandt skurkene tilsyneladende ud af, at mindst 40 e-handelswebsteder stadig ikke havde opdateret deres websider for at fjerne links til Cockpit, og stadig ringede hjem og accepterede JavaScript. kode, der var på tilbud.

Du kan se, hvor denne historie er på vej hen.

Alle ulykkelige tidligere Cockpit-brugere, der tilsyneladende ikke havde tjekket deres logs ordentligt (eller måske endda overhovedet) siden slutningen af ​​2014, kunne ikke bemærke, at de stadig forsøgte at indlæse kode, der ikke virkede.

Vi gætter på, at disse virksomheder bemærkede, at de ikke fik flere analysedata fra Cockpit, men fordi de forventede, at datafeedet ville holde op med at virke, antog de, at slutningen af ​​dataene var slutningen på deres bekymringer vedrørende cybersikkerhed. til tjenesten og dens domænenavn.

Injektion og overvågning

Ifølge Jscrambler, de skurke, der overtog det hedengangne ​​domæne, og som dermed fik en direkte rute til at indsætte malware på alle websider, der stadig stolede på og brugte det nu genoplivede domæne...

…begyndte at gøre præcis det ved at injicere uautoriseret, ondsindet JavaScript i en lang række e-handelswebsteder.

Dette muliggjorde to hovedtyper af angreb:

• Indsæt JavaScript-kode for at overvåge indholdet af inputfelter på forudbestemte websider. Data i input, select , textarea felter (som du ville forvente i en typisk webformular) blev udtrukket, kodet og eksfiltreret til en række "ring hjem"-servere drevet af angriberne.
• Indsæt yderligere felter i webformularer på udvalgte websider. Dette trick, kendt som HTML -indsprøjtning, betyder, at skurke kan undergrave sider, som brugerne allerede har tillid til. Brugere kan troværdigt blive lokket til at indtaste personlige data, som disse sider normalt ikke ville bede om, såsom adgangskoder, fødselsdage, telefonnumre eller betalingskortoplysninger.

Med dette par angrebsvektorer til deres rådighed, kunne skurkene ikke blot fjerne alt, hvad du skrev i en webformular på en kompromitteret webside, men også gå efter yderligere personligt identificerbar information (PII), som de normalt ikke ville være i stand til at stjæle.

Ved at beslutte, hvilken JavaScript-kode der skulle vises baseret på identiteten af ​​den server, der anmodede om koden i første omgang, var skurkene i stand til at skræddersy deres malware til at angribe forskellige typer e-handelswebsteder på forskellige måder.

Denne form for skræddersyet respons, som er nem at implementere ved at se på Referer: header sendt i de HTTP-anmodninger, der genereres af din browser, gør det også svært for cybersikkerhedsforskere at bestemme hele rækken af ​​angrebs-"nyttelast", som de kriminelle har i ærmet.

Når alt kommer til alt, medmindre du på forhånd kender den præcise liste over servere og URL'er, som skurkene leder efter på deres servere, vil du ikke være i stand til at generere HTTP-anmodninger, der ryster alle sandsynlige varianter af angrebet, som de kriminelle har programmeret løs. ind i systemet.

Hvis du undrer dig, er det Referer: header, som er en forkert stavning af det engelske ord "referrer", får sit navn fra en typografisk fejl på det originale internet standarder dokument.

Hvad skal jeg gøre?

• Gennemgå dine webbaserede forsyningskædelinks. Hvor du er afhængig af URL'er leveret af andre personer til data eller kode, som du serverer, som om det var din egen, skal du jævnligt og ofte kontrollere, at du stadig kan stole på dem. Vent ikke på, at dine egne kunder klager over, at "noget ser gået i stykker". For det første betyder det, at du udelukkende er afhængig af reaktive cybersikkerhedsforanstaltninger. For det andet er der måske ikke noget oplagt for kunderne selv at lægge mærke til og rapportere.
• Tjek dine logfiler. Hvis din egen hjemmeside gør brug af indlejrede HTTP-links, der ikke længere virker, så er der tydeligvis noget galt. Enten skulle du ikke have stolet på det link før, fordi det var det forkerte, eller også skulle du ikke stole på det længere, fordi det ikke opfører sig, som det plejer. Hvis du ikke har tænkt dig at tjekke dine logfiler, hvorfor så genere at samle dem i første omgang?
• Udfør testtransaktioner regelmæssigt. Oprethold en regelmæssig og hyppig testprocedure, der realistisk gennemgår de samme online transaktionssekvenser, som du forventer, at dine kunder følger, og spor alle indgående og udgående anmodninger tæt. Dette vil hjælpe dig med at opdage uventede downloads (f.eks. din testbrowser suger ukendt JavaScript ind) og uventede uploads (f.eks. data, der eksfiltreres fra testbrowseren til usædvanlige destinationer).

Hvis du stadig henter JavaScript fra en server, der blev pensioneret for otte år siden, især hvis du bruger den i en tjeneste, der håndterer PII eller betalingsdata, er du ikke en del af løsningen, du er en del af problemet …

…så vær venlig ikke at være den person!

---

Bemærkning til Sophos-kunder. Det "revitaliserede" webdomæne, der bruges her til JavaScript-injektion (web-cockpit DOT jp, hvis du vil søge i dine egne logfiler) er blokeret af Sophos as PROD_SPYWARE_AND_MALWARE , SEC_MALWARE_REPOSITORY. Dette angiver, at domænet er kendt for ikke kun at være forbundet med malware-relateret cyberkriminalitet, men også for at være involveret i aktiv servering af malware-kode.

---