Slashdot Mirror
Caveat Emptor: Egghead.com Credit Records Nabbed
Voorshwa and at least a dozen others wrote with this news: "Found this one over on ZDNet.com news. Turns out the security over at Egghead wasn't very good. Losing 3.1 million credit card numbers has got to put a damper on a lot of Christmas cheer!! Wish these big companies would learn a little ..." No yoke. It's too bad that this kind of theft will probably scare people away from online purchases even when it's a database that's cracked rather than their transactions. Reader insmod points to coverage at MSNBC as well which mentions that Egghead was not the only site hit this holiday season.
It is for this and many other reasons that companies should be prohibited from keeping personal information beyond the immediate transaction between the consumer and the company. It's the law in the EU, and it should be the law here.
I am a former employee of egghead. I was let go because I downloaded a remote admin tool, so I could connect to my home windows boxen. I also had putty to ssh into my linux boxes. They found those tools to be "hacker tools" so they let me go. The entire IT security team consist of two people. Everret and Ben, they are two 20 something year old punk asses who lack a basic knowledge of computer security. Egghead security consist of daily virus checks of the work stations and a firewall. THATS ALL. Because I am young, they automatically assumed I was a hacker and a risk to security, when I got a job there doing Ecommerce Analyst work at my young age. Young does not equal hacker. I still was never given a reason as to why I was fired, except for that if the media found out I had remote admin tools on my workstations it could be bad publicity for the company. Now this comes along, Im suprised i havent been blaimed for this attempt. Unfortunate, if they would of hired me on as IT security like I wanted to be int he first place, this would of never happened. :P
Jeff Knox
All I wanted to know was: credit cards stolen, yep, they're using Microsoft. This is the exact same type of image mongering, fud slinging, guilt by association that Msft mktng would gleefully use to smear any competitor, so I've no qualms whatsoever whenever something like this shows up in the public prints that puts a big fat egg pie in their face. Tit for tat, bubba.
try { do() || do_not(); } catch (JediException err) { yoda(err); }
If MC and Visa aren't already doing it, I would expect them to start including a clause in their merchant contracts (which allow merchants to process credit cards) that if the merchant has a large number of credit card numbers stolen, the merchant will have to pay some sort of damages.
Software sucks. Open Source sucks less.
Since it's my quote, I'll defend against the FUD charge...
../ bug.
It's a fact that most reported Web Site compromises for Microsoft sites happen via IIS. It's also a fact that most of those are RDS. It's another fact that the last significantly visible break-in was reported as the Unicode
The quote is definitely based on currently available information. It's also got a greater than 75% lieklyhood of being the true vector of attack. FWIW, we also called the Microsoft vector of attack correctly about two days before MS figured it out.
I challenge you to take the top 6 IIS exploits and run scans against your ~60 NT sites and report the results. If they're not all virtual servers, I'd bet you'll find at least 30% of them vulnerable to one form of attack or other.
Given the initial information circulating in the press and in the community, I blamed the attack on incompetent administration. While IIS has more holes per pound than Apache, it's trivial to make any Web server vulnerable, and I was careful to state that it didn't matter *what* server you were running (and Rob quoted that at the very end of the article- so it was obviously clear to him that my intent was to ensure that he understood that the likelyhood of the attack being due to poor administration was fairly high.)
If you design sites where the DB is on the same server as IIS, you'd better get down off that high horse, you bear some culpability for poor design practices.
Paul
http://www.pauldrobertson.com
AMEX isn't so great, either. I spent the better part of a year trying to get them to remove over US$12,000 in bogus balance transfers to my "Blue" account.
These transfers were not authorized by me, were from accounts that didn't belong to me, and went through before I had received the card in the mail, or indeed even knew the account number.
AMEX, when I finally rattled enough cages to get them to look into the matter, removed the charges as 'Fraud'. They refused to explain to me how this fraud occurred, without being subpoenaed. But you figure it out. It was either an inside job, or there was some hacking involved somewhere.
They pissed me off so badly, I did up an entire website about their piss-poor customer service, and I got threatened by their lawyers over the domain name. The site has been down since the problem was finally fixed, but I just threw it back up into my webspace for anyone who's interested in reading it (there are a few things that need to be changed before I make it a permanent part of my forthcoming personal site).
~Philly
MS is the largest software company in the world. I just went to Borders tonight for some last-minute Xmas shopping. The store is FILLED with books on MS products, and many of them have large, reasonably comprehensive sections on security. There are probably millions of MCSE's and similar MS** professionals out there. The MS KB is FULL of articles on securing the machines. Bugtraq and NTBugtraq are likewise full of articles - good, technical ones - on security flaws, the NT/IIS security model, and security in general. ALl of these comments apply to Oracle, as well.
Why can't they secure the fscking box, then?
Personally, I believe that this is not a question based on the techical merits, rather, the social or cultural merits. These kinds of problems are, in the oh-so-eloquent words of my father, "dumb-boy shit".
I don't think IIS is inherently insecure; I think the computing model promoted by Microsoft - that an accountant, secretary, or poorly-trained nobody can set up a fully functional e-boz site - is the inherent insecurity. That MS's "bring computing power to the masses" crusade is what's biting them on the ass.
ZOMG I WOULD LOVE TO KNOW ABOUT YOUR FEELINGS ON MACINTOSH VERSUS WINDOWS, VI VERSUS EMACS, AND HOW YOU'RE NOT A DORK
The backend of the system is MACS or what's now called ecometry from Smith-Gardner. The main part of the system runs on an HP3000. Since until recently there wasn't a secure web server on the 3k they used NT/IIS to front end the system on the web.
So was it actual access to the 3k?A problem with NT/IIS?
A weakness in the S-G software?
Bad home grown code on eggheads side?
Poor security practices?
The later is my guess... it would be rather hard to get to the 3k if it was firewalled properly.
By the way the Smith-Gardner software is fairly widely used... if you don't believe me take a look at http://www.ecometry.com/clients/cl_list.htm
Shouldn't EggHead be held responsible for the loss of those CC#'s? As in, there were plenty of industry-accepted techniques for securing CC#'s that they didn't use. Shouldn't they be legally responsible for, at the very least, all costs to the credit card company of dealing with bogus charges and replacements on those cards? I really don't think the credit card company should have to pay. suppose it costs $10 worth of time and resources to reprint a CC. thats thirty seven MILLION dollars that I really don't want to pay for in the form of interest rate hikes. I think the CC companies should file a lawsuit demanding recompense. Yes, it was bad luck that it happened to egghead. but they were negligent. In the same sense that if I don't put a fence around my pool and some kid drowns in it, I am responsible because I was negligent. Perhaps that very direct cost to egghead would help wake up the industry to this very real danger.
- I never shopped online there
- When I shopped at their old brick and mortar stores, the credit card I used then has long since expired, and I cancelled that credit card account.
-
Any kiddie can find a script to generate fake numbers that pass the crc tests that they use.
That being said, since I do shop online from time to time, you would expert that they could do better. That is a rather large amount of plastic.Maybe that is how Saddam Hussein is paying for all of those Sony PS2s
"It is a greater offense to steal men's labor, than their clothes"
Is it any suprise that they are using MSIIS for there server? Or that the crackers almost certainly used a well-known exploit? Or that their server software probably did not have the most up to date patches installed?
This doesn't even begin to address the issue that I (and apparently others that have commented above) feel that storing CC#'s after the transaction has finished is highly negligent. When you go to a restaurant, do they maintain a database with your CC# to speed up your next purchase? NO! If they did, there would be serious hell to pay. So why to e-tailers (god I hate e-words) feel that it is an acceptable practice? And then they have the nerve wonder why people have little confidence in purchasing online. It's because we are not morons!!!
Security is always less strong than it's weakest link. It's about time that people start taking that fact seriously.
Its an Oracle database. I worked there, I know.
Jeff Knox
BZZZZT
You can store the transaction number which does not contain the CC number at all or a way to generally access the account AND just MAYBE the last 4 numbers of the card.
I have written several e-com sites and dealt with cybercash and authorize.net... customers HAVE gotten their money back on purchases but we dont store credit cards plain and simple.
And if you REALLY must store them oh please oh please encrypt the damn things and store the private key EXTERNALLY, the simple version is you have to type the thing eery time, typically we make the customer enter it in twice just for verification because I personally have only worked with one site where we stored (encrypted using a public key with priavte keys far from the net) which was only for bad cases or customer service, the process to retrieve a CC from the DB was pretty easy but still took human intervention.
Overall if your storing them as plain text you DESERVE to be hacked big time.
That is just how it is
Excuse the formatting of my post I just wanted to mention this, thanks.
Jeremy
This incident underscores the usefulness of one-time credit card numbers, such as those provided by American Express' Private Payments service. This service allows the cardholder to generate an account number for each transaction. So if that number is stolen from a merchant's database later, it's useless. This also comes in handy for preventing unauthorized billings from the same merchant later on.
There are two ways you can spend money using your credit card. In meatspace, you hand a cashier your credit card, they run it through a machine, enter the amount to charge, its deducted, and if they're smart, they'll ID you to confirm that it really IS your credit card, or at the very least, you have the same name as the cardholder. Then you sign the receipt.
The other method is calling someone on the phone, or using the internet, reciting the credit card number and expiration date, giving some personal information and the charge goes through, no signiture required, no problem until someone (hopefully YOU) gets the bill.
Well, credit card companies, at the option of the cardholder, should be able to implement some type of confirmation scheme to prevent anyone with your credit card number from actually using it. For instance, if I provide my credit card to a company, I would then have to validate the transaction (by phone or web page) using information not provided to the merchant before the money would actually trade hands. For convienence, this could also be done in advance, or allow a certain merchant to always be authorized, so although that merchant could always charge the card, nobody else would be able to.
Since the service would be an optional one for cardholders, it would not infringe on anyone's convience if they're not willing to go through the extra effort to avoid having their card maxed out by someone ten thousand miles away. We have to assume that credit card numbers will get stolen and distributed. You can't rely on the security of some website or server to keep that information safe, as you have no control over that security.
Perhaps I'm missing something obvious here, but this seems like a good idea to me.
-Restil
Play with my webcams and lights here
why do all these companies insist on storing credit cards in plain text, let alone storing them at all? is it really that hard for people to pull out their wallet and type in their card number each time they want to buy something?
if these companies insist on storing credit cards on their servers, why not encrypt them? since just about every site that would store your credit card makes you login with a username and password, why not encrypt them with that account's password? this way if the security is comprimised, they'd have to brute force every single account to get each one's credit card number. if you use a strong password on the system, you won't be subject to the site's lame security should their database get illegally accessed.
Comment removed based on user account deletion
But why have they not contacted me? Email is an EASY way to contact customers, yet they haven't.
They keep your CC# on file indefinately, even if you have your account suspended. I honestly don't know why they keep your CC# in the databases?
This is always the problem with all these sites that a broken into.
Plus, for pete's sake.... deny (YES DENY) all select requests on the tables that contain cc#s... if your database can't deny SELECTs then you need a new DB server!
Ever need an online dictionary?
Encrypting data in a database that a server uses means that the server has to have the key. That lowers the value of the encryption. It also doesn't provide a good scale point- that doesn't mean it isn't a good thing, it means that it's not always a likely thing.
There's been ongoing debate in the INFOSEC community and computing community at-large about the culpability of a vendor who knowingly fields bad software (the 32,000 known Win2k bugs fly immediately to mind)- in the automotive industry a manufacturer who knowingly fielded an unsafe product on such a scale would be sued into the poorhouse. Bridgestone/Firestone probably unkowningly fielded unsafe tires, and if they'd not done the recall, Congress and/or the court system would have stepped in because of the fact that they knew after the fact that the adhesive wasn't good and didn't rush to pull out the products until they had to. It's only the computer field that really hasn't felt the pain of product liability- licenses notwithstanding it's bound to get a legal precedent sooner or later.
Like many others, I feel that eventually we'll see some manufacturer culpability, and I don't like the idea of it at all. I'm even more worried about its impact on free software. Though with freee software the potential is probably less because you can pick what you use and fix it if it doesn't meet expectations, with commercial closed-source, the vendor picks when it hits the market and how it functions.
The thing I have little tollerance at all for is the lack of responsibility being placed on the attacker. We should be vilifying the hell out of people who have the ultimate responsibility for producing badness and creating victims out of consumers irregardless of the culpability of either manufacturers, retailers, adminsitrators or anyone else in the chain. In a lot of states, if a motorist has a chance to avoid an accident and doesn't- regardless of their fault in creating the accident conditions, then they bear responsibility. We need to focus more on that responsibility on the behalf of attackers.
On the DB thing:
Typically, running the DB off the same box give you the problem that the entire database is on the same likely to be compromised machine. So are the keys to the database, and that means that it's significantly easier for an attacker to grab all the cookies and go home to eat them. Also, SQL Server is its own nightmare of twisty waiting-to-be-exploited passages (as is Oracle for anyone out bias-hunting.)
Happy Holidays,
Paul
http://www.pauldrobertson.com
"It's too bad that this kind of theft will probably scare people away from online purchases even when it's a database that's cracked rather than their transactions."
It's even WORSE when databases are cracked! I can easily call my credit card company when I have a dispute to a charge or suspect my credit card is screwed, but if millions of card numbers are stolen, then millions of people have to deal with it. Credit card companies probably don't like having to notify or handle millions of irate customers with disputed charges, and probably don't like having to re-print new cards for all of these cardholders. This is really sad, that this was even able to happen, and that Egghead left the credit card numbers on their server. If they'd be backed up to another computer that only has a hard connection while the backup is in place then this would much more difficult.
"Titanic was 3hr and 17min long. They could have lost 3hr and 17min from that."
IBM had PL/1, with syntax worse than JOSS,
And everywhere the language went, it was a total loss...
I don't get this. It would be technologically trivial for the merchant to forward the credit card number and acount info off to the CC companies, and get back some a big n-bit number, consisting of enough information for the CC company to identify the card and the merchant authorized to use the card. Then, the merchant could totally forget the CC number forever, and just use the ugly number it got back from the CC company for any future correspondence with the CC company.
It's a long way from being a perfect system, but unlike other processes I could think of in the 30 seconds it took me to read the slashdot blurb, it wouldn't involve putting any additional software on the consumers machine, and it wouldn't involve any change in the habits of the consumer. And it wouldn't be painfully difficult to implement it for new e-commerce sites, and it wouldn't be particularly difficult to retrofit onto old e-commerce sites, either.
Oh well -- it wouldn't be much harder to implement a much more secure system than I described (i.e., the merchant wouldn't know the CC number either), but it seems credit card numbers are generally considered "disposable" by now, anyhow. There is certainly no effort made by anyone to actually keep the silly things secret.
Slashdot is jumping the shark. I'm just driving the boat.
Apache is known to have zero security flaws.
[This was the note I received from Egghead regarding whether or not my credit card # was stolen or not.]
Subject: IMPORTANT MESSAGE FROM EGGHEAD.COM CEO
Date: Sat, 23 Dec 2000 09:43:41 -0800
From: "Egghead.com Special Update"
To: mcdan@CSI.COM
Dear Customer,
Egghead.com has discovered that a hacker has accessed our computer
systems, potentially including our customer databases. While there
is no indication that any customer information has been compromised,
as a precautionary measure, we have taken immediate steps to protect
you by contacting the credit card companies with whom we work. They
are in the process of alerting card issuers and banks so that they
can take the necessary steps to ensure the security of cardholders
who may be affected.
We wish to underscore that we have taken these steps as precautions.
We have no information at this time to suggest that any credit card
information has been compromised. We are investigating this possibility,
and we are doing everything we can to proactively protect you. If you
would like further information, you may wish to contact the issuer of
your credit card to determine what steps they are taking. We regret any
inconvenience this may cause you.
We issued a press release on this matter earlier today. It is appended
below this message. If you have additional questions, please call our
customer service team at 1-800-EGGHEAD (344-4323).
Respectfully,
Jeff Sheahan
President & CEO
Egghead.com, Inc.
[There was a press release below this but I cut it out. It was standard business stuff.]
--
Have fun: Join D.N.A. (National Dyslexics Association)
In practice, I wouldn't be surprised to find that Amex's database does include the customer's permanent credit card number, but that's an implementation detail. There's no question that any way you look at it, one-time numbers really do add significant security.
It's too bad that this kind of theft will probably scare people away from online purchases even when it's a database that's cracked rather than their transactions.
Be it a hole in SSL or a lazy/stupid box admin that opens up the door for crackers and script kiddies to get access to your info, the fact remains that you have an annoyance on your hands. Canceling card, getting new card, notifying ISPs and other of the change in information.
I'd rather spend the time to drive to the mall, I can look at women in tight pants at the mall. Hell, maybe even score a phone number.
LK
"Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano
At least the cracker could use one of those numbers to send the sysadmins a recovery care package:
pizza
Mountain Dew
1/2 ton of candy in Christmas colors
151 proof "eggnog"
If you don't connect a box to the Net, you can't send it data (I condsider anything connected to a box connected to the Net to be connected to the Net, so that's possibly symantics in a first vs. second order connection, but I think an important distinction.)
I'm curious as to why you'd poll the database looking for unencrypted data versus arbitrating all DB access through a data broker that ensured it? In either case, the Web server has to be able to request and obtain the clear data, and while stored procedures are obviously the way to go, I've been hard-pressed to come up with a way to rate-limit the server's access to critical data if the server needs it (obviously CC#'s aren't the type of data a Web server needs access to, and stored procedures and second servers for customer service reps. fill that need quite well.) Especially in the "hundreds of thousands to millions of customers" category where queries per second are sometimes hardware limited instead of DB limited.
I've also asked folks to implement middleware changes in the past that would disallow any wildcard query and alert like hell on them. That helps reduces worst-case exposure pretty significantly even though it's not a 100% ideal solution.
My point on the number of bugs was twofold- first of all, I think that it's indicitive of the legal climate that such realities could be aggressively tilted toward contributary negligence. Secondly, one of the things that we rely on in the security community is history. Historical exposure provides significant help in determining relative security. For instance, BIND, which I now refer to as the "Sendmail of the 90/00's" has historically been insecure. Choosing DNSCache is more than likely going to produce a more secure system. It obviously shouldn't be the sole criteria, but I think it's important to add historical context to any architecture design decision.
OS Zealotry has such a limited place in any technical discussion or plan that it's minor, no matter what side the zealot fall on, but number of bugs does indeed indicate quite a bit once you normalize the results somewhat.
I've found history and current bug severity and number to be accurate in chosing firewall vendors, and in choosing at what point a firewall vendor has changed development/QA processes enough to significantly impact functionality (it's a shame there's not a money-back critical bug metric in software contracts.) 32k bugs says one good and one bad thing. It says a lot for the QA process and a bad thing about the development/release process. But then I originally worked on mainframes where you got a couple hours of scheduled downtime a year if you were lucky and vendors who produced significant recurring bugs got thrown out on their asses quite quickly.
I'm pretty happy working to secure alomst anything, but there are a lot of choices that I wouldn't make to host data *I* personally was responsible for the security of (Irix springs immediately to mind in its non-trusted varient.)
You should pause and ask yourself what the catchy number of bugs says about the design and implementaton of Win2k. The reason for its slow adoption curve is because that spoke volumes to a lot of people. Granted only a portion of those bugs have a significant security context, but security is but one piece of the whole. Win2k is where NT should have started in regards to features and stability, and I've little personal patience for any vendor who wants me to pay for QA (MS certainly isn't the only vendor on my list, just the extreme case.)
In an ideal world, we'd have easy to use and administer compartmented systems. Compartmented systems fly in the face of Microsoft's productivity in producing OS', and I see that as a potential problem moving forward- we're only starting to see the tip of that iceberg now in process-based protection mechanisms failing with very recent MS products. As usual though, security is always about compromise and securing what you have instead of what you might want. In an ideal world, OS' are commoditized to a point where it doesn't really matter which one you use and you can pick secure ones for secure purposes. That however flys in direct competition with every commercial OS vendor. It'll be really interesting to see what IBM does with AIX. SGI actually gamed it out early, but it doesn't seem to be overly important that IRIX is basicly EOL'd as far as their sales go.
Ah well, if the world was the way I'd like it to be, I'd be looking for interesting work...
Happy Holidays,
Paul
http://www.pauldrobertson.com
Thier is not 15 databases. They have Worfin, and Blue which are the main databases. Then thier is Lectroid which ARC (the software the customer service and sales reps use). Worfin is the main database, which is live, and Blue is updated at midnight. Lectroid (and I think one more, I forget its name) are updated in semi real time. So, if they cracked one database, and not another, it really doesnt matter. They have identical content, except that they might be one day behind in content then another database. So best case senario, they hacker got all the data upto the day before, I didnt get any new customer data the day he hacked it. Which is neglible when you think about how many credit cards he stole whole. And Im quite sure they would know which one was stolen, unless the IT people are stupider then they were when I left egghead.
Jeff Knox
If your CC number is stolen, just call the Credit Card company and have them cancel the charges. The only people who lose any money in thefts like these is the CC companies themselves, because it is actually cheaper to let things like this slide than it is to pursue legal action or even track the people down. And, frankly, I don't think I will be crying for them any time soon.
Friends don't let friends use multiple inheritance.
Um, actually all Visa card numbers begin with the number four. Get your facts straight
-atrowe: Card-carrying Mensa member. I have no toleranse for stupidity.
[We can take this to e-mail if you'd like]
;)
;) I just don't think that 2k brings anything significant to the table to make it worth the embedded device premium- you've still got the same driver difficulty issues and none of the source to fix them. Hardware's getting cheaper- why spend those revenue dollars on driver development? That's why "embrace and extend" and MS-only features are necessary to them, they're not scaled to compete any other way at the low end where volume would devalue their mid-and high end stuff. That's also why they need desktop and server OS merging.
;) )
NT4 Stability:
It's a combination of hardware, load and additional softare. These days it's *extremely* difficult to depend on a single motherboard being manufactured for more than 2 quarters, so I'm leary of anything that's hardware-finicky or driver related (having just had to try to track down some video and Ethernet chipset stuff, I'm particularly sensative to this at the moment.)
I've seen certified hardware with unescapable problems and random issues, though not as often as grab-bag stuff.
Bugs:
In the best environment, 2/3ds of bugs are known- while most won't have a direct security context, 1% of them would be pretty significant. I don't like at all the fact that Microsoft will release a product that they've no intention whatsoever of ever fixing/finishing. Instability has been a next release selling point for them, and that bothers me a lot, but mostly morally.
Some people like the idea of microkernels, I'm not convinced they have any real-world advantages, and side with Linus on that front. Given the APIs, I'm not sure that Win2k qualifies as "micro" anything
You should try Apache under NT, it's been threaded for what about 2 years now? The server is modular enough that if you spend some time with it, you can pare it down pretty significantly, and it handles named virtuals as well as anything.
ACLs are only a beginning. If you want to see how a secure OS is built (secure to the level of potentially being able to give out writable CGI directories and open shell accounts and not worry about compromise) check out http://www.rsbac.de. That's the major advantage of an Open Source OS, for a relatively miniscule sized chunk of code (not to belittle the effort, the effort was and is tremendous) RSBAC gives us role based stuff (No more superuser compromise), full ACLs, Mandatory Access Control, compartments, malware control, and the European Privacy Model. Better yet, it's not just an implementation, it's a framework for creating new security paradynes. It's securelevel taken to the next level. That's where small *secure* dedicated machines should spring from. Best of all, it's still able to run normal programs. The only thing it could really use is more socket-oriented stuff, but there's already enough to use and gain from significantly as a base for secure systems.
Don't even get me started about Exchange- you *can't* pare it down, SQL Server is monsterous- very secure doesn't come in packages that large without a lot of dedicated work that MS will never do because it's not profitable. Lovebug's spread had help from Exchange's architecture issues.
They've already got massive version control issues with the current Service Pack/Hotfix stuff adding more products would be a death knell for QA. Regression testing is probably their longest lag time to fix on critical issues and why SPs take so long to get out and can't have last-minute fixes incorporated.
Given the inroads Linux has made into the high side, it's inevitable that MS will have problems down the road getting the successor to Win2k adopted since Win2k is at least mostly-stable.
Personally, I don't think Embedded NT stands a chance against Linux/*BSD. But I've been wrong before. Twice
Back to real-world stuff- It's certainly possible to run real-world sites on NT, and we have no problem certifying our customers that do so once they've gotten through the essentials, but the level of dillagence for IIS is higher than that for Apache (mod_rewrite's last bug is the only significant security sensative Apache bug for a while now if you've configured conservatively.) Obviously because on-going reporting and testing are a part of our business, IIS is good for our model. Just like Word and the Macro Virus problem though, I personally think there are a lot of better choices that make more secure platforms. Beta was better than VHS though- and now the only Beta is the broadcast stuff, not consumer stuff (that wasn't one of the times I was wrong though, I went VHS all the way
BTW: I was serious in the first post about trying the top few exploits against your IIS servers- the last time I saw someone do it on what seemed to be well-managed sites, the results were astounding.
Best wishes,
Paul
http://www.pauldrobertson.com
I'm sure the guys(or girls) with 3.7 million credit cards are pretty cheerful right about now.
-atrowe: Card-carrying Mensa member. I have no toleranse for stupidity.
Its actually a bit harder to use than everyone on slashdot wants to believe. If you order something sent to an address other than the one listed on the credit card company, chances are they'll call you to confirm it. Even if they don't most people will catch unauthorized use pretty quickly, and under federal law you're only liable for up to $50 of unauthorized purchases. Only real problems start if you don't catch the credit card use fast enough, and let the thieves go wild for an extended period of time. And then unless you have an unrealistically high credit limit they won't be able to charge too much before they're maxed out.
--
You can also use one-time credit card numbers with Discover.
All ye need is the registered name and address of the card holder, the card number, and the expiry date. And if one bit is in a database, likely all bits are.
Vintage computer games and RPG books available. Email me if you're interested.
Fucking Egghead.
:(
I typically avoid e-commerce site that require me to "register" before I can buy, however I do happen to a "registered" egghead customer
First off you have to give them a user name/password which after a while you start using the same username/password unless you have a very good memory. Typically passwords are stored unencrypted on a database somewhere so that you (or some devious social engineer) can retrieve your password if you forget it. Once your username/password is compromised then a simple script can test for other accounts at major e-commerce and/or stock trading sites.
Also, I prefer to have the store where I buy from wipe out my cc number after processing the order instead of leaving it around for some disgruntal employee to access.
Regarding my previous comments on "Security being the red-headed stepchild of computer science because consumers are too stupid to know or care about it".
Education can be painful. But in the end, it's better to learn a lesson than not.
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
This is not to say that I think keeping silent is right (taking responsibility for your mistakes is the Right Thing To Do), but it is certainly understandable.
Here's a telling excerpt from the article.
>Hacked servers by Microsoft
>Robertson said that Egghead.com is using Microsoft's Internet >Information Server, a common e-business server, as the platform for >its online service.
>IIS is known to have had many security flaws.
Show that to your boss.
--
--
blinko - "the nail that sticks up gets hammered down"
Does anyone know how the numbers were stolen? Were they obtained purely from the outside, or with inside help? Were the numbers encrypted in the database? So far, I haven't seen an account of how the theft occurred.
Their god is Linus Torvalds and they'd live and die for him.
They believe in source code, and not in the corporate way.
So I'll go to "slashdot dot org" and post a comment and saaaaayyy....
HEY THERE MISTER SLASHDOTTER! Merry fscking Christmas!
Put down that disk of core dumps, and hear my holiday wishes...
In case you haven't noticed, it's Jesus's birthday
So get off your penguin-loving butt and fscking celebrate!
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
Comment removed based on user account deletion
Me either! ;)
../ bugs out, we'd at least raise the bar a couple notches.
Seriously, getting 10-20 minutes worth of interview into a few lines of quoted text, you always hope that the reporter will understand and report the gist of what you said.
The sad part is that over two years after it's been fixed, RDS is still the #1 attack vector for IIS. It's _really_ getting difficult to point to Microsoft as partially responsible for releasing crappy code when fixes that are eons old are never applied. If we could get wu-ftpd, sunrpc, RDS and the unicode
Paul
http://www.pauldrobertson.com
Comment removed based on user account deletion
I used to work for a consulting firm who had a lot of startup online-store-making clients. One of these folks emailed us a plaintext file full of credit card numbers from their database. They just didn't know any better! Your credit card number, like your CC# and favorite member of Wham, are not safe.