Slashdot Mirror
MSNBC: Stealing Credit Card Numbers Online is Easy
tiny69 writes "This is the reason why I don't use my credit card on the internet. The people I give it to may not be as responsible as I would like them to be. It's easy to point the finger at Microsoft and the MCSE's running the systems on this one." [Irony alert!] Yes, MSNBC says all the servers they cracked were running MS SQL. [/irony alert]
If you haven't already noticed, most of the servers which are used by businesses are Win NT. Maybe if businesses used UNIX instead you'd see UNIX SQL installations getting cracked. UNIX owns the college and hobbyist world for 50% of the internet, but Win NT clearly owns the part of the internet that deals with business. Just read Alan Cox's diary. Every business server he deals with is running Win NT whether it's catalog orders or metro stations. Not a single business server he mentions is running UNIX. Not a one. Just because colleges and hobbyists account for over 50% of the internet doesn't mean that businesses are flocking to UNIX, which they obviously aren't.
I mean - people are willing to call a complete stranger on the phone, and give them their credit card number. Same goes with a waiter in a restaurant, for example. I guess there's more potential for abuse online, since a list of 1000's of numbers might be available... but using a credit card in almost *any* fashion has the potential for abuse or theft.
----
I've read through alot of these posts, and there seems to be two common threads to most of them:
I think both of these need to be addressed to see the underlying reasons for the problem, of which neither of the above are.
First off, I'm a professional SysAdmin, and have spent most of the last 4 years doing System Architect and Security stuff. The last two at E-commerce places.
People, the problem is threefold, none of which is easy to fix:
Virtually nothing is designed with security in mind. That includes all our favorite UNIX OSes, Windows, and virtually all applications. The few apps that seem to have some reasonable security setup often sacrifice this by using stupid defaults to aid "ease-of-use". The sad fact here is that nothing we are using these days is decently secure (no, not even OpenBSD). UNIX is stuck with the all-or-nothing model of security, while Windows actually has a good model that is horribly implimented. Apps tend to be the same. Given that the systems are poor to begin with, hardening them is more than difficult. And compromises tend to do massive damage.
Business is not taking security seriously. Right now, time-to-market is king, and everything else is sacrificed to that great Idol. This is primarily the public's fault, as people seem to reward cheap and first rather than more expensive and well-designed. The miserable state of software quality is a prime example of this mentality. And bugs are a leading cause of security problems.
Also, companies have limited resources. Right now, spending the extra money to shore up security (or maybe even - gasp - do it Right) is about as likely as giving the entire staff a free vacation to Tahiti. They simply have no reason to do it - there isn't much real PR problem, the public doesn't seem to reward companies that spend the extra on security, and there aren't really any legal liabilities yet for failing to do so. So why spend money on something that doesn't have any real returns?
Security is an ongoing battle. This is related to both the previous problems (lack of proper resources, and poor security to begin with). In order to keep a site even basically secure, it's far more complex than simply keeping an eye on BugTraq and watching for vendor security updates. A typical mid-size e-commerce site probably has at least 100 different products (remember, each script is a different product) to keep an eye on, covering at least a dozen (nowdays, with ASPs, likely several score) machines. Just keeping up to date is a daunting task, and like fighting a really war, the opponent isn't stupid, and adapts rapidly. You will suffer defeats. Security is a massively complex and difficult job. Don't let anyone kid you otherwise.
The knee-jerk reaction to fire the admin is merely a Management-covering-their-ass mentality. Blaming the product overlooks the reasons why the product is that way, and also doesn't say anything about the state of the market as a whole.
Until there is a concentrated demand from the public for security, things will continue to be as they are. If the public can stand it, well, then that's the shape of the world we live in. If they don't like it, give business the incentives to buckle down - make them legally responsible for breakins, buy only properly-designed software, etc. Until that happens, blaming the admins and the software is stupid.
There are always four sides to every story: your side, their side, the truth, and what really happened.
People, the credit card numbers that MSNBC stole were not stolen through a "cracked" database. MSNBC did no cracking of any kind, and therefore the security of MS SQL Server is not the issue. The issue is, once more, the people who stupidly set the sites up and left the default "sa" account active. The "sa" account is included in SQL Server merely to allow the software to be set up. It is not meant to be left active on a server connected to the web.
Try cracking a Microsoft SQL Server that's been configured correctly, by someone who actually has half an idea what they're doing. It's just as impossible as cracking any other database solution...in fact, I'd venture to say MS SQL Server is even more secure than most other database servers.
Furthermore, the "::$DATA" vulnerability was only in IIS4. Microsoft patched that bug over two years ago, and anyone stupid enough to still be running an unpatched IIS4 server is just asking for trouble.
--
I won't go quite as far as the poster about abstaining from online credit card purchases, but I do have a method by which I can at least identify the culprit company if anything goes wrong.
Whenever I make an online purchase, I use the name (or first initial) of the company as my own middle name. That way, if someone steals my personal info, emails me spam, or any number of invasions, I will know instantly from the name on the billing which I company I should never use again.
Of course, this does nothing to prevent your information from actually being stolen in the first place...
-konstant
Yes! We are all individuals! I'm not!
-konstant
Yes! We are all individuals! I'm not!
I can't understand why people refuse to buy things over the internet.
First of all, if someone makes a purchase with your credit card, but you haven't actually lost the card, then you are liable for nothing. You have nothing to use!
Credit card theft and fraud occur without the internet. Your wallet/purse can get stolen. In that case, you are liable for up to 50 dollars. A waiter or clerk can copy down your numbers.
The risk isn't any greater at all, but fear tactics from the media like this MSNBC story don't give a sense of proportion.
No comment at this time
But anyway, all the attention to this issue is probably a Good Thing. Popular Internet e-commerce servers are bound to have quite a bit of credit card numbers, along with other goodies such as the name of the owner and the expiration date, floating around, and it's time that a people became more clueful about how to handle this situation.
Face it: any setup where both your webserver and database server are available from the Internet is a major security risk. The way most e-commerce shops, especially those running at hosting companies, are set up today (webserver and database server on the same machine, or at least the same network without any access controls) is simply asking for trouble.
Here are a few reasons why: ::$DATA issue, although most clueful providers will fix it quickly.
Software bugs - and no, not running any Microsoft products won't get you off the hook. In fact, I guess the cozy little MySQL password security exploit that was discovered recently is way worse than the
Untrusted staff - how easy is it for a rogue operator at your provider, or a lowly-paid temp working for the shop itself, to run a complete copy of the credit card file?
General data security - in other words: hey, do you know who else has access to your shared database server, or where the backups go at night?
All of the above leads to a few conclusions:
1. Partitioning - Web and database server functionality should be separated as much as possible: having your database on a separate machine and fitted with proper access controls (i.e. only accepting connections from trusted hosts and using proper authentication in addition to that) is pretty much a requirement.
2. Encryption and access controls - Even with proper partitioning in place, most of your customer details need to be encrypted using a non-trivial scheme, and proper access controls need to be put in place. Make sure only the right people have access to your data, and log every access. Disable bulk commands, except during the backup window, if possible.
Now, which percentages of sites is operating as described above today? My guess would be less than 10%, leaving enough room for on- and off-line crackers to steal whatever information they want. It's not consumer problem per se (since credit card companies have pretty extensive consumer protection from fraud...), but still a lot needs to be done before the general public will truly get a warm fuzzy feeling about on-line shopping...