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!