ID Theft Incidents

Chris Hoofnagle published a report that attempts to measure ID thefts at major financial institutions. It is no surprise that BoA is the leader of the pack here, but that is mainly due to the fact that it is also the largest institution in the list. To address that, he created another list - this time with number of incidents per billion in deposits.




Moral of the story: The highest APR on your deposit may not be the only thing to look for when shopping for a bank.

Can I get your Username and Password ?

A while back, I got a call from someone claiming to be from a major benefits provider and said "Hello Sir. We noticed that you have a security flag on your account. Could you please give us your username and password to reset the flag.?"

"Wow!" I almost yelled in excitement "A real live telephone scammer!" I quickly noted the possibly-fake telephone number (yeah - Nitesh alerted me about spoofcard.com a long time ago!) and attempted to get a number where I could call him back. Surprisingly - he was fine with letting me call him back at the number list on my callerID - and he told me to ask for helpdesk/customerservice/security desk something.. I forget.. I said "Sure - Let me call you right back".

I quickly looked up the benefit provider's number on the internet intending to alert them of this scam - guess what ? It was the same number. I called that number and explained that they probably have a scammer on the inside asking for userids and passwords - On explaining in detail what happened - the girl at the other end was perplexed on how I could jump to that conclusion and exclaimed that that was the only way they could clear these security flags. They login as the user and clear it out. !!!

So much for expecting a little security from a company that was managing my 401k, pension plan and other benefits!

Hannaford Supermarkets

This is going to get very interesting. Hannaford Supermarkets announced on Mar 17 that they lost 4.2 million card numbers to a hacker (Began Dec 7, discovered on Feb 27) . They also claim to be certified as compliant with PCI DSS. So what value does the certification hold ?

Instead of saying PCI is worthless, lets step back for a minute and think about this. If this was an inside job, PCI Co can't be blamed. Also, as it stands today, the QSAs/ASVs can claim that their assessment was a point in time and as such, they shouldn't be held responsible for a company getting hacked after they gave it a clean chit. Change that and watch the number of QSAs/ASVs drop like a brick, and PCI Co get better value out of these QSAs and ASVs.

Lets see what the Hannaford CEO Ron Hodge said
"
Hannaford has contained a data intrusion into its computer network that resulted in the theft of customer credit and debit card numbers. No personal information, such as names or addresses, was accessed. Hannaford doesn’t collect, know or keep any personally identifiable customer information from transactions.

We sincerely regret this intrusion into our systems, which we believe, are among the strongest in the industry. The stolen data was limited to credit and debit card numbers and expiration dates, and was illegally accessed from our computer systems during transmission of card authorization.

"

Huh ?

No personal information such as names or addresses was accessed.

If that is the case, the authorizations should fail for most transactions of medium to high value when those numbers are reused since they don't have the name (I say most - because most auth engines typically use a complicated formula depending on location of purchase, amount of purchase, a margin for errors in reads during swipes etc before authorizing a transaction).

[Interesting Update: According to this article, there are around 1800 cases of related fraud so far, and they talk about a $1270 charge going through. Which really means there are authorization engines out there that don't seem to care about the customer name in a transaction. Either that, or someone is lying.]

Could there be a sniffer installed on the network ?

Track data has your name, card number, expiration date and encrypted IPIN among other things. If a sniffer was present at the swipe location, it surely would've got the name. But he clearly states no names were accessed. But what if it was in the scenario described a few posts below - about the ATM authorizations ? If you look at the message formats, they have card numbers and expiration dates. What was compromised ? Card numbers and expiration dates. (ISO 8583 seems to have track data in its message transmissions - but not until a long way into the stream, and for some reason, I didn't notice it in my raw transaction data log review. The attackers probably just captured the initial bytes of the transmission ?)

"But they were PCI Compliant and hence would've had to encrypt their data in transmission" you say.

