Largest Online Credit Card Heist Ever? 349
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."
Question for the pros (Score:1)
Apprehending Maxus will not be easy, said Richard M. Smith
"It's possible he could have slipped up somewhere along the way, but I think he's pretty free and clear and it's near zero that they will catch him," Smith said.
I would think that this guy would be able to be tracked down. Check out his writing style, scan newsgroups relevant to security and see if there's familiar styles. Also, there was an mp3 file on there. I didn't check it out, but if it is an actual song, that gives insight into what types of music he listens to, and irc and the newsgroups again can be watched in these areas. Plus, the article mentions that he's 18 years old and from russia. That narrows it down a helluva lot. Talk to the ISP's that the ip's were from, and see if they have ANY logs... Caller ID, whatever. Also it appears that he goes by this nick often. Don't know if any of you know of +fravia and +ORC but they had many teachings on stalking on the internet...
So the question is: is there a good possiblility that this guy can be tracked down?
Re:Customers of CDUniverse (Score:1)
What does this have to do with online payment? (Score:1)
Re:Old Vulnerability (Score:1)
Re:a mini Ask Slashdot (Score:1)
Re:Damn-it-all: NOW CAN WE HAVE STRONG ENCRYPTION? (Score:1)
Re:Beat the system! (Score:1)
Well, the only reason this is possible is that the credit card comanies don't care. Introducting strong cryptography, challange-response protocols and real online banking will make such frauds nearly impossible. All these technologies exist, but why aren't they implemented? Apparently the losses of the credit card companies are not enough to justify the move towards stronger verification schemes. This is also fine with everybody - the card ownerers are not liable for more than $50 of losses and the hackers have an easy source of income.
Do a web search for "digital bearer certificates" and "Robert Hettinga" for some interesting ideas on the future of electronic payment.
Re:Staying offline won't help either (Score:1)
Re:Scary (Score:1)
Although I really do hate your negative way of giving feedback, after reading more interesting comments, I retrieve my comment for it was misinformed and outdated.
On the other hand, your comment almost pissed me off, no wonder you post as AC..
Re:Scary (Score:1)
What really scares me about this news, is that I don't understand why would a company how my CC# in a database? Do you give your CC# to your drugstore just because you shop there once a month?
Aren't there some sort of PGP systems to use CC# information, with the help of CC companies like VISA and MasterCard? If people are ready to invest $billions in online commerce, why can't CC companies (who are right anyways) develop useful open standards to protect consumers? (buzzwords rock
Re:Scary (Score:1)
Who said _just_ using a packet sniffer? You're over-simplifying the issue. The way I understood the original message was 'packet sniffing' as a _method_, and not as a simple act. Anyways, most things in life are very complicated, we just like to explain them in simple terms.
Signature (Score:1)
The Matrix is going down for reboot now! Stopping reality: OK. The system is halted.
That looks an awful lot like Redhat -- while The Matrix runs on FreeBSD ;-)
Re:Beowulf cluster! (Score:1)
Ahem. DO you do everything Linux does? Gimme a break. This has _nothing_ to do with Linux or Alan or Stephen or whoever. It's just a question of morlity.
Re:Better Security Method (Score:1)
Have a look at SecurEpayment [aba.net.au] for an idea of how credit cards should be handled. Through the use of an applet only the bank gets to see the customer's credit card number. The card number never goes to the merchant site.
I'm interested to know what people here think about this system. I've been developing PHP3 code that uses this system.
--
Simon
Re:Outdated information (Score:1)
Recently similar Federal laws were passed giving similar protection to debit card holders. According to this site [natlconsumersleague.org], there's a$50 or $500 limit depending on when you report the theft.
e-.com? didn't we have this discussion? (Score:1)
:)
Re:Storing cc details (Score:1)
Re:Old Vulnerability (Score:1)
Re:i'm suprised they did not pay him (Score:1)
Poor idea. Poor, poor idea.
Re:Multi Tiered security. (Score:1)
Re:Old Vulnerability (Score:1)
Would it even HAVE to be pay-ware? But that's beside the point - I for one, if I were developing an electronic commerce system and wanted it to run on Linux, certainly would consider such a thing. It's just the right way to do such things.
Re:Damn-it-all: NOW CAN WE HAVE STRONG ENCRYPTION? (Score:1)
Re:i'm suprised they did not pay him (Score:1)
Re:Boycott Slashdot ! (Score:1)
Why? Personally, I don't feel the need to boycott Slashdot, but I still filter out all banner ads from all sites I visit. I own my bandwith and computer monitor and I don't let anybody use my property for purposes I don't approve of. If they want to advertise on my computer screen, they have to offer me a good price for my screen real estate and bandwidth. Short of that, no dice.
--
I think it's good. (Score:1)
--
Re:CDUniverse was actually going to pay! (Score:2)
Here's the scenario:
1) Person uses social engineering to find out choice pieces of info about, say, a bank. Stuff the bank believes no one outside the bank knows
2) Same person uses same social engineering skills to determine, again, some choice info about the structure of the computer systems at the bank
3) Tha bank is contacted, told their systems have been compromised with suitable threats included in the "blackmail". Bad guy asks for money wired into an offshore bank account.
4) Bank assumes that the system have in fact been compromised. Not knowing the extent of the compromise, and being unable to take their systems offline, the bank makes the payment.
5) Bank may or may not contact the authorities about the situation. Contacting authorities increases dramatically the chance that the public will be aware of the "compromise"
6) Bad guys walk off with a few hundred grand without having broken into any system with the knowledge that their actions will likely not be reported anyway.
It happens all the time, cduniverse.com just happened to have the whole thing fall apart in their face, and this bad PR is the result.
People are dumb - not bank/processor/merchant (Score:2)
Look at this... People go shopping (online). Cool. They order something, they checkout, they get "CC authorized", and they're happy. They receive their item, and they are even more happy. But now, they want to buy something again, and... they need to input the information again.
LAZY PEOPLE ARE GUILTY FOR SECURITY PROBLEMS!
It's that simple. Because people are lazy, merchants (not PROCESSORS - processors are only a 'gateway' betweek a bank and a merchant) are storing the cc numbers on a server. And when sh*t happens - merchant is guilty, and those SAME lazy people are yelling around "how bad this company is". But they are the same ones who were sending complaints to support@your.favourite.shop.com about "I want my cc to be remembered!".
It just CAN'T be done securely (at least, not until bank gets REALLY involved, meaning - merchant/processor stores MD5 sigs of CC, and bank maintains the database, and compares; however, bank will do this only for HUGE client, since bank doesn't want to get involved into 'e-commerce' - they just want to authorize the cards) at this time.
Just look at computer systems... No matter what people think, most of the tests (talking about intrusion tests, not lame script kiddies defacing web pages) are at the end successful as a result of *weak* authentication schemes at some point. You get a FW-1 w/ VPN (and you don't have a budget to get SecurID or similar thing), but your 'CEO' is too lazy to remember password like '$!*C&*E', so he orders you to let him use 'john/john123'. And there goes your security... [I'm talking from experience]
And NOBODY is going to sniff you SSL connection and to crack it in order to get a cc number. Get real. It's not worth the time. Chances are that you'll randomly generate valid cc/expiry date before you manage to crack the key. At the end, it's not the 'connection' that you will attack, it's the site that hosts the cc information. I'm so tired of those 'packet sniffing' gurus that have started sniffit on local LAN and think how they've discovered the fire...
Yes, I've been involved in creation of 'payment gateways' for real-time cc authorization, so I *know* how painful it is, and how LAZY/STUPID customers are. As long as customer won't listen to techies just 'because customer is always right', there will be no security. When customers realize that techies don't suggest things because they like to bother other people, but because they want to do the things 'right way' - we'll have a progress.
It's pathetic to see how many companies expect their people to maintain perfect security, in all areas, but yet they limit IT budget to some silly amounts (that can't cover the costs of hardware needed, not to talk about other infrastructure, or software), don't want to employ more people to do security work, don't want to LISTEN to people who are in charge of security (no, we don't want CEO to have a modem connected to his PC, so that he can dial in whenever he wants, bla, bla, bla...), etc.
If there is no mgmt involved, everything would be much better. But right now, you have deadlines, you have marketing dept that always announces something you didn't have clue about (like, you make a payment gw, and you find out from the newspapers that your payment pw can easily be integrated with every shopping cart - yet you know that integration wasn't ever mentioned during the development, it was supposed to be 'ongoing process' after the gw is running 'live'). Bla, bla, bla... You should get a picture now, I hope.
Re:Signature (Score:2)
Re:Signature (Score:2)
HTTP/1.1 Server Too Busy (Score:2)
--
Re:Right. (Score:2)
Bullshit.
Store a cookie with some unique identifier and pass that identifier along with the $ to take to a secondary server which is not net accessible ot do the actual transaction.
Re:Yep... (Score:2)
All companies offset all incurred costs to customers. That's the way business works.
On a side note, this could have been avoided had law permitted better/higher encryption on the CDUniverse site.
Wrong again. This has nothing to do with encryption and everything to do with improperly secured servers storing customer's CC numbers in databases. Like I said in a previous post, servers should _never_ store the actual credit card number. I think a one-way hash (via MD5 or equiv) would be suitable for e-commerce infrastructures (eg a large db of them is useless to script kiddiez, and it still allows the company to authenticate).
--
odds of being killed by lighning and
Consumers Just Don't "Get It" (Score:2)
I work for a major hotel in Las Vegas and I can't believe some of the stuff I hear when I happen to be in the Room Reservations Department.
Many times I have heard a clerk spend a minute or more explaining to a returning customer that they can't magically pull up the credit card number from their last visit on the computer system. Sure we have the number archived for accounting and legal reasons, but it is in no way linked to the customer database.
I bet these same customers are the ones that are worried about packet sniffers on the Internet. They would probably have a fit if you mentioned how easy it is to intercept their number when they use that $19.95 cordless phone while giving out their CC number. But they expect that person on the other side of the line that they will never meet in person to have access to a database with the customer's CC number bundled with their name and address?
"Mommy, stupid consumers make my head hurt."
"I know dear. Just ignore them and they might go away."
Re:Old Vulnerability (Score:2)
They aren't a dime a dozen for a reason.
Re:Old Vulnerability (Score:2)
"Computer Security Basics" by Deborah Russell & G.T. Gangemi, Sr.
http://www.oreilly.com/catalog/csb/
"Computer Security Handbook" By Hutt, Arthur E. / Hoyt, Douglas B. / Bosworth, Seymour
http://www1.fatbrain.com/asp/bookinfo/bookinfo.
"Cryptography and Network Security: Principles and Practice, 2/e" by William Stallings
http://vig.prenhall.com/acadbook/0,2581,0138690
"Hacker Proof: The Ultimate Guide to Network Security" By Lars Klander and Edward J. Renehan
Renehan
http://shop.barnesandnoble.com/booksearch/isbnI
(This book really isn't that good, though. Some errors and tends to be too general)
Of course, you could always find an electronic copy of the Orange book itself online. It's out there, I just don't have a URL handy.
Re:Old Vulnerability (Score:2)
--
How to avoid storing credit card numbers (Score:2)
Another possibility is for the credit card verification company to issue a unique token which can be used only for billing to the same merchant. This data is stored in the merchant's databases and should be quite useless to anyone else.
----
Legal trouble for the victim is the right approach (Score:2)
If paying the blackmailer were to come with sufficient legal ramifications (huge fines, jail time, etc.), and actively prosecuted, companies and individuals will be more likely to cooperate with law enforcement rather than criminals. In a contest of jail vs. embarressment, or fine+public knowledge vs. public knowledge alone, the blackmailer will almost always lose. Without victims willing to pay, the blackmailer must fine another line of work if they don't have the human decency to simply starve instead.
BTW -- keep up the boycott. Financial pressure is a reasonable tool to discourage this sort of behavior as well.
Re:Multi Tiered security. (Score:2)
When developers do not understand development (Score:2)
Re:Yep... (Score:2)
If you think you're not paying for credit card fraud, think again. If VISA loses $1 billion in a given period to fraud, who do you think pays for it? That's right -- all VISA customers.
----
Re:CDUniverse was going to pay! (says cracker) (Score:2)
Certainly, though, you could write them off as a vendor after their poor attention to security issues.
----
Re:Staying offline won't help either (Score:2)
There isn't a high risk to using your credit card online, as long as you know who you're buying from (e.g. perhaps brandnewsexsite.com isn't the best place). We put our cards at risk in many other ways (e.g. 1-800 operators who are low-paid prisoners, the waitress who sneaks your card into her palmpilot reader while she's behidn the counter, etc.).
----
Re:Incidentally what's the URL :) (Score:2)
I could believe that this guy is just working alone without the help of his government the day pigs fly!
I find it much more plausible that he is an individual than that there is a vast Russian government conspiracy to shake down American dot-coms. But I wouldn't put it past the Russian mafia. (Most likely he did have help setting up that bank account.)
I don't see this as a government operation because it's just too small. There's more money in shaking down the US for space station funding, many times more money
----
Re:Beat the system! (Score:2)
And seriously, why should card owners be liable for *ANYTHING*? The card is just a symbol of the credit granted to the individual, not the credit itself.
What should I do? (Score:2)
Re:Scary (Score:2)
Packet sniffing is trivial, if you're inbetween the people who are communicating, and if you know what you're looking for.
I've personally seen a lot of people snag a lot of interesting stuff from the sniffing.
A friend in university wrote a program to watch for IRC traffic, it was pretty stupid, just grabbing things to the default ports, 6667 or whatever, and scanning for keywords. Found some funny stuff that way.
A guy I work with ran a small business which required net access, so they dropped the machine off at an ISP instead of getting dedicated bandwidth. Turns out all third-party machines were on the same 100mbps hub (the service was for T1-equivalent of bandwidth, so the ten or fifteen machines didn't saturate this)... They could remotely put the second network card (no idea why it had two cards.) into promiscuous mode, and by sniffing, they were able to watch all transactions from the other machines... Mostly mail servers, but a few web servers, at least one of which was taking orders. Mostly PO stuff, but still...
As long as you're inbetween the two ends, or on a hub with either end, you can see what they send, and if it's unencrypted, you can read it. Many ordering forms are still unencrypted, and if you watched for traffic to those sites, you'd probably get a few hits here and there. Not enough perhaps to justify it, compared to hacking into something to just grab a list, but...
Sniffing IS easy, and with some luck and skill, it's not hard to get stuff you shouldn't have access to.
Score (Score:2)
Re:CDUniverse was actually going to pay! (Score:2)
Quite likely, almost every major financial institution has done it.
Not that this is a good thing, just common practice.
LetterRip
CD Universe says... (Score:2)
Nothing compared to in-person transactions (Score:2)
This may seem scary, but the same thing happens almost daily in the real world. Hell, the same thing happened to me - a company I had had problems with in the past decided that they wanted me to have e 300 dollar DVD player, so they charged my card. Problem was, I neither wanted or needed it, and they couldn't/wouldn't cancel the order. Took me two months of wrangling to get it sorted out.
And I never touched a computer while making my original order with said Giant_Bastard_Company. It was all done over the phone.
I tend to worry more about the company on the other end than anyone in the middle or hacking.
The secure old banking network (Score:2)
My opinion is that 1200 baud connections are very very sniffable and consider that all this encryption is closed source, unverifiably secure. Ok, big deal. You'd expect banks to be closed source. Next we started to deal with a few other "gateway" companies like First Data Resources (of whom we havn't dealt with, but apparently are very good.. I'm still waiting for my programmers documentation). One particular gateway company has an exclusive arrangement with a local bank that a few of our merchants were interested in using. We went and spoke to them. They gave us lots of development information and talked to us for a few hours. After about 2 hours of talking about security, they showed us the reporting mechanism of their gateway. I casually asked: "So where is all this data stored?".. their reply: "Oh.. we maintain an access database on the local harddrive". A few minutes pass.. I ask: "So what exactly is stored in that database?", the reply: "Well, everything about the transaction", "Including credit card details?", "Of course!".. After informing them about the total insecurity of that I asked what else their NT based gateway had installed on it other than their closed source processing/report generating software. "PC Anywhere".. "oh, why is that on there?", "We like to dial up and do maintainence on the gateway", "Dial up using what?", "The tran$end modem".. so they want to dial up a box on my secure network using a 1200 baud connection over the private banking network to use PC Anywhere to access a database that includes credit card information. These people virtually represent the bank! Yawn. I took their programming docs and quitely told the manager with me that we would wait until we did our FDR development before we offered service to that bank.
Yes it has to do with encryption (Score:2)
Credit cards are still safe, even with fraud... (Score:2)
I have my credit card company by my side. My credit card agreement/contract protects me from any unauthorized charges and the credit card company will investigate any such charges. Of course, there is the problem of going through phone calls and other communication to get the matter straightened out, but not a single unauthorized/fradulent charge makes it past one statement!
So, if you are/were a customer of cduniverse.com, don't get too worried. You're protected.
Re:Beowulf cluster! (Score:2)
---
Re:Beowulf cluster! (Score:2)
---
Incidentally what's the URL :) (Score:2)
It's actually a pretty slick thing. Just unofficially get someone to crack a site and then blame him and you can just walk away.
Credit cards and online shoppig: a necessary evil. (Score:2)
The REAL losses are covered by 19.9%+ APR (Score:2)
Interest paid on a loan is free money. It's a part of the chain of how the economy grows:
The more interest the Bank can charge on a loan, the faster they get rich. They can afford to pay all the other incidental costs of the mistakes: bad loan risks, stolen merchandise on stolen cards, etc.
One late payment, and that "Low APR For A Limited Time" card of yours balloons to a ridiculous loan-shark rate of 19, 20, even 25% APR.
The large corporations don't pay the costs. If they did, they wouldn't be large corporations.
Re:This is why DEBIT card visa/MC are EEEEEEVIL! (Score:2)
Only if they got your card. (and in reality, the bank never makes you pay the $50). In this case, without the physical card, you'd be out a maximum of $0.
And just when... (Score:2)
--
One more reason... (Score:2)
Re:Incidentally what's the URL :) (Score:2)
http://www.pc-radio.com/maxus.htm
There's a strange client-side pull though, so be prepared to hit that stop button to be able to read the page (before being redirected to a non existing CGI script).
Cheers!
Costyn.
The real problem (Score:2)
The idea that the printed information on a card is enough to verify it is IMHO plain outrageous. It doesn't matter if a villain got my credit card number by cracking a site or from simply looking at the card. Paying for stuff giving only the cc number (and date) is as stupid as logging on using only a uid.
Multi Tiered security. (Score:2)
Put it behind a firewall (or even just shutoff all services on a UNIX machine) and only have a system to procces credit cards, and have it setup so it is only accessable from the web server, and then only accepts credit card numbers, and NEVER puts them back out. If the store wanted to store numbers for quick access by customers (I like this, although the security is definatly a problem), the system can a assign a unique reference to that card number that can be stored on the web server.
If this program is written carefully, and doesn't have buffer overflows, there would be no way to get the credit card numbers from it without access to that machine. How the admin wants to keep it secure could vary, the ultimate would be using a dedicated connection to the credit card company (I am not sure how all these work, but it would be the same as any POS system), and even console only admin access, although the admin may choose to trust some form of remote access such as ssh or ssl telnet, etc, and of course if that is compromised the whole above system is insecure, but I think it would be secure enough if the sysadmin stayed on top of things.
Credit Cards safe online.. for the most part. (Score:2)
Jeremy Allen
jallen@idminc.com
Beat the system! (Score:2)
Well, the only reason this is possible is that the credit card comanies don't care. Introducting strong cryptography, challange-response protocols and real online banking will make such frauds nearly impossible. All these technologies exist, but why aren't they implemented?
Apparently the losses of the credit card companies are not enough to justify the move towards stronger verification schemes. This is also fine with everybody - the card ownerers are not liable for more than $50 of losses and the hackers have an easy source of income.
The REAL losses are covered by the big corporations, and I couldn't care less about them. Don't bitch about the lack of security - it doesn't harm any REAL people, only corporations.
Re:Old Vulnerability (Score:2)
Combine this fact with this part of the "FAQ" on Maxus' site (mirrored here [pc-radio.com])
In other words, all he got were rather old credit cards. One might surmise that CDUniverse updated their CyberCash software, but failed to delete the log file you mention.
Re:Ive been saying it for years (Score:2)
Banks will regret not pushing SET. . . (Score:3)
Maybe SET was a bad standard, I don't really know. But the idea (transfer the money, not the card number) was highly sound.
Re:Credit cards and online shoppig: a necessary ev (Score:3)
Are you joking? (Score:3)
So you are saying there is some conspiricy of the Russian government & hackers to steal credit card numbers and post them on the 'net.
Why?
I find it is much more likely that he is an individual - like most hackers are.
Not everything is a conspiricy, you know.
Scary (Score:3)
Outdated information (Score:3)
HOWEVER, if you use a debit card you should still maintain multiple accounts, since there is usually a significant delay before your funds are returned. The people who get bounced checks might be understanding when you contact them, but they are not legally required to be so. I've known more than a few landlords who would not hesitate to assess substantial penalties, even start the eviction process, if your check bounces for *any* reason.
Re:Banks will regret not pushing SET. . . (Score:3)
It was credit card companies pushing SET, and the reason they failed to succeed was important (I think).
Nobody had real incentives to adopt SET.
You paid more to deploy it, and that was on top of the substantial aggravation to even try to get it going. You had little choice of suppliers (vs a dozen or more suppliers of SSL enabled web servers, on most any hardware you cared to mention), it cost two or three orders of magnitude more, and sacrificed almost all of the flexibility that enabled companies to construct innovative E-Commerce websites (the kind people wanted to use). Oh, and did I mention that it never seemed ready for real deployment? And worst of all, SET wouldn't work on most web browsers so you'd lose most of your potential customers right off the bat. Needed a "wallet", and let's defer talking about the security nightmares they involve ... right where they'll scare a user away from a purchase. Deploy software that complex on a global scale? No thanks, I'll pick the simple known-to-work solution.
The problem with SET is that it was too complicated to adopt. It was never a real option. As a "top down and centralized" solution, it was also completely contrary to the "bottom up, grass-roots" genesis of the web that we know today. And the perceived threat wasn't a new one; it's one that everyone dealt with already, quite effectively. There was no clear need for new technology; if you give a phone to a waiter at a sub-minimum wage, and to a telesales agent on the phone, why not to a website?
Yes, something like SET might have made this particular problem go away. But then, so do some incredibly basic security precautions ... this is a case, from what facts have come to light thus far, where stupidity explains everything.
Re:instead of you or mgmt deciding for the custome (Score:3)
Re:Good Not Good (Score:3)
2) He is still selling them for $1 / card, minimum of 1000. (See entry in his guestbook)
So, the person you are admiring is not the moralistic crusader you think he is, instead he is someone who used a known exploit to read the log file of a website that didn't bother upgrading the software they were using to fix a known security hole.
There is no-one in this incident to admire, that's including posters who are using this to push their own agenda (encryption, server OS software etc).
How many people encrypt their log files ? And how many people just make that subdir non-global readable ?
Instead, there are 300,000 people who are going to get put through a lot of trouble over the next year as these credit cards are doled out by this 'hacker' to his other teenage friends for phonesex lines and other wonderfully mature pursuits.
A quote from CDUniverse.com (Score:3)
What most people don't realize is that shopping with your credit card is actually safer than paying by check. In the event that there is a problem with your purchase, the credit card company will remove the purchase from your bill and the on-line merchant is not paid. In the event that your credit card number is stolen, the credit card companies do not hold you responsible for any unauthorized purchases.
So go ahead and join the six million other people that are experiencing the pleasure of on-line shopping.
So thats OK then! (well, I found it amusing anyway)
Risks of fraud online and at the store. (Score:3)
If you ever looked at that little "educational" thing called the anarchists cookbook you will notice that they have a fairly detailed scheme that demonostrates how to commit credit card/mail fraud using carbons taken from retail stores in their rubbish bins.
Customers of CDUniverse (Score:3)
wacko (Score:3)
Re:Customers of CDUniverse (Score:3)
The banks wil tag your file and if you catch the fraud on your card they will gratefully remove the charge. If you miss it and don't call your bank, your out of luck.There is really no incentive for the bank to call you and say "We've had a massive case of fraud. That $2200 charge on your account will be removed. We thank you for your business and want to assure you that crackers steal from banks all the time, this is normal, please don't worry, your money is safe with us!".
Not really good pr, is it??
Companies with small/no security view (Score:3)
Security seems to come second for alot of those companies, and it shows. No one with some sense of security would store credit card numbers with expiration dates of all its clients in a database!
Companies need to be educated about security, and users as well. We just had the proof that some companies who try to get users' trust are definitely not trustworthy.
Damn-it-all: NOW CAN WE HAVE STRONG ENCRYPTION??? (Score:4)
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?
Re:a mini Ask Slashdot (Score:4)
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.
CDUniverse was actually going to pay! (Score:4)
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 [mailto] and telling them why, too!
Banks should enforce TOS (was; Re:Banks ... SET) (Score:4)
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,
Re:Old Vulnerability (Score:4)
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.
Storing cc details (Score:4)
Here's a mirror (Score:4)
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.
Re:Storing credit card numbers (Score:4)
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.
Re:Old Vulnerability (Score:4)
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?
Don't be so sure (Score:4)
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.
Ive been saying it for years (Score:4)
How To Collect Credit Card Numbers (Score:5)
CALL YOUR BANK NOW (Score:5)
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 [bankrate.com] 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.
----
U.S. Consumer Banking Laws (Score:5)
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. [fdic.gov]" If I was a customer of this company I would call my bank and cancel my card ASAP.
Most e-sites secure... not that scary... (Score:5)
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 $.
Re:Staying offline won't help either (Score:5)
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.
Old Vulnerability (Score:5)
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).