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: 5, Interesting) by bob_super on Wednesday November 21 2018, @11:52PM (7 children)

    by bob_super (1357) on Wednesday November 21 2018, @11:52PM (#764992)

    I just want my bank to generate a unique 2^n-bit code (n>8) to send to a vendor to authenticate one transaction, for a given amount, between me and a designated party.
    Go to the bank's website, tell them who should get how much, copy-paste the code into the vendor's website. The code only works for that transaction to that website's bank, per some key they provide, and the vendor gets my address from the bank. Once the transaction is over, the code is useless.
    This way, anyone who gets a bunch of codes from a random database can't use them to get anything. Yes, it would still allow shenanigans via hijacking the vendor's page to change the codes, but that's a lot easier to notice than obfuscated scripts, obviously...

    Of course, that would put the responsibility on the banks, who seem oddly okay with the current frauds instead.

    Starting Score:    1  point
    Moderation   +3  
       Interesting=3, Total=3
    Extra 'Interesting' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   5  
  • (Score: 1, Insightful) by Anonymous Coward on Thursday November 22 2018, @12:16AM (5 children)

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

    So basically you wanna use bitcoin with chargebacks?

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

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

      Not even close.
      Using bitcoin would still require putting my shipping info on the vulnerable front-end.

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

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

  • (Score: 4, Interesting) by edIII on Thursday November 22 2018, @12:34AM

    by edIII (791) on Thursday November 22 2018, @12:34AM (#765005)

    The stupidity was handling the payment processing yourself. As much as possible, the payment processor should be storing the info. The few companies that I've worked with use an API to perform an initial transaction and then receive a storage ID for that payment type. With that payment processor you can handle scheduled and repeat payments, just by specifying that storage ID and payment amounts. In the local databases there was limited customer information, and none of it was related to payments beyond that storage ID. Didn't even store SOS since we didn't need it.

    I'm for literally having VISA/Mastercard run portals like PayPal. Redirect them to their site, and be 100% reliant on their security. After payment, a redirect back to the e-commerce site. That way the worst that happens in some thieves know what you ordered from the company, and could maliciously order 200 widgets to your front door.

    Let Visa/Mastercard deal with all that bullshit, and let e-commerce sites concentrate on their core business. That isn't payment processing obviously.

    --
    Technically, lunchtime is at any moment. It's just a wave function.