Slashdot Mirror
Google Fixes Credit Card Security Hole, But Snubs Discoverer
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.
Why are these pages even indexed? Wouldn't it make more sense to just expunge them from the database (perhaps by hostname or even domain name as appropriate) rather than keep them around waiting for someone to figure out a way to trick Google into retrieving them?
I still don't get it. When do you go to jail for this, and when don't you?
Namely- do you go to jail when...
Is it arbitrary? It seems sometimes you get a reward/bounty, sometimes a thank you, sometimes a threat, and other times you get sent to jail...
What does a reasonable/prudent person do if they stumble onto a potential (or actual) security hole in someone else's system? Someone explain please.
Why in the hell is Google indexing credit card numbers to being with? I realize their bots sniff the web but this is information that they should just avoid collecting.
Harrison's Postulate - "For every action there is an equal and opposite criticism"
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.
why are credit card numbers even available to be indexed in the first place?
The Elements of Style. 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!
No, no, you're not thinking; you're just being logical. --Niels Bohr
5 minutes and I made this dork. https://www.google.com/search?q="card+type"+"card+number"+"cvv2"+pastebin&tbs=cdr%3A1%2Ccd_min%3A11%2F1%2F2013%2Ccd_max%3A12%2F12%2F2013
n/t
Sorry, but Google filtering is simply doing everyone a favour by helping mitigate credit card fraud. Users of Google products and services were in no way at risk prior to the filtering change.
Why would they acknowledge this? They don't publically acknowledge people flagging inappropriate images and this falls in the same category.
"I don't know if this qualifies as a bug bounty bug,". If you want the money, don't ask like you're in doubt. You made it too easy to answer it with "no".
Perl Programmer for hire
He should just count himself lucky that he's not being sued and leave it at that.
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
This is Google's search working as intended: finding stuff on the internet. It isn't their fault that sensitive information is publicly disclosed for an undiscriminating indexer to find.
I am becoming gerund, destroyer of verbs.
anyone read it like that?
Discover doesn't get much love
-I'm just sayin'
Google uses automatic systems to try to detect "abusive" queries. When the system is triggered, you get the message "Our systems have detected unusual traffic from your computer network. Please try your request again later.".
Searching for the same random hex string every day for a week that nobody else in the world has searched for would probably make you stand out from the crowd as some kind of bot. (Bots often use google search looking for random keywords to check for updates to their own code, and the bot-owner can then put the software update anywhere on the internet with the right random keywords and it will be found).
When you have triggered the bot-detect code, it will probably get more sensitive ("look mom, I learned to detect a type of malware, and I'm gonna make sure it never gets through again!").
Hence, I have a suspicion that the entire content of this post could have happened without any interaction on the part of Google Engineers. And if thats the case, they really shouldn't get blamed for screwing over a little guy, but instead praise for making such a smart system that it can detect a little guy doing something evil and block him all automatically.
This makes no sense. What bug? You searched for numbers you got the numbers. Sounds like google was working correctly at first and broken, not fixed, as the story went on.
The people who put pages of credit card numbers on the web like this have a problem, but it isnt googles problem, google cant fix it, and it's insane that they are expected to do so.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
"Simple question: Why should Google filter or censor anything? Do we even want that?"
Simple answer. No. Hell no.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
And you mightn't think that something that is obviously not a bug is a bug.
What's stopping you? Last time I heard IMAP was pretty easy to master. Wait, is it because other providers don't offer it for free?
If it was up to me not only would I let those searches trough but also make a nice list of all the fucking idiots who leak private customer data like this. Maybe so the retards running those sites would move on from the "who would guess the link?" security model.
Hey, I'm Gergely who found the hex method. First of all, Google did get back to me after Bennett put this up, I let him know. They said that they deemed it was not a bug, outside the bounty's scope. Someone else outside the security team fixed this though, but it is not eligible for a bounty, which is fair. They probably ignored my email on the security side as it was not relevant while some other googler fixed it in the meantime. Oh well. Pretty much what this boils down to is: I have found the bug in a system that was put in place to prevent these queries from going through. The filter could be bypassed, which got fixed now so it was indeed a bug. Whether the filter should be there is an entirely different question. I'd really like Google to not have any filters like this at all. Censoring is always a slippery slope, and might not be efficient. The current system sort of makes this attack harder, and is relatively harmless, unless you want to search for large number ranges (legitimately). You also say that these should not be put up on the internet, and I agree completely. Mostly these are not leaked by companies (come on, no one is that stupid). 99% of the data found are credit card trading forums, leaked keylogs, pastebins, other stuff malicious people put up. Script kiddies are very stupid, they might be infecting lots of machines with their malware but leave the logs in an indexable directory (I've seen this happen). A person here hacked together a google dork which works somewhat less reliably than the hex method but you can get pretty much the same stuff. I've came to the same result as he did (you can put together this dork in 5 seconds), but found it to be much less realiable than my method. In any case if someone wants to search for cc numbers they will be able to, no matter what google does. Security is very often not making things 100% secure, but raising the bar high enough so that the effort put into breaking in doesn't worth it.