Protect Debug Info Transaction Participant

jPOS-EE has a very handy transaction participant called “Debug” its main purpose is to dump the contents of the jPOS’s Context. While this is very helpful in test modes and during development – The context remains “un-protected” and all of the data remains in the clear. Even the ProtectedLogListener and FSDProtectedLogListener will not protect data in the context.

Enter the ProtectDebugInfo Transaction Participant a configurable implementation I wrote based on some of Alejandro’s ideas, and one that lives in most of OLS’s payment products in various specific iterations.

It’s configuration looks like:

ProtectDebugInfo.png

Protecting your q2.log in this truncated example:

<entry key=‘FSDMESSAGE’>
<fsdmsg schema=‘file:cfg/fsd-base’>
account-number: ‘599999______0001’
</fsdmsg>
</entry>
<entry key=‘PAN’>599999______0001</entry>
<entry key=‘RESPONSE’>
<isomsg direction=“incoming”>
<field id=“0” value=“2110”/>
<field id=“2” value=“599999______0001”/>
<field id=“35” value=“599999______0001=____________________”/>
</isomsg>
</entry>
<entry key=‘REQUEST’>
<isomsg direction=“incoming”>
<field id=“0” value=“2100”/>
<field id=“2” value=“599999______0001”/>
<field id=“35” value=“599999______0001=____________________”/>
</isomsg>
</entry>

ADT Offers New ATM Security Technology to Combat ‘Skimming’

622

I read about a new Anti-Skimming device for ATM readers here

 

In a matter of seconds, criminals can place a skimming device on an ATM card reader that blends in with the machine’s appearance and does not interfere with its operation. A small wireless camera, concealed near the ATM fascia, is also used to capture the user’s personal identification number (PIN) as it is entered. Information from the device and camera is sent wirelessly to the criminal’s laptop computer. The ATM user typically has no idea that his or her information has been compromised.

To help reduce ATM skimming, the ADT solution is installed inside an ATM near the card reader, making it invisible from the outside. The technology helps prevent card-skimming attempts by interrupting the operation of the illegal card reader. The solution also detects the presence of foreign devices placed over or near an ATM card entry slot, without disrupting the customer transaction or operation of most ATMs. For effective, layered ATM security, the ADT solution can trigger a silent alarm for command center response and can coordinate video surveillance of all skimming activities.

 

Look interesting.

Heartland Payment Systems Breach – My Thoughts

index_logo

You should all be aware of the Heartland Payment Systems Breach that happened on Inauguration day – had it been a different day it would be a front page story, perhaps it will be a front page story today? This post is to share my thoughts (that are speculation) based on my experience in payment systems and security rather than to re-hash the Heartland Press Release.

Let the pundits come: I can hear it now, "Was Heartland PCI Compliant ?" (They were/are btw, the QSA was Trustwave and they are listed as a compliant service provide dated April 30th, 2008) If they were PCI compliant how did a breach occur ? It is important to note (again, and again) that Compliance != Security. Compliance is a snapshot in time, PCI is not based on an organization’s own risk assessment of their environment. It is a prescriptive list of general IT Controls to be used as a baseline for "better" security then those organizations that are not compliant with the intent of reducing the risk of breaches. But you can be compliant and not secure, security is a process and constantly striving towards that end (it is like driving to infinity you never get there), is the goal, not compliance itself. I also expect to see merchants use this as an excuse — why are we spending all of this money for PCI complaint when attackers can successfully attack Processors anyway?

Processors and Service Providers are Fort Knox: Processors process for thousands of merchants and handle a large volume of transactions. Processors are in the business of processing card data, they require card numbers to communicate over the payment systems interchange networks as well as to provide settlement, clearing , and authorization files (among others) — The data of these files and message formats have account numbers, track data, cvv2 data (only the authorization messages include the last two) in the clear -but transmission is typically over a private leased line, use file level encryption, or transport level encryption, but there is a place in the "PCI-ZONE" of companies that sends this data in clear across the network – making sniffing the traffic a threat here. Can this be further controlled by further network segmentation and control at processors? I think so (topic of another post). Only the Payment Switch would need to have direct connections to these end-points not the full PCI-Zone.

Blame the QSA: Nobody has blamed the QSA yet, and I don’t know if anyone will, but I’m sure someone will try to; when breaches occur they are going to be asked what they missed ? What does that mean for QSA’s or IT auditors ? How do your work papers look ? Can a independent third party look at your work papers as evidence and come to the same conclusion as you? Did you test to the control or did you test something else ? Did you understand intent of the control ?

