Google Fixes Credit Card Security Hole, But Snubs Discoverer 127
Back in 2007, I wrote that it was possible to find credit card numbers on Google by searching for the first 8 digits of your credit card number with a space in the middle, e.g. "1234 5678". Some users pointed out in the comments that it was even easier to find card numbers by searching for a number range such as
4147000000000000..4147999999999999
At some point after that discovery was posted, Google altered their search filters so that using number ranges to search for credit cards, was no longer allowed. If you search for that range, you get a denial page which reads
Our systems have detected unusual traffic from your computer network. Please try your request again later.
According to security researcher Gergely Kalman, he had read my 2007 article and thought about the issue occasionally for a few years, then in December 2012 discovered a loophole in Google's search filter: He could search for number ranges matching credit cards by searching using hexadecimal numbers. So that instead of searching for
4060000000000000..4060999999999999
he could search for the same number range in hexadecimal:
0xe6c8c69c9c000..0xe6d753e6ecfff
and Google would allow the search, and return a list of matching pages (most of which contained credit card numbers).
Gergely sent an email to security@google.com on December 28, 2012 (which he later showed to me), describing the vulnerability in detail. After describing the simple trick, his email stated: "I don't know if this qualifies as a bug bounty bug, but I think it's certainly not in your interest to let these queries through. Using this method one can bypass all your numerical query filters, filters for SSN, TFN, credit cards, maybe DoS prevention and others I can not think of at the moment."
Gergely sent them a follow-up email on August 23, 2013. In both cases he said he received no response except for an auto-reply.
Then on November 8, 2013, I wrote another article bringing up the fact that the original "1234 5678" trick still made it easy to find credit card numbers through Google, and generally wondering if that particular issue was ever going to be fixed (while remaining unaware of Gergely's discovery).
Gergely saw the article, and subsequently posted his discovery publicly on November 12, along with disclosing the fact that he had written to Google and never received a response:
"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."
Gergely emailed me about my article and sent me a link to his blog post. With Gergely's permission, I posted a message in Google's product forums on November 14th, describing the problem and trying to bring it to the attention of a Google employee:
"This is a security issue that I'm trying to bring to the attention of a Google employee. I'm not sure if it fits under 'malware,' but I couldn't find a better place to post it. The original discoverer already emailed security@google.com twice and says he received no response.
[...]
The original discoverer posted about this trick here:
http://www.toptal.com/web/with-a-filter-bypass-credit-card-numbers-are-still-still-google-able
Can we get confirmation from someone at Google that they're aware of this issue, regardless of what they decide to do about it?
Thanks!"
At the same time, I became curious if Google would fix the bug any time in the next couple of days, so I set up a daily reminder on my computer to click the hex-search-link every morning and see if it was blocked. So I checked every morning from November 15th until about November 20th, and then didn't bother for a few days after that. When I checked again on November 26th, the bug had been fixed, and searching on Google for a hexadecimal-number range matching credit card numbers, now gives the denial message:
Our systems have detected unusual traffic from your computer network. Please try your request again later.
Since Google didn't fix the bug for 11 months after first being notified by Gergely, but then fixed it within 2 weeks after Gergely's blog post and my forum question, it seems pretty certain that the blog post or the forum question was what triggered the fixing of the bug. But, then, why not acknowledge either with a response, or a bounty award for Gergely? According to the chart on Google's Application Security bounty program page, it should probably qualify for a $500 reward in the category "XSRF, XSSI and other common web flaws" under "Normal Google applications."
If Google had ignored the discovery completely -- or if they had replied and said that it was too low of a security priority to fix -- that probably would have settled the issue, whether we agreed or not. This is, after all, not exactly a sky-is-falling security hole -- in any case not as long as the "1234 5678" security hole allows people to find credit cards almost as easily.
But once Google decided to fix the bug, there would seem to be no excuse for snubbing the person who discovered it. Even though the fix was probably simple at the code level, pushing a code change through to the almighty Google search engine, is presumably not cheap. If they're going to incur the costs of fixing the bug, what could be the reason for not crediting the discoverer and paying the bounty, which would also establish a good future relationship with a smart bug hunter? (Presumably that's one of the reasons the program exists.)
Maybe both of the original emails to security@google.com got lost, and maybe that has to do with the high volume of emails that the email address receives. I have no idea how those emails are processed internally at Google, but I assume it's likely that there is a pool of security experts to review the incoming emails, and each incoming mail is randomly assigned to one of those experts. If Google wants to reduce the chance of a legitimate bug slipping through the cracks without spending any extra money, my suggestion would be:
Instead of having each email be reviewed by one person chosen at random from a pool of highly paid security experts, have each email be reviewed by five people chosen from a low-paid pool of smart but inexperienced employees. The group of five would each independently vote "Yes" or "No" on whether the security issue needed to be bumped up, with a majority making the decision.
This recommendation is based on two principles. First, if you do a majority vote from a group of five, this reduces the chance of a legitimate issue being mis-categorized by a fluke. If a single "expert" categorizes an issue report correctly 90% of the time, and an intern categorizes an issue correctly 80% of the time, then taking a majority vote from a group of five interns will yield the right answer more often than a single expert. (I'm hand-waving over a few details -- I'm assuming that the probability of the different interns categorizing the issue correctly, are independent, and I'm not weighing the relative cost of missing a legitimate issue versus raising a false alarm -- but the general principle still applies.)
Second, while it may take an experienced security researcher to understand the deeper implications of a bug and the cost of fixing it, in my experience most smart people can quickly see what constitutes a legitimate security hole and what is merely a decoy, even without a lot of coding experience. So it would be ideal work for interns or new employees who want to learn more about the kinds of security reports that come in.
That suggested fix is just based on my assumption that incoming emails to security@google.com are each reviewed by a single person, so that one oversight can cause an email to slip through the cracks.
On the other hand, when someone at Google did read the blog post or the forum question and discover the bug, I have no idea what sequence of events that kicked off, which led to the security hole being plugged without acknowledging the discoverer. That's another process that should be fixed.
Google, of course, deserves credit for fixing the bug, and generally for taking on the issue of filtering credit card searches in the first place. Blocking these searches, after all, mainly prevents harm to others by averting identity theft, without really benefitting Google directly; presumably they filter these searches due to some combination of (1) wanting to be a good corporate netizen and (2) not wanting their search tool abused by script kiddiez searching for credit cards (a class of users who would be singularly unlikely to click on the ads). But since they did fix the bug, they should pay the discoverer, or at least give Gergely a shout-out. If they ever decide to implement my intern-majority-rules idea for emails to security@google.com, a shout-out for that would be fine too.
This accomplishes nothing (Score:5, Insightful)
The problem is not that google accidentally lets you search for credit card numbers. Not at all.
The problem is that credit card numbers is published on the web so that search engines and anybody else can find them. Google can filter queries perfectly, but the numbers are still out there on some webpage - for some reason. If google won't let me search for numbers, then I can switch to another search engine. Google is far from the only one - it is merely the most popular one. (Google "search engines" to find some others.) Chances are the others are not so restrictive.
And of course I don't really need a search engine - I can make my own web crawler. A search engine like google is a big thing, but a web crawler that collect credit card numbers only is much simpler - it is something you can run from home.
So google: Please don't filter out card numbers from your searches. The fault does not lie with google, but with those who put credit card numbers on the web for all to see. If we can find them, we can warn them or even sue them. Let the searches go through, so they can get busted. Or so those numbers will get abused. That way, people might learn not to publish them.
Also, number searches are useful. I often search for product numbers, which sometimes have the same length as credit card numbers. This is "normal use", not hacking at all.
The bigger issue is (Score:4, Insightful)
Bennett, Please Read... (Score:5, Insightful)
The Elements of Style [amazon.com]. Your ponderous prose is an affront to literacy. Every time I see that you've posted something I wonder if you've finally realized that quantity does not equal quality. You may get paid by the word elsewhere, but not here.
I might even bother to read what you write if you would just, for the sake of all that is good in this world, be concise. ARRRGGGHHH!
Re:Great so another bug fixed but... (Score:5, Insightful)
The better question is this:
Why is this information even stored in plain text and publicly accessible where it can be indexed in the first place?
Re:Great so another bug fixed but... (Score:5, Insightful)
plenty of good reasons to index long strings of numbers. I use google for part numbers, serial numbers, etc.
Re:Bennett, Please Read... (Score:5, Insightful)
Most of them. This article boils down to:
"Google was returning credit card numbers in their search results. I wasn't happy about that, and wrote a blog entry about it. Google then changed their search results a bit to reduce these kinds of search results. A security researcher wrote to me to say that he found there were still ways to get card numbers in the search results. He wrote to Google to tell them about this and got no meaningful response. Fast forward several months - I posted in a Google forum about this issue, quoting the researcher, and a couple of weeks later Google fixed this issue. I'm not happy that neither he nor I got any credit for it or received a reward from the bug bounty program (even though this wasn't a bug and was a personal issue with the search results that were returned from a valid query), because I'm quite sure I'm the one to which they were responding when they "fixed" the query results. Here are some further ideas I have for improving the way these results are computed, and you should pay attention because I'm Bennett Haselton."
So what does everyone think?