36

We are currently setup using Magento on a LAMP stack for our e-commerce platform. As of a month or two ago we began noticing a lot of carding attempts against our website. All attempted transactions would be for a small amount, just to check if their credit card is valid. As one is declined they usually try it again repeatedly changing the card number by 1 or 2 numbers. These attempts happen very quickly, in succession. As you can imagine, this adds up quickly in our credit card processors system and often times we get shut down for a brief period of time to prevent more attempts.

Most of the attacks were coming from outside of the U.S. and we are a U.S. only business so we used mod_geoip to deny all traffic from outside of the country. This has helped with the mass attacks but we still get people carding from U.S. origins. I am really interested in knowing what’s going on here. How do they setup scripts to mass attempts orders like this? Is there really anything else I can do to stomp this out? Any insight on these types of attacks is appreciated!

This question was IT Security Question of the Week.
Read the Sept 14, 2012 blog entry for more details or submit your own Question of the Week.

Community
  • 1
jkphl
  • 361
  • 3
  • 4
  • 2
    Do you require a user's address as part of your transaction information? – Jeff Ferland Aug 29 '12 at 14:24
  • 13
    "As one is declined they usually try it again repeatedly changing the card number by 1 or 2 numbers" - This doesn't sound right. CC numbers are self-checksummed using the Luhn algorithm. I think you'd need to change more than one or two digits to get a valid number. At any rate, you can limit these attempts by having your site also do a checksum validation of any card entered. It will help usability too, this is designed to prevent miskeying a number. – Freiheit Aug 29 '12 at 18:25

8 Answers8

24

Given that you have strong verification of name / address, etc., it's most likely that your site is known to return different values for different types of errors. The best thing you can do to discourage card testing is to ensure that any declined transactions provide the same result regardless of the reason that the processor told you it was declined.

Jeff Ferland
  • 38,090
  • 9
  • 93
  • 171
  • 6
    At the expense of annoying legitimate customers who mistyped their credit card details, didn't realize their card had expired, accidentally went over their limit, etc. – Gilles 'SO- stop being evil' Aug 29 '12 at 20:27
  • 3
    @Gilles Well, I suppose if the address matches up, then perhaps more information. Right now I'm guessing whether a card is registered at all is being leaked regardless of whether anything matches it. – Jeff Ferland Aug 29 '12 at 20:58
  • 1
    I concur with @Gilles, it was _very_ annoying to only receive a "didn't work" message from PayPal (I paid for a computer and despite all my previously successful payments I was apparently not deemed trustworthy enough to buy anything else for the next four weeks), especially when followed buy copy-paste replies from support... – Tobias Kienzler Sep 15 '12 at 07:57
21

You can use a "CAPTCHA" mechanism to limit brute force attacks. Depending on the product, you could possible configure the CAPTCHA to block a user from submitting another transaction after some many fails attempts; and or, introduce a time limit (e.g. 15~20 secs) between transactions.

If possible, you could also try an authentication mechanistic for your users an only allow specific accounts to perform transactions.

w.c
  • 434
  • 2
  • 3
  • I'd really discourage the "authentication mechanism" idea, it's 2012, way past the time when "site accounts" should have been dumped outright. CAPTACHA is an excellent idea, as is locking out users who fail it multiple times for a reasonable period of time. – Chris S Aug 31 '12 at 00:56
9

If your attackers are using sequential account numbers then that's a giveaway you can use to filter attempts. If someone tries 001, then 002, then 003 it's a pretty good guess that they are carding and you can then filter attempts from that IP address.

The thing is that smart attackers will then modify their attacks by randomizing the card numbers they try, or more likely randomizing over a block of numbers, so then you will need to look for other signs. If you build a DB of IP addresses and requests you can look for these signs like a high number of small value transactions, or use an algorithm to detect block transaction attempts.

Or course the carders can adapt: they could start using multiple servers for attempts, or try larger transactions, less attempts per hour, etc. However they will have to adapt to keep using your system, and some of them may not be able to do so, or not want to bother. At the very least they'll have to work for it.

