# Internet Crime Compliant Center (I3C) : Preventative Measures - Hardware Security Modules

The Internet Crime Complain Center (I3) released a memo on December 15th 2008 - titled Preventative Measures: “Over the past year, there has been a considerable spike in cyber attacks against the financial services and the online retail industry. There are a number of actions a firm can take in order to prevent or thwart the specific attacks and techniques used by these intruders.” There are 12 Recommendations here, 11 of those, that in all honestly, should not be new to any one addressing IT Security or PCI Compliance - I can map each of these 11 to a PCI requirement:

• Recommendation 1,2,4,6,8 : maps to PCI 2.2.x “Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.”

• Recommendation 3: maps to PCI 6.5.x “Develop all web applications based on secure coding guidelines such as the Open Web Application Security Project Guide. Cover prevention of common coding vulnerabilities in software development processes”

• Recommendation 5: maps to PCI 7.2.x “Establish an access control system for systems components with multiple users that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.”

• Recommendation 7: maps to PCI 8.5.13 “Ensure proper user authentication and password management for non-consumer users and administrators on all system components”

• Recommendation 9,10: maps to PCI 1.3.x “Prohibit direct public access between the Internet and any system component in the cardholder data environment.”

• Recommendation 11: maps to PCI 1.2.1 “Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment.”

The last one is a little different and or not as common as the items above: Recommendation 12: Ensure your HSM systems are not responsive to any commands which generate encrypted pin blocks. More specifically, HSMs should not accept commands that allow plain text PINs as an argument and respond with encrypted PIN blocks. HSMs are normally used to verify Personal Identification Numbers (PINs), generate PINs used with bank accounts and credit cards, generate encrypted Card Verification Values (CVVs), generate keys for Electronic Funds Transfer Point of Sale systems (EFTPOS), and generating and verifying Message Authorization Codes (MACs). These systems, if accessed by an unauthorized intruder, can provide the attacker the ability to discover the appropriate PIN number for a corresponding credit or debit card. Therefore, in an effort to prevent this, HSMs should be configured to disallow “in the clear” PINs as an argument for performing its tasks. This recommendation discusses configuration options with Hardware Security Modules or HSM’s. There is a attack that allows an attacker to derive how a PIN is encrypted if the HSM Allows for functions that allow a Clear PIN as an input an attacker can send various clear PINs and analyze the output from the HSM. At one of our acquiring clients we communicate with a Thales 8000 HSM. The functions that we are are for PIN Translations for Debit/EBT Transactions. The functions that we use for this do not involve a clear pin, we receive an encrypted PIN Block from the Point-of-Sale and PIN-Pad that we translate to a different PIN Block under a different encryption key to the Debit/EBT Networks and/or providers. Looking at the “Thales – Console Reference Manual” - I see this option: Select clear PINs: Yes or No This enables the clear PIN support via host commands „NG? and „BA?. Authorised state is a requirement for these commands to be processed by a host application. Note: This is a security risk unless precautions are taken at the host. The Manual states that this is clearly a bad thing:

So for Requirement 12 - Make sure that you are not using any “Clear PIN’s” and any function that allow “Clear PIN’s” as an argument are not enabled.

# Compliance != Security - the Titanic illustration

Dr Anton Chuvakin points us to NEWS FLASH! Titanic Was Compliant a post on The Guerilla CISO located here.

The theme of the post is that compliance is not security. Do yourself a favor and read the full post for yourself. It is about someone questioning how a failure could occur “even after smart people put their heads together and try to deal with the problem before facing a crisis” The example of the RMS Titanic is perfect:

I told her that the problem here was that the Titanic indeed did meet all of the safety requirements of the time. And that a big part of the problem was that the safety requirements were drafted in 1894 at a time when there were rapid changes and in the size and design of ships of this kind.

So, the bottom-line was that when the Titanic was reviewed by the safety accountants, they took out their check-list and went over the ship with a fine tooth comb. When the day was done the ship fully met all the safety criteria and was certified as safe.

Did you get that ? The Titanic was compliant to the current safety standards of the time.

Think of this when you are reading through your SAQ or PCI DSS Audit Procedures - and understand that the PCI Standard is a baseline of controls to follow to protect cardholder data, you may need to go above and beyond these. Don’t feel that you are “secure” because you are PCI compliant, and don’t be surprised that PCI compliant entities can still have security incidents. Your Risk Management program and practices should include addressing compliance, but compliance should not be your goal for “security.”

# Fraudulent ATM Reactivation Phone Calls

