Stories
Slash Boxes
Comments

SoylentNews is people

posted by mrpg on Wednesday November 21 2018, @11:00PM   Printer-friendly
from the fight! dept.

Submitted via IRC for SoyCow0824

E-commerce site is infected not by one, but two card skimmers

Payment card skimming that steals consumers’ personal information from e-commerce sites has become a booming industry over the past six months, with high-profile attacks against Ticketmaster, British AirwaysNewegg, and Alex Jones’ InfoWars, to name just a few. In a sign of the times, security researcher Jérôme Segura found two competing groups going head to head with each other for control of a single vulnerable site.

The site belongs to sportswear seller Umbro Brasil, which as of Tuesday morning was infected by two rival skimmer groups. The first gang planted plaintext JavaScript on the site that caused it to send payment card information to the attackers as customers were completing a sale. The malicious JavaScript looked like this: [image]

A second gang exploited either the same or a different website vulnerability as the first. The second group then installed much more advanced JavaScript that was encoded in a way to prevent other programs from seeing what it did. This is what it looked like: [image]

The obfuscated JavaScript actively tampered with the less-sophisticated payment skimmer installed by the first gang. Specifically, it replaced the last digit of a credit card number with a randomly generated digit before being sent to the first group. As a result, there was a 90 percent chance that the number obtained by the first group would be incorrect. Because the first group used unobfuscated JavaScript, the skimmer is much more vulnerable to tampering by rivals.


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: 2, Interesting) by Anonymous Coward on Thursday November 22 2018, @12:23AM (3 children)

    by Anonymous Coward on Thursday November 22 2018, @12:23AM (#765002)

    You haven't thought about the fact that merchants are taking a risk by accepting your order. There literally is no time limit after which a credit card or ACH transaction cannot be reversed by the sending bank in the US. Go ahead and try to find a real limit, I had a transaction reversed 3 months later and fighting it would have cost more than the tx so I left it...

    So being to map a cc number to a (honest or dishonest) customer is very useful from the merchants point of view, and your purchase is cheaper because of that.

    PS. I have no idea what your shipping info has to do with anything. If you are getting something shipped you will need to put some sort of shipping info.

    Starting Score:    0  points
    Moderation   +2  
       Insightful=1, Interesting=1, Total=2
    Extra 'Interesting' Modifier   0  

    Total Score:   2  
  • (Score: 2) by bob_super on Thursday November 22 2018, @12:50AM (2 children)

    by bob_super (1357) on Thursday November 22 2018, @12:50AM (#765012)

    You don't understand the intent. I suggest replacing the whole "Who. Where. How" part of the order by a single code redeemable for information at a bank/CC provider.
    The always-exposed website only has the one-time code. The company's processing computer, ideally not the same and not as exposed to hacking, uses the code to finalize the transaction. The vendor still knows what they are sending and to whom, but they can get paid based on the code, without having to store reusable and sensitive data right where it's the most exposed.

    Ideally, they could even ignore who they ship to, by having only the shipper translate the transaction code into a delivery address, and therefore not have a physical address in the vendor's database (only a zip code for tax reasons). But there are many reasons why that's not gonna happen, as you point out.

    • (Score: 0) by Anonymous Coward on Thursday November 22 2018, @01:38AM

      by Anonymous Coward on Thursday November 22 2018, @01:38AM (#765022)

      Ideally, they could even ignore who they ship to, by having only the shipper translate the transaction code into a delivery address, and therefore not have a physical address in the vendor's database (only a zip code for tax reasons). But there are many reasons why that's not gonna happen, as you point out.

      That part could almost be done in AU. Every post office deliverable address here has a unique numeric identifier.* You could have a scheme whereby the bank encodes that identifier by the post office's public key, and sends the result to the merchant as part of the payment. The merchant puts that code on the label and the PO decrypts and delivers it.

      *You can purchase this database, and save a lot on mass mailing costs by barcoding and pre-sorting. It is not considered private information because the database doesn't contain names, only a list of physical addresses and PO codes.
       

    • (Score: 0) by Anonymous Coward on Thursday November 22 2018, @09:30AM

      by Anonymous Coward on Thursday November 22 2018, @09:30AM (#765105)

      All you have done is repeat yourself. This plan makes it easier to scam than the current system. Satoshi wasn't a genius but he easily thought of obvious stuff like this...