GdD
  • 17,291
  • 2
  • 41
  • 63
  • 3
    @Jeff Ferland - Yes. None of these transactions ever go through because we have strict address/name verification but all the Declined attempts add up and the CC processor freaks out. – jkphl Aug 29 '12 at 14:28
  • It's not an instant fix it's true, but it has the potential to quickly eliminate machines being used for multiple carding attempts. It's all about patterns. – GdD Aug 29 '12 at 14:57
  • 1
    My only concern with this answer is the possible denial of service to legitimate users due to NAT IP address sharing. This is especially a problem if a botnet is running the attack as opposed to a single client. – Phil Aug 29 '12 at 18:08
  • 1
    @Phil, you're absolutely right. The problem is that the carders are already causing a DoS through their multiple carding attempts, so something must be done. – GdD Aug 30 '12 at 07:44
7

I don't think this person (people) care about whether or not they get valid numbers since as you say you're validating with addresses as well, and they are trying sequentially. Getting blocked by CC processor could actually be a goal, especially if they are your competitors or they're doing it for the lulz.

There's a couple of options I can add to the list: You can randomize the name of the input field, and store the name of the field in the session or somewhere safe, like this if you use PHP: 

<input type = "text" name = "ccnum" />

to:

<input type = "text" name = "<?php echo $ccFieldName; ?>" />

Also, you can force your users to enable JavaScript (roughly 96% of users have JS enabled). It's likely that your abuser(s) is using a command line tool such as wget to try to hit your server, and if so, wouldn't be able to parse JS. Once you have enabled Javascript, you can add your input field for the credit card once your document is ready, with a random name like above so that all current attempts at automating requests fail.

ajacian81
  • 171
  • 1
  • 3
  • Just don't forget to add a "Please enable JavaScript" message for users who use NoScript on first-time visits – Tobias Kienzler Sep 15 '12 at 08:01
  • 1
    Unfortunately this only works against very simple bots that talk directly to the server. As far as I can tell, it is quite common to remote control a normal browser for this kind of attack. I am referring to an approach using something like [Selenium](http://seleniumhq.org/), which is a software designed for automatic testing of web application – Hendrik Brummermann Sep 22 '12 at 09:28
5

When this was happening to an organization I know, they told their processor to decline all charge amounts below a certain threshold. This stopped the low value transactions completely, and the carders quickly left their site alone.

If you haven't done anything about it yet, consider contacting your local FBI office. They may be interested in the case. The account "tasting" process is possibly coming from somewhere traceable.

John Deters
  • 33,650
  • 3
  • 57
  • 110
3

One option to consider would be introducing an artificial delay to the credit card checking process. Legitimate users shouldn't mind a slight delay in the process, but it should significantly hamper the usefulness of your site to the carding scripts.

Winston Ewert
  • 131
  • 4
3

Once you identify a suspicious stream of requests (presumably by a real time pattern match on recently failed transactions). First, automatically deny all subsequent requests that match for a period of time (hours at least). This will remove the load on your actual transaction processing system, and stop feeding the culprit any useful information at all, in fact it will feed him misinformation, since valid requests will be denied too. Slow down your response to limit the rate of new requests.

ddyer
  • 1,974
  • 1
  • 12
  • 20
0

We have had the same issue here. We decided the quickest and user-friendliest way was to implement a modern Recaptcha ('I am not a Robot') extension. We decided on the Yireo Google Recaptcha extension because it was fast and easy to implement (https://www.yireo.com/software/magento-extensions/recaptcha), but you can also implement your own here (http://www.proxiblue.com.au/blog/magento-recaptcha/).

For our Yireo implementation I used the 'Customer registration' and 'One Page Checkout Billing' settings as 'Yes', all the others were set to 'No'. There is an issue I noticed with Yireo when I had used the 'One Page Checkout Login' setting as 'Yes', then our registered users were having issues logging into their accounts (For some reason there was no recaptcha shown, and when they tried to log in it would state 'invalid recaptcha' in a message block). So, I changed that setting to 'No', and now normal users can log in and the carding has also stopped pinging our payment processor. Everyone is happy now.

A note on the Yireo extension. It uses short PHP tags (dumb), so if you are using a PHP version less than 5.4, you will need to turn on short tag support in your PHP.ini. Make sure you read the Yireo extension requirements before implementation!

EDIT: Recaptcha does nothing to prevent the attacks. It's apparently very easy to trick the system because the recaptcha just uses a cached cookie after the first attempt, so bots can then run after that by just using the cookie. Poor design Google. Recaptcha is supposed to prevent bots, but it can't in it's current state.

lanrosta
  • 1
  • 2