Carding Attack

[eurobeautiful]

My store has been the target of several carding attacks in the last few weeks, growing in intensity and sophistication. Thousands of credit cards (presumably stolen numbers) are "tested" using a single guest cart on my store.

Initially we were manually blocking IP addresses after receiving the Payment Transaction Fail email notices, and increased Cloudflare security level. When the attacks became more frequent, created a custom fail2ban filter that would ban IP addresses having several POST requests to /rest/<view>/V1/guest-carts/<cart_id>/payment-information.

Then the attacks started to come from dozens of IP addresses. At that point we noticed that ModSecurity wasn't working, and once we got that fixed, they have mostly stopped.

Here's a small sample from the Apache logs... they continue with hundreds of different IP addresses:

85.155.214.182, 162.158.63.239, 127.0.0.1 - - [07/Jun/2020:10:36:45 -0400] <domain> "POST /rest/<view>/V1/guest-carts/MY0w0zl6J0P1k6F7Pc1Q0seFlgkPHyAM/payment-information HTTP/1.0" 400 789 "https://<domain>/checkout/" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36"
189.216.67.26, 173.245.52.202, 127.0.0.1 - - [07/Jun/2020:10:36:45 -0400] <domain> "POST /rest/<view>/V1/guest-carts/MY0w0zl6J0P1k6F7Pc1Q0seFlgkPHyAM/payment-information HTTP/1.0" 400 789 "https://<domain>/checkout/" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36"
190.167.13.76, 162.158.63.113, 127.0.0.1 - - [07/Jun/2020:10:36:47 -0400] <domain> "POST /rest/<view>/V1/guest-carts/MY0w0zl6J0P1k6F7Pc1Q0seFlgkPHyAM/payment-information HTTP/1.0" 400 789 "https://<domain>/checkout/" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36"
189.218.238.138, 162.158.63.239, 127.0.0.1 - - [07/Jun/2020:10:36:50 -0400] <domain> "POST /rest/<view>/V1/guest-carts/MY0w0zl6J0P1k6F7Pc1Q0seFlgkPHyAM/payment-information HTTP/1.0" 400 791 "https://<domain>/checkout/" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36"
101.12.115.190, 162.158.62.220, 127.0.0.1 - - [07/Jun/2020:10:37:01 -0400] <domain> "POST /rest/<view>/V1/guest-carts/MY0w0zl6J0P1k6F7Pc1Q0seFlgkPHyAM/payment-information HTTP/1.0" 400 789 "https://<domain>/checkout/" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36"

This last escalation is what makes me think that there may be a vulnerability in Magento. Is it normal for Magento to accept activity from the same session, from different IP addresses? As you can see, all the POST requests use the same cart ID, and my guess is that there are additional cookies and tokens necessary for the requests to be accepted and processed by Magento.

You may have noticed that the log includes 3 different IP addresses on each line. This is because we have a multi-proxy setup: Cloudflare > nginx > Varnish > Apache. Maybe Magento isn't catching the real remote user IP address but instead using 127.0.0.1?

Preconditions (*)

1. Magento 2.3.4
2. Credit card payments using Braintree
3. Multi-proxy setup: Cloudflare > nginx > Varnish > Apache

Other conditions that may or may not be related:

4. One page checkout
5. Multi-website installation

Steps to reproduce (*)

1. Create a guest cart and then send payment information POST requests to /rest/<view>/V1/guest-carts/<cart_id>/payment-information from different IP addresses.

Expected result (*)

1. Magento detects that a single session is getting requests from several IP addresses and either rejects these requests or voids the session.

Actual result (*)

1. Requests are processed normally.

---

Please provide Severity assessment for the Issue as Reporter. This information will help during Confirmation and Issue triage processes.

• [ ] Severity: S0 - Affects critical data or functionality and leaves users without workaround.
• [ ] Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
• [x] Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
• [ ] Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
• [ ] Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.

[m2-assistant[bot]]

Hi @eurobeautiful. Thank you for your report. To help us process this issue please make sure that you provided the following information:

• Summary of the issue
• Information on your environment
• Steps to reproduce
• Expected and actual results

Please make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, please, add a comment to the issue:

@magento give me 2.4-develop instance - upcoming 2.4.x release

For more details, please, review the Magento Contributor Assistant documentation.

Please, add a comment to assign the issue: @magento I am working on this

---

• Join Magento Community Engineering Slack and ask your questions in #github channel.

[eurobeautiful]

I'd ask someone from the community familiar with this type of issue to help with reproducing it on a vanilla installation. I don't know how to generate a carding attack.

[btekbtek]

Typing manually few times wrong cards numbers can simulate this. Or post in postman.

We had this issue. It looks like people check cards on magento stores, so they can use cards in ATM. A lot of payments was successful. They always used same quote - cheaper product.

On first step we made to block requests after 3 times for not logged and 7 for logged customers in PaymentInformationManagment.php and QuestPaymentInformationManagments.php.

            if($attempts = $this->_cache->load(sha1($cartId))) {
                if($attempts >= 7) {
                    throw new \Exception;
                }
                else {
                    $this->_cache->save($attempts + 1, sha1($cartId));
                }
            } 

... but what happens they starting to get successful payments after 1 and 2 time. I think they stilling cards numbers and they test them manually (or with simple auto filing extension for browser) in few stores.

