Chapter 6

Breaking into PCI-protected Areas

And when memory failed and written records were falsified-when that happened, the claim of the Party to have improved the conditions of human life had got to be accepted, because there did not exist, and never again could exist, any standard against which it could be tested.

—George Orwell

Most payment application vendors today sell PA-DSS validated software, and many merchants are PCI DSS compliant. It would be reasonable to assume that vulnerability areas which are protected already by PCI rules are in practice less vulnerable than others. However, even though this is true to a certain extent, it is not the case for all of them and there are security holes in PCI-protected areas.

PCI Areas of Interest

For mostly historical reasons, PCI security standards take care of very specific places where sensitive card data can be intercepted. If you take a look at the detailed review of PCI DSS and PA-DSS requirements provided in Chapter 3, you will be able to easily distinguish those two key zones: data at rest and data in transit. It is important to note that data-at-rest protection is supported by PCI almost in full, while data in transit protection is very limited and mostly ineffective inside the store or data center. These findings are summarized in Table 6.1.

Table 6.1 Payment Application Protection Provided by PCI

Data at Rest: The Mantra of PCI

Data at rest is a security term for information stored on hard drives. To a certain extent, it is the opposite of data in transit, which is information that travels between various devices and computers. And it is also mostly what PCI is after. PCI rules are focused mainly on defense against attacks on data at rest because historically it was one of the two easiest ways to steal cardholder information (another one is “data in transit” which is discussed in the next section).

Before the PCI era, sensitive data was stored on hard disks and backup drives unencrypted, and it was only protected by merchants' network and physical security controls, which were often weak or in many cases missing completely. Since PCI was introduced, payment software vendors started protecting stored information by using cryptography which significantly reduced the possibility of exploiting these kinds of vulnerabilities. However, the level of protection provided by cryptography depends on specific implementation which includes different factors such as encryption algorithm, key length, and key management scheme. Using weak algorithms and poor key management for database and log protection is common practice, even in PA-DSS validated software.

The situation with application configuration is even grimmer: PCI does not require payment software vendors or users to encrypt application configuration, and it is usually stored in clear text and open to uncontrolled modifications. At first glance, this does not seem to be too dangerous since configuration information itself does not contain sensitive cardholder data. However, in the following paragraphs, you will see how the payment application can also be compromised through misconfiguration.

Temporary Storage

Some payment application vendors claim that they do not store sensitive data on POS machines, and as a result their systems are not vulnerable to attacks on data at rest. Such statements can be untrue, even though it is possible that they do not lie, and here is why. Product managers typically think about storage as long-term records of information, such as archive databases, while developers know that there are many occasions when data is stored temporarily. “There is nothing in this world constant, but inconstancy.”¹

The best examples of such temporary storage are S&F (Store and Forward) and TOR (Timeout Reversals) records which can be implemented as either local database tables or simply flat data files. Without entering into discussion about the importance and functional necessity of these two containers (for more details about S&F and TOR, see Chapter 2), just note that they exist in almost any POS payment system. Most important is the fact that despite the famous PCI prohibition of sensitive authentication data storage.

Sensitive authentication data must not be stored after authorization (even if encrypted).²

In practice these files still include full Tracks 1 and 2, which makes them very desirable targets for hacking. There is a simple explanation to such a severe “violation” of PCI rules: S&F and TOR records are normally generated when the authorization host is offline, which means no authorization is received, and thus storage of sensitive authentication data is allowed.

By prohibiting storage of sensitive authentication data after authorization, the assumption is that the transaction has completed the authorization process and the customer has received the final transaction approval.³

An important characteristic of S&F and TOR implementation is the necessity to perform both encryption and decryption operations at the same machine because those records are encrypted when temporarily stored to hard disk, but must also be decrypted immediately after they are restored so they can be further processed. Therefore, only a symmetric encryption scheme can be utilized. The inability to use hashing or public key cryptography means that the cryptosystem is vulnerable because the decryption key (the same as the encryption key in symmetric algorithms) is always available in the system, even if it is hidden and encrypted, and will be found sooner or later by an attacker.

