Three Indicted In Huge Identity/Data Breach 101
ScentCone and other readers let us know about an indictment just unsealed in federal court for stealing 130 million credit cards and other data useful in identity theft, or just plain money theft. The breaches were at payment processor Heartland (accounting for the bulk of the 130M), Hannaford, 7-11, and two unnamed "national retailers." Interestingly, the focus of the indictment, Albert "Segvec" Gonzalez, is currently awaiting trial for masterminding the TJX break-in, which until Heartland counted as the largest credit-card theft ever. The indictment cites SQL injection attacks as the entry vector. Two unnamed Russia-based conspirators were also indicted. Securosis has analysis of the security implications of the breach ("These appear to be preventable attacks using common security controls. It's possible some advanced techniques were used, but I doubt it") and the attackers' methodology.
Re: (Score:2, Informative)
Re: (Score:1, Offtopic)
Why is it legal to be hispanic?
In Maricopa County, Arizona, it is.
Re: (Score:1, Offtopic)
Losing faith in the system (Score:5, Insightful)
These credit card processing companies had better get their acts together fast, or they'll be sunk by so many lawsuits that they won't be able to stay in business.
Insurance companies will see this sort of business as a radioactive risk. They'll let existing contracts expire and quietly back out --UNLESS these companies get serious about their data security.
There is a huge opportunity for someone to make some real coin doing this sort of thing, but it will take a mindset that these people have been loath to accept: People really are out to get them.
Re:Losing faith in the system--Don't Lose Faith! (Score:3, Insightful)
Don't lose faith. The banks never lose. Both the Democrats and the Republicans see to that!
The losses always get pushed away from the stockholder and onto the consumer! That's what capitalism is! Capital dominates government!
Re: (Score:2, Insightful)
Why should this be modded down? It's the logical conclusion to the system. We know the credit card system is insecure, we can fill the message boards with comments going back and forth about it... but that isn't the larger problem. Discussion centering around only the credit card system is bound to revolve around band-aid approaches to fixing the system. In order to truly avoid this sort of problem again we need to understand underlying flaws.
So, logically, you wonder why people need credit cards, and t
Re: (Score:1, Troll)
I recommend a method wherein we inscribe some sort of Mark on the right hand or the Forehead to identify people.....Meh yea. lets go that route.
Re: (Score:2)
Note that these 'systems' were attacked through MSSQL holes.
Yes, don't lose faith! Lose Microsoft!
Re:Losing faith in the system--Don't Lose Faith! (Score:4, Insightful)
The best system is a swiss cheese if the patches are not applied...
Seriously. I've seen far more serious security holes due to negligence on the side of the administrators and beancounters than on the side of the supplyer of hard- and software. For many companies, security is still seen as a product. It's something you buy, some box you put in front of your machines, and you consider yourself safe and secure, never to touch it again.
That's not how it works. Security is a process. Security is something you have to establish and audit. Preferably constantly, but that's not economically feasible for most companies. But you have to audit your security system against current, modern threats, you have to audit it against everything that has happened and is a known exploit or a known procedure employed by criminals. Today, tomorrow, for the rest of your company's existance. It's nothing you do today and then you're done with it.
Security is an evolving process. A race between attacker and defender. You can't "win" and then be over with it.
And as soon as companies realize that, we'll see some progress in this field. Not a second earlier.
Re: (Score:3, Informative)
Seriously.
I mean, SQL injection? That's just disgustingly stupid and lazy.
Re:Losing faith in the system (Score:4, Insightful)
I agree.
And the downside for their company is-- WHAT? Why should they make the extra effort to avoid such flaws? Whose responsibility is it?
The problem is that the liability isn't all theirs. This is the same reason that so many software firms can sell steaming piles of insecure garbage, and there is very little practical consequence.
This is the same feature that led to the downfall of the housing market. If you spread the risk around too thinly, nobody will know who to assign blame to. That's how we got in to the mess we're in. When people start demanding accountability and liability, this nonsense will end.
Re: (Score:2)
I hate problems where the solution is "educate people" and "change minds". :(
Re: (Score:2)
Problem is that accountability died along time ago side by side common sense.
Faith is gone. We need a better way! (Score:5, Interesting)
These credit card processing companies had better get their acts together fast, or they'll be sunk by so many lawsuits that they won't be able to stay in business.
Yes, but there is still an underlying problem: The credit card payment system is inherently insecure. I'm not talking about the computers, I'm talking about the system at large. Credit card numbers are basically a password that you share with anybody who you buy stuff from. Any of these vendors by definition have all the information necessary to use your credit card.
What you can't do with the current system:
1) You can't "lend" your card to a subcontractor so that they can buy supplies, without opening yourself up to a world of hurt.
2) You can't trust that your identity isn't stolen at every possible transaction.
3) In the case of a leak, you can't be automatically alerted to attempts to use your credit card.
It could be some otherwise bored l337 h@x0r in Montana at his mom's house who cracks an online shopping cart, or the Russian Mafia, or the pimply guy who pumped your gas. All of them get the ability to "be you" simply by transacting as you, and so long as this fundamental insecurity remains unchanged, credit cards are and will continue to be problematic.
Me? I'm imagining something with my cell phone, a PIN like an ATM card, but one that's different for each transaction. In this manner:
1) I swipe my card.
2) The credit card gives me a challenge code, asks me for my PIN.
3) I get a text message on my cell, which has the challenge code on one line, and a one-time-PIN on the next line, and a third line with the amount charged.
4) I enter the one-time PIN, proving that I have the registered phone in my hand.
5) Then, I enter in my permanent PIN, just like I do now.
This protects me:
1) Anybody at the cell phone company can see the challenge and the response PIN, but it doesn't do them any good since these change with every card swipe.
2) Anybody at the store can see the whole transaction, but it doesn't matter since they don't have my phone.
3) Even the credit card processing center can't fudge the transaction because the amount of the charge was submitted prior to generating the one-time PIN, and I've already been made aware of the charge.
4) If somebody did get your card #, and tried to use it, you would know immediately that it was happening, and the amounts involved because you'd be getting notices of the transactions sent to your phone!
This would DRAMATICALLY reduce the security footprint of the credit card transactional system, and would easily allow for causual "lend him the credit card" scenarios, since you could give the card to someone, and even let them know your permenant PIN, but keep the phone in your hand. The only person who can effectively compromise this credit card system effectively would be the credit card company itself.
The only downside that I can see is that you couldn't use this system in areas without cell service. But even in that case, you could "pre-register" a transaction or two with no amount set, keep the one-time PINs handy, and use them when you don't have service.
The current system is terribly insecure - I've had 3-4 different compromises of my credit card numbers in the last couple years despite my being VERY careful with my data. Then I talk to the fraud department, sign the affidavit, get my credit back, blah blah blah...
The current system sucks. We need a better system.
Re: (Score:2)
While I agree completely that a cell phone system would be much much more secure, nothing is unbreakable. See http://mobile.slashdot.org/article.pl?sid=09/08/17/0014235 [slashdot.org] for a description of hacking cell phone providers as an example. Basically, I think every card owner he stole should get the opportunity to take a paddle to his ass for one crack. His bright red butt should then be photo'ed and posted on the web. Now that would be justass.
Re: (Score:2)
While I agree completely that a cell phone system would be much much more secure, nothing is unbreakable.
It does not have to be unbreakable, only better.
Re: (Score:3, Interesting)
But it doesn't matter if the cell phone company is compromised - or did you miss that bit?
The only thing that the cell phone company gets is the ability to approve the transaction that I already started. I don't give a shiat who reads the cell message. And if the cell network was hacked so that I get a bogus text message, then the transaction still doesn't work.
In other words, yes, perhaps it's possible to hack a GSM cell phone tower, but even so, the attack window is very, very small.
Compare that to toda
Re: (Score:2)
wow, what part of much much more secure wasn't clear.
Re: (Score:1)
my bank ( HSBC Sing )used to use SMS confirmation for transfers but now uses the dongle , but the SMS was a pain as I would have to call and change my number when I changed countries and sim cards.
maybe a secure login from your phone via a wireless data link to receive a confirmation code - maybe have it interrogate the IMEI of your phone to authenticate the device - though the mobile computers with phone capabilities will be nex
Re: (Score:2)
Re: (Score:3, Informative)
The current system sucks. We need a better system.
Here in Poland it is customary to pay for online purchases with bank transfers, and only use debit cards as a substitute for cash and at ATMs - nobody ever gives their card number to anybody. I am wondering why people bother with insecure credit cards when online banking fills most use cases of card-not-present transactions.
Re: (Score:1)
People bother with credit cards because the system is built on the assumption of trust. The vast majority of transactions do happen to be legitimate, and at the moment, the credit card companies are able to push most of the consequences of illegitimate transactions off onto merchants, so change isn't going to come quickly.
Re: (Score:3, Informative)
Re: (Score:1)
Re: (Score:2)
As someone who's had both his credit card account compromised in one of these breaches and had his identity full-on stolen (SSN, DOB, name, address, etc), a simple "thief uses your card to buy some stuff" is no big deal (relatively speaking). A close eye on your credit card statements, something you should do anyway, a quick call to the card company and you'll get a new card number and the charge will be taken off. Once the card is canceled, you're safe again. With full-on identity theft, even closing th
Re: (Score:1)
The social security office could use a very similar protocol for setting up banking and credit accounts.
This is a *good* system and is roughly modelled after a system I designed for signing digital certificates.
And, do you want to talk about paranoia? Try designing a truly secure digital certificate system! It's harder than you think if you start with the assumption that any computer in the system could be hacked, but that still can't mean a system compromise.
Re: (Score:2)
Including any kind of active circuitry in the credit card would severely impact the cost of shipping dozens of "free credit cards" to those who shouldn't be trusted with a lemonade stand.
Sorry - people are too stupid for this (Score:1, Interesting)
When I set up the cart for my employer, I naturally required buyers to put in their billing address info.
Fully 40% couldn't manage to supply their billing zip code.
Not even after they called us and we went through the guessing game over the phone.
I know we are a mobile society - but c'mon - I can remember every zip I've lived in for the last 15 years.
I finally gave up and now require only card number and expiration - that's it.
Fortunately, the vast majority of our purchases are under 50 bucks, and we've onl
Re: (Score:2)
How can your buddy answer the random PIN challenge when you have the phone that receives the message that contains the random PIN to enter at the POS terminal? Do you call your buddy and tell him the random PIN, or do you loan him your phone?
Re: (Score:1)
Re: (Score:2)
But the data IS secure! there is a little padlock on my web browser window that says so! ;-)
--jeffk++
Re: (Score:2)
Yeah, I was hoping when it said "Three indicted" that the three were actually working for one of these companies and they finally started indicting for incompetence.
We've handled this whole security thing poorly.
Re: (Score:2)
No report that I've read suggests that 7-Eleven will be punished for this, even though they were self-evidently negligent with their customers' data - SQL injection vulnerabilities would by uncovered by any perfunctory peer review, security review or penetration test. In the UK, they'd be looking at a huge fine from the Office of the Information Commissionerfor this.
It also throws the whole PCI/DSS scheme into question. If PCI means anything, a company that demonstrates an attitude to security that's this
Re: (Score:2)
The problem is that the credit card companies look at this investment as a luxury and not a necessity and like most investments, unless there is a need it will get filtered down to a basic formula.
Compare the cost of just reimbursing the people who have been stolen from, compared to the investment it would take to change the WHOLE cc infrastructure , and then ask yourself this....If it is not a crime to offer less secure credit cards, do you have to invest in more security, or will just saying you could not
Hate to say it... (Score:5, Insightful)
Re: (Score:3, Informative)
That's only relevant to the end stores that need payment processing. The rules, of course, do not apply to the big name at the top.
Re: (Score:2, Informative)
PCI
only relevant to the end stores ... rules do not apply to the big name at the top
Um. Ur wrong. It's relevant for everyone not Visa, MasterCard, American Express, Discover. TJX et al have way heavy PCI fines.
Re:Hate to say it... (Score:5, Interesting)
PCI compliance is the definition of security theater. I used to work for a credit card processing company, and every month we'd get some new "PCI" rule we had to follow, which did virtually nothing to make us more secure.
Month 1: Can't store credit card numbers in problem tickets. Must use e-mail. (Internal e-mail, obviously.)
Month 2: Can't e-mail credit card numbers internally. Must put them into problem tickets.
Month 3: Can't do either one. Now you must provide the credit card numbers verbally (over the phone), or write them down and carry them to the person resolving the ticket.
Which made resolving card-specific software issues absolutely delightful to deal with - I couldn't even begin to guess how many miles I trudged through the IT floor, distributing sticky notes with credit card numbers written on them, which if you ask me was more of a security risk than having them stored digitally.
Meanwhile, the things that really mattered were left virtually untouched. I don't even know how many times something was completely and utterly screwed up by someone, somewhere in the company... and we couldn't even figure out who did it because there were no logs of what had happened, or because the logs pointed to a shared account that anybody could have used. My account on the actual card processing front-end system was watched like a hawk, however, nobody would ever have noticed if I'd downloaded a database dump from the FTP server and made off with it.
PCI has absolutely nothing to do with actually tightening security, and everything to do with making businesses able to say "It's OK! We're PCI COMPLIANT!"
(Post anonymously? Hmm, I wonder.)
Re: (Score:1)
Meanwhile, the things that really mattered were left virtually untouched. I don't even know how many times something was completely and utterly screwed up by someone, somewhere in the company... and we couldn't even figure out who did it because there were no logs of what had happened, or because the logs pointed to a shared account that anybody could have used. My account on the actual card processing front-end system was watched like a hawk, however, nobody would ever have noticed if I'd downloaded a database dump from the FTP server and made off with it.
I'm not sure if you are joking, but by this statement alone I can tell you were not PCI compliant, whether you were certified or not. Full logging is a requirement, it has an entire section of the PCI standard. Shared accounts are prohibited. And FTP? In a compliant cardholder data environment? Not likely.
Perhaps you were actually doing 'Auditing Theater', where you pretend to be audited, and buy a cert from a small company that isn't actually validating your systems.
Re: (Score:2)
PCI compliance is the definition of security theater. I used to work for a credit card processing company, and every month we'd get some new "PCI" rule we had to follow, which did virtually nothing to make us more secure.
Month 1: Can't store credit card numbers in problem tickets. Must use e-mail. (Internal e-mail, obviously.) Month 2: Can't e-mail credit card numbers internally. Must put them into problem tickets. Month 3: Can't do either one. Now you must provide the credit card numbers verbally (over the phone), or write them down and carry them to the person resolving the ticket.
Which made resolving card-specific software issues absolutely delightful to deal with - I couldn't even begin to guess how many miles I trudged through the IT floor, distributing sticky notes with credit card numbers written on them, which if you ask me was more of a security risk than having them stored digitally.
Meanwhile, the things that really mattered were left virtually untouched. I don't even know how many times something was completely and utterly screwed up by someone, somewhere in the company... and we couldn't even figure out who did it because there were no logs of what had happened, or because the logs pointed to a shared account that anybody could have used. My account on the actual card processing front-end system was watched like a hawk, however, nobody would ever have noticed if I'd downloaded a database dump from the FTP server and made off with it.
PCI has absolutely nothing to do with actually tightening security, and everything to do with making businesses able to say "It's OK! We're PCI COMPLIANT!"
(Post anonymously? Hmm, I wonder.)
I'm on the PCI compliance team where I work (well, was...eventually management decided they would rather outsource all credit card transactions and not have to worry about it), and you never were PCI compliant. For one, the numbers can't be stored in cleartext, which sounds exactly like what emailing them and putting them in trouble tickets, or even writing them on a sticky note would do. The actual PCI DSS is pretty normal security procedure and something you would want in place anyways. Aside from a sh
Show Me The Money (Score:1)
Re: (Score:3, Informative)
It does take a huge bite out. It costs a fortune for merchants, card processors, banks (and of course to the retailers they pass those costs along to) to deal with fraud. Billions and billions a year. It's a drag on the economy that makes it more expensive to be a merchant, more expensive to (however briefly) borrow money, more expensive to run law enforcement, etc.
PCI stands for... (Score:4, Funny)
... Pay Cash Instead!
Re: (Score:1)
SQL Injection? Really? (Score:4, Insightful)
Re: (Score:3, Funny)
Oh, I'm sure that the database was properly protected! I've seen quite a number of high-security environments that protect their databases with very cleverly written javascript that makes it all but impossible to hack!
Yet, somehow, those wascally l337 hax0rz still get in... (shrug)
new business model (Score:3, Insightful)
1. Credit Card Industry fails to secure servers
2. Massive Identity Theft Occurs
3. Offer Credit Report and Identity Theft Services to mitigate steps 1 & 2
4. Profit!!!
-I'm just sayin'
Re: (Score:2)
Step 3 is what irks me the most and as far as I'm concerned, step 3 is all the proof that we need that the financial industry does not care about protecting our personal data. If they truly cared about credit fraud they will give us free credit reports and free identity theft prevention services. They would do so because doing so would be more cost efficient than dealing with the fraud.
The reality seems to be that they will charge us to protect us and just continue to ignore the fraud. I will never pay f
The 1990's called ... (Score:4, Informative)
Re: (Score:2)
It's not hard, just hire a bunch of recent CS graduates.
Re: (Score:1)
All preventable (Score:2)
Re: (Score:2)
Don't hate on MSSQL -- it's actually a fairly well-respected database, even among folks who also use/maintain some of the open-source options. You could do far, far worse than MSSQL, even for this application.
Of course, if your administrators and developers are idiots, an injection vulnerability can be written into any database, no matter how secure.
National security issue? (Score:2)
Re: (Score:3, Interesting)
How is 130 million cards getting compromised not going to have an impact on the economy?
The question is, how is this going to impact the economy?
If these identities are being used for fraudulent transations, then the initial impact might be an overall increase in sales. Obviously those sales will be challenged, and repercussions will be felt at various points throughout the system, but the impact on the economy is not going to be a simple cause-and-effect, regardless of scale.
This scenario makes me wonder whether mass-compromise of the credit card system has been modeled yet. And more import
Re: (Score:2)
As I understand it, not a lot of the CC numbers actually get used for identity theft. Most of the money in stealing the cards is selling the list to others. Besides, if you had 130 million CC numbers dropped in your lap, what would you do with them? At most you could personally exploit only a tiny fraction of them usefully.
The big financial hit here is the credit card companies having to do a mass cancel/resend of cards, as happened to me after the TJ Maxx heist.
Next Credit Application (Score:2, Insightful)
Re: (Score:2)
http://xkcd.com/327/ [xkcd.com]
This is all academic. (Score:2)
Before people chime in to either wish Albert a roommate who thinks he has a pretty mouth, or 'explain' why the charges are bogus, just chill. This cracker was in trouble in 2004, turned state's evidence, and walked. There are people still on the inside who really miss him. It doesn't matter what the sentence is in his case, he literally is a dead man walking. It doesn't help either, that his Russian buds, still un-arrested and likely to remain so, may be worried about what new tales he will tell. They proba
Why store credit card info?? (Score:1)
Re: (Score:2)
Two things. First, RTFA, especially the link to Securosis, where it says the guy installed sniffers to record the data while it was being sent to the credit card company. The bad guys didn't steal stored accounts from Heartland, they were just snorting it off their network.
The other thing is that your assumption about how settlement works (while long discussed as a better solution than the current system) is incorrect. The retailer does not get a perfectly unique transaction ID back on a credit author
Re: (Score:1)
Re: (Score:2)
There is a very secure solution available that involves replacing the current "valuable account number" system with smart cards and cryptographic protocols, but the roadblocks are many. The big initial hurdle is the resistance by the banks to implement it due to their costs. Certificate management, HSMs, card generation and deployment, all this would add up to over $20 per card. I figure that the amount wasted by merchants securing their systems would more than make up for the expense of such a system, b
Re: (Score:1)
identifying the transaction to the bank requires the following data: merchant ID, terminal number, transaction date/time, account number, and approval code.
The combination of merchant ID, terminal number, transaction date/time, and approval code seems like a pretty unique transaction ID to me. If the payment processor stores this info as the primary key, then the account number is redundant to specifying the transaction.
Re: (Score:2)
identifying the transaction to the bank requires the following data: merchant ID, terminal number, transaction date/time, account number, and approval code.
The combination of merchant ID, terminal number, transaction date/time, and approval code seems like a pretty unique transaction ID to me. If the payment processor stores this info as the primary key, then the account number is redundant to specifying the transaction.
Again, I agree with you, but I was describing the current protocol. Remember these systems were built long ago when these sorts of systems could be trusted. I believe the account number was originally used as the primary key in many of them (certainly at the banks, but probably at the processors and merchants as well.)
How it works in Sweden (Score:5, Interesting)
I just recently moved to Sweden from Denmark. The changes in online payment processing wasn't that big - just introduced an extra bit of security. It's not a matter of being from Sweden or Denmark, it's a matter of how the shops are set up.
In Denmark, it's the same way as in the US:
1) Punch in your card number
2) Punch in the card's security code
3) There is no step 3
The Swedish stores I've bought from adds extra steps when I'm using the card from my bank though; it uses authentication that you need to have with you:
A smart card reader [todos.se] using the chip and pin for my card.
When I want to pay using that system, the steps are as follows:
1) Payment processor is my bank, not some random company, and is in a separate SSL session to my bank
2) Enter SSN on payment page
3) Enter the one-time control code in my reader
4) Enter the pin number for my card in the reader
5) Punch in the return code from the card reader on the payment page
It's the same system I use for my online banking as well; it has steps for login, signing and buying, each presumably using a separate private key.
A system like this put in to place everywhere would make gleaning my credit card number useless. I don't have any physical identification that has my SSN on it, nor am I required to have such by Swedish Law (unless I'm driving). And even with my SSN, they still need to know my pin code. Can't say for sure if the card and reader are tied to each other though - I haven't tried using someone else's reader.
Additionally when this system is used on the websites, all processing is done through the bank's own systems, meaning the bank itself is the one that needs to be compromised, and they're probably a bit more worried about a breach than the other guys. I mean - if their systems are broken into, it's not like they can just pass the blame onto some random third party and tell the customers "don't worry, we won't be doing business with them again" - they screw up and it's us telling the banks we won't do business with them again.
Re: (Score:2)
I'd like to see banks go one step further with this, and issue a 'credit fob' instead of a credit card, though. The idea of this fob would be to have security for remote transactions built in, and it would have a number on it that changed every 10 seconds or whatever that you had to enter to make a transaction. That way you wouldn't need to carry around a bulky card reader with you to make online transactions everywhere. People would have to get used to the idea of a fob instead of a card, though, and th
Re: (Score:2)
What your are talking about doesn't really sound like card processing, it seems you are using Direct Payment where you can pay using your bank account and some form of authentication (differs from bank to bank, but usually the same two or three factor auth you use for you online banking.
Now, at least my bank uses 3D Secure as well. The implementation differs between banks in Sweden. Some use only a text challenge/response while others use a two factor system where you need your cardreader as well. Works ext
Huh? (Score:2)
Excuse me? - The ability to fetch patches is essential to keeping a server secure. Allowing it to fetch patches from an intermediary server only doesn't make anything more secure as that server is easily compromised if the attacker already have root on the production server. It will only serve as a delay and an annoyance to the attacker, nothing more.
No, the only way to go is to p
Blame (Score:2)
Unless your name is Johnny Tables, how do you execute a SQL injection on a credit card processing system?
Maybe the blame should be placed on the system that gave the attacker visibility into the transaction processing database, rather than a sandboxed (rather, firewalled) access to the data needed to complete his specific transaction.
big companies = big morons (Score:1)