New Credit Card Scam

A criminal ring was arrested in Malaysia for credit card fraud:

They would visit the online shopping websites and purchase all their items using phony credit card details while the debugging app was activated.

The app would fetch the transaction data from the bank to the online shopping website, and trick the website into believing that the transaction was approved, when in reality, it had been declined by the bank.

The syndicates would later sell the items they had purchased illegally for a much lower price.

The problem here seems to be bad systems design. Why should the user be able to spoof the merchant’s verification protocol with the bank?

Tags: authentication, credit cards, fraud, scams, security engineering

Posted on May 11, 2016 at 6:34 AM • 17 Comments

Comments

Bob Paddock • May 11, 2016 6:54 AM

‘…while the debugging app was activated. … Why should the user be able to spoof the merchant’s verification protocol with the bank?’:

“Test card details for your test transactions

Before your account can go live you must first complete a number of tests on our system. You may also want to test your own integration fully to ensure everything is working as expected before you put your account live.

Because our test accounts have no connection to the banks live card and address details will not work. Any live card details that are used with our test platform will get rejected.

In order to allow you to test your account completely we have created a range of card details, address information, and 3D Secure passwords that will allow you to complete all transactional processes and responses on your account before going live.

European Payment Types

If you have European Payment Types enabled on your Sage Pay [Randomly picked example company] account – giropay – sofort – iDEAL – EPS – you do not need any test details to process a transaction.

Any TEST transactions processed using these payment options will give you the option to select an outcome – succeeded, pending, failed (multiple options). The Sage Pay system will then simply simulate the response for you and provide the outcome in the post back to your platform.

Card Details

Because of this we have a list of card details that can be used to test your account and allow successful transactions to be processed.

Each card number will provide you with a different result when processing a transaction to ensure your website can handle all possible responses from our system.

Along with the different 3D Secure results each card type will return you are also able to test cards issued from multiple countries. …”

Appears someones debugging app has bugs…

Philip • May 11, 2016 7:04 AM

My reading of the article is that this is a variant of the old attack where the bad guy changed the price of items in the shopping cart before checkout. It sounds as though, with these websites, there is a final “success” message sent to the web server that indicates that everything went well (and it is this message that triggers the shipment). It appears that there is a bug in that this message is not checked against the state of the credit card transaction (or the state of the credit card transaction is held on the client side).

I expect this to become more common as we get more sophisticated browser apps where implementors will be tempted to put the business logic only in the client….

Anon • May 11, 2016 7:38 AM

Web developers generally have a low level of programming ability, and are the reason the moniker “coder” appeared.

Why is debug mode/debug code present in a live system at all? If it’s not present, it can’t be exploited.

gm • May 11, 2016 7:40 AM

There are some payment gateways that do a browser redirect sending the user to a 3rd party to complete transaction. I imagine they would be redirected back – since this goes through a browser, you can modify the fields (and if there’s no HMAC or it’s not verified – then the site will trust the input)

Demian • May 11, 2016 7:59 AM

I wonder if the site was doing the verification from JavaScript code running on the browser or if it was back-end systems that were compromised. If the verification happened from code running on the untrusted browser that would be quite a problem.

a • May 11, 2016 8:33 AM

Reminds me of a similar thing that happened with Domino’s Pizza: http://www.ifc0nfig.com/dominos-pizza-and-payments/

Daniel • May 11, 2016 9:54 AM

The problem here seems to be bad systems design.

The design was only bad because it was exploited, if it had never been exploited it would have been good design.

Sofa • May 11, 2016 10:03 AM

@Daniel

Res ipsa loquitur (The thing speaks for itself)

The system being exploitable in this way is essentially the proof the design is bad. Your sentence is “If it had never been exploited…” when it seems, “If it COULD never have been exploited…” seems more correct to call it a “good design” in this particular context. It should be assumed and factored into the design that people will try at exploit the design.

-Sofa

Craig • May 11, 2016 10:29 AM

@Daniel: You’re kidding, right? Or are you just trying to prove @Anon’s point above about web “coders”?

Paul • May 11, 2016 11:21 AM

@Craig: Sounds like Daniel is taking the management view of things 🙂

