Slashdot Mirror
Largest Online Credit Card Heist Ever?
Brian writes, "Today InternetNews.com
broke a story about a Russian cracker who claims to
have stolen 300,000 credit cards from CDuniverse.com. After failing in an
attempt to blackmail the company for $100,000 to keep quiet, the cracker
posted the cards at his site."
Someone was saying just the other day (week?): It will take a major fraud before common everyday people begin to demand strong encryption.
Perhaps now the time has come? A few more heists like this, and if some reporter would just have the balls to "leak" how strong public/private key encryption could provide decent security... Maybe things would improve?
This response was obviously from someone who doesn't deal with either cryptography or "e-commerce" (I HATE that buzzword).
Secure cc transactions require a multi-layered cryptographic approach. The protocol used in the receiving of the cc numbers is much different then what is done when you store the numbers. If you a)process a credit card number with a cryptographically secure PRNG (cc's are VERY PREDICTIBLE), sign treated cc numbers before encrypting, and use an asymetric encryption algorithm with large keys that has shown to be strong (and the server only has the public key stored on it), YOU CAN SAFELY STORE THE CREDIT CARD NUMBER ON THE SERVER. Only the credit card processor has the private key, and the cc numbers should NEVER be decrypted on a system connected to the Internet.
If a server is set up this way, and the entire credit card database is downloaded to some script kiddie's system, they are still useless. I've never met a script kiddie that could decrypt randomized credit card numbers with 2048-bit RSA keys.
The problem is that the proper use and implementation of cryptography is amazingly difficult. I've been dealing with encryption for five years, and e-commerce sites for about two years; even most "Unix Guru's" don't get it right. It takes a lot of time and specialized knowledge.
Maxus claims the company agreed to the payment last month, but subsequently balked at initiating a wire transfer to a secret bank account because it might be noticed by auditors.
I can't freakin' believe this, that the people CDUniverse were actually going to pay the blackmail instead of trying to either fix the hole, or alert law enforcement/credit card companies to what happened!
This disgusts me, it's not that CDUniverse didn't pay because they might have though he was bluffing, but they didn't pay because their were worried that they might get into legal trouble for that! What about the customers with the comprimised credit card numbers in the first place, don't they mean anything to CDUniverse? Bastards.
I don't think I'll ever be doing business with CDUniverse. I think I'll be dropping a line to manager@cduniverse.com and telling them why, too!
SET is completely unworkable. It requires an infrastructure (PKI) that somebody has to provide and that infrastructure is costly. The other issue was that it required the processing performed at the merchant site (real world, not electronic). This is also unworkable because most merchants don't have the capacity to run the technology required.
I was involved in investigating SET for operation in the "real world" not some mickey-mouse VISA/BANK setup that "prooved" it worked. Ack!
What the banks should be doing is enforcing their TOS which (in Australia) state that credit card numbers cannot be recorded for any purpose other than for the duration of the transaction. So, you can take down the CC# and use it to process the transaction, and then it must not be kept for any other reason. None at all. As for the USA ? YMMV.
As you state, transfer the money, not the card. That's pretty much how it should be. If you encrypt the card details and the decrypted card details is only used to approve the availability of funds, the "window of opportunity" can be kept to a minimum. With appropriate encryption, the decryption of the CC# can be done at the bank, and the cc# is never, ever in the clear outside the banking network. That's how it should be done. Oh, did I forget to mention that's why we did when I was involved in developing a credit card authorisation system. ;-)
Why don't the banks care ? Well, it doesn't cost them any money, now does it ? The merchant and the consumer always lose. (Mostly the merchant) Cheers,
I have found a vulnerability in CyberCash 3 where local users can do Bad Things.
I have tried many times to get an adequate response from then over the last two or three months. They do seem to be fairly clueless about security issues.
I will be submitting the details to BugTraq tomorrow. They have been warned.
I work for a company producing a credit card processing gateway. I have had pressure by management (evil!) to store credit card details in my database. I refused. The bank stores credit card details.. and they do it securely, in semi-stand-alone computers that are protected by guards with guns. There is no reason to keep a customer's credit card number in a database and stories like this are another reason I can show to management to get them off my back.
How we know is more important than what we know.
No digits, of course :) HERE
Incidentally you have to hit <esc> to get it not to autorefresh to a 404'd page...
mcrandello@my-deja.com
rschaar{at}pegasus.cc.ucf.edu if it's important.
No, not all online merchants do this -- only the foolish ones. I build e-commerce sites for a living, and steadfastly refuse to even allow credit card information to traverse my client's servers unless they are encrypted at every step.
Of course, we have to provide for those cases where the remote payment processing center is unreachable, so we do sometimes have to store the information on the internet-connected server. The information stays strongly-encrypted until it reaches the merchant, and is never within reach of the HTTP server. We counsel the merchants to keep the decryption process out of any internet-connectable machine, and we keep a very jealous eye on the server logs for crack attempts. When a crack attempt is found, the site is disabled and we go to work analyzing the attempt and searching for any damage or changed files and take whatever action is appropriate.
We make noise to the administrators whose machines and network were used, but the fact remains that a persistent cracker will just come back using some other route -- and the knowledgable ones can cover their tracks pretty well. If they come back often enough they're more likely to make a mistake that gives them away, but even then there may be nothing that can be done about it short of increasing security. In many places on the globe, cracking is not illegal.
As long as there is commerce, there will be thieves. And as long as there are thieves, there will be a few who get away with it. It's easier to commit credit card fraud in the physical realm than it is in the virtual -- and the black market for stolen credit card numbers is huge. All it takes to gather up a group of stolen credit card numbers in the physical world is to find some embittered minimum wage punk in a gas station, mini-mart, or restaurant who wants to make a quick buck on the side, and they'll do so willingly. It's tougher to make a computer give them up unwillingly.
E-commerce is generally no more risky than is handing your credit card across a counter to someone you don't know just because he's there, and I would even go so far as to say that it's probably safer. If for no reason other than the fact that e-commerce sites are not where you'd expect to get caught in the crossfire of an armed robbery.
It's a good thing that tomorrow never comes, because most of us are stuck in yesterday.
But that's not the problem this time. This cracker reportedly found a bug in ICVERIFY, which is a completely separate program. ICVERIFY is an old, clunky program that emulates a credit card terminal, dialing and all. There's a free version; I got a copy once on a CD-ROM in an early book on Internet commerce. It's slow; when you see a site that says "It may take minutes to verify your transaction", it's probably an ICVERIFY site. CyberCash resells the thing, and has some improved versions.
CyberCash itself is a different system. A site using CyberCash on its servers runs the CyberCash CashRegister program, which sends transactions over the Internet (encrypted) to CyberCash HQ, which in turn has servers connected both to the Internet and to the interbank networks. This works much better than using ICVERIFY; you get address verification and proper error codes, and turnaround is about a second. CyberCash 2.x no longer works; it's not Y2K compliant. The current minimum version is 3.x. So that bug should be fixed for all sites.
Let me ask Slashdot readers a question. Suppose you could get a version of Linux that ran 25% slower, but was highly secure, secure enough to run trusted applications in a leakproof environment and untrusted applications in a "sandbox". Would you run it? Would you buy it?
Most "high" end banking institutions DO have their revenue processing systems directly connected to the other areas of their environment.
If a cracker had the right tool and a little social engineering skill, it would not be difficult at all.
Simple scenerio is to gain access to a less secure DB and then spoof the card DB's into thinking your session is just another R/W from an trusted DB.P.Actually this sort of thing happens all too frequently and the card companies just right it off as bad debt. It's unfortunate, but in the long run, they would much rather keep the fraud FUD down, it is much more dammaging than having a high bad debt number. Most issuing comanies run between 4-8% written off as bad debt.
More race stuff in one place,
than any one place on the net.
I hate to be right, but when people would talk about the risks of using credit cards online, I would tell them that no h/c(racker) is going to intercept a communication and break the encryption for one credit card number when they can simply steal the entire database after breaking into one server, guess this guy proved me right.
-- "The higher we soar, the smaller we appear to those who can not fly" -Frederick Nietzsche
As a side effect of tracking down spammers and liquidating them, I found many low budget web sites that accepted credit card orders and stored them in globally readable files on the web server. If you read the source for these web pages, you can see how they process the data submitted by their customers. Many just take the data from the form and append it to a file on the web server.
Mea navis aericumbens anguillis abundat
Call your bank. Most likely they will simply issue you a new card.
Since you stated this is a debit card, be aware of a little-known fact:
Debit cards do not have the same protections as credit cards.
While many bank policies are similar to the legal limitations on credit card liability, they are not, repeat not subject to the same laws. Read this recent article explaining the differences. Under certain circumstances, your entire bank account could be cleaned out, and the bank wouldn't have to give you one cent back.
----
lake effect weblog
{Network engineer in Chicago--looking for work!}
Here they are (in no particular order):
Of course "Under federal law, the most you'd owe for unauthorized charges to your credit card is $50 per card. You owe nothing if you report the problem before charges are made. " If I was a customer of this company I would call my bank and cancel my card ASAP.
E-Commerce sites have had problems like this from the beginning. Just last week I read a story in the news about someone saying that their credit card got stolen from Amazon.
What is scary about this heist is the fact that the cracker posted the page online and doled out card #'s to anyone in the world that wanted to get one... that is a first. The blackmail thing has been done b4.
However, I believe that the majority of credit card #'s that are stolen or taken advantage off w/out the owners knowledge over the internet are taken by kiddies and their credit card # generators. Most sites are secure and are not broken into by hackers. If (the myth that) most sites were broken into was true... someone with a fair amount of brains would have cracked a college application website and got ssn #'s and addresses and other crap and done a whole lot more damage to a person, or cracked an online banking service by now and screwed over thousands.
Also, the fact that stuff like this gets major news stories shows that it is not common place, if it were the news sites/people would not cover it because viewers want sensationalism.
Personally, I doubt that this guy did what he says he did. Had he done it, Interpol/Russian Cops would have gotten involved right away and tossed him in the chink - or at least payed the blackmail $.
Is it progress if a cannibal uses a fork?
The "server" that companies keep credit card information are are Authorization servers. These are the machines that are connected to point of sale devices, automated tellers, and other methods used to conduct transactions. These servers are not internet servers. They are not hackable the way that internet servers are, simply becuase they serve a completely different purpose and were built on entirely different protocols.
Could they be hacked? Yes. But then again so could an ATM. However the methodology for doing so is quite different, and not discussed on 2600.
Banks, Credit Card processors, and governing bodies, such as Visa and MasterCard take their security very seriously. This is why the weak point has always been the point of sale location, whether it be a mall, gas station, or online store. It is much easier to get a specific credit card number by going through a person's mail than to attempt to attack the authorization servers.
Think of it this way. Visa and MasterCard care about the security of their cardholders. Online and real world merchants however, do not, except as far as it affects the fee they pay.
offtopic note: When a merchant completes a transaction, for say, $10.00, he pays a small percentage, a penny or five, depending on what security measures he uses. A merchant who get's an auth and send in the transaction immediately gets a better rate than a merchant who is using paper tickets. This "fee" is used to cover the cardholder banks losses due to fraud. By accepting a credit card, the merchant makes a little less money on each transaction (this is why gas stations used to charge extra to accept credit cards), but they no longer have to deal with bad checks and counterfit bills.
For anyone to suggest that the authorization servers are as weak as the online stores is pure folly.
No Zen is good zen
Vulnerability found in CyberCash v 2.1.2 has been known for a while. Either these people didn't bother to fix their configuration, CyberCash didn't fix it in subsequent releases (if there have been any), or they continue to not take security seriously. For example, here is a summary of the vulnerability in CyberCash 2.1.2:
CyberCash v. 2.1.2 has a major security flaw that causes all credit card information processed by the server to be logged in a file with world-readable permissions. This security flaw exists in the default CyberCash installation and configuration.
The flaw is a result of not being able to turn off debugging. Setting the "DEBUG" flag to "0" in the configuration files simply has no effect on the operation of the server.
In CyberCash's server, when the "DEBUG" flag is on, the contents of all credit card transactions are written to a log file (named "Debug.log" by default).