Bots attacking our OPAY page to validate credit cards

[Nick]

wajake41 and nottheusual1 I would recommend NOT to use Emporium Plus Toolkit as it has been depreciated and no longer supported. Just about any function that can be done with Toolkit can be done with native Miva functions. Toolkit has known issues with the current version of Miva.

Here is a link to some documented replacements for Toolkit: https://docs.miva.com/developer/addi...ment-examples/

Here is an example of using Miva functions to read/write a file to the server: https://docs.miva.com/developer/deve...ad-write-file/

[wajake41]

Hello forum
So I've installed the Write_Basket function as Alpha suggested to save the customer's ip address. It is writing the ip address Info for our customers. This morning the person that is using our site to validate credit cards was back and their ip address is not in the BasketInfo table. How can that be? It was working previously for them but now isn't.

[wajake41]

It's working now. I am capturing the intruder's ip address and using it to block them. Presently I am monitoring our Baskets table looking for their return. Their third ip address has been added to the black list. Waiting for the next one. This appears to be an individual with limited IT skills. We had a second one initially but they have disappeared after I redirected them to the FBI cyber crime site.

[ILoveHostasaurus]

If they're performing the entire transaction as one request, there may not be an opportunity for the basket to have been written with that data. I would recommend against using the IP address for some type of validation, i.e. deny if the IP address has changed, because it's common for shoppers on mobile devices or heavy utilization networks to change IP's mid-session or even per-request. This can also have very noticeable performance implications for your site, as storing a custom basket field about shoppers, regardless of logged in state or basket content, defeats deferred baskets, and will make the site incompatible with the redis caching module.

My recommendation would be to have our TAC staff get Cloudflare with bot management set up for your site (free), and also consider using the recaptcha version 3 module. The default config of the recaptcha v3 module does enable it for the AUTH action, which means a carder doing a single-request add to basket + auth will have to have also passed the default score threshold, which generally they won't.

[wajake41]

Hello Hostasaurus: Sounds like good advice but for now I'm using WiteBasket to save their ip address in BasketInfo. The validators (2 of them it appears) are creating orders by progressing thru OCST to OPAY and then validating from their credit card list of stolen cards. Only one order has been created so far out of many attempts. How many failed credit card tries does Mia allow? I think putting their ip address in the admin Black List shouldn't create much overhead.. If what I'm doing doesn't eventually work to deter them I will look into CloudFlair. I'm afraid of using something I know nothing about.
I don't see how Captcha would help, they just look like any customer. I identify them by repeated new baskets with the same name/address info and never creating an order.

[ILoveHostasaurus]

Doing a write basket on every request harms your site performance, which in turn harms SEO, which leads to lower conversions or higher costs; so you're trading margin to stop a couple bad actors. The recaptcha v3 module should prevent them from doing a scripted progression through AUTH with new card numbers, without the same impact on the rest of the site, and generally won't even need an interaction from legit shoppers. The built-in decline blacklisting also works by IP address, and you can configure when to start delaying based on decline counts.

[wajake41]

Thanks David: I'm surprised that inserting a row into BasketInfo for each basket entering OCST would have such impact on our site. In fact I am skeptical. Still I am interested in learning what Cloudflare provides. Where can I find documentation.
Thank you,
Larry

[ILoveHostasaurus]

Oh, didn't realize we were talking about only tracking the IP from that point; that's not an issue since a legit shopper will already have a basket by then. I thought the tracking was occurring at regular runtime pages where empty basket shoppers would be. I still wouldn't create a blocker ot explicitly distrust a session with an IP change, as it's normal for certain swaths of users to have IP changes while shopping.

The Cloudflare features we use for this specific scenario are the Super Bot Fight Mode with the javascript detection enabled https://developers.cloudflare.com/bots/get-started/pro/, and the setting to challenge non-verified bots. These are requesting parties who do not process javascript, and don't have an expected Cloudflare cookie. We can also use their web app firewall to make more specific challenges when specific criteria are met, such as POST requests to merchant.mvc, AND other useful data once we know more about this, could be region, country, etc. A Cloudflare 'managed challenge' is a three second Javascript "testing browser" page that legit shoppers will see temporarily and not have to take any action on, and not see again for thirty minutes.

[wajake41]

Hello David: Thanks for the info on Cloudflare. I still can't understand how CF would distinguish the intruders from legitimate customers. The intruders select a product and then traverse through our checkout just like a real customer. I manually am checking the Baskets table on a regular basis looking for their return with a new basket. When I identify them on BasketInfo I black list their AP address. They aren't very smart yet, they continue to use the same OCST values on subsequent baskets. We use Toolkit save your OCST info so they just click through OCST, select a credit card and then arrive at OPAY. Typically on our site this will only take about 10 seconds at most. The Baskets timestamp showed turn around on subsequent baskets was about 40 to 60 seconds. (Last update on Baskets row). So I'm guessing they had about 30 seconds or so to test authorization on several cards before being locked out.
I hope being diligent I can scare them off eventually. It takes a few days before they get a new IP address. Last one was from Lithuania. (sp)

[ILoveHostasaurus]

You had mentioned bots in the first post, and 500 attempts, so I assumed rapid attempts in rapid succession and crossing ip addresses like most carders. Do you believe this is not automated and instead is a real human with a list of cards, and they're spending hours on the site, waiting out the blacklist lockout each time they hit it, to then try a few more cards? We almost never see such behavior as the value of a stolen card is so low that even criminals don't think it's worth their time testing them in that manner.

If that's what is occurring though, you are correct, Cloudflare would not help prevent a human browser from doing this. You could use it to greatly inconvenience them though. Cloudflare adds a geo location header to each proxied request. If there are specific countries that tend to do this, or even better, if it's highly abnormal for your store to see orders not from specific countries, you could add a conditional to the checkout pages that if the requesting country is not US (or more), it takes further mitigation steps. For example, you could trigger a mandatory solvable captcha, or just add a 30 second delay on every page load, so now they're taking minutes and minutes per card, etc.

[wajake41]

Hi David:
Yes originally we thought this was a bot attack. Investigating further (seeing all of the Baskets with identical OCST info I've come to believe it is 2 individuals esch using different OCST info. A couple of kids I imagine. One of them was able to get an order completed (found a good credit card I guess) but we immediately recognized it as a phony and cancelled the order. No harm to us. The black listed IPs are set to permanent so they have to shop for another IP address provider I guess.
I am retired so have a lot of time to mess with them and also patient so I am kind of enjoying the battle.
Cheers, Larry

[wajake41]

Finally I looked at the admin fraud settings. Saw we were allowing 15 authorization failures plus multiple tries of the 15, Changed the 15 failure limit to 4 and enabled automatic blacklist. It was set to manual. Problem seems to have been resolved.