1

We have experienced recent malicious credit card testing attacks against our Civi/Joomla/Stripe site's Contribute pages. How have others successfully deterred such attacks?

Our site:

  • CiviCRM 5.52.2
  • Joomla! 3.10.11
  • Stripe Processor 6.7.10

We use a publicly accessible Civi Contribute page for donations. Up until these attacks yesterday, Joomla login was not required for a user to submit a donation payment on this page. Ideally, we would like to remove the login requirement again to provide a seamless path to donation for non-members.

What happened:

Our publicly accessible Civi Contribute donation page started receiving invalid $2 charge attempts at a frequency of ~1 charge per second. Stripe successfully identified these as spam and thankfully blocked every charge (10k+ individual charges).

The frequency of requests to the web server brought the site to a crawl. Accessing the web GUI for Civi and Joomla was nearly impossible. The database also spun up to consume 95% of our available CPU while attempting to handle the queries associated with each malicious charge attempt.

Using Stripe Radar and the Apache access logs, we determined that the attackers were using rotating IP addresses (many hundred per hour).

What we did (in order):

  • Blocked some of the recurring malicious IPs addresses using our firewall. This did not help, as the attacker just rotated IPs.

  • Added a reCAPTCHA to the Civi Contribute page. This did not have any effect on the attacks.

  • Blocked access to the Civi AJAX API using an Apache .htaccess RewriteRule. This stopped the invalid charges from reaching Stripe but also expectedly broke legitimate payment requests.

  • In the web GUI, modified the Joomla Access Control setting for "CiviCRM: access AJAX API" to only be allowed for logged-in Joomla users.

After blocking non-logged in users from submitting payments we continued to see attack requests at a high frequency for another 3 hours. All those requests were correctly returned a 403 or 500 error. The database took 3 hours to finish processing the queries for the malicious payment attempts.

How have others successfully deterred such attacks? What additional mitigation would folks recommend if want to remove the login requirement from the Contribute page?

Thank you!

Improve this question
1
  • I think this is possibly Joomla specific, but you already have 5 tags.
    – Elin
    Commented Oct 30, 2022 at 19:04

5 Answers 5

Reset to default
2

For future reference, here is how we solved this issue:

We implemented the below changes, which have successfully deterred a card testing attack since:

  • Installed the Civi Firewall extension (https://lab.civicrm.org/extensions/firewall). This extension works alongside the Stripe extension to automatically block IP addresses whose payment attempts return fraudulent or blocked status from Stripe. Highly recommend this as a first step.

  • Worked with MJW Consulting to add and install a function to the Stripe Extension which sets a global minimum payment amount for the Stripe Extension (in our case, a $10 limit, as all testing transactions were less than that). This prevents the payment requests from ever reaching Stripe, if under the limit. I am not 100% sure if this feature will be included in Stripe Extension 6.8 for all users, but it is a really great feature.

  • Enabled Stripe's Radar feature temporarily to identify IP addresses carrying out the attack that weren't rotating and block at the web server firewall (had a few Microsoft Azure IPs in the mix that were being heavily reused).

Improve this answer
1

Welcome to SE! Are you using https://lab.civicrm.org/extensions/firewall ? Not sure whether it will help with rotating IP's but worth looking at.

Improve this answer
1
  • Thanks! We will check that out. We do use the Joomla Extension "Admin Tools Professional" akeeba.com/products/admin-tools.html, which includes a firewall feature we do have deployed. However, we aren't aware of any features in that extension that would help in this situation, as the attacker was rotating multiple-thousand IPs per hour.
    – MattEMBA
    Commented Sep 30, 2022 at 23:50
1

This does not help your situation but for Drupal users, if you use CiviWebform Integration for your contribution pages. You can set it so that the user/ip cannot process the form more than Xs in an hour.

Improve this answer
3
  • Good to know! Even if we were Drupal and used the CiviWebform Integration, I suspect that type of user/IP blocking would not have worked in this case, as the page does not require login and the user was rotating IPs with each request. Seems like we need a solution that isn't IP-based.
    – MattEMBA
    Commented Sep 30, 2022 at 23:51
  • Rate limiting is the key here, as Iowa Boy says. I'm unfamiliar with how to do this on Joomla! forms, but there will be a way and this approach will save you this kind of headache in the future.
    – JohnFF
    Commented Oct 1, 2022 at 17:43
  • I will look into options to rate-limit the frequency which the page can be served all-together. This will need to be purely based on page loads, since we don't want to require login and the attackers rotated IPs. That may prove a little blunt but we don't receive a high frequency of simultaneously donations anyway. Thank you!
    – MattEMBA
    Commented Oct 3, 2022 at 17:36
1

One of the easiest ways to prevent your site from being used for credit card tumbling is to set a minimum amount on your donation form. The reason card tumbling is always with small $ amounts is b/c they are trying to stay under the radar from a card holder’s perspective (until they find a set of credentials that works - and then go big).

Re: https://home.iatspayments.com/blog/why-credit-card-processing-matters-for-your-business/

Improve this answer
5
  • is there a magic # that you suggest going above? Does it have to be above $X to get into the CC radar?
    – Iowa Boy
    Commented Oct 2, 2022 at 0:07
  • Added a reference -> suggestion there is $15 minimum
    – KarinG - Semper IT
    Commented Oct 2, 2022 at 13:54
  • Setting a minimum donation is a great idea, had not considered that but every charge was exactly $2, so that would have helped at least prevent the transactions from reaching Stripe. Thank you!
    – MattEMBA
    Commented Oct 3, 2022 at 17:31
  • I recommend you read the Re I attached in my answer. It explains Fraud and has more tips on how to prevent it (setting a minimum is just one of them).
    – KarinG - Semper IT
    Commented Oct 3, 2022 at 21:46
  • noting a site we support just got hit with thousands of $35 ones
    – petednz - fuzion ♦
    Commented Aug 10, 2023 at 22:44
0

I wanted to point out a recent question/answer I had Server access error for event registration with credit card

Where in order to make event registration work I had to change the ACL for the ajax api "public" which I never had needed before. I think that is a bug that was somehow introduced somewhere in the interaction of Joomla and Civicrm.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.