Issuing Banks: You don’t get to hear much of the story about the burden on Issuing Banks here. They have the cost of notifying cardholders, postage expense, customer service calls, brand perceptions problems due to confused customers, costs to reissue cards, etc. This includes both credit, debit, payroll, gift and others.

Press Release: Two things that got me about the Press Release, one was its timing, which may or may not be a coincidence, and the second was the focus was on the data that was not compromised, not the data that was. Like why not add: The cardholders’ favorite colors and cereals were also not compromised Account Numbers, Expiration Date and Track Data (Track 1 contains Name, Track 2 doesn’t) were compromised, cloned cards can be made from these "dumps" of magstripe data.

PCI Compliance: Remember that Service Providers and Processors where the very first to be scrutinized under Visa’s CISP and MasterCard’s SDP programs, and later PCI. The truth is that many processors and gateways should have close to 5 years or so of experience with PCI compliance and reviews if they are not a new service provider. Also: If you ever read through some of the actual audit procedures of PCI – notice what the auditors actually test: some tests are just based on Inquiry or documentation alone, furthermore some tests that do not test the operating effectiveness of some of these controls to a period of time.

Cost of the Breach: Anything that you hear is a guess – nobody knows for sure– (Well the card brands and affected issuers probably will) – we know that Heartland does 100 million in volume a month, and can safely assume that data was sniffed for a few months (some reports it as in place as early as May 2008) — we don’t know the unique number of card numbers nor do we know which card numbers are affected. I would guess around $600 million – based on cost of record at ~$6.00 and assuming 100 million unique card numbers were affected.

How did it Happen: Let’s look at the PR:

" After being alerted by Visa® and MasterCard® of suspicious activity surrounding processed card transactions, Heartland enlisted the help of several forensic auditors to conduct a thorough investigation into the matter. Last week, the investigation uncovered malicious software that compromised data that crossed Heartland’s network."

There really isn’t enough information here but let’s make an educated guess: We know that malware/software was installed. So we have the threat of physical security/social engineering that would install a piece of software, an OS or Application level attack, or a targeted piece of malware that was installed in the PCI Zone accidentally. Perhaps a combination of some of these. This type of Malware (sniffers) requires administrator system or root level access in order to sniff network traffic in promiscuous mode (in most cases.) There are ways to flood network switches to make them act as a hub to broadcast traffic, and there are also VLAN hopping attacks.

PCI 1.2.1 / 1.3.5

Let’s look at PCI 1.2.1:

"Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment"

and PCI 1.3.5

"Restrict outbound traffic from the cardholder data environment to the Internet such that outbound traffic can only access IP addresses within the DMZ"

So the data would need to be collected and re-transmitted to a drop site, the drop site was probably actually multiple drop sites, and I’m guessing a well known outgoing port such as 443/SSL was used with encrypted payloads. These two PCI controls are intended to prevent outbound access from the cardholder environment, did these systems have outbound Internet access ? or if they did was it controlled ? and if it was controlled was it able to pass though the allowed outgoing traffic ?

Anti-Virus / Firewalls / Encryption: These are terms that are used to define ones security, Security is not a product – But let’s look at each of these briefly:

Anti-Virus – The effectiveness of Anti-Virus is poor, if you are familiar with services such as VirusTotal or have read something like this <– This is why not all malware can be detected by Anti-Virus.

Firewalls – I swear I think people think that firewalls are magic devices — Hollywood  and TV Land  don’t really help here either. Understand what a firewall does – it works at the network layer and can either allow or block IP Address or ranges and port numbers, that is basically all they do. Granted, Application level firewalls and Web Application Firewalls can inspect the content of the traffic (I’m not talking about these)

Encryption: There are different types of encryption, each protects different things in different ways.So you you say something to the effect of:

"We have industry leading encryption"

Are you talking about File Level Encryption ? Disk Encryption (which only works at data at rest), Transport encryption, encrypted data elements or application level encryption, column level or transparent encryption in a database ?  Understand that Encryption is not Encryption is not Encryption.  For example using a product to encrypt a disk to store data at rest, does not provide encrypted data elements and transport level encryption. And lastly End-to-End Encryption solutions would not of prevented this either: see my post here: When End-to-End Encryption is really not End-to-End.

When End-to-End Encryption is really not End-to-End.

