web analytics

Archive for the ‘PCI-DSS’ Category

To Tokenize Or Not Tokenize – The Truth About Scope And Compliance Risk

The hard-to-face reality is that billions of personal records are exposed each year. A commonly used, yet incomplete solution, is tokenization. Tokenizing sensitive data does not eliminate the need to achieve and certify PCI DSS compliance.

In order to completely descope from PCI, a business can partner with a data custodian (VGS) that handles 100% of data capture and vaulting – removing any compliance risk and completely avoiding data leaks.

Massive data leaks, at this point, are becoming a frequent occurrence – with headlines regularly popping up highlighting cybersecurity disasters that have impacted millions of consumers.

Earlier this summer, news of a cybersecurity disaster rattled North American consumers. The highly-publicized Capital One data breach of 2019 led to the sensitive data exposure of 100 million Americans and 6 million Canadians – including hundreds of thousands of social security numbers and bank account numbers.

Similarly, in July, we learned about the whopping $700 million settlement as a result of the Equifax data breach. Now, years later, the 147 million customers impacted by that disaster all get a piece of that pie.

It only seems like a matter of time until the next multi-million-dollar data breach settlement will be announced, and another consumer data-handling organization will have their feet publicly held to the fire.

From the improper configuration of web applications to the massive security risk involved in cloud storage generally, companies have wisely been seeking alternatives to storing their own sensitive user data and opening themselves up to data breach risk.

The rise of tokenization

In order to reduce data leakage risk as much as possible, many tech organizations have leveraged a method called tokenization. It’s a way to limit storing plain text sensitive data within a company’s own systems by using “tokens” to replace private user information like medical data or credit card numbers.

Unlike encryption, where a mathematical equation can “solve” the data replacement and reveal the original sensitive information, tokenization is not reversible. With no mathematical relationship to the original data point, tokenization is widely considered to be a safe way of transmitting and storing critical information.

However, tokenizing sensitive data does not eliminate the need to achieve and certify PCI DSS compliance – although it can reduce the number of system components to which PCI DSS compliance would apply.

With tokenization, sensitive data is mostly hidden. But, there are two points where tokenized data still remains within the scope of PCI DSS compliance: the data vault and the original point of capture.

Even when organizations store and use tokens instead of raw sensitive data, the original data is within PCI scope because they’re still within the cardholder data environment. In this environment, a business is still responsible for any leaked data.

But what if businesses could offload this data risk fully, and enjoy the benefits of tokenization while keeping all the original data completely off their own systems?

Descoping entirely

In order to completely descope from PCI DSS compliance, a business can partner with a data custodian that handles 100% of data capture and vaulting – removing any compliance risk and completely avoiding data leaks.

VGS is an innovative data custodian that takes on their clients’ compliance risk, securely storing all sensitive data and removing businesses from PCI scope in full.

By leveraging synthetic data ‘aliases,’ which are generated in real-time to protect all sensitive customer information, VGS empowers businesses to use customer data just as they did before – but never actually touch the sensitive data themselves.

Startups that work with VGS remove their compliance risk and avoid the potential risk associated with data breaches because there’s nothing to steal in the first place.

By partnering with a data custodian, organizations can completely descope their systems and win over new customers with the peace of mind that their sensitive personal data is in safe hands.

When businesses implement VGS solutions to handle their sensitive data, they instantly inherit VGS’s best-in-class security posture, which enables them to fast-track their certifications like PCI, SOC2 and others.

With data security as one less thing to worry about, organizations can focus their time and resources on growing their core businesses.
This article was originally published in Very Good Security.

Credit Card Hacks and How To Avoid Them

Preface

If you know me, or have read my previous post, you know that I worked for a very interesting company before joining Toptal. At this company, our payment provider processed transactions in the neighborhood of $500k per day. Part of my job was to make our provider PCI-DSS compliant—that is, compliant with the Payment Card Industry – Data Security Standard.

It’s safe to say that this wasn’t a job for the faint of heart. At this point, I’m pretty intimate with Credit Cards (CCs), Credit Card fraud and web security in general. After all, our job was to protect our users’ data, to prevent it from being hacked, stolen or misused.

You could imagine my surprise when I saw Bennett Haselton’s 2007 article on Slashdot: Why Are CC Numbers Still So Easy to Find?. In short, Haselton was able to find Credit Card numbers through Google, firstly by searching for a card’s first eight digits in “nnnn nnnn” format, and later using some advanced queries built on number ranges. For example, he could use “4060000000000000..4060999999999999” to find all the 16 digit Primary Account Numbers (PANs) from CHASE (whose cards all begin with 4060). By the way: here’s a full list of Issuer ID numbers.

At the time, I didn’t think much of it, as Google immediately began to filter the types of queries that Bennett was using. When you tried to Google a range like that, Google would serve up a page that said something along the lines of “You’re a bad person”.

This is Google’s response to those trying to figure out how to find credit card numbers online.

About six months ago, while reminiscing with an old friend, this credit card number hack came to mind again. Soon-after, I discovered something alarming. Not terribly alarming, but certainly alarming—so I notified Google, and waited. After a month without a response, I notified them again to no avail.

With a minor tweak on Haselton’s old trick, I was able to Google Credit Card numbers, Social Security numbers, and any other sensitive information of interest.

So I notified Google, and waited. After a month without a response, I notified them again to no avail. With a minor tweak on Haselton’s old trick, I was able to Google Credit Card numbers, Social Security numbers, and any other sensitive information.

Bennett

Yesterday, some friends of mine (buhera.blog.hu and _2501) brought a more recent Slashdot post to my attention: Credit Card Numbers Still Google-able.

