Plugin Support
RK a11n
(@riaanknoetze)
Hi Dean,
I’m not 100% sure of the question here – If it is indeed a bot that’s enumerating those POST requests, adding Cloudflare/banning IPs on a server level would indeed make the most sense. Alternatively, it might also be worthwhile taking a closer look at https://woocommerce.com/products/woocommerce-anti-fraud/
Hi @riaanknoetze
Thank you for your quick reply.
Sorry, my question is whether there a way to prevent this abuse on these POST requests?
I’ve been trying to get to the bottom of this for weeks now. It went quiet for a period of time and then suddenly the past few days, traffic like this has spiked.
I’ve banned IPs as I’ve been investigating both on a website and server level.
Here are a few examples of the requests made. I took this from logs where the same IP address made 6.3k requests 8:41am and 10:02am.
xxx.xxx.xxx.xxx – – [18/Jul/2020:08:41:06 +0100] “POST /?wc-ajax=checkout HTTP/1.0” 200 1738 “https://website.com/checkout/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0”
xxx.xxx.xxx.xxx – – [18/Jul/2020:08:41:07 +0100] “POST /?wc-ajax=checkout HTTP/1.0” 200 1738 “https://website.com/checkout/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0”
xxx.xxx.xxx.xxx – – [18/Jul/2020:08:41:07 +0100] “POST /?wc-ajax=checkout HTTP/1.0” 200 1738 “https://website.com/checkout/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0”
xxx.xxx.xxx.xxx – – [18/Jul/2020:08:41:09 +0100] “POST /?wc-ajax=checkout HTTP/1.0” 200 1738 “https://website.com/checkout/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0”
Thanks
Dean
Plugin Support
RK a11n
(@riaanknoetze)
Just to make sure – are you overriding any template files with custom ones in your theme/child theme? Which payment gateways do you have active on that site? Do you know the parameters of that POST request? The reason I’m asking is that simply running https://wc.local/?wc-ajax=checkout doesn’t create any new orders in the admin area (at least not on my local testing site)
Plugin Support
Missy a11n
(@m155y5)
Automattic Happiness Engineer
We haven’t heard back from you in a while, so I’m going to go ahead and mark this thread as resolved. If you have any other questions please feel free to start a new thread.
Hi both, sorry for the delay – somehow I missed this.
There are many template files that are overridden. We used Braintree Payments until last week and now use Stripe – not had any issues with Stripe yet.
I don’t know what headers are being sent in these POST requests – I only have server logs showing all the requests at present.
Thanks
Dean
I have been seeing the same in my logs. My firewall logged some POST bodies, and it appears the attackers are using multiple credit cards to see if Braintree accepts them. I ended up with failed orders with thousands of cards tried against them. I have reported this on the official Braintree plugin support but this thread came up in Google so posting here.
@galapogos01 this was a vulnerability with WooCommerce and was fixed in version 4.6.2.
I have this happening to one of my sites over the past 3 days so far, causing notifications from my customers credit card processor. They are on version 5.6.1 currently, however it was updated recently over the past couple days as well. It started happening after my sites were updated from 5.6.0 to 5.6.1.
I have put in some fail2ban limiting for this on my server looking at the log files, but that catches it after some activity occurs, but im hoping there could be a fix for it.
We are using the Payment Plugin for USAEpay.
13.72.87.98 - - [04/Feb/2021:04:13:17 -0500] POST /?wc-ajax=checkout HTTP/2 200 205 https://mysite.com/checkout/ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.104 Safari/537.36
13.72.87.98 - - [04/Feb/2021:04:13:17 -0500] POST /?wc-ajax=checkout HTTP/2 200 205 https://mysite.com/checkout/ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.104 Safari/537.36
13.72.87.98 - - [04/Feb/2021:04:13:19 -0500] POST /?wc-ajax=checkout HTTP/2 200 273 https://mysite.com/checkout/ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.104 Safari/537.36
13.72.87.98 - - [04/Feb/2021:04:13:17 -0500] POST /?wc-ajax=checkout HTTP/2 200 205 https://mysite.com/checkout/ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.104 Safari/537.36
13.72.87.98 - - [04/Feb/2021:04:13:19 -0500] POST /?wc-ajax=checkout HTTP/2 200 273 https://mysite.com/checkout/ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.104 Safari/537.36
13.72.87.98 - - [04/Feb/2021:04:13:18 -0500] POST /?wc-ajax=checkout HTTP/2 200 205 https://mysite.com/checkout/ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.104 Safari/537.36
13.72.87.98 - - [04/Feb/2021:04:13:19 -0500] POST /?wc-ajax=checkout HTTP/2 200 202 https://mysite.com/checkout/ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.104 Safari/537.36
13.72.87.98 - - [04/Feb/2021:04:13:16 -0500] POST /?wc-ajax=checkout HTTP/2 200 202 https://mysite.com/checkout/ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.104 Safari/537.36
13.72.87.98 - - [04/Feb/2021:04:13:19 -0500] POST /?wc-ajax=checkout HTTP/2 200 202 https://mysite.com/checkout/ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.104 Safari/537.36
13.72.87.98 - - [04/Feb/2021:04:13:21 -0500] POST /?wc-ajax=checkout HTTP/2 200 273 https://mysite.com/checkout/ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.104 Safari/537.36
13.72.87.98 - - [04/Feb/2021:04:13:20 -0500] POST /?wc-ajax=checkout HTTP/2 200 202 https://mysite.com/checkout/ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.104 Safari/537.36
13.72.87.98 - - [04/Feb/2021:04:13:21 -0500] POST /?wc-ajax=checkout HTTP/2 200 273 https://mysite.com/checkout/ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.104 Safari/537.36
13.72.87.98 - - [04/Feb/2021:04:13:20 -0500] POST /?wc-ajax=checkout HTTP/2 200 202 https://mysite.com/checkout/ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.104 Safari/537.36
13.72.87.98 - - [04/Feb/2021:04:13:21 -0500] POST /?wc-ajax=checkout HTTP/2 200 273 https://mysite.com/checkout/ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.104 Safari/537.36
13.72.87.98 - - [04/Feb/2021:04:13:21 -0500] POST /?wc-ajax=checkout HTTP/2 200 202 https://mysite.com/checkout/ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.104 Safari/537.36
13.72.87.98 - - [04/Feb/2021:04:13:21 -0500] POST /?wc-ajax=checkout HTTP/2 200 202 https://mysite.com/checkout/ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.104 Safari/537.36
13.72.87.98 - - [04/Feb/2021:04:13:22 -0500] POST /?wc-ajax=checkout HTTP/2 200 273 https://mysite.com/checkout/ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.104 Safari/537.36
13.72.87.98 - - [04/Feb/2021:04:13:22 -0500] POST /?wc-ajax=checkout HTTP/2 200 273 https://mysite.com/checkout/ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.104 Safari/537.36
13.72.87.98 - - [04/Feb/2021:04:13:21 -0500] POST /?wc-ajax=checkout HTTP/2 200 202 https://mysite.com/checkout/ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.104 Safari/537.36
13.72.87.98 - - [04/Feb/2021:04:13:22 -0500] POST /?wc-ajax=checkout HTTP/2 200 202 https://mysite.com/checkout/ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.104 Safari/537.36
13.72.87.98 - - [04/Feb/2021:04:13:22 -0500] POST /?wc-ajax=checkout HTTP/2 200 202 https://mysite.com/checkout/ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.104 Safari/537.36
13.72.87.98 - - [04/Feb/2021:04:13:22 -0500] POST /?wc-ajax=checkout HTTP/2 200 202 https://mysite.com/checkout/ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.104 Safari/537.36
Adding I’m on WC 4.9.2 since it was released
I am on WC 4.8.0 and this just happened to us. 7,000+ orders in one night running over 20,000 different cards. We also use a WAF. This is a pretty complex attack. IP addresses are rotating and they are going slow enough not to be considered a ddos by WAF. Any ideas?
@webgmclassics we’ve fixed this by updating to WooCommerce 4.6.2 which I’ve been led to believe includes the security fix.
Another client came to us with the same problem and since the update, they’ve been fine.
@machinedean I am running WooCommerce 4.8.0 on this store, so it appears it is not as simple as updating WC. 🙁 Did you all do anything else or did the attackers just move on?
@webgmclassics I was able to use this free plugin to start blacklisting some of the domains they used for the orders, Woo Manage Fraud Orders. They were very similar in my case using @btsese.com, and @temporary-mail.net. I also blacklisted the orders, users, and ip addresses.
In addition I am using CSF as a firewall, so I wrote a custom regex rule for lfd to detect this attack and blackhole them.
if (($globlogs{CUSTOM1_LOG}{$lgfile}) and ($line =~ /^(\S+) - - .* POST \/\?wc-ajax=checkout HTTP\/[1-2][\.]?1? 200/)) {
return ("Attempted AJAX Checkout Attack",$1,"woocommerce-ajax-attack","5","80,443","3600");
}
In my analysis of the attack, it looked like a human being browsed around on a site for a little bit, added some products to a cart, then went to checkout and got all the cookie details. Then popped this info into a script and attacked from somewhere else like AWS/Azure with many different credit card numbers.
In addition we worked with out credit card payment gateway to put more stringent fraud system on our ordering, so the credit card processor did not hit the end customer for charges.
@myst3k99 This is very helpful; thank you. We experienced the same attack. They were determined too… I threw in a minimum order amount code snippet just to make it a little harder ($5) and I saw in the access logs where they sorted my shop by price to find the items that were just above that amount. I do not understand how that amount of effort is worth it.
Yup this is also what we saw, the only ever add a single item like a 5$ item, and are completely happy with paying $16 of shipping on it. We were contemplating putting some limits on single items orders of that matter, as our products are typically purchases in multiple items due to the cost/shipping/local pickup.
