Credit card skimmers are now being buried in image file metadata on e-commerce websites:
The attack is a variation that uses favicons, but with a twist. Malicious code was tracked back to a malicious domain, cddn[.]site, that is loaded via a favicon file. While the code itself did not appear malicious at first glance, a field called "Copyright" in the metadata field loaded the card skimmer using an[sid] header tag, specifically via an HTML onerror event, which triggers if an error occurs when loading an external resource.
When loaded onto a compromised website, the JavaScript grabs input from fields used to submit payment information, including names, billing addresses, and card details.
The Magecart group obfuscated the code within the EXIF[*] data, and unusually, will not simply send stolen data via text to a command-and-control server (C2). Instead, data collected is also sent as image files via POST requests.
"The threat actors probably decided to stick with the image theme to also conceal the exfiltrated data via the favicon.ico file," the researchers say.
It is thought that Magecart Group 9 is to blame, due to links made by security researcher @AffableKraut to domains and registrars also hosting scripts using the EXIF technique.
[*] EXIF: Exchangeable image file format.
(Score: 3, Insightful) by Anonymous Coward on Monday June 29 2020, @07:13PM (7 children)
(from https://blog.malwarebytes.com/threat-analysis/2020/06/web-skimmer-hides-within-exif-metadata-exfiltrates-credit-cards-via-image-files/ [malwarebytes.com] )
Merchants should STOP using JavaScript on the pages taking credit card data. The "aesthetic reasons" are no reason at all to put users in danger. Two decades spent on stupid act "securing" the unsecurable-by-design should produce the obvious conclusion: STOP. Just STOP.
Providing such fertile ground for criminals to use, should be treated by the courts as aiding and abetting, or at least, wilful negligence. Then the "unsolvable" problem will become solved overnight.
(Score: 4, Insightful) by EvilSS on Monday June 29 2020, @07:21PM (1 child)
(Score: 0) by Anonymous Coward on Wednesday July 01 2020, @10:30AM
I hate sites like that. It can take 15 checkout attempts to figure out which sites and frames to allow through the browser's ad/javascript blockers.
(Score: 1, Touché) by Anonymous Coward on Monday June 29 2020, @09:04PM (4 children)
So the merchants stop using javascript, that doesn't affect the javascript inserted into their page by some third party. It would only help users who use their site with javascript disabled ... which if they're only changing the final order page - and still use javascript throughout the store front and cart management pages - will be almost no one.
Maybe merchants shouldn't have injection vulnerabilities in their secure pages?
(Score: 0) by Anonymous Coward on Monday June 29 2020, @11:50PM (3 children)
A secure page should FORCE JavaScript to be disabled. It is not like everyone and their goat aren't adding new tags and behaviors to HTML's "living standard" every week; add a <meta kill_scripts_with_fire> to be used in secure pages' headers and be done with it. Surely more realistic than this:
Yeah, just like they should not have had those the previous 20+ years. It's dead, Jim.
https://en.wikipedia.org/wiki/Flogging_a_dead_horse [wikipedia.org]
(Score: 0) by Anonymous Coward on Tuesday June 30 2020, @12:24AM (2 children)
https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP [mozilla.org]
They can disable all javascript on their page already regardless of source.
(Score: 0) by Anonymous Coward on Tuesday June 30 2020, @02:55AM (1 child)
Sounds like we have a volunteer to take calls from my Mom when her webs pages look funny.
(Score: 0) by Anonymous Coward on Tuesday June 30 2020, @05:10AM
CSP is a tool for websites themselves, dummy.