Before I get into this post, I'd really like to explain some of the thought behind it. It's a little lengthy, but I think it's important to understand. If you really don't care, you can skip below to the next section, but I would ask you try to read this first.

A debate for the greater good

There was an interesting talk by [qu0rum] on the Crypto Village track of DefCon 24 called "Opps! I cracked my PANs!" This talk focused on the poor practices that merchant gateways can use to generate PCI-compliant transaction tokens for online payments. The idea is: if you have one of these tokens, and store this instead of certain parts of PII, it will help protect your customers in the event of a breach. That's all fantastic on paper, but the execution of this policy is extremely important. However, [qu0rum] discovered that many MGPs will generate these tokens using insecure hashing schemes (say, for example, unsalted SHA1).

Why is this such an issue?
Well, I think it's rather safe to assume that a vast majority of the people and institutions integrating these processes don't understand the feasibility of cracking hashes. In concept, hashes are "one-way" mathematical algorithms that, by definition, can not be reversed. But just because they can't be reversed, doesn't mean they can't be cracked. Sadly, this is often confused, and you will quite quite a few people who imagine hashing as some sort of "magic bullet." Some with limited scope in cracking may even draw drastically incorrect conclusions about the key-space of targets, and assume their hashes are safe due to the infeasibility of cracking them (which is a problem that happens often with password cracking.)

All of that leads to the awful position where the defenders believe they are far more well-off than they really are. At the same time, malicious actors will know better.

How should we go about correcting the problem?
This is something I have struggled with quite a bit. As a simple solution, one would assume that you either alter the hashing algorithms to something stronger, or even use a different scheme entirely (.e.g. UUIDs.) However, this is easier said than done. With massive amounts of infrastructure already in-place, possible misunderstandings about the technology, and no obvious epidemics to recognize or reference, where is the motivation for businesses to spend large amounts of money changing infrastructure that appears to work fine? If it's not broke, don't fix it! Right?

Except, it is broken, and a lot of people just don't know it. So now where do you go? There are only a few options from here, and none of them seem particularly good.

One answer is to do some research, and talk to the world about the problem. Maybe people will get riled up enough to actually want to do something and get the issue corrected. This DefCon talk could have been that. The problem here is that people may not listen. Unfortunately, it's now well into 2017 and not many people seem to have taken notice of [qu0rum]'s talk. Most people in tech that I try to talk to about this topic don't seem to even know transaction tokens may be a possible problem.

An alternate solution might be releasing tools which demonstrate the dire consequences of failing technologies, and hopefully inspire the defenders to take some action. This is the category I place tools like Hashcat into (although I recognize that Hashcat specifically grew from very different roots.) But the problem with this approach is, how can you trust the ways in which these tools will be used? Or abused, as the case may be. I've spoken to quite a few people about this exact dilemma. I wish there were an easy answer, but there isn't. People have vastly different perspectives, with quite a range of passion regarding this point.

You could sit down for quite a while trying to come up with theoretical options, but in the end I came to acknowledge that no matter what we choose to write, or how we choose to disseminate this information among defenders, the malicious actors will be writing their tools anyway. All it will mean is the defenders won't have the tools (or possibly even the insight) to know how to protect against these actors properly. Personally, I see that as a grave problem.

Given my choices, I tend to think giving defender the proper tools they need to understand a problem out-weighs the relatively smaller chance of abuse. I mean, Kali Linux is an entire OS built on this principle! Give defenders the tools they need to be effective.

It's an imperfect world, filled with imperfect solutions. All you can do is try your best at the right thing, and hope it all doesn't go south.

So please, if you use this tool, don't abuse it.

A new tool for the job

For defenders looking to test their infrastructures as part of a security life-cycle, I have crafted a new utility called ccsiege. Unlike [qu0rum]'s solution of modifying Hashcat directly, I thought it would be more useful to have a standalone utility which can be used to generate candidates. You can then further process the generated data before eventually piping it as input into whatever range of tools you happen to want to use. Here, we're no longer limited to just using Hashcat if we don't want to.

You can use the --help flag to see a list of options about the software, but there are 3 main modes which can do the following:

  • Generate a random sampling of PANs for a given IIN pool
  • Generate all valid PAN candidates for a given IIN pool
  • Verify input on stdin contains valid PAN candidates

There are a number of tools out there which do any combination of these things already, so this functionality is not unique. Where ccsiege really gets interesting is its ability to filter down the IIN pool. There are flags to filter based on card issuers, vendors/institutions using the cards, or even geographic location (based on country.)

NOTE: The following examples illustrate some general use-cases of ccsiege and are not meant to specifically target any particular institution or region.

For example, one could choose to generate all valid candidates of PANs issued by MasterCard in the UK.

$ ccsiege --walk --issuers mastercard --country uk

Or all of the PANs issued by MasterCard in Australia used by BankWest or Commonwealth Securities.

$ ccsiege --walk --issuers mastercard --country au --vendors bankwest,"Commonwealth Securities"

Additionally, you can use --verify and feed it data on stdin. This will output only the data which qualifies as a valid PAN candidate.

$ cat file.txt | ccsiege --verify

Looping back around to merchant gateways, let's pretend that the security team of the Acme company wanted to do some security analysis on the tokens Gateway X is handing them. They suspect these tokens are unsalted SHA1. In this example, we can use ccsiege to feed Hashcat and find out results.

$ ccsiege --walk | hashcat -m100 tokens.txt

Or, we could even use ccsiege for simply generating random PANs to be used with testing of online merchant systems.

$ ccsiege

It's easy to see the flexibility of this system. ccsiege allows us greater control on crafting specifically targeted tests, and can easily become a valuable tool for those trying to protect online merchant systems. I am placing the code on GitHub with a BSD license. All I ask is that you take care when using this software, and please don't use it for malice.