What finally helped? 3D validation in settings to set threshold for lowest price product.

Another option is to load recaptchta in checkout.

[btekbtek]

Create an empty cart Add one or more products to the cart Set the billing address Set the shipping address Set the shipping method Set the payment method For guest customers, assign an email to the cart

In GraphQl

Create empty cart

mutation {
  createEmptyCart
}

Add products to cart:

mutation {
  addSimpleProductsToCart(
    input: {
      cart_id: "MNrWvSCyKRl1RYLxeo1ZDe7m7wv0uXTZ"
      cart_items: [
        {
          data: {
            quantity: 1
            sku: "ProductSKU"
          }
        }
      ]
    }
  ) {
    cart {
      items {
        id
        product {
          name
          sku
        }
        quantity
      }
    }
  }
}

And after changing Ip you can still add to cart like a quest, also finish order.

Add Billing address:

mutation {
  setBillingAddressOnCart(
    input: {
      cart_id: "MNrWvSCyKRl1RYLxeo1ZDe7m7wv0uXTZ"
      billing_address: {
        address: {
          firstname: "Bob"
          lastname: "Roll"
          company: "Magento"
          street: ["Magento Pkwy", "Main Street"]
          city: "Austin"
          region: "TX"
          postcode: "mk420at"
          country_code: "GB"
          telephone: "867544309"
          save_in_address_book: true
        }
        same_as_shipping: false
      }
    }
  ) {
    cart {
      billing_address {
        firstname
        lastname
        company
        street
        city
        region{
          code
          label
        }
        postcode
        telephone
        country{
          code
          label
        }
      }
    }
  }
}

Set shipping address

mutation {
  setShippingAddressesOnCart(
    input: {
      cart_id: "MNrWvSCyKRl1RYLxeo1ZDe7m7wv0uXTZ"
      shipping_addresses: [
        {
          address: {
            firstname: "Bob"
            lastname: "Roll"
            company: "Magento"
            street: ["Magento Pkwy", "Main Street"]
            city: "Austin"
            region: "TX"
            postcode: "MK420TQ"
            country_code: "GB"
            telephone: "867530449"
            save_in_address_book: false
          }
        }
      ]
    }
  ) {
    cart {
      shipping_addresses {
        firstname
        lastname
        company
        street
        city
        region {
          code
          label
        }
        postcode
        telephone
        country {
          code
          label
        }
      }
    }
  }
}

and rest points, I dont have time now.

[n2diving-dgx]

We too have had severe problems with carding attacks (merchant account is Braintree, but I doubt that makes a difference.) Settings on our merchant account can enable rate limiting, which will eventually cause the card validation to always decline and defeats the purpose of the attack, but doesn't stop directly the hammering of checkout and the merchant card processor with many attempts at validating the card. Enabling rate limiting helps, but recently the carding attacks have adapted and will slow their rate of validation attempts to stay under the rate limit.

The underlying issue is the security of the M2 native onestep checkout flow is inadequate to detect or manage the problem and carders appear to have tailored their attacks to rely upon the inherent weaknesses in the current Magento native checkout flow. The severity of the problem is more than just an annoyance. This security problem has to be resolved or the merchant card processor will suspend the website merchant card processing account for carding. Without card processing, the Magento checkout has no method to automatically accept card payments, effectively shutting down the website! In our case, Braintree even threatened to permanently close our account if we didn't resolve the problem by improving our checkout security.

The short term solution is to enable the native M2 captcha and/or Google ReCaptcha capability for the native M2 onestep checkout flow. Having to solve a captcha adds 'friction' to the checkout flow, of course undesirable yet necessary to stop carding attacks, but Google ReCaptcha V3 (aka 'invisible' ReCaptcha) keeps the friction to a minimum. Unfortunately, M2 doesn't support that choice in the native configuration as of 2.3.5-p1. The only solution I have found available as of now is to install a 3rd party extension that supports ReCaptcha on the M2 native onestep checkout flow. After researching and trying several, as of June 2020 only been able to find one viable extension: swissuplabs M2 recaptcha.

Ultimately, it would be much better for M2 to add support for enabling M2 captcha or Google ReCaptcha (including support for V3) on the Place Order button in the checkout flow.

[eurobeautiful]

Thank you for your comments. I think adding adding ReCaptcha should be a last-resort measure. Specially when there are other low-hanging fruit opportunities.

The focus of my posting this issue is on the fact that Magento, during checkout, can check that all activity (requests) related to a specific cart are coming from a single IP (maybe cart can be associated with a PHP session ID).

This should prevent this kind of carding attack coming from several different IP addresses.

[n2diving-dgx]

We tried various methods based on the IP. The carding software adapts within minutes, switching to using the same IP until that blocks, then switching to another. Then we are playing 'whack-a-mole' in the Cloudflare WAF adding IP addresses. Block Tor exit nodes, and they switch to anonymous VPN's. We tried all the other ideas mentioned here that were 'low hanging' fruit... some worked for a few days, but the only thing so far has been a captcha on the place order button. The underlying security of the M2 checkout needs some extensive re-work, but ReCaptcha V3 has been adequate for now.

[btekbtek]

@n2diving-dgx We use Braintree also. What about this 3D validation changed for smaller amount. Looks like its fixing issue. All our card attacks was with cards that use 3D.

