Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 17 submissions in the queue.
posted by Fnord666 on Monday June 29 2020, @05:19PM   Printer-friendly
from the watch-what-you-look-at dept.

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.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Insightful) by Anonymous Coward on Monday June 29 2020, @07:13PM (7 children)

    by Anonymous Coward on Monday June 29 2020, @07:13PM (#1014221)

    Upon closer inspection we found that extraneous code had been appended to a legitimate script hosted by the merchant.

    (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.

    Starting Score:    0  points
    Moderation   +3  
       Insightful=3, Total=3
    Extra 'Insightful' Modifier   0  

    Total Score:   3  
  • (Score: 4, Insightful) by EvilSS on Monday June 29 2020, @07:21PM (1 child)

    by EvilSS (1456) Subscriber Badge on Monday June 29 2020, @07:21PM (#1014223)
    Better yet, merchants stops collecting card data, period. Do like Paypal, redirect to the payment processor, enter the info there, and send back a one-time use token to the merchant, who can use that token to complete the transaction. Yes, it means the payment processor is a bigger target, but they already are anyway since they have CC and PID info for lots of transactions in their systems and most have better in-house security than small online merchants.
    • (Score: 0) by Anonymous Coward on Wednesday July 01 2020, @10:30AM

      by Anonymous Coward on Wednesday July 01 2020, @10:30AM (#1014931)

      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)

    by Anonymous Coward on Monday June 29 2020, @09:04PM (#1014248)

    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)

      by Anonymous Coward on Monday June 29 2020, @11:50PM (#1014308)

      It would only help users who use their site with javascript disabled

      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:

      Maybe merchants shouldn't have injection vulnerabilities in their secure pages?

      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)

        by Anonymous Coward on Tuesday June 30 2020, @12:24AM (#1014315)

        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)

          by Anonymous Coward on Tuesday June 30 2020, @02:55AM (#1014347)

          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

            by Anonymous Coward on Tuesday June 30 2020, @05:10AM (#1014405)

            CSP is a tool for websites themselves, dummy.