I’m reading a lot about solutions that implement end-to-end encryption, where account numbers and track data is encrypted and can utilize a Hardware Security Module (HSM) and DUKPT or other encryption algorithms from the point-of-sale. I thought it important to share what data is actually encrypted in the payment system.

 

Here is a list in no particular order:

Gateways:

(contact me and I’ll add you if you are not listed)

 

Most of these are ISO’s that sell you a merchant account and access to their gateway that uses "end-to-end" encryption and that it will shift the PCI and PA-DSS burden from you to them, if you are a merchant, some claim you don’t even need to go through PCI compliance because you don’t have access to the card numbers or the encryption keys to decrypt the cards (Please also see this post on this subject).  This is all really good stuff, I’ve written about End-to-End Encryption before and am a big proponent of it. This can help prevent "sniffers" and card capturing malware from capturing track data and account numbers in the clear as they traverse your internal network. Attackers would either need to install card skimmers or gain access to encryption keys, or use brute force methods against captured encrypted data to capture data at your store.

But it isn’t really End-to-End Encryption.

Let look at two examples:

  1. A typical small merchant using a payment gateway
  2. A large retailer or processor/gateway that uses a payment switch

 

A typical small merchant that uses a payment gateway:

Slide2

 

A large retailer or processor/gateway that uses a payment switch

Slide1

( uses leased lines to connect directly to a Payment Processor (FDR, Chase/PaymentTech, Fifth Third, MPS, etc ) or Interchange Network (VisaNet, BankNet, etc )

Let’s say that you are using a gateway or even a switch that supports an encrypted message format from the point-of-sale (POS). The area in RED in each diagram shows where the account number traverses the payment networks in clear text. At the small merchant example from the Gateway to the rest of the network – the account number and track data and CVV2/CVC2 data is sent in the clear. In the direct connect model with the Payment Switch (which actually just operates as a local gateway) from the payment switch to the rest of the network. So End-to-End is really not End-to-End at all. (it depends on where you define end :)  This should also explain why End-to-End Encryption in its current state would not of prevented the breach at Heartland Payment Systems – as a processor they need to connect and communicate over the interchange networks using TCP/IP connection and ISO-8583 messages to these endpoints.

 

Why is this ?  The Payment interchange networks and message formats that processors and the Interchange networks use does not support this in their current message formats (primarily ISO-8583) There is no room in the current implementations of Visa’s Base1, MasterCard’s MIP, or FDR’s message formats for example. Data Elements can be added to support this, but would require massive changes to Payment Systems infrastructures and systems.

 

Does any one have any solutions for this ? Please provide comments below — I’ll provide a follow-up blog post with some of my ideas.

 

Remember that End-to-End is really not End-to-End, it may shift or transfer some of the compliance "burden"  from the merchant to that of the processor, but still exists in clear text on private networks and at processors.  Oh, and tokenization and secure card vaults would work the same way here, the cards need to be translated to their raw value to ride the payment networks.

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

hsm 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:

2009-01-06_1636

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

180px-Titanic-New_York_Herald_front_page

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."

mobile commerce – sms text notifications

Picture 20If you have ever used Obopay or even social networking site Facebook, chances are that you have interacted with your mobile phone with these sites in some manner with your phone.  Obopay, is a little more obvious, but you receive text notifications when you send or received money on your mobile.  Facebook sends text messages to your registered mobile phone number for you to validate your account, Obopay also uses multi-factor authentication to validate the user of its website using a phone call and spoken code, or a text with a message and a code that need to type in a webpage. This is called Out-of-Band Authentication and your bank may have implemented something similar for its Internet banking.

 

Yesterday, I researched and implemented text notifications when you perform an Reload or Add Money transaction on our issuing platform to your prepaid card using an interface to a SMS Gateway. Check it out below: I’m using my Nokia E71 here.

 

Fun with Card Readers and Encoders/Writers

I received a MSR505c Card Reader/Writer in the mail today. I use and have a need to create test cards that have magstripes for a variety of purposes; The main one being a way to test/demo our issuer based products from Point-of-Sale (POS) systems and payment terminals.

 

I thought I create a short screencast to show how this works, which is provided below:

Some considerations to note:

It is extremely easy to "clone" a payment card using a device such as this, and the entry point from a cost and availability perspective is low (~$300 range). In a follow-up blog post, I’ll write about Maktek’s MagneSafe and MagnePrint products to detect card cloning at a magstripe level.

Picture 19

Obopay adds multi-factor authentication

Picture 16Since 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)