[n2diving-dgx]

3D Secure validation, and it's follow on 3DS 2, requires the card be enrolled in the card issuer's version of the 3D secure program... Visa Secure and Verified by Visa, American Express SafeKey, Mastercard Identity Check and Mastercard Securecode. Unfortunately, North American cardholders (we are in the US) are far behind Europe (or anywhere else for that matter) in the issue of cardholder security because they are completely protected by law from losses due to fraudulent charges, all risk is borne by the Merchant. According to Braintree, virtually none of the cards processed through our site are enrolled in 3D secure programs because it is not done automatically by the card issuers here, the US card holders rarely take the extra steps to first enroll themselves at the card issuers website. Further, it appears few of the US banks that issue cards currently have support for 3DS 2 in their backend authorization systems, although most EU banks now support it. For more information see https://www.theatlantic.com/business/archive/2016/03/us-determined-to-have-the-least-secure-credit-cards-in-the-world/473199/

One more thought regarding using 3DS from the merchant's point of view. It doesn't actually stop the carder from hammering your site with attempts. The authorization attempt still gets transmitted to the card processor. Failure of the authorization due to 2FA still doesn't stop the authorization attempt, it just stops the fraud, and only for those cards enabled for 3DS. Thus, the transaction logs at the card processor are still filling up with bogus authorization attempts (that cost money!), and the merchant gets the threatening contact from the card processor. The ReCaptcha approach stops even the attempt at an authorization if it's a bot and not a human. Unfortunately, that's still not a perfect solution to blocking carding.... just slows it down a lot.

[aliomattux]

I have spent quite some time on this issue. There is a general consensus in the community that implementing recaptcha on checkout is bad practice, many developers have refused to create this functionality, but apparently at the moment it seems to be the only way to stop it.

Having seen this first hand, each request was coming from a different ip, so not even possible to track add to cart action to checkout. Tracing on ip is a fools errand. Have seen also using the same session. That was the only way I could identify the attack. I had to study the access logs, usually it is very easy and quick to identify attacks. This confuses me because Magento admin has settings to specifically validate session ip, x-forwarded-for and so on. Even with all these settings enabled it had no effect in their ability to execute the attack.

I did a custom implementation of recaptcha but found it very difficult to implement and still the attack was able to bypass it. Being a framework that is designed to make the developers job easier, I find it would be easier to work with a blank sheet of paper than to properly implement it in Magento 2. Module will require both client and server side validation to prevent attack. IMO, this is a highest priority issue.

[n2diving-dgx]

I'm not clear on what the objection seems to be for a well implemented captcha in the checkout flow. Using the 'invisible' recaptcha which doesn't require an interaction (i.e. no puzzle to solve) with the user has not caused any abandonment or loss in our case. Checkout friction is essentially non existent. It did turn out to be a challenge to find a correctly implemented version, but eventually I did find extension that supported recaptcha in the checkout flow and that has worked to stop the carding.

Just to be clear, the issue being addressed here is what is known as 'carding' as opposed to fraud. The 'carder' is simply using the checkout stream as a method to find valid cards that will successfully authorize by using carefully crafted software to send a constant stream of different cards (typically hundreds per hour) to the Magento checkout to see which will pass. The validated cards are then used elsewhere for fraudulent purposes. From what I've learned, it's the weaknesses of the M2 onestep checkout that has been exploited by the carding software tools which are tailored for M2.

The M2 native checkout flow security needs an overhaul, but the short term solution would be a native ability to support captcha/recaptcha in the checkout flow itself on the place order function. I note the PayPal payment module bundled with M2 already supports this function, but not the M2 native onestep checkout.

[eurobeautiful]

I appreciate all the comments, but it looks like the conversation got derailed into an unrelated topic.

The question is about whether Magento has a security vulnerability because it allows for a single session / cart to receive HTTP requests from multiple IP addresses.

This seems to be a very basic security validation that isn't happening. I wish I was a more experienced with Magento to look at the code myself and check it.

[lucasapoena]

Hello, is there any news about this problem? Will a security patch be released?

[pfdcdigital]

Exactly the same issue re-produce on live site multi-website EE 2.3.2-p2, is there any security patch?

[sb-nick]

I'm having the same issue with Magento ver. 2.3.3-p1. Right now we're playing whack-a-mole blocking IPs in Fastly. I've been attacked on and off since migrating to M2 in late March 2020. I think the guest checkout api is flawed and allows for this to happen. Magento and Braintree had said to implement recaptcha, but that won't help if you're already being attacked. In addition, BrainTree's advanced fraud tools need some work.

Some advice for others posting about this:

1) Put in a Magento support ticket to document the issue, request escalation immediately.

2) Get a hold of your Magento account rep and explain the severity of the situation. In my case she's working on my behalf getting eyes on this from the engineering side. I'm still in active talks with them regarding this.

3) Complain to BrainTree about this and here's why. This is from an email exchange between BrainTree and Gene about advanced fraud tools in the current version of the extension 3.4.1. Gene support notes: “A quick note regarding AFP; it came to light recently, that the AFP provided in Production is not the same as that in the Sandbox. The Gene module currently supports the AFP that is available in the Sandbox, and was available in Production until around February time, after which, the Fraud Tools in Production are now newer and is not available for testing in the Sandbox.” So BrainTree's development partner can't upgrade our extensions to support newer advanced fraud protection, mainly device detection tools, until the upgrade their sandbox environment.