Additional common security issues with such temporary storage are weak encryption algorithms and poor cryptographic key management, such as lack of key rotation, hard-coded key components, or insecure key storage (these vulnerabilities are discussed in more detail later in this chapter). Poorly designed key management can easily compromise even the strongest encryption algorithm.

That said, the temporary character of S&F and TOR data often leads to them being overlooked during security assessments, and their exploitability level not being adequately protected.

Application Logs

Payment application log files may contain much more interesting information for hackers than you can even imagine. Unlike primary application functions which are supervised by product management, log files and their content are usually controlled by developers who often do not care about security. Developers want to know as much as they can about their application runtime in order to troubleshoot it remotely, and log files containing as much detail as possible are their only way to gather such information. Thus developers may decide (without telling anyone) to write everything to the log files, including card tracks and account numbers. Yes, at best they may encrypt the sensitive data. However, the encryption keys can either be hard-coded or badly managed. If the same key is used for encrypting all the data for a long period of time, the history of the log files may contain enough information for cryptanalysis: “the art and science of breaking ciphertext.”⁴

Another threat associated with logging is tokens generated using the hash function of the PAN. At first glance, tokens are supposed to be safe by definition and are recommended to replace the actual card account numbers. However, when generated using hashing, they can be relatively easy to crack (more details about vulnerabilities of PAN hash functions are discussed in the next section).

Locating Temporary Storage and Log Files

Both temporary storage and logs are usually present in one of the following forms:

• Databases
• Flat data files
• Text files

Many POS and payment applications store temporary data using commercial database management systems such as Microsoft SQL Server, Oracle, Interbase, or MySQL. The fact that one of those systems is installed at the POS machine or store server means that the POS and/or payment application most likely uses this particular database for data storage.

The databases are typically password protected. However, payment applications often use default, well known administrative accounts with default passwords (as shown in Table 6.2) or passwords stored in clear text (either hard-coded or in configuration files).^{5, 6}

Table 6.2 Examples of Default Database Accounts and Passwords

The following fragment of a PA configuration file containing the SQL server database connection string is an example of the database password stored in clear text:

Server=localhost;Database=Payments;User Id=sa;Password=ld50fAnkesOTSUMW;

At first glance, the value of Password may look like it is encrypted, but this is just a password in clear text.

Flat data files can be used by custom in-house implementations of database management systems. The data in such files can be stored in binary format when information is encoded using all possible byte values (0–255) rather than just the ASCII codes (32–126) typically used in text files. Flat data files often have .dat file extensions.

POS and payment applications normally use text file format for logs so they could be easily read by developers and technical support personnel. They typically have .log or .txt file extensions.

Hashed PAN

The standard use of hash functions is producing a short digest of a message or file. The hash function is also called one-way encryption because it is mathematically impossible to reconstruct the original message from its digest, or more precisely, we “know of no easy way to reverse them.”⁷ This property of hashing is utilized by payment systems for “encryption” of credit card account numbers without the need to secure the encryption keys (simply because there is no key in most hash implementations). Table 6.3 shows different types of hash functions utilized for PAN encryption. The SHA-256 algorithm is considered safe today, while MD5 is obsolete.

Table 6.3 Examples of PAN Hash Functions

Brute Forcing and Rainbow Tables

The problem with hashing of credit card numbers is the fact that those numbers are “predictable” in that they consist of digits only and have a fixed length (15–19 digits, but usually 16) predetermined by card brand, with well-known 6-digit prefixes, and the last digit reserved for the Mod 10 checksum which can be validated. More than that, the first six and last four digits are often exposed in clear text, which is allowed by PCI and other standards, so in reality it's only six digits (16 - 6 - 4) that need to be guessed (Table 6.4). These factors provide an ability to conduct a relatively simple brute-force attack on credit card numbers.⁸

Table 6.4 Examples of PAN Masking According to PCI Rules