Thanks to the vagueness of PCI, even if rule 4.1 were to be applied -
Use strong cryptography and security protocols such as secure sockets layer (SSL) / transport layer security (TLS) and Internet protocol security (IPSEC) to safeguard sensitive cardholder data during transmission over open, public networks.

Could they have used the excuse that the network was not open or public ? And then - they could always use the compensating controls excuse to not encrypt.

I'm willing to bet there was some form of sniffing involved - and this probably is sniffing of the POS/ATM transaction in the ISO8583 format. (a scenario I was afraid of in this post)

PCI Co and ASVs

Talking of PCI SSC - We all know VISA has been the biggest contributer to the cause so far and has donated loads of time and IP towards PCI - which has been adopted by PCI Co - but what neither VISA nor PCI Co have been able to successfully do so far - is to monitor the ASVs / QSAs to do their jobs correctly. Meaning QSAs should not be allowed to recommend vendor products or have relationships with vendors. That is so completely unethical. And ASVs should understand security. Seriously. I was completely aghast when I noticed Anurag's and Jermiah Grossman's blog entries about ScanAlert saying YOU DON'T HAVE TO FIX XSS ISSUES TO BE PCI COMPLIANT. Symantec and ScanAlert really need Security 101.

"XSS vulnerabilities do present a serious risk. However, to date their real-world use has been limited," said Oliver Friedrichs, director of Symantec Security Response in an e-mail. "XSS vulnerabilities can result in the theft of session cookies, Web site login credentials, and exploitation of trust. XSS vulnerabilities are site-specific, and therefore their life cycle is limited; they become extinct once they're discovered and repaired by the Web site owners."

Joseph Pierini, director of enterprise services for the ScanAlert "Hacker Safe" program, maintains that XSS vulnerabilities can't be used to hack a server. He maintains that XSS vulnerabilities aren't material to a site's certification. "Cross-site scripting can't be used to hack a server," he said. "You may be able to do other things with it. You may be able to do things that affect the end-user or the client. But the customer data protected with the server, in the database, isn't going to be compromised by a cross-site scripting attack, not directly."

Pierini dismisses the suggestion that certifying a site as "Hacker Safe" when it remains vulnerable to XSS attacks could be confusing to consumers. He insists that the meaning of the certification is clear and notes that his company's scanning service reports the XSS flaws it finds to its clients.

"We definitely identify this [XSS] and we definitely bring this to our customers' attention," he said." And we provide our customers with the information. Our customers are allowed to make the decision where to put their resources. I personally want them to put their resources where they're needed most, in things that can affect the confidentiality, the integrity, or the availability of that system that we're certifying. Cross-site scripting can be used to do a variety of things, but it's all on the client side. And that's an area that we don't have control over."

The Case For Information Security

While working as a security consultant, every MDAC attack, every cross-site scripting attack, every SQL injection attack, every custom application vulnerability that was exploited, was treated with such zeal that it made me think the companies that we assessed should be eternally grateful to us for having found those vulnerabilities and saved them millions and millions of dollars.

Now that I'm on the other side of the fence, I see why they didn't care so much. The companies don't care. Okay, so there is a SQL injection. a few dozen SQL injections. what does it mean to me the CFO or me the CEO ? the loss of a few card numbers ? we already are monitoring fraud losses - and have money set aside too. Can this be translated into a mass compromise of card data ? Hmm - now, you probably caught my attention. Loss of reputation - temporary. But try convincing me this could mean something critical to the bottom line - that is downright hilarious. Because the truth is - Wall St doesn't care about a company being hacked. Don't believe me ? Check out TJX. 46 million card numbers. Biggest ever breach so far. The current stock price ? An all-time high right now.







The same with AT&T. 19000 Card numbers stolen.




Choicepoint shareholders punished the company for a while - and then forgave and forgot.