The article’s author, again Bennett Haselton, who wrote the original article back in 2007, claims that credit card numbers can still be Googled. You can’t use the number range query hack, but it still can be done. Instead of using simple ranges, you need to apply specific formatting to your query. Something like: “1234 5678” (notice the space in the middle). A lot of hits come up for this query, but very few are of actual interest. Among the contestants are phone numbers, zip-codes, and such. Not extremely alarming. But here comes the credit card hack twist.

The “Methodology”

I was curious if it was still possible to get credit card numbers online the way we could in 2007. As any good Engineer, I usually approach things using a properly construed and intelligent plan that needs to be perfectly executed with the utmost precision. If you have tried that method, you might know that it can fail really hard—in which case your careful planning and effort goes to waste.

In IT we have a tendency to over-intellectualize, even when it isn’t exactly warranted. I have seen my friends and colleagues completely break applications using seemingly random inputs. Their success rate was stunning and the effort they put into it was close to zero. That’s when I learned that to open a door, sometimes you just have to knock.

The Credit Card “Hack”

The previous paragraph was a cleverly disguised attempt to make me look like less of an idiot when I show off my “elite hacking skills”. Oops.

First, I tried several range-query-based approaches. Then, I looked at advanced queries and pretty much anything you might come up with in an hour or so. None of them yielded significant results.

And then I had a crazy idea.

What if there was a mismatch between the filtering engine and the actual back-end? What if the message I got from Google (“You are a bad person”) wasn’t from the back-end itself, but instead from a designated filtering engine Google had implemented to censor queries like mine?

It would make a lot of sense from an architectural perspective. And bugs like that are pretty common—we see them in ITSEC all the time, particularly in IDS/IPS solutions, but also in common software. There’s a filtering procedure that processes data and only gives it to the back-end if it thinks the data is acceptable/non-malicious. However, the back-end and the filtering server almost never parse the input in exactly the same way. Thus, a seemingly valid input can go through the filter and wreak havoc on the back-end, effectively bypassing the filter.

You can usually trigger this type of behavior by providing your input in various encodings. For example: instead of using decimal numbers (0-9), how about converting them to hexadecimal or octal or binary? Well, guess what…

Search for this and Google will tell you that you’re a bad person: “4060000000000000..4060999999999999”

Search for this and Google will be happy to oblige: “0xe6c8c69c9c000..0xe6d753e6ecfff”.

The only thing you need to do is to convert credit card numbers from decimal to hexadecimal. That’s it.

The results include…

  • Humongous CSV files filled with potentially sensitive information.

With this simple credit card hack, a major privacy invasion is waiting to happen.

  • Faulty e-commerce log files.

These faulty e-commerce log files make credit card lookup easy.

  • Sensitive information shared on hacker sites (and even Facebook).

How to hack credit cards is as simple as using hexadecimal.

It’s truly scary stuff.

I know this bug won’t inspire any security research, but there you have it. Google made this boo-boo and neglected to even write me back. Well, it happens. I don’t envy the security folks at the big G, though. They must have a lot of stuff to look out for. I’m posting about this credit card number hack here because:

  1. It’s relatively low impact.
  2. Anyone who’s interested and motivated will have figured this out by now.
  3. To quote Haselton, if the big players aren’t taking responsibility and acting on these exploits, then “the right thing to do is to shine a light on the problem and insist that they fix it as soon as possible”.

This trick can be used to look up phone numbers, SSNs, TFNs, and more. And, as Bennett wrote, these numbers are much much harder to change than your Credit Card, for which you can simply call your bank and cancel the card.

Sample Queries

WARNING: Do NOT Google your own credit card number in full!

Look for any CC PAN starting with 4060: 4060000000000000..4060999999999999 ? 0xe6c8c69c9c000..0xe6d753e6ecfff

Some Hungarian phone numbers from the provider ‘Telenor’? No problem: 36200000000..36209999999 ? 0x86db02a00..0x86e48c07f

Look for SSNs. Thankfully, these don’t return many meaningful results: 100000000..999999999 ? 0x5f5e100..0x3b9ac9ff

There are many, many more.

If you find anything very alarming, or if you’re curious about credit card hacking, please leave it in the comments or contact me by email at [email protected] or on Twitter at @synsecblog. Calling the police is usually futile in these cases, but it might be worth a try. The given merchant or the card provider is usually more keen to address the issue.

Where to Go From Here

Well, Google obviously has to fix this, possibly with the help of the big players like Visa and Mastercard. In fact, Haselton provides a number of interesting suggestions in the two articles linked above.

What you need to do, however (and why I’ve written this post), is spread the word. Credit Card fraud is a big industry, and simple awareness can save you from becoming a victim. Further, if you have an e-commerce site or handle any credit card processing, please make sure that you’re secure. PCI-DSS is a good guideline, but it is far from perfect. Plus, it is always a good idea to Google your site with the “site:mysite.com” advanced query, looking for sensitive numbers. There’s a very, very slim chance that you’ll find anything—but if you do, you must act on it immediately.

Also, a bit of friendly advice: You should never give out your credit card information to anyone. My advice would be to use PayPal or a similar service whenever possible. You can check out these links for further information:

And a few general tips: don’t download things you didn’t ask for, don’t open spam emails, and remember that your bank will never ask for your password.

By the way: If you think there’s no one stupid enough to fall for these credit card hacking techniques or give away their credit card information on the internet, have a look at @NeedADebitCard.

Stay safe people!

This article was written by Gergely Kalman, a Toptal Security Specialist.