A brute-force attack in the case of PAN means going through all possible combinations (10¹⁶) of account number digits (or only 10⁶ in case the first six and last four digits are known), performing a hash function, and comparing the results with the “encrypted” (hashed) number obtained from the payment application log files or database. Rainbow tables can be used to simplify the process.

Rainbow tables are pre-compiled hash results that can be compared dynamically with the hashed PAN without the need to go through all the combinations and conduct hash functions for each permutation. It is possible to reduce the size of a rainbow table (and thus the lookup time) by excluding prefixes that are not used by major payment card brands (such as 0, 7, 8, and 9) and account numbers with invalid Mod 10 check digits. Table 6.5 shows a fragment of a rainbow table calculated for SHA-1 functions of major credit card account numbers. Note that the combinations with invalid Mod 10 are omitted.

Table 6.5 Example of PAN Rainbow Table Fragment

Insecure Storage of Encryption Keys

Strong requirements for data-at-rest protection are the most powerful side of the PCI standards, and they are implemented by many software vendors and merchants, mostly through use of symmetric encryption algorithms. More details about symmetric and asymmetric encryption can be found in Chapter 7, but for now just note that there is an important characteristic of symmetric encryption algorithms: the same cryptographic key can be used for both encryption and decryption. With respect to payment applications, this means that if the POS was able to encrypt the data (for example, before dumping it into the temporary storage or log file), there is almost always the possibility of decrypting the data on the same machine, even if the application is not programmed to do so. This is because the encryption key (which is also decryption key!) is present somewhere at that computer.

