TJX Hacking Incident Shows Cracks In Payment Card Systems

TJX Hacking Incident Shows Cracks In Payment Card Systems

The revelation by TJX Companies, owner of T.J. Maxx and other retail brands, that at least 45.7 million credit and debit cards were compromised over several years highlights anew the risks associated with processing card transactions and the need to protect the information they contain.

The breach eclipses the previous disclosure of 40 million compromised payment card records by CardSystems in 2005.

Intruders gained access to TJX’s computer systems beginning in 2005 and continuing until January 2007. Although debit card PINs weren’t compromised, unencrypted magnetic stripe data, also known as “track 2 data,” was stolen on transactions that occurred before September 2003, the company said.

Despite the company’s use of masking and encryption, the intruder had the technology to steal payment card data during the payment card issuer’s approval process, in which data (including track 2 data) is transmitted to the payment card issuer’s without encryption. Further, the intruder had access to the decryption tool for the encryption software utilized by TJX.

TJX said it deleted transaction information before the theft was discovered in late 2006, but not before the theft took place. A cardinal rule of card transaction security is to only retain information that’s needed for business purposes and delete everything else.

Although the full extent of fraud arising from the break-in won’t be known for some time, banks and payment card companies have notified TSX that they’ve discovered preliminary evidence of possible fraudulent use of stolen payment card information. The company said it is tightening its security policies in the wake of the breach.

Despite the tightening of security policies, the retailer is facing a class action suit filed on April 23 by the Massachusetts Bankers Associations (MBA) seeking tens of millions of dollars in restitution for banks that were forced to block and reissue thousands of debit cards following the breach. The Boston-based MBA said in a statement that banks in the state along with those in Connecticut, Maine, and California were among the financial institutions most hurt by the TJX data breach. A spokesperson for the MBA said they expect other banks to join the class action suit, filed in US District Court in Boston. (See related story:New England Banks File Class Action Against Retailer TJX )

The Payment Card Industry Data Security Standard (PCI) requires banks, payment processors, software vendors, and retailers to maintain rigorous policies, procedures, and practices to prevent sensitive information from falling into the wrong hands. PCI explicitly prohibit the storage of the full contents of the magnetic stripe once the authorization process is completed. Unfortunately, many merchants and service providers may be unknowingly storing this data because a number of commercially available payment systems and custom-designed payment applications retain this data by default without any action by the user. PCI also prohibits the storage of the Card Verification Value 2 (CVV2) and Personal Identification Numbers (PINs).

The value of full track data to hackers is significant. With little effort, a duplicate card can be created that will appear indistinguishable from the original card during the authorization process. Mass storage of this data by merchants and agents exposes this sensitive information to potential compromise and can make it easy for hackers to commit fraud that is difficult for issuers to detect. CVV2 and PINs are also highly sought after by hackers and when compromised can expose the payment system to undue risk.

Merchants that use commercially available POS systems should contact their POS vendors to validate whether the applications and versions in use are storing track data or other sensitive data, such as PINs. Additionally, merchants can ensure their payment applications do not store track data or other sensitive data by using a payment application that has been validated as PCI-compliant.

Merchants that discover track data or other sensitive data in their systems should immediately delete this data and take steps to upgrade or replace any software vulnerable to this security flaw. Custom-designed solutions should also be carefully evaluated for any evidence of magnetic- stripe data storage. If track data or other sensitive information is stored subsequent to an authorization, the data should be eliminated immediately and the solution modified to no longer store this data.

Hackers attempt to exploit known software vulnerabilities, as well as uncover unknown deficiencies in commercially available software products. An improperly patched system offers an attacker a convenient method to exploit known vulnerabilities with minimal effort. Automated tools are constantly being developed by attackers to locate vulnerable systems. A single exploitation of such a security gap can lead to the compromise of the merchant’s payment system infrastructure and result in a large-scale loss of data.

A technique called SQL injection is used to exploit Web-based applications by using client-supplied data in SQL queries. Through this avenue of attack, an attacker can break out of the Web server and database realms, gaining complete control over the underlying system. Another serious consequence can be the compromise and theft of data that resides within the payment application infrastructure.

PCI requires that Web-facing applications be developed in accordance with secure coding guidelines to guard against such attacks. Any part of the payment application infrastructure that accepts client input and subsequently passes this data onto a database must validate the legitimacy of the input. Values not conforming to the expected and acceptable input criteria must not be allowed to pass this validation step.

Custom-coded payment applications should be reviewed for potential SQL injection-related weaknesses. Automated tools are available in the marketplace to test applications for susceptibility to an SQL injection attack and should be utilized.


About the Author

Andrew Miller

Andrew Miller is a freelance writer specializing in financial services and information technology. He holds an MBA from Columbia University and a Master's in computer science from Rensselaer Polytechnic Institute. He has held jobs at CMP Media, MetLife, and Gartner.




Around the Network