Insecurities in Privacy Protection Software

I recently wrote an article for INSECURE Magazine (awesome mag BTW!) on the lack of protection given to one's sensitive information, ironically, by the very software that claims to protect it in the first place! These security companies seem to be riding on a new wave of PII protection - and the vendors are scurrying to come up with their own versions of a solution, forgetting all about secure software development practices. The importance of writing secure software cannot be stressed upon enough. Security vendors should know that. The article is at http://www.net-security.org/dl/insecure/INSECURE-Mag-18.pdf
Or read it online at http://issuu.com/insecure/docs/insecure-18/44?mode=a_p

Also - Jeremiah Grossman's nice article on the bitter reality of Web Browser security.

While on the topic of vendors - What vendor in his right mind would send something like this to a security contact in a company.. mind you - this vendor has NO NDAs with us - and I have had no prior contact with this guy.



I have no idea if a project like that even exists in the company, but it sounded like an important security project that should definitely be company confidential information. On quizzing the person, he replied that he got that information from his 'inside sales folks'.. riigggght. I asked for names. I haven't heard from him since.

Is an incorrectly implemented security program better than a non-existent one ?

Think carefully before you answer that one. A large majority of you would be inclined to give a resounding 'yes' - but I really want you to think carefully on this one. Think long term. Think about implementation hurdles, think about project documentation.

The answer to this IMHO is a big "DEPENDS".

To explain:

Imagine you're working in a company that has no security controls in place - and is in desperate need of getting a security program impemented. They hire a new CISO to make sure their physical and logical controls are in place, network and applications are secured appropriately and their incident management and forensics capabilities are upto date. At this point the CISO clearly knows that he needs to create and implement a number of programs and hires a bunch of people to perform and manage a series of tasks. Till this point, things are going smoothly. Everyone understands the need, and is working towards meeting a common goal. The program is not in place yet, but people know and understand the urgency need to act immediately. The CISO's risk radar has a list of projects ranked by priority and everone begins to tackle them.

Now consider the scenario when certain security programs are not done right - say, a few of the high risk applications are not considered in the initial risk matrix or there are certain business units that have been granted an 'exception'to the process that is being put in place, with the most common excuses of:

1. This is a pilot
2. We will get to this in the next phase
3. The group has a number of high profile clients who don't want it implemented right now
4. <plug your own excuse here>

Well - initially, everyone is completely aware that they have more issues to remediate and and have honest intentions to fix that too, once the pilot and
PoC is well established and in place. But then things change. Leaders change. Managers change. People's roles change. What doesn't, is the documentation regarding the project. But documents usually tend to highlight what the project does, not what it doesn't do. Nobody seems to remember there are additional tasks that need to get completed. People take a quick look at documents detailing what was done in the program and begin to assume that it is well established, completely ignoring the fact that a very important Phase 2 still needs to be in place. A false sense of security is now well in place... and life goes on.

Till you get hacked.

..and then a forensics team attempts to determine the cause. A new CISO comes in, reviews the existing program, decides it is too complex and structureless and decides to do away with it entirely and create a new security program.. and the cycle continues.

The moral of the story: When you have no security program - be very careful while diligently working to get one in place

But when you have a partial one, be extremely careful and don't leave any loose ends while getting it completely and correctly put in place.


On a lighter note - here's an email I received from a school I was doing some courses from ..

Beautiful !! Here is your PIN (username). But we will not give you your password over email. I was sooo impressed when I got that! - Could it be that schools and universities are finally waking up and trying to understand security ? No more SSNs as IDs ? No more default 'password' passwords ? This was great. I followed the procedure outlined to receive a new password - it asked for my name, DOB and email.. and then .. I receive this:




For those who cannot see the image:


the email says:

blah blah blah blah blah blah..
your PIN:
your password: password1234

blah blah blah blah blah blah

Random stuff on my to do list

SQL injection in web apps is sooooo old. It still exists everywhere and security companies are still making good moolah by capturing 'crown jewels' by exploiting this - However, I'm not sure that SQL injection testing for non web based applications/scenarios has caught on. Are they even worth trying ? For example: I'd really like to test the logic for the following (for starters) at some point in life :

1. Cell phones - IMEI registration. Attempt to SQL inject the backend during registration and/or normal communication - would that work ? Before I even say "Only one way to find out.." I should really read up on cell phones to test the theory..

2. Magstripes on cards - change data in the magstripe of ID cards , hotel access cards, credit cards, debit cards etc - to SQL inject the backend - Hmmm.. my name/cardnumber/PIN is now ' OR 1=1 -- ?
Something like little bobby tables.

3. Checks - Change the account number on checks to SQL inject the backend. I'm almost certain this would fail because of the MICR E13b restrictions of characters.. ah well..

Ah well..I would need to get back into security consulting at some point if I want to test this out in a legal way..

.. and now - PIN stealing..

Once the bad guys figured out how easy it was to sniff unencrypted ATM and card authorization traffic to steal track data, and after making a killing with stolen card numbers, they began setting their sights on bank PINs. PIN numbers - thanks to ANSI's TG3 - are encrypted with a half decent algorithm (and they are looking to strengthen that even more now). Which means that sniffing the traffic will only give you an encrypted number - something which would require a decryption key. A number of security controls like requiring dual control and split knowledge for key components, strict physical security requirements and Tamper Resistant Security Modules help in securing the keys. Assuming one cannot gain access to the encryption keys, this leaves only two scenarios for an attacker to gain access to the unencrypted PINs:
1. Before the PIN is encrypted by the Tamper Resistant Security Module (an ATM in the case of bank customers). Most criminals have been using fake PIN PADs and a number of other techniques like jamming and skimming to steal PINs, blissfully unaware that they are on camera most of the time. Nice video here.

OR

2. After the PIN reaches the issuer and is decrypted. This is the scarier situation -as the attacker would have access to a database of unencrypted PIN numbers / PIN offsets coming in from all around the globe. PCI supposedly requires that issuers be compliant and not store unencrypted PANs or PINs - but does not give any guidance on how validation of this should be done(unless they are a VisaNet processor - in which case they need to validate that they are PCI compliant).

Well - Kevin Poulsen at Wired wrote today about how an alleged ATM crime spree has been blamed on a Citibank hack. While Citibank has denied the hack as the cause of the fraudulent withdrawals - all signs seem to point towards it so far.
(This definitely is not new - While testing an issuer's security I had stumbled upon ATM log entry files - complete with PAN, PIN, full name, address, zip code and ATM location - all this - back in the day when RFP had just released whisker. ) Sigh.

This is probably just the beginning of a new wave. Issuers really need to pull up their socks and begin to treat cardmember data with the same respect that PCI Co is requiring merchants and processors to do. - and while I'm wishing horses - can ANSI or someone start working on some standards for requiring all track data to be encrypted in transit too?

Secure Email from Voltage

Voltage offers one of the many alternatives present in the industry for secure encrypted email communication. It is supposed to have incorporated strong anti-phishing technology within it. Could very well be, but there is a huge problem with the whole concept. You see, the way it is supposed to work is:

1. I type an email - and then choose to encrypt via voltage and send

2. Receiver gets an email with my email-address in the "From:" field, but with content stating something like "You have received an encrypted email. To view your email, click on the attachment.." - and a neat little html attachment presents itself for you to click.

3. Receiver - knows all about Voltage and its anti phishing technology - and hence assumes it is safe to click on a link / open the attachment.





Sheeeesh. No option to type a url and go to Voltage's website. No notification that I could be sent to sushi-land.. nothing..

.. More phish anyone ?

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.