There are fewer options to hide the keys, which can be stored either in hardware or software. A hardware option is out of scope because it is too expensive (at least in most merchants' opinions) to use cryptographic hardware modules on each POS machine. The software options for key storage usually are:

• Hard drive (data file)
• Registry (on Windows-based machines, of course)
• Hard-coded (in the application binary file)
• Any combination of these options

Given the fact that many software vendors today use strong encryption algorithms, finding the cryptographic keys and using them to decrypt the sensitive data is the easiest and most likely scenario for attack on data at rest compared to others, such as cryptanalysis.

But why don't developers use asymmetric algorithms where the encryption and decryption keys are different and encryption keys cannot be used to decrypt the data? Simply because the payment application usually also needs access to the stored information, like in case of temporary S&F or TOR records, which means it must be able to decrypt the data after reading it from storage.

DEK and KEK

In simple cryptographic implementations, the data is encrypted using an encryption key which is stored in clear text in a file, a Registry, or hard-coded in the application code. In more sophisticated applications, the data is encrypted by Data Encryption Key (DEK) which is protected by Key Encryption Key (KEK). In this case, the DEK is still stored in one of the “secret” places listed above but it is encrypted using KEK (Figure 6.1). The problem with this approach, which is obviously more secure than encryption with just a single key, is that the KEK still needs to be hidden somewhere, and the choices are really the same as for the DEK: hard-coded, file, or Registry (usually, KEK is hard-coded because it is rarely changed). So the attacker's task—finding the key and decrypting the ciphertext—in general remains the same, it simply requires a bit more time and effort to find the KEK first, then find the encrypted DEK, decrypt it using the KEK, and finally decrypt the ciphertext using decrypted DEK.

Figure 6.1 Example of encrypted AES 256 DEK “hidden” in Windows Registry

Key Rotation

Key rotation is a security mechanism that was invented to resolve at least two issues:

The problem with key rotation is that it is not a simple task to implement, especially to implement it correctly. PCI standards do not contain explicit technological requirements or recommendations for software vendors regarding implementation of automatic key rotation features. The only requirement for key rotation is providing some minimal basic functionality, therefore, many application vendors just provide the merchants with manual instructions on how to change the keys.⁹

Naturally, such merchants never do key rotation because it is infeasible to perform those manual procedures on hundreds or thousands of their POS machines without significant interruption to the business.

In any case, key rotation is a great deterrent control; however, it does not provide ultimate data protection because the symmetric encryption key, even if it is rotated often, still must be present somewhere in the machine and can be retrieved by an attacker.

Default Keys

The problem with using default encryption keys is somewhat related to the issue with key rotation. Many merchants receive payment software from a payment application vendor and install it “as is” using out-of-the-box features and configurations. If the application vendor does not bother to design the automatic key generation and rotation mechanism, it is possible that all their customers' POS machines use the same default encryption keys.

Getting to the Keys

In order to find the keys, an attacker first needs to know where and how they are stored. This information can be obtained either with help of insiders or by reverse engineering.

Insiders are people who work or used to work for the payment software vendor, integrator, or merchant. They are familiar with the application design and have access to the code and/or documentation. Those current or former employees can abuse their authority and knowledge in order to meet their financial goals, or just for some kind of revenge. Using their knowledge of the system, they may craft malware to retrieve the keys themselves or sell this information to hackers.

Reverse engineering, or disassembling, is a process of “decoding the code.” Most programming languages used to write the payment application code are either compilers or interpreters. In any case, they create some kind of binary file as the last step of the code-building process. If a compiler creates the machine executable code (examples are C, C++, or Delphi), it is more difficult to disassemble such code to its original representation, which is called source code. With modern languages that create intermediate code (such as Java or C#), it is much easier to understand the original source unless the binary code is obfuscated. In any case, whatever time it takes, reversing the code in order to locate the keys is a feasible task.

And finally, we should not forget about the fact that the application has to decrypt the DEK before it can use it for data encryption or decryption. Most payment applications use software encryption which means that all the cryptographic operations are performed in the application memory, so unencrypted DEK must be present in memory and can be captured by the malicious memory scanning software installed on a POS machine.

Once the application logic is studied, it is only a matter of time and the programmer's skills to create malware that would be able to retrieve the keys, decrypt the cardholder data stored by payment application, collect it, and send it to the attacker via the Internet, wireless, or even a Bluetooth connection.

DiskScraper Utility

Although encrypting PAN and track data storage is one of the strongest and most famous PCI requirements, it is possible that some records are still sitting out there because somebody forgot to delete them or simply because there is a bug in the POS software. There are several tools—both commercial and open source—available to scan the hard drives for sensitive data. If you run such a tool, you may be surprised that account numbers or even track data that should have been deleted from the PCI DSS compliant machines running PA-DSS validated applications are still there. DiskScraper is a sample .NET utility that scans the files which may contain sensitive data (such as .log, .txt, and .dat), and finds the PAN, Track 1, and Track 2 of the payment cards (Figure 6.2). It uses the same search technology—regular expressions—that is also implemented by the MemoryScraper and NetScraper tools that are described in the previous chapter. Run the executable (NetScraper.exe, which along with the source code, is available for download from www.wiley.com/go/hackingpos) on the computer with your favorite POS software. The results of the search will be displayed in the log file (Figure 6.3). And once again, if you are not a programmer and not interested in the code details, skip to the next sections.

Figure 6.2 DiskScraper utility

Figure 6.3 DiskScraper search results

Recursive search

When DiskScraper is set up to search all the files on either a single drive or all the drives, it is using recursion which is a simple and elegant method of scanning a tree (a folder tree in our case).

The recursive function starts from the root folder and calls itself until it reaches the “bottom” of the folder tree branch:

bool RecursiveScan(DirectoryInfo Directory, bool CountOnly)
{
…
IEnumerable<DirectoryInfo> dirs = Directory.EnumerateDirectories();
foreach (DirectoryInfo dir in dirs)
{
if (!RecursiveScan(dir, CountOnly))
return false;
}
…
return true;
}

Then, it scans all the files in that folder and “automatically” moves to the next branch:

IEnumerable<FileInfo> files = Directory.EnumerateFiles();
foreach (FileInfo file in files)
if (!ProcessFile(file, CountOnly))
return false;

Eventually, it passes all the folder branches and scans all the files.

Text vs. Binary Files

There are two major types of files with different structures: text and binary. Text files consist of lines of ASCII or Unicode characters. The text lines are separated by carriage return (0x0D) and new line (0x0A) ASCII characters. The binary files are arrays of bytes which may have any value. Depending on the file types, there are different ways to open the file and iterate through its content.

The text files can be read using .NET StreamReader (TextFileSearch class),

StreamReader sr = new StreamReader(fName);

and then simply scanned line by line:

while (sr.Peek() >= 0)
{
input = sr.ReadLine();
LineNumber++;
searchLine.Search(input, LineNumber.ToString(), fName, ref res);
}

The binary files should be opened by .NET FileStream and BinaryReader (BinaryFileSearch class):

using (FileStream fs = new FileStream(
fName, FileMode.Open, FileAccess.Read, FileShare.ReadWrite))
{
using (BinaryReader br = new BinaryReader(fs, new ASCIIEncoding()))
{
…
}
}

They should be read in chunks since they can be too large to load as a single block. The chunk size is set to 4,096 (4 KB) by default but it can be any size depending on desirable performance:

chunk = br.ReadBytes(CHUNK_SIZE);
while (chunk.Length > 0)
{
string ASCIItext = Encoding.ASCII.GetString(chunk);
string Unicodetext = Encoding.Unicode.GetString(chunk);
searchLine.Search(ASCIItext, position.ToString(), fName, ref res);
searchLine.Search(Unicodetext, position.ToString(), fName, ref res);
chunk = br.ReadBytes(CHUNK_SIZE);
position += CHUNK_SIZE;
}

DiskScraper uses the same code (located in HackingPOS.Scrapers.Common) as MemoryScraper and NetScraper for finding the card account numbers and tracks.

Data in Transit: What is Covered by PCI?

In the requirements related to communication protection, PCI standards distinguish between different types of networks: “open, public” and any other network.

“Encrypt transmission of cardholder data across open, public networks.”¹⁰

The problem with such a distinction is that non-“open, public” networks, which include in-store LAN, corporate WAN, and frame relay between merchant and processor, play significant roles in the functionality of payment applications. Moreover, payment applications mostly use those types of networks for sensitive data transmission (Table 6.6).

Table 6.6 Network Protection Requirements

With that said, even a simple analysis of PCI DSS requirements makes most “PCI compliant” payment applications vulnerable for basic network-sniffing attacks, which are described in Chapter 5. However, even PCI-protected “open, public” networks are still vulnerable to more sophisticated attacks.

SSL Vulnerabilities

Secure Socket Layer (SSL) is a very popular and established protocol used for protecting data in transit, and payment applications are no exception. However, SSL is not unbreakable and it may have flaws, especially when it is not properly configured.¹¹

Outdated Versions of SSL/TLS

SSL went through several modifications since it was first invented by Netscape in 1995.¹² The last version of SSL was 3.0 and since then it has been continued under the name TLS (Transport Layer Security) protocol. If a payment application does not use the latest and greatest version of TLS (1.2 at the time of this publication), it is most probably vulnerable to attacks because each version of SSL and TLS included security patches.¹³

Weak Cipher Suits

One of the features of SSL is the ability to negotiate the type and level of encryption between client and server. On the one hand this feature is beneficial because it allows different types of clients and servers to communicate with each other. On the other hand, this feature may allow an attacker to downgrade the level of encryption and tamper with a communication that is supposed to be secure.¹⁴

Man-in-the-Middle

Man-in-the-Middle (MITM) is one of the most famous type of attacks. It allows an attacker to seamlessly tap on-network traffic between unsuspecting clients and servers and steal sensitive payment card data. The client configuration can be manipulated so it establishes communication with the bogus server through a different host address and a server certificate that is valid for that address. If the client does not validate the host URL and the issuer of the server certificate, then it assumes it is talking to the legitimate server.

Another possible scenario of a MITM attack is inserting a bogus proxy (an intermediary that transmits requests and responses between clients and servers) which intercepts the network traffic between the legitimate client and the server using a fake server certificate as shown on Figure 6.4. The bogus proxy establishes communication with the legitimate server and pretends to be a legitimate client. This can be made possible by several conditions, including:

Figure 6.4 Man-in-the-Middle Attack

Summary

PCI Security Standards protect only limited, relatively small areas of payment applications and are mostly focused on data at rest, which includes temporary storage of S&F and TOR data on hard drives, log files, and more. Even though all the sensitive data stored on hard drives must be encrypted according to PCI requirements, payment applications use software encryption with weak key management implementations which are often vulnerable to simple attacks. Encryption keys are “hidden” inside the application code (hard-coded), Windows Registry, or data files, and can be easily located and used to decrypt the sensitive cardholder information.

PCI also protects very limited amounts of sensitive data in transit, which is transmitted only through “open, public networks” such as wireless LAN and Internet. PCI compliant payment applications are not required to encrypt data traffic on store LAN, corporate WAN, or frame relay links to payment processors. Even though the traffic is encrypted on wireless networks and the Internet, vulnerabilities of security protocols such as SSL can be exploited in order to tap on-network communications and steal sensitive cardholder information.

Notes

1 Jonathan Swift, “A Critical Essay upon the Faculties of the Mind,” The Works of the Rev. Jonathan Swift, D.D. Dean of St. Patrick's, Dublin with Notes, Historical and Critical, Vol. 2, Arranged by Thomas Sheridan, A.M., (London, 1808), p. 460.

2 PCI DSS Requirements and Security Assessment Procedures Version 2.0, PCI SSC, (October 2010), Req. 3.2, 3.2.1, p. 29, https://www.pcisecuritystandards .org/documents/pci_dss_v2.pdf

3 PCI PA-DSS Requirements and Security Assessment Procedures Version 2.0, PCI SSC, (October 2010), Req. 1.1, 1.1.1, pp. 17-18, https://www. pcisecuritystandards.org/documents/pa-dss_v2.pdf

4 Bruce Schneier, Applied Cryptography, Second Edition: Protocols, Algorithms, and Source Code in C, (Hoboken, NJ: Wiley, 1996), p. 13.

5 Default Passwords, CIRT.net, http://www.cirt.net/passwords

6 Default Password Database, Virus.org, http://www.virus.org/default _passwds

7 Bruce Schneier, Applied Cryptography, Second Edition: Protocols, Algorithms, and Source Code in C, (Hoboken, NJ: Wiley 1996), p. 35.

8 “Hashing Credit Card Numbers: Unsafe Application Practices” (2007), http://www.integrigy.com/files/Integrigy_Hashing_Credit_Card_Numbers_Unsafe_Practices.pdf

9 “PCI PA-DSS Requirements and Security Assessment Procedures Version 2.0, PCI SSC” (October 2010). Req. 2.3, pp. 24–26, https://www.pcisecuritystandards .org/documents/pa-dss_v2.pdf

10 “PCI DSS Requirements and Security Assessment Procedures Version 2.0, PCI SSC” (October 2010), Req. 4, p.35, https://www.pcisecuritystandards .org/documents/pci_dss_v2.pdf

11 David Wagner and Bruce Schneier, “Analysis of the SSL 3.0 protocol,” https://www.schneier.com/paper-ssl.pdf

12 “The SSL Protocol, Netscape” (1996), http://web.archive.org/web /19970614020952/ http://home.netscape.com/newsref/std/SSL.html

13 TLS/SSL hardening and compatibility Report 2011, G-Sec, http://www.g-sec.lu/sslharden/SSL_comp_report2011.pdf

14 WeakCipherSuites: Testing for weak cipher suites, Sslyze, (March 2012), https://code.google.com/p/sslyze/wiki/WeakCipherSuites

15 “Comodo Fraud Incident, Comodo” (March 2011), http://www.comodo .com/Comodo-Fraud-Incident-2011-03-23.html

16 Steven J. Vaughan-Nichols, “How the NSA, and your boss, can intercept and break SSL,” ZDNet, (June 2003), http://www.zdnet.com /how-the-nsa-and-your-boss-can-intercept-and-break -ssl-7000016573/