4) Also put in a support ticket with BrainTree Gene, the developers of the integration.

I encourage everyone posting here to do the same. Apply pressure all three teams, Magento, BrainTree and Gene. They need to be working together to get this resolved.

[eurobeautiful]

@sb-nick thanks for your comments, I completely agree.

In the absence of any response from Magento (I wish I were more proficient in coding so that I can contribute to the solution), we have been managing the attacks. We have created additional fail2ban rules that trigger with different settings, and together with ModSecurity we have been able to stop for the most part attacks from single IP addresses. At the worst points the only thing that stops the attacks in the 'I'm under attack" mode in Cloudflare.

The challenge continues to be the distributed attacks. Just last week we were attacked from 500+ IP addresses - we played whack-a-mole for 2 hours, blocking IP addresses and them popping up new ones. At the end of the attack I plotted the IP address and they were spread all around the world.

In any case, I didn't realize until a couple days ago that the developer of the Magento-Braintree integration is a company contracted by Braintree (Gene https://www.gene.co.uk/). I sent them an email asking for support just a day ago.

Braintree contacted us a couple weeks ago because our account was flagged as "risky". Now that I know that the Magento module is essentially developed by Braintree I am baffled. I will be contacting Braintree directly.

I will keep you posted.

[pfdcdigital]

Why is this not controlled if we have Fastly Installed and configured, magento is still not responding to any security patch to lock the request, I am still getting lots of declined emails in trying to attempt the rest API.

Braintree Suggest the rotate the API key and API secret which may help. let monitor if this help

[sb-nick]

Couple things we have implemented from mage support:

1) In Admin > Configuration > General > Web > Session Validation Settings Set to "Yes" the following: Validate REMOTE_ADDR Validate HTTP_VIA Validate HTTP_USER_AGENT

I'm not 100% sure what this does, the documentation is very high level.

2) Upgraded fastly above 1.2.138 as this version added Add rate limiting to WebApi https://github.com/fastly/fastly-magento2/pull/379

3) Created a custom VCL to block the rest api url to the guest checkout in Fastly. NOTE you need to update your Fastly plugin to leverage this. Magento support can help you with this.

3) Enable bat bot protection and rate limiting with Fastly. Though this hasn't really helping imho, though I just got our Fastly plugin updated yesterday in production, Still watching.

BrainTree suggested:

1) In BrainTree, set your fraud thresholds low. E.g. 2 failed credit cards in 2 hours. Or two failed email transactions within 2 hours. BrainTree support had me put this in. This will be a pain for customers who data enter incorrect, but we're doing to see how this combats.

Bottom line is, this guest checkout api needs to be adjusted/patched to prevent this. Magento is on the hook for this. BrainTree needs to add in better fraud tools for carding attacks. Auto ip banning for suspicious behavior and etc. Would be great it Faslty had some better bot protection and auto ip bans. In addition, I'm surprised Fastly doesn't have a database or "HoneyPot" of bad IPS to block nefarious activity in their solution. Not everyone can afford a PerimeterX addon integration.

The only way we can get this fixed is to be vocal to our vendors and demand they do something. Call your account reps!

[dribblecastle]

Thanks @sb-nick. I ran into this problem on Friday night and it continued into Saturday morning. It was hard to understand what was going on until I came across this post. I tried simple things like disabling guest checkout but that didn't help.

After taking our site offline for 15 mins or so and applying your #1 suggestion the attack stopped. I'm going to look further into the Braintree you suggested so I'm prepared for any future attacks.

In Admin > Configuration > General > Web > Session Validation Settings Set to "Yes" the following: Validate REMOTE_ADDR Validate HTTP_VIA Validate HTTP_USER_AGENT

FYI, we were running 2.3.4 open source with PHP 7.2 and NGINX.

[eurobeautiful]

We had Validate REMOTE_ADDR, Validate HTTP_VIA, Validate HTTP_USER_AGENT already set to Yes since we launched the site. Looks like these settings were reset to "No" (baffling, the default value) after the update to 2.3.4.

[itgwebsight]

Thank you for the recommendations above to help with this issue, i have implemented Session validation and Captcha onto the site which seemed to of stopped it over the weekend but unfortunately it started again this morning, This time all the attempts were coming from the same IP which is why i am guessing the session validation didn't stop the attempts, I have blocked the IP now and removed the cart ID they were using which has stopped the attempts for now, we are using 2.3.4 and php 7.2,

Does anyone know if magento are looking into a patch for this issue?

[sb-nick]

@itgwebsight how did you implement captcha and braintree. Its really challenging my team coding wise having to reverse engineer both Magento and BrainTree?

[sb-nick]

We still get hit after having the REMOTE_ADDR settings turned on. We built a mini firewall module that looks for those guest checkout api calls and if they hit too many, we block the IP and email a copy to ourselves so we can check to see where its coming from. Still Mage needs to legit fix this to help prevent it. I agree recaptcha isn't the solution.

[itgwebsight]

