Kreditkortskimning – den långa och slingrande vägen för fel i leveranskedjan

Forskare vid applikationssäkerhetsföretaget Jscrambler har just publicerat en varningssaga om attacker i leveranskedjan...

…det är också en kraftfull påminnelse om hur långa attackkedjor kan vara.

Tyvärr är det lång bara när det gäller tid, inte lång när det gäller teknisk komplexitet eller antalet länkar i själva kedjan.

För åtta år sedan…

Den högnivåversion av berättelsen som publicerats av forskarna är helt enkelt berättad, och den går så här:

• I början av 2010-talet erbjöd ett webbanalysföretag som heter Cockpit en gratis webbmarknadsföring och analystjänst. Många e-handelssajter använde den här tjänsten genom att hämta JavaScript-kod från Cockpits servrar, och på så sätt införlivade tredje parts kod på sina egna webbsidor som pålitligt innehåll.
• I december 2014 lade Cockpit ner sin tjänst. Användare varnades för att tjänsten skulle gå offline och att all JavaScript-kod de importerade från Cockpit skulle sluta fungera.
• I november 2021 köpte cyberbrottslingar upp Cockpits gamla domännamn. Till vad vi bara kan anta var en blandning av överraskning och förtjusning, fann skurkarna tydligen att minst 40 e-handelssajter fortfarande inte hade uppdaterat sina webbsidor för att ta bort några länkar till Cockpit och fortfarande ringde hem och accepterade JavaScript. kod som erbjöds.

Du kan se vart den här historien är på väg.

Alla olyckliga före detta Cockpit-användare som uppenbarligen inte hade kontrollerat sina loggar ordentligt (eller kanske till och med alls) sedan slutet av 2014, märkte inte att de fortfarande försökte ladda kod som inte fungerade.

Vi gissar att dessa företag märkte att de inte fick mer analysdata från Cockpit, men att eftersom de förväntade sig att dataflödet skulle sluta fungera, antog de att slutet på data var slutet på deras cybersäkerhetsproblem. till tjänsten och dess domännamn.

Injektion och övervakning

Enligt Jscrambler, skurkarna som tog över den nedlagda domänen, och som därmed skaffade sig en direkt väg för att infoga skadlig programvara på alla webbsidor som fortfarande litade på och använde den nu återupplivade domänen...

…började göra precis det, injicera otillåten, skadlig JavaScript i ett brett utbud av e-handelswebbplatser.

Detta möjliggjorde två huvudtyper av attack:

• Infoga JavaScript-kod för att övervaka innehållet i inmatningsfält på förutbestämda webbsidor. Data i input, select och textarea fält (som du kan förvänta dig i ett typiskt webbformulär) extraherades, kodades och exfiltrerades till en rad "ring hem"-servrar som drivs av angriparna.
• Infoga ytterligare fält i webbformulär på utvalda webbsidor. Detta trick, känt som HTML -injektion, betyder att skurkar kan undergräva sidor som användare redan litar på. Användare kan med all sannolikhet lockas att ange personlig information som dessa sidor normalt inte skulle begära, såsom lösenord, födelsedagar, telefonnummer eller betalkortsuppgifter.

Med detta par attackvektorer till sitt förfogande kunde skurkarna inte bara ta bort det du skrev i ett webbformulär på en komprometterad webbsida, utan också gå efter ytterligare personligt identifierbar information (PII) som de normalt inte skulle kunna stjäla.

Genom att bestämma vilken JavaScript-kod som skulle visas baserat på identiteten på servern som begärde koden i första hand, kunde skurkarna skräddarsy sin skadliga programvara för att attackera olika typer av e-handelssajter på olika sätt.

Denna typ av skräddarsydd respons, som är lätt att implementera genom att titta på Referer: header som skickas i HTTP-förfrågningar som genereras av din webbläsare, gör det också svårt för cybersäkerhetsforskare att avgöra hela utbudet av attack-"nyttolaster" som brottslingarna har i rockärmen.

När allt kommer omkring, om du inte i förväg känner till den exakta listan över servrar och webbadresser som skurkarna letar efter på sina servrar, kommer du inte att kunna generera HTTP-förfrågningar som skakar loss alla troliga varianter av attacken som brottslingarna har programmerat in i systemet.

Om du undrar, Referer: header, som är en felstavning av det engelska ordet "referrer", får sitt namn från ett typografiskt misstag på det ursprungliga internet standarder dokument.

Vad göra?

• Granska dina webbaserade länkar i leveranskedjan. Överallt där du litar på webbadresser som tillhandahålls av andra människor för data eller kod som du tillhandahåller som om det vore din egen, måste du regelbundet och ofta kontrollera att du fortfarande kan lita på dem. Vänta inte på att dina egna kunder ska klaga på att "något ser trasigt ut". För det första betyder det att du helt och hållet litar på reaktiva cybersäkerhetsåtgärder. För det andra kanske det inte finns något självklart för kunderna själva att lägga märke till och rapportera.
• Kontrollera dina loggar. Om din egen webbplats använder sig av inbäddade HTTP-länkar som inte längre fungerar, så är något helt klart fel. Antingen borde du inte ha litat på den länken tidigare, för det var fel, eller så borde du inte lita på den längre, för den beter sig inte som den brukade. Om du inte ska kontrollera dina loggar, varför bry dig om att samla in dem i första hand?
• Utför testtransaktioner regelbundet. Upprätthåll en regelbunden och frekvent testprocedur som realistiskt går igenom samma transaktionssekvenser online som du förväntar dig att dina kunder ska följa, och spåra alla inkommande och utgående förfrågningar noggrant. Detta hjälper dig att upptäcka oväntade nedladdningar (t.ex. din testwebbläsare suger in okänt JavaScript) och oväntade uppladdningar (t.ex. data som exfiltreras från testwebbläsaren till ovanliga destinationer).

Om du fortfarande köper JavaScript från en server som togs bort för åtta år sedan, särskilt om du använder den i en tjänst som hanterar PII eller betalningsdata, är du inte en del av lösningen, du är en del av problemet …

…så snälla, var inte den personen!

---

Notera för Sophos kunder. Den "återupplivade" webbdomänen som används här för JavaScript-injektion (web-cockpit DOT jp, om du vill söka i dina egna loggar) blockeras av Sophos as PROD_SPYWARE_AND_MALWARE och SEC_MALWARE_REPOSITORY. Detta anger att domänen är känd för att inte bara vara associerad med malware-relaterad cyberkriminalitet, utan också vara involverad i att aktivt servera skadlig kod.

---