Johannes Ullrich at SAN’s Internet Storm Center writes:

Thanks to our reader Glenn for alerting us of this scheme: He received an automated phone call, telling him that his ATM card has been deactivated. The system then offered him to re-activate it. He didn’t fall for it, and instead called his bank. His bank told him that they had multiple reports like that, and the calls are false.

Lessons learned:

• first of all, the bank should somehow identify itself by telling you something only they know. Your account number maybe?
• better: call them back at a listed number. Do not ask them what number to call. Usually, the fraudsters will use an automated system to call you, not a human (but they may).
• never provide confidential information like account numbers, social security numbers, PINs, passwords over the phone.

This is something to consider in your own customer service and information security training programs as well as “educate your customers”

Since becoming an Obopay user, I’ve noticed that very recently that they have implemented a multi-factor authentication for transactions initiated from their mobile website. I needed to pay $2.14 to a friend who picked up a lunch for me yesterday: Monday is$1.00 Maid-Rites :) When sending the money I received the following (see picture on left) screen, and my phone rang shortly after - requiring me to type in my obopay PIN to complete the transaction. Very well done! I know that Chase uses a similar process (out of band verification) for its Internet banking. Authentify is a company that provides a service like this – please leave a comment below if you know of any others. Also - if you noticed in the picture I’ve updated my Nokia E51 to a Nokia E71 - a very nice phone - (I really missed the QWERTY keyboard)

# EV (Extended Validation) SSL Security - XSS Attacks

So I’m on a webinar right now, listening to a gentlemen from Verisign talking about how the EV (Extended Validation) SSL Cert’s prevent Phishing among other things. You have probably seen the Green Bar and SSL Certificate – The name next to the lock is embedded in the certificate, and the theory is that this cannot be modified by the attacker or phisher. Here is a picture courtesy of Versign:

But, I’m hearing mostly about the “Green Bar”, and seeing statistics on how users like the “Green Bar” and sites that get increased transaction volume, transaction ticket sizes, as well as as reduced cart abandonment. Unfortunately the “Security” presentation has turned to a “Sales” presentation… But with these XSS attacks:

The green address bar displayed by the web browser would assure users that they are looking at a website that can be trusted, even though the page they are looking at may contain scripts or HTML created by a remote attacker.

# HSM - Atalla simulator/emulator (Hardware Security Module)

My very first experience with an Atalla was with an old PCI card version of the ATALLA 10000 that was used in an issuer system for CVV and CVV2 verification. Having access to an HSM for development and testing is really a good thing , and is also a requirement is you are building a PIN based debit system, and since not everyone has access to HSM’s in their labs :) A friend has recently shared the following link: http://ziggurat29.com/ that includes “BogoAtalla”

This is an Atalla emulator (or simulator). This software emulation (simulation) of the well-known Atalla Hardware Security Module (HSM) that is used by banks and processors for cryptographic operations, such as verifying/translating PIN blocks, authorizing transactions by verifying CVV/CSC numbers, and performing key exchange procedures, was produced for testing purposes. This implementation is not of the complete HP Atalla command set, but rather the just portions that I myself needed. That being said, it is complete enough if you are performing acquiring and/or issuing processing functions, and are using more modern schemes such as Visa PVV and DUKPT, and need to do generation, verification, and translation. This runs as a listening socket server and handles the native Atalla command set. I have taken some liberties with the error return values and have not striven for high-fidelity there (i.e., you may get a different error response from native hardware), but definitely should get identical positive responses. Some features implemented here would normally require purchasing premium commands, but all commands here implemented are available. Examples are generating PVV values and encrypting/decrypting plaintext PIN values.

I gave it a very quick shot in a test virtual machine: <00#020035#0101##> Let’s see – my first error message, invalid character/message :) And if you are a real geek- you can use the WRTG version: BogoAtalla for Linksys -- makes a great portable HSM. I’ll probably play a little more with this in the future.  8/19/2008 : Previously I could not seem to get more then the error message set back, so it looks like it has very limited functionality. I’ve revisited the http://ziggurat29.com/ website and notice it lists what commands are implemented, and a few examples, I downloaded a new zip file and ran the examples from the website and get what is expected. Ziggurat29 lists the following implemented commands: 00, 10, 11, 13, 1A, 30, 31, 32, 37, 5D, 5E, 7E, 90, 93, 97, 98, 99, 9E, 11B, 1111, 1226 - At some point I’ll need to try these other commands, but as per the example 31 and 32 appear to work. Here is a short test of cut and pasting a command via telnet to 127.0.0.1 7000