2017 Hacker Threats: The Distributed Guessing Attack & Steps to Prevent It
The switch to EMV technology for retail merchants was predicted to dramatically increase the amount of credit card fraud perpetrated against eCommerce merchants in the US. And thus far, the results have lived up to those fears, with credit card fraud against eCommerce merchants now up almost 4x (by dollars at risk) what it was prior to the EMV shift. As the fight to prevent eCommerce fraud escalates, so also do the techniques utilized by fraudsters. In this article, we highlight to a relatively new and potentially devastating technique that fraudsters are using to attack eCommerce merchants, and what steps small and mid-sized eCommerce merchants can take to protect themselves.
How a Distributed Guessing Attack Actually Works
A recent study by Mohammed Aamir Ali of Newcastle University demonstrated that by using relatively simply software algorithms, hackers can guess cardholders full Visa credit card numbers, expiration dates, and CVV codes without triggering any alarms with the credit card issuer in as little as six seconds per card.
This fraud technique used two weaknesses endemic to the existing payments infrastructure:
- That the online payments system does not detect multiple invalid payment requests when spread across multiple websites. That is to say, instead of attempting to guess a customer’s the credit card number by typing in slight variations until one is approved using the checkout shopping cart at a single website (which might block the IP / credit card after say 10 attempts) the fraudsters spread the attempts out over as few as 30 separate eCommerce they can guess and never trigger an IP block at a single website.
- Various shopping carts ask for different variations in the card data fields (some do not require CVV, or the card’s expiration dates for example). Thus hackers are able to validate limited guesses (for example just the credit card number), and then leverage that confirmed credit card number and use it to guess the additional required data at more secured shopping carts.
The researchers go on to hypothesize that this method is already being used by hackers, as potentially witnessed in the recent Tesco bank hack. The reason this is so devastating to merchants, is that the vulnerability isn’t preventable by simply doing a better job securing cardholder data. Rather, it’s a vulnerability built into the very nature of the credit card infrastructure.
What Steps Should Merchants Take
To be clear, this hacking technique is almost exclusively a concern to eCommerce merchants. And the payments system is already responding to eliminate this threat long term. MasterCard branded credit cards, for example, are already immune because they are able to detect guesses even across multiple websites, whereas Visa is not. But in any case, until the payments infrastructure changes to block this type of hacking across all card brands, there are a few steps that merchants can take to mitigate their risk.
The most practical defense a merchant can put into place is to require the card holder to enter information that isn’t ordinarily required in an eCommerce transaction. That is to say, requiring extra cardholder data is much like having a home burglar alarm. It doesn’t actually prevent a burglar from entering your home, it simply raises the effort and cost of doing so, so the burglar focuses on easier targets.
More specifically, we recommend that merchants enable and require AVS matching on all card-not-present transactions. Why? For two reasons…
- AVS Zip Code Match requires that the customer enter their zip code, and that the zip code entered match the card on file with the card issuer in order for the transaction to process. The first reason this is beneficial is that the zip code isn’t written on a physical card and because many eCommerce merchants do not require it, it is often not stored in another merchant’s database. Thus, the information is less likely to have been compromised and obtained by a hacker previously.
- The second, and more important reason in this context, is simply that it’s an additional hurdle that hackers have to jump over. If 95% of eCommerce stores allow the customer to make a purchase without obtaining the zip code, and if obtaining the zip code through guessing requires extra time (albeit only a second), effort, and resources, then simply put the hackers are more likely to choose more vulnerable targets.
The second tip, is to automatically flag IPs which have over five attempts at a transaction, so that their transactions are subject to manual review. While this undoubtedly will flag some false positives and in so doing create an element of extra work for the business, the ability to prevent fraudulent transactions (and all of their ensuing costs and headaches) is typically worthwhile.
Implementation
Implementing these recommendations requires only very simple settings changes in your payment gateway and fraud prevention software. If you’re using the Soar Pay payments gateway, we’d be happy to discuss how specifically to make these changes on your platform. Otherwise, if you need assistance, contact your payment gateway or fraud prevention suite provider.
Conclusion
These two recommended security protocols are in addition to, of course, standard risk protocols of monitoring transaction sizes, transaction velocity (in an attempt to identify bots), and other steps appropriate to your business. And to be clear, neither of these two tips are foolproof in eliminating this risk. But again, the goal is to make your eCommerce platform less vulnerable than the vast majority of other potential in the hopes that the fraudsters will strike elsewhere. There are more foolproof methods of preventing against this attack, such as requiring Verified by Visa authorization (a variation on 3D Secure) for all Visa transactions. But typically these more aggressive measures cause a conversion rate decline so severe that they’re almost never utilized. By implementing the two recommendations above, however, hopefully you can buy your business enough time until the payments infrastructure changes sufficiently to eliminate this threat, a process which is already underway.