So what does this mean for you and me ? Should we just ignore the fact that our personal data can be compromised and sold on the internet because the loss of our information is something 'they' have already accounted for ? Thats brutal. A weak glimmer of hope could be PCI. PCI SSC has been making an effort to fix this scenario - and we could begin to see changes. But these standards are currently so vague and can be interpreted in so many different ways - it is pathetic. Unless there are strict regulations (FFIEC/FDIC begin requiring Application Security integrated into the SDLC of a company and quarterly validation by different independent 3rd parties would be nice :) )and stricter enforcement - with real hefty fines - Wall St. may just continue to look the other way ..and we all know that Wall St is what matters.

ATM Communication - How Secure ?

A while ago, I attended a class on PIN and Key Management for Payment Networks. ANSI has laid out strict guidelines (in their ANSI X9 TG-3 standards checklist, ANSI documents X9.8 and X9.24) for how a customer's PIN should be kept secure: how they should be stored on the card (store only the difference/offset of the encrypted PIN value and the natural PIN), what the minimum encryption requirements are (Triple DES), what the specifications of the devices that encrypt/decrypt the PIN are (Tamper Resistant Security Modules), how PINs should be exchanged between various Financial Institutions (exchange keys between two FIs out-of-band AND under the principles of dual control and then encrypt the keys, how should compromised - no - even "suspect" compromised PINs and Keys that encrypt the PINs be treated (securely delete the key, recreate a new key under the principles of dual control and split knowledge and re-encrypt *every* key or PIN that has been encrypted under it! and re-issue cards containing PIN offsets for PINs encrypted under the new encryption key, if applicable) etc.

It was simply awesome. To know that the Financial Institutions do their due diligence is a huge confidence booster. The fact that these guidelines are just that - guidelines, and haven't been strictly enforced by governing bodies is not my biggest concern. Neither is the fact that there are a number of papers out there that talk about the insecurities in PIN translation.

The following, however, is:

The folks at redspin (Brian Hayes, Matt Marshall) analysed ATM traffic and wrote a paper on insecurities in ATM communications.

What you see above is the raw data message format that leaves the atm connected to a network. Cleartext communication. Notice the account number and expiration date. Totally vulnerable to man-in-the-middle attacks. The response message that is supposed to come from the FI, looks something like this:

I'm not going to say what one needs to do at this point. Read up message format ISO 8583. It is scary.

Your State ID

By now, everyone clearly understands that, in the grand scheme of things, their SSN is probably one of the most important numbers they need to keep safe and secure from public view. That's usually because most of their other information that the Credit Agencies require to validate their identity is known to mostly anyone who wants to know. Their birthday. Their home phone. Their home address. Not that it is _critical_ for them to get your report - Oh No - the CRAs can look you up even without your SSN _and_ give that to certain parties who sign a statement claiming to be from law enforcement (or a few other related categories) - ever wonder why certain utilities will ask for your SSN, but if you refuse, they seem satisfied with just getting other identifying information ? But at least there are a few locks on the door to this data.

If you were to think about the information you memorize - you realize they fall into two broad categories. Sensitive information about you that is difficult to get such as Credit card numbers, PIN numbers, Social Security Number etc. and non sensitive information such as your birthday, your listed telephone number etc. I strongly believed one's State ID/ Driver's License Number belonged to the former category.

Believed.

I was wrong.

Recently, I stumbled upon the algorithm used by a few states used to generate driver's license numbers. Its been public knowledge for a long time. So, if you know someone's name and birth date - you can generate their DL number. Why is this so unnerving ?

Well - for starters - every mom and pop shop I know that wants to use your card for a high value transaction, wants you to fax a copy of your DL and CC. Depending on the Mom (or Pop), this DL number is checked to make sure it is valid before allowing the transaction. Also, at least one of the CRAs I know, would like you to fax a copy of your Driver's Licence if you fail to authenticate at their site, if you, you pathetic non-law-enforcement civilian, want to get your hands on your credit report. Once they get the fax, they review the DL# against their database, and if it matches - you're in! You generate the correct DL number, you can charge whatever you want. Become whoever you want.