Bumble Bee • May 11, 2016 12:56 PM

None of this fancy posh upscale European chip/pin technology on the bank cards provides any assistance whatsoever with dispute resolution in the U.S. It all feeds back into the ACH system, which is completely open, insecure by design, and managed at such a high level in the upper echelons of the fed that no dispute resolution process exists except for felonies involving transactions with a value of at least hundreds of thousands of dollars if not millions each.

The rest of us have to deal with the prevailing attitude of merchants: “Come on, dude, there’s a chip on this card, fuck, let’s charge something on it!!!”

Oh, sure, you can run your debit card as credit if you want, but the receipt still says

^{DEBIT card DEBIT sale. PIN bypassed. All sales final. No retakes. No refunds.}

Receipts are printed in disappearing ink if at all. It’s more “environmentally friendly” that way.

Jesse Thompson • May 11, 2016 3:21 PM

@Daniel

The design was only bad because it was exploited, if it had never been exploited it would have been good design.

What about this design was good? Trusting the client Javascript — utterly at the control of the client user — to pass back the bank’s authorizing message with fidelity?

And this would be good because why, it’s simpler and cheaper to implement?

In that case, the next good design idea is to drop both SSL and credit card processing altogether and simply flash a message in front of the user asking them to “promise” to wire the correct payment to the company whenever they get around to it.

Because as long as nobody exploits that honor system, it represents the logical endpoint of cutting ecommerce web design costs.

Coyne Tibbets • May 11, 2016 5:40 PM

Why should the user be able to spoof the merchant’s verification protocol with the bank?

There are lots of ways they could have secured this, but all of them require a direct channel between the bank and the merchant. So much trouble, easier to just pass a simple XML with an…

approved="yes"

…attribute via the customer’s browser.

Exposure? @Daniel was being tongue-in-cheek, but his statement accurately reflects the state of security today. I’ve talked about security denial before, which comes in three phases (and I’m pretty sure Bruce has discussed them too, in different ways perhaps):

1. “Our app is perfectly secure.”
In the first stage, the application is presumed to be secure. The app owners don’t actually know that; because they did no security design or testing. But it’s easy to be oblivious to the weaknesses of the app.

2. Driving away/discrediting anyone who says otherwise.
When someone points out the emperor is naked, the response is more denial…and anger. The doomsayer must be silenced by some combination of being discredited, being sued, or being charged with a crime. “How dare he say our app is insecure?”

3. The app is exploited.
“We never could have imagined there was a weakness like this in our app,” and/or, “The app would be fine if it weren’t for all these hackers.”

In fact the stages show, throughout, an express denial of–an unwillingness to–assume fiduciary responsibility.

When they say, “The app would be fine if it weren’t for all these hackers,” they’re actually correct: it is the hackers. Just like house robberies are the fault of people who commit larceny.

With the customer’s house, the owner can put a lock on the door to keep the thieves out. Application owners, who are proud to assume control of customer data, prefer to live in denial that hackers exist. Having created a new door into the customer’s house, they happily leave the door sans lock, wide open, and let customer suffer the consequences.

After all, it’s not their house: why should they assume responsibility for protecting it?

AAA • May 12, 2016 5:27 PM

Caution. 971 dash 512 dash 6745 really is a known spam and scam phone number, not just a bad joke.

tor • May 13, 2016 5:30 AM

Isn’t it obivious that bank is using such a “system design” on purpose?

Craig Francis • May 15, 2016 5:29 AM

If Bob Paddock is right about the use of Sage Pay, there are much bigger problems with that payment gateway, as Sage Pay has no idea how to do encryption, or even simple encoding:

https://www.code-poets.co.uk/misc/security/sagepay/

These security problems were reported to them in December 2013, and the only thing they have changed is to actually confirm the vulnerabilities in their documentation (i.e. using the Encryption Key for the IV).

James • May 17, 2016 12:43 AM

the problem of the security world is sloppy programming. lazy programmers!!

you want to fix security issues then the name of the programmer/s and their photos should be attached to each application they develop. now let’s see those security holes disappear overnight.

New Credit Card Scam

Comments

Leave a comment Cancel reply