@sb-nick i tried a load of different options to enable this but could not find an off the shelf product so looked into building a module for it, i finally spotted that the mageplaza recaptcha module supported Custom CSS Selectors and Form URL's so managed to add it via these with the aid of the below github issues

https://github.com/mageplaza/magento-2-google-recaptcha/issues/20

[aliomattux]

The mage plaza module shows the recaptcha but it does not actually prevent checkout and the module is not designed to support recaptcha on checkout.

On Wed, Jul 22, 2020 at 12:01 PM iTG notifications@github.com wrote:

@sb-nick https://github.com/sb-nick i tried a load of different options to enable this but could not find an off the shelf product so looked into building a module for it, i finally spotted that the mageplaza recaptcha module supported Custom CSS Selectors and Form URL's so managed to add it via these with the aid of the below github issues

mageplaza/magento-2-google-recaptcha#20 https://github.com/mageplaza/magento-2-google-recaptcha/issues/20

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/magento/magento2/issues/28614#issuecomment-662571408, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIAVCI3J7CAMWJ7L6SD7R3R44LP5ANCNFSM4NYKEZMA .

[eurobeautiful]

It seems like the Braintree integration needs to be refactored in order to allow for reCaptcha to work: normally reCapctha works by having the request sent to the server and then the server can check with the reCaptcha API whether the response is valid, and from there decide what to do. However the current implementation of the Braintree integration makes the payment request directly from the browser to the Braintree API.

[Flipmediaco]

I found this thread on experiencing the Carding Attack on a Magento 2.3.5 site. So this issue remains following the upgrade. We have a Recaptcha enabled on user login on the checkout, so this does not help either.

