Card Testing Attacks

[CantonJester]

Hello, Brian! Last year my client's WooCommerce site was hit by a credit card testing attack. So, I added reCaptcha to the checkout page and tightened some things in WordFence. Their site was hit again with another cc testing attack late last week. The Captcha plugin, as best as I can tell, works, so I've no idea how they managed to execute the script after the Captcha test is satisfied, but 1674 orders were placed by the same IP within 60 minutes. That's 27.9 attempts per minute, or one attempt every 2.15 seconds. My guess is they're using some type of Python / Selenium based script.

I'm thinking of adding your plugin to my client's website, because once an attacker's script clicks the 'Place Order' button beyond twice inside of 60 seconds, the order will stop processing, correct? That tells me once the hacker revisits his work, he'll move on to easier prey once he realizes his unsatisfactory results.

Is that the gist of how your plugin works? Are you hearing success stories from the people who have utilized it?

Thanks for your time,

Keith Robideau

[BrianHenryIE]

That is correct about how it works.

I do not have success stories because it's not recording much. With debug logging enabled, it can be seen how the plugin is counting and stopping orders. But it stops things before the order is created, so it's not obvious in most cases that it has even taken effect.

More importantly, I've never heard anyone say they had this plugin installed and they then had a card-attack.

That said, there is room to improve. I think I should add a rate limit on similar carts – I think the typical card attack is adding the same product(s) to the cart and placing the same order each time.

If you want success stories and you are a developer, I would change the point where the rate-limiting happens from currently the AJAX action where clicking the Place Order button happens to the process payment hooks and I would preserve the newly created order objects and set a new custom status of "rate-limited" and then add an admin notice and email to inform the site owner what has happened.

Additionally, if the plugin were to allow the orders to be created, the metadata could be gathered, sent to me, and used to determine more rules for preventing the problem.

How much did the card attack cost the company?

[CantonJester]

Thank you for taking the time to reply! A rate-limited warning message would be fantastic. I only know there were 1674 fraudulent attempts. The last attempt was saved in the order queue, however. How much it costs the company will depend on what Heartland is willing to eat, I suppose. I will say that Heartland (the payment gateway company that uses the ‘Secure Submit’ plugin (subsidiary of Global Payments)) has been helpful. Their development team wants to install a security plugin, OpenPath to monitor the transactions on the site. Actually, they’re willing to pay the fee for Vaccaro’s to utilize the plugin. What’s odd though is the OpenPath plugin hasn’t been updated in 18 months and is behind on the past three major WP releases (not to mention WooCommerce itself, come to think of it). That may be why when I attempted to create an account on OpenPath’s website, I never received an email confirmation code to complete registration. So I’m essentially at a crossroads. Vaccaro’s is a mom & pop Italian pastry shop with three locations in Maryland, and they have a pretty loyal customer base. They’ve used Heartland for at least 20 years (and have been using their Point of Sale devices in their locations prior to utilizing their ‘SecureSubmit’ plugin)….But if Heartland’s recommendation is to install a plugin that may very well be abandoned? Ouch. To be fair, the fact I alerted them that I was unable to complete registration on OpenPath’s site, and the fact the plugin was 18 months since its latest release may have something to do with that, may have been news to them. Keith Robideau Baltimore, MD

…

On Oct 27, 2023 at 6:46 PM -0400, Brian Henry ***@***.***>, wrote: That is correct about how it works. I do not have success stories because it's not recording much. With debug logging enabled, it can be seen how the plugin is counting and stopping orders. But it stops things before the order is created, so it's not obvious in most cases that it has even taken effect. More importantly, I've never heard anyone say they had this plugin installed and they then had a card-attack. That said, there is room to improve. I think I should add a rate limit on similar carts – I think the typical card attack is adding the same product(s) to the cart and placing the same order each time. If you want success stories and you are a developer, I would change the point where the rate-limiting happens from currently the AJAX action where clicking the Place Order button happens to the process payment hooks and I would preserve the newly created order objects and set a new custom status of "rate-limited" and then add an admin notice and email to inform the site owner what has happened. Additionally, if the plugin were to allow the orders to be created, the metadata could be gathered, sent to me, and used to determine more rules for preventing the problem. How much did the card attack cost the company? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[BrianHenryIE]

As I recall, when the card attack hit the company I was working for, there were per-transaction fees that went into the thousands of dollars but were forgiven by the processor. I can't remember who the processor was.

A bigger issue was that they cut off processing for the day! We quickly implemented "offline credit card" gateway which records the number, and someone manually punched in the card details in the gateway's website a couple of days later. I've been meaning to upload that code to GitHub too. AIUI, it is PCI compliant to record card details until the transaction is run.

The idea of "abandoned" plugins is never clear. Some are so simple that what worked 18 months ago should work in 18 years. For my own plugins, I like to follow code standards as best I can, write a reasonable amount of automated tests, and write a half-decent README. Then, if I don't touch this plugin for years, I think people can be relatively confident in it.

You can see test coverage at: https://brianhenryie.github.io/bh-wc-checkout-rate-limiter/

I do plan to update it sometime in the next few months. The long goal is to have the automated tests run on every new WordPress + WooCommerce release. Then automatically update the README to reflect that.

I've begun that: https://bhwp.ie/2023/11/add-playwright-e2e-tests-to-existing-wordpress-plugins/

There's also the new WooCommerce Blocks Checkout which this does not work with. It should be easy to add compatibility, and the new checkout actually creates the order long before the payment is processed, so it will be natural enough to mark orders as "fraud" rather than the lack of recording that's currently happening.