We have enabled rate limiting on CloudFlare as the requests to /rest/english/V1/guest-carts/*/payment-information were around 15 a minute. The rate limit will block any IP that attempts X requests to the above URL in a minute.

I have traced the origin of the attack to the day before when someone took the checkout through to payment. This delivered a URL which contained a {cart id}. Later that night they picked up the same URL using the same {cart id} and used this for an automated request of around 15 requests a minute before changing to another IP address.

Whilst CloudFlare will result in the requesting IP being blocked after X requests a minute, all this will do is slow down the action and make the host unreliable for the attacker.

I have been looking for information about what validation is being used for these requests... Can the cart be validated via IP address for example?

[eurobeautiful]

I still have not received any answer from the developers of the Braintree integration. However I want to bring back this issue to the original question: how does Magento allow for requests relating the a single cart/session to come from different IP addresses? This is a very basic security flaw.

Just this morning we are experiencing another attack. As of now, more than 1,000 requests, coming from over 400 different IP address have been made using the same cart ID. You can see the log here: https://gist.github.com/eurobeautiful/08b25ae2925d4d692c3de327afcb47f3

I have all the following settings configured to YES: Validate REMOTE_ADDR Validate HTTP_VIA Validate HTTP_X_FORWARDED_FOR Validate HTTP_USER_AGENT

And these requests just fly through like there is no actual checking happening.

I hope this issue gets the attention of someone in the Magento community that can help.

[pcmerc]

We are seeing similar issues & we're not using any Braintree integration. This is a core magento flaw.

[johnvanrees]

We have the same issues as everyone mentioned, using Braintree. A few things I've learned to stop a current attack:

1) Invalidate the cart through the database which renders all subsequent requests null or 2) Blacklist the URL path in the POST request /rest//V1/guest-carts//payment-information

Either of these options will prevent any more POST requests until a new cart ID is generated.

I have not had success in working with the host, Sucuri, or Braintree in finding another solution to stop the continued attacks. This does seem to only affect the credit card payments on the default Magento checkout. I have not seen the problem manifest in a payment the requires a redirect (i.e. PayPal or ApplePay). I am wondering if a redirect payment gateway (such as 2checkout) would solve the issue.

[sb-nick]

@johnvanrees can you share the queries you used to invalidate the cart? Is this done through multiple tables? tables: quote, quote_item, quote_item_option

[pfdcdigital]

Yes, please let us know how you can invalidate the cart, I have the same attack on cloud instance with netacea protection still getting the attack

if you have any solution, share your solution

Thanks

On Wed, Aug 12, 2020 at 7:28 PM Nick M notifications@github.com wrote:

@johnvanrees https://github.com/johnvanrees can you share the queries you used to invalidate the cart? Is this done through multiple tables? tables: quote, quote_item, quote_item_option

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/magento/magento2/issues/28614#issuecomment-672905757, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALDIHDKV3LMFOUS5JMBGGFDSAKRKJANCNFSM4NYKEZMA .

[johnvanrees]

To invalidate the cart and stop the current attack, in 'quote' update 'is_active' to '0'.

I sort the by entity_id by the most recent and find the cart based on value since the carding attack is always very small. If you have the failed transaction email, you can look in quote_address to find the entity_id of the offending order.

This only stops the current bot automation. As soon as the attacker generates a new cart, the process starts again.

[iphigenie]

I have had the same issue on 2.3.4 and Stripe so it is not just Braintree - that's the main thing I am reporting

Blocked it via Cloudflare putting automatic humanity check on all the countries that are known to have these kind of operations (that one was Philippines) but it is a luxury few will have - I can put a geo captcha check on nearly all countries without much adverse effect, as my customers are at 95% from one country.

[ghost]

Let me get back to you.

Sent from my Apple Watch

[Flipmediaco]

I can confirm Magento 2.3.5-p1 using the Gene Braintree Payment Method and standard Magento checkout remains vulnerable to these attacks.

We have had another instance of a Carding Attack since upgrading the site to 2.3.5-p1

This time the activity was shut down after around 19 requests by CloudFlare, but this is a very loose-fitting plaster so to speak.

Would be good to know resolving this is part of a future release.

[sb-nick]

We implemented recaptcha at checkout in two parts: storefront layer and api layer. With some customizing we tied recaptcha fails to auto auto ban the ip in Fastly upon hitting a threshold. API fails get autobanned after 1 attempt since we know this is a carding attack. We even widened the ip ban to ban class a,b,c,d class networks and /16 or /24 ranges. It's been live for about two weeks. I've seen 1 auto ban so far. Storefront layer did catch a legit customer that got banned due to too many postal code fails, so I had to manually remove them from our Fastly wall when they contacted us.

In BrainTree we setup a couple fraud rules to block transaction based on criteria, a phone call to support helped us tailor these.

So far this seems to be helping. The idea is that if they are unsuccessful after 1 attempt, they go elsewhere.

For the record this customization was brutal. There is ZERO documentation for BrainTree / Mage's payment gateway integration along with integrating recaptcha into the checkout workflow. It took a TON of trial and error along with reverse engineering both systems. Roughly 60+ hours of work from a single developer.

I'll post back here often as I monitor.

[eurobeautiful]

@sb-nick that sounds like a major effort. I was contacted by Braintree because they were concerned by the number of attempts. Fortunately we have not had a single fraudulent charge because we have practically all fraud detection tools enabled on Braintree and we also use https://www.weltpixel.com/magento2-maxmind-fraud-prevention-minfraud.html. The developers of the module (Gene https://www.gene.co.uk/) informed me that they continue to support the module, but that they aren't allowed to develop a fix for this problem (yeah, I also don't understand) unless PayPal/Braintree gives them the order. I indicated this to the person from Braintree, and asked them to fix this issue in their module.

I will follow up with sample code that we have used to aid on this problem (outside of Magento).

[sanxionghuang]

.Thank you

获取 Outlook for Androidhttps://aka.ms/ghei36

---

From: EuroBeautiful notifications@github.com Sent: Saturday, September 5, 2020 8:22:07 PM To: magento/magento2 magento2@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: Re: [magento/magento2] Carding Attack (#28614)

@sb-nickhttps://github.com/sb-nick that sounds like a major effort. I was contacted by Braintree because they were concerned by the number of attempts. Fortunately we have not had a single fraudulent charge because we have practically all fraud detection tools enabled on Braintree and we also use https://www.weltpixel.com/magento2-maxmind-fraud-prevention-minfraud.html. The developers of the module (Gene https://www.gene.co.uk/) informed me that they continue to support the module, but that they aren't allowed to develop a fix for this problem (yeah, I also don't understand) unless PayPal/Braintree gives them the order. I indicated this to the person from Braintree, and asked them to fix this issue in their module.

I will follow up with sample code that we have used to aid on this problem (outside of Magento).

― You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/magento/magento2/issues/28614#issuecomment-687603098, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AO3NVJJX74JJTQ4EEK77LO3SEIUO7ANCNFSM4NYKEZMA.

[eurobeautiful]

Ok, this is a long post, I hope it's useful. Here is our overall security setup:

1. Cloudflare for automated protection against bots, DDoS, their "I'm under attack" mode as well as firewall for blocking IP addresses
2. Web server configured with ModSecurity and OWASP security rules to automatically block suspicious traffic
3. fail2ban with a custom filter and jail (more on that below) to automatically ban IP addresses
4. Some attacks still slip through this and we handle them semi-manually

fail2ban

We created a simple new filter: /etc/fail2ban/filter.d/magento-payment.conf:

[Definition]
failregex = ^<HOST>.*POST.*\/rest\/[^\/]+\/V1\/guest-carts\/[^\/]+\/payment-information.*$
datepattern = %%d/%%b/%%Y:%%H:%%M:%%S

we created a simple custom jail /etc/fail2ban/jail.d/magento-payment.conf that includes multiple definitions for repeated matches to the URL patters at different speeds, with different ban times:

[magento-payment1]
# every 1 second
filter   = magento-payment
enabled  = true
logpath = /srv/www/*/logs/access.log
findtime = 3s
maxretry = 3
bantime  = 30d

[magento-payment2]
# every 2 sec
filter   = magento-payment
enabled  = true
logpath = /srv/www/*/logs/access.log
findtime = 6s
maxretry = 3
bantime  = 30d
...

and modified the default Cloudflare action /etc/fail2ban/action.d/cloudflare.conf, updating the actionban and actionunban to utilize the new Cloudflare API.

From:

actionban = curl -s -o /dev/null -X POST -H 'X-Auth-Email: <cfuser>' -H 'X-Auth-Key: <cftoken>' \
            -H 'Content-Type: application/json' -d '{ "mode": "block", "configuration": { "target": "ip", "value": "<ip>" } }' \
            https://api.cloudflare.com/client/v4/user/firewall/access_rules/rules

actionunban = curl -s -o /dev/null -X DELETE -H 'X-Auth-Email: <cfuser>' -H 'X-Auth-Key: <cftoken>' \
              https://api.cloudflare.com/client/v4/user/firewall/access_rules/rules/$(curl -s -X GET -H 'X-Auth-Email: <cfuser>' -H 'X-Auth-Key: <cftoken>' \
              'https://api.cloudflare.com/client/v4/user/firewall/access_rules/rules?mode=block&configuration_target=ip&configuration_value=<ip>&page=1&per_page=1' | cut -d'"' -f6)

To:

actionban = curl -s -o /dev/null -X POST \
            -H 'X-Auth-Email: <cfuser>' \
            -H 'X-Auth-Key: <cftoken>' \
            -H 'Content-Type: application/json' \
            -d '{ "mode": "block", "configuration": { "target": "ip", "value": "<ip>" } }' \
            https://api.cloudflare.com/client/v4/user/firewall/access_rules/rules

actionunban = curl -s -o /dev/null -X DELETE \
              -H 'X-Auth-Email: <cfuser>' \
              -H 'X-Auth-Key: <cftoken>' \
              https://api.cloudflare.com/client/v4/user/firewall/access_rules/rules/$(curl -s -X GET \
              -H 'X-Auth-Email: <cfuser>' \
              -H 'X-Auth-Key: <cftoken>' \
              'https://api.cloudflare.com/client/v4/user/firewall/access_rules/rules?mode=block&configuration_target=ip&configuration_value=<ip>&page=1&per_page=1' | tr -d '\n' | cut -d'"' -f6)

(the cfuser and cftoken parameters are configure at the bottom of the file)

Manual blocking

The above setup has been mostly successful in blocking the majority of the attacks, but some still manage to avoid the automated methods. When we see "Payment Transaction Failure" emails coming in, we just take a look with the following commands:

Scan the web server logs to identify cart IDs that have been used repeatedly

cat /path/to/webserver/logs/access.log | grep payment-information  | grep -oP "guest-carts\/([0-9A-Za-z]+)" | uniq -c
   1285 guest-carts/hfPVp6TbW6deLlm7EjSdX1Gxw3aplVYR
     14 guest-carts/SY6VVlGetZM2UrIaSy1jA1cNCe3rAAiN

You can see how that one cart ID has been received over 1000 requests, clearly malicious. The next step is to generate the list of IP addresses that attempted this cart. They are ALL going to be banned. This command will export the list to a file:

cat /path/to/webserver/logs/access.log | grep hfPVp6TbW6deLlm7EjSdX1Gxw3aplVYR | grep  -E -o "^([0-9a-f\.\:]+)" > access-ip.log

the following command, sorts and removes duplicates, and saves the list into a new file:

sort access-ip.log | uniq > ban.txt

And then we run this script to ban each IP address with fail2ban (and also add the IP address to Cloudflare firewall):

#!/bin/bash
filename='ban.txt'
while read ip; do
     fail2ban-client set magento-payment1 banip ${ip}
done < $filename

This usually quiets things down for a couple weeks. Let me what you think. I would love to automate this manual process but I need some help.

[sb-nick]

@eurobeautiful are you on-prem hosting and not using Magento Cloud Commerce?

[Flipmediaco]

I am just looking at this issue again and it occurred to me...

@eurobeautiful @btekbtek @n2diving-dgx @aliomattux @lucasapoena @pfdcdigital @sb-nick @dribblecastle @itgwebsight @pcmerc @johnvanrees @iphigenie @cherryz23 @sanxionghuang

Are you all using CloudFlare?

[pfdcdigital]

No, we are using NETACEA on Magento cloud

On Tue, Sep 8, 2020 at 6:23 PM Laurie Barker notifications@github.com wrote:

I am just looking at this issue again and it occurred to me...

@eurobeautiful https://github.com/eurobeautiful @btekbtek https://github.com/btekbtek @n2diving-dgx https://github.com/n2diving-dgx @aliomattux https://github.com/aliomattux @lucasapoena https://github.com/lucasapoena @pfdcdigital https://github.com/pfdcdigital @sb-nick https://github.com/sb-nick @dribblecastle https://github.com/dribblecastle @itgwebsight https://github.com/itgwebsight @pcmerc https://github.com/pcmerc @johnvanrees https://github.com/johnvanrees @iphigenie https://github.com/iphigenie @cherryz23 https://github.com/cherryz23 @sanxionghuang https://github.com/sanxionghuang

Are you all using CloudFlare?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/magento/magento2/issues/28614#issuecomment-688862632, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALDIHDLPZGFN2W3R4YBIVATSEYV4NANCNFSM4NYKEZMA .

[eurobeautiful]

@sb-nick self hosted, Magento open source

[wjpbill]

I'm getting the same problem, seems like there is a lot of us.

To date we've been hit 4 times. The first two they processed circa 800 attempts in 10 minutes, was amazed the server held up. Since then, I've joined the Wackamole club and I'm blocking IP addresses as they pop up. I have implemented Braintree Fraud rules to stop repeated requests on the same card etc. but it doesn't stop the traffic.

For now, we monitor Failed Payment Transaction emails and if they start appearing, I jump on to the server, check the quote table for the IP, block it and then contact whichever hosting company it's with. In addition, we only ship to the UK so we've blocked all traffic from non-EU and UK servers. However, yesterday we got another one from a Switzerland based server hosted by DataCamp and frankly they were useless at helping me.

We host with Nexcess and their tech support people are trying to assist us but there has to be a better way than this. I've used CloudFlare in enterprise installations before but not with M2.3.5 and I don't think it fixes the core problem of M2 checkout.

I would welcome any solutions anyone has and urge Magento to fix the problem somehow.

[iphigenie]

We are on stripe. I don't think it matters much which it is, the thing that matters is the way to prepare carts and checkout via open API.

We were much more mildly hit - first a set of maybe a dozen attempts, which I reported to Stripe as I felt bad for the people - surprised nobody there knew to tell me "it's likely that was a test, it worked, so they will likely come back"

Then the next afternoon it started again, and they did indeed 100 in minutes. That was during working hours so I checked the country these were from and went to cloudflare and simply turned on the "javascript challenge" for those countries.

All it would take is a human going through this once and then they could shift a couple hundred through again, so I was ready to need more rules and layers but actually not had an attempt since - it times out or challenges a few times and they don't try, they just move on to the next target.

But that cart and checkout creating open API needs to be locked down far more.

[BreezeMaxWeb-NS]

Got hit with 400,000 attempts over the long weekend, Braintree told us to implement reCAPTCHA, and that it should be "super easy" with "tons of tutorials showing exactly what's required"... Am I blind? How would I even go about implementing reCAPTCHA inside of Magento 2 for the GeneCommerce Braintree module? We already have the built-in reCAPTCHA enabled on the frontend and backend.

Also, trying to enable the 3D Secure feature in Magento 2 Configuration for Braintree prevented 100% of valid users from completing a transaction.

[Flipmediaco]

The issue does highlight a vulnerability in the Magento 2 REST API /rest/[store view code]/V1/guest-carts/[cart_id]/payment-information

The REST API should have some form of validation that marks the cart as invalid when it is repeatedly accessed in this way. Changing IP address in quick succession. Or have an expiry, the attack is set up around 24hrs in advance, but the cart remains valid. The Cart needs only validation similar to the session validation options.

Hopefully, Magento will see this as an issue, because it is an issue with: /rest/[store view code]/V1/guest-carts/[cart_id]/payment-information, this endpoint is exposed to the browser and can easily be reposted to changing the data for each post. Which is how this exploit is performed.

The Carding Attacks I have been looking at all have the same shipping address - a courier company, so I suspect the request is designed to attempt to achieve a purchase from the target site to obtain goods and identify valid cards for use on other sites.

My experience so far is if you make your site hard work for this exploit they will simply move on to the next target site.

Points I have observed that make your site less likely to subject to this type of attack - harder work:-

Cloudflare:-

1. Rate Limiting - build a rate limit rule around the request pattern used in the attack.

2. JS Challenge specific countries - challenge request from IP addresses linked countries where the attack originates. Identify IP addresses used in the attack

Braintree Configuration:-

1. Set up Fraud Management AVS, CVV and Risk Threshold Rules

Magento Configuration:-

1. Limit Countries in the address drop down to only countries you will ship to. The store I have had this issue with is in the UK and only ships to the UK and so the billing address country could only be UK... But the cards being used were all US based and so ALL failed AVS Reject Rules - requires AVS rules to be configured.

2. Disable Guest Checkout - with Guest Checkout disabled you can block the guest-carts endpoint (via CF or .htaccess). The "mine" endpoint uses the same email for each request and there is the option to configure a Custom Risk Threshold rule in Braintree that is triggered to Gateway Reject 4+ Verifications from the same email in one minute. A human will muster at best 2 payment verifications in under a minute so 4+ within a minute is a bot.

3. Enable 3D Secure - I appreciate that 3DS is not an option for all countries. But I believe this exploit is targeting sites without 3DS Enabled - if your site is not B2B there is no excuse not to have 3DS enabled.

So the take away here is that via configuration alone in Magento, you can make your site less susceptible to these attacks by either enabling 3D Secure or Disabling Guest Checkout... The other points are nice to have.

A B2B site who is resistant against 3DS could opt to disable guest checkout. A B2C website should be using 3DS as it's a processor requirement.

Hope this helps someone.

@BreezeMaxWeb-NS 3D Secure for Braintree using Gene needs to be configured within the Braintree Gene Module: ADMIN > STORES > Configuration > SALES > Payment Methods > Braintree [Configure] < button > 3D Secure Verification Settings (test on stagging version of your site and you may need to update the Gene module if it's not working I found older version of the gene module fail 3DS since the 3DS v2 update)

[sshymko]

Experienced the automated place order requests hammering the M2 sites. Cloudflare rate limiting rules (available in the Pro plan) mitigated the issue entirely: Firewall > Tools > Rate Limiting

[wjpbill]

Experienced the automated place order requests hammering the M2 sites. Cloudflare rate limiting rules (available in the Pro plan) mitigated the issue entirely: Firewall > Tools > Rate Limiting

Experienced the automated place order requests hammering the M2 sites. Cloudflare rate limiting rules (available in the Pro plan) mitigated the issue entirely: Firewall > Tools > Rate Limiting

Thanks for the advice.

Did you set those rule only on /checkout and customer/account/login/ ?