Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Security Google The Almighty Buck IT

Google Fixes Credit Card Security Hole, But Snubs Discoverer 127

Posted by timothy
from the and-that's-the-thanks-I-get dept.
Frequent contributor Bennett Haselton writes: "Google has fixed a vulnerability, first discovered by researcher Gergely Kalman, which let users search for credit card numbers by using hex number ranges. However, Google should have acknowledged or at least responded to the original bug finder (and possibly even paid him a bounty for it), and should have been more transparent about the process in general." Read on for the rest of the story.

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 discussion has been archived. No new comments can be posted.

Google Fixes Credit Card Security Hole, But Snubs Discoverer

Comments Filter:
  • by Dachannien (617929) on Thursday December 12, 2013 @04:46PM (#45674825)

    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?

    • by tibit (1762298) on Thursday December 12, 2013 @05:55PM (#45675427)

      Google. They are a search engine. They are supposed to index stuff, not to censor it. It's the problem of the fucktards whose site security is so bad that a search engine can get to customer data like such (or the fucktards who leak such things on purpose). I really don't see why Google cares abbot it, and why do other retards classify this as a "security hole". It's not Google who is leaking the data, so why is it upon them to fix it? If I were running a search engine, I'd be fighting requests for such "improvements" tooth and nail. People need to realize how insecure some sites/servers are, and who is to better expose it than a large search engine. Sigh.

  • by Anonymous Coward on Thursday December 12, 2013 @04:46PM (#45674829)

    . 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."

    I still don't get it. When do you go to jail for this [wired.com], and when don't you?

    Namely- do you go to jail when...

    • You become aware of a security bug?
    • If you test a security bug to make sure it exists?
    • You report the bug to the owner?
    • You report the bug to the media?
    • You blog about your discovery of the bug?

    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.

    • by Virtucon (127420) on Thursday December 12, 2013 @05:01PM (#45674953)

      You get all of the above depending on what company/organization you're dealing with. If you're dealing with an entity that has an open attitude about these things, you'll get a reward or a pat on the back. If you're dealing with a private company that isn't open and has a monopoly to protect you'll get usually a CFAA indictment for accessing their system in an inappropriate way...

  • 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.

    • by ArcadeNut (85398) on Thursday December 12, 2013 @05:13PM (#45675061) Homepage

      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?

      • while a good question, I don't think it is a better one.

        Clearly it shouldn't be. EVERYONE here agrees on that. The point is that due to Google's technical expertise and business product, they are in a position to significantly reduce the ease at which people can come accross these "powerful" numbers.

    • by rubycodez (864176) on Thursday December 12, 2013 @05:17PM (#45675095)

      plenty of good reasons to index long strings of numbers. I use google for part numbers, serial numbers, etc.

      • Very true, although I would think a rather small minority would be 16 digits long and pass the Luhn test.
        • by swillden (191260)

          Very true, although I would think a rather small minority would be 16 digits long and pass the Luhn test.

          10% of random 15 and 16-digit numbers pass the Luhn test.

          • Yes, and I would still consider 10% a "rather small minority". It still means that 90% of all 15/16 digit numbers would be inappropriately filtered. One could restrict the result set even more by only looking for leading digits in combination with digit counts that correspond to known card issues and bring that percentage down quite a bit more.

            The point was that given a random 12-16 digit number, it's not very likely that it will be a valid credit card number (even if the check digit passes), and even
            • by rubycodez (864176)

              no, making 10% of a catalog with 15 to 19 digit numbers is not acceptable solution. the core problem is stupidity of using a credit card number at all for financial transactions, already a long solved crytographic problem. the credit card companies need to stop using a stupid system, just as government needs to stop using social security numbers. fix what's broken, don't put bandaids on a bridge.

              • by rubycodez (864176)

                meant to say making 10% of catalog with 15 to 19 digit numbers unavailable is not acceptable solution

    • by tibit (1762298) on Thursday December 12, 2013 @05:58PM (#45675451)

      Why should they avoid collecting fucking numbers? Why is it their problem? What other information they "should just avoid collecting". It's a very slippery slope I'd them rather not take. If it takes Google to get the U.S. credit card industry to wake up and realize that people need to use secure chip cards for physically-present transactions and secure pin generators for card-not present ones, like is done in a lot of more bank-developed places on Earth, then so let it be. The fallout from having those numbers visible for all to see can't be but beneficial for the consumer in the long term.

      • by Virtucon (127420)

        Look, numbers are fine but when they're mining it from sites that publish and peddle lists of Card Numbers and CVV2 info, that's another thing. Those sites have no other business than to promote crime. It's the same thing with Child Porn and other things that have been banned from search engines. Nobody likes censorship but there are things that should be filtered based upon good business practice and being a responsible corporate citizen. Google is smart enough to build filters to know that what they're

    • 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.

  • by Anonymous Coward on Thursday December 12, 2013 @04:49PM (#45674859)

    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.

    • by swillden (191260)

      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.

      I think Google did take that approach for several years, and it was found not to work. Specifically, the pages with all the card numbers didn't get taken down, and Google search made it trivial for people to find lots of potentially-valid CCNs.

      • Any turing complete programming language can generate lots of potentially valid credit card numbers. All of them, in fact.
  • by purpledinoz (573045) on Thursday December 12, 2013 @04:58PM (#45674929)
    why are credit card numbers even available to be indexed in the first place?
    • by rubycodez (864176)

      wrong. the bigger issue is why we are so silly as to use short 15 or 16 digit numbers for making financial transactions. it's the same as the stupidity shown with using social security numbers.

      • wrong. the bigger issue is why we are so silly as to use short 15 or 16 digit numbers for making financial transactions. it's the same as the stupidity shown with using social security numbers.

        If your CC number is on a web-facing interface in plaintext, I doubt it matters much whether it's 16 digits or 256.

        • by rubycodez (864176)

          you're not getting it. there would be no single unique number, only lasting thing would only be encrypted message summarizing single transaction. you could post it on the web, wouldn't do a thief any good. the transaction would be done by secure cryptographic means, we've mastered that already, solved problem.

          • I see - less a dedicated number, and more like an OTP.

            Seems like a good idea, but I can't see how it would ever work, considering that such a system would require a lot of big players to learn how to work together for the common good.

      • by swillden (191260)

        wrong. the bigger issue is why we are so silly as to use short 15 or 16 digit numbers for making financial transactions.

        It's not the length that's the problem, it's the fact that we use the same value as both identifier and authenticator.

        • I thought the identifier was the 15 or 16 digit number on the front of the card, and the authenticator was the three-to-four digit number on the back of the card (except in cases where a keypad is available, and then the identifier is the 15 or 16 digit number encoded on the mag strip and the authenticator is your 4 digit pin).

          • by swillden (191260)

            I thought the identifier was the 15 or 16 digit number on the front of the card, and the authenticator was the three-to-four digit number on the back of the card (except in cases where a keypad is available, and then the identifier is the 15 or 16 digit number encoded on the mag strip and the authenticator is your 4 digit pin).

            Nah, there are ways you can use the card number without the CVV1 or CVV2. And it's not like a three-digit authenticator adds very much security (more length there actually would help).

          • by rubycodez (864176)

            still completely insecure. transactions need to be done with 3-way private key cryptography system. it's a solved problem

    • Various black-hat websites have stolen credit card numbers available for sale or (I guess) free to anybody. It might make sense for credit card companies to trawl for these things and see if any of their user's cards are compromised, but they don't seem too interested in that. They'd rather wait until I make a purchase for a big item, decline the transaction, and make me call them when my new NAS fails to ship. I'm lucky if I get an email notification about it in a timely fashion.
  • by NotSanguine (1917456) on Thursday December 12, 2013 @05:02PM (#45674959) Journal

    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!

    • What's a paragraph you didn't think was necessary?
      • by vux984 (928602)

        fwiw, i think the biggest issue is virtually every other article on slashdot is a summary with a link to the article(s) ...(well on a good day in an idealized imagining of how Slashdot works - we're lucky if the summary makes sense, summarizes the acutal article, and provides links to anything remotely agreeing with the summary... but I digress), except your submissions. Which seem to always be a full mufti-page article in place of the usual "summary".

        Its off putting; both because it deviates from the norm,

      • I'll bite. FTFA:

        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."

        • I'll bite. FTFA: 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. There's really no reason for the last two sentences to be in a separate paragraph, and this is something that is common in the way you write. From The Elements of Style: "In general, remember that paragraphing calls for a good eye as well as a logical mind. Enormous blocks of print look formidable to readers, who are often reluctant to tackle them. Therefore, breaking long paragraphs in two, even if it is not necessary to do so for sense, meaning, or logical development, is often a visual help. But remember, too, that firing off many short paragraphs in quick succession can be distracting. Paragraph breaks used only for show read like the writing of commerce or of display advertising. Moderation and a sense of order should be the main considerations in paragraphing." (emphasis mine)

          Thanks for picking that up NormalVisual. You're absolutely correct. I was just going to ignore Mr. Haselton's ridiculous question about paragraphs because it's not really the paragraphing that annoys me.

          What really annoys me is the verbosity and lack of semantic content in his prose. I suggested "The Elements of Style" because he clearly isn't going to go away and thought he might learn something about writing clearly and concisely.

          Mr. Haselton's posts (IMHO) appear to be written for a general audience,

          • Do you have an example of what you're referring to?
            • Do you have an example of what you're referring to?

              Yes. All of your posts.

        • But this "rule" doesn't seem to have any bearing on clear communication. I'm all in favor of rules for writing that improve communication, but what's the point of following a rule that exists just for its own sake?
          • I disagree. A paragraph is supposed to convey a single train of thought. When it's broken up into multiple paragraphs, it makes it more difficult to parse since one is expecting that the expressed thought is complete and is expecting something new, but has to rewind a bit. At least that's my opinion, and that of many others as well. It's just bad style.
      • by NormalVisual (565491) on Friday December 13, 2013 @01:08AM (#45677915)
        What's a paragraph you didn't think was necessary?

        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?
        • You're hired.

          Now, who are you going to replace? Samzenpus, Timothy, Soulskill, Commander Taco?

        • This just states the conclusions, without the arguments in support of each conclusion. Of course you can make anything shorter if you just list the conclusion and not the intermediate steps.

          For example, saying it's "not a bug" has no supporting argument. I said in the article that since Google decided to block the original number-range searches, that means they had implicitly declared that one of their design goals was to block searches that match lots of credit card numbers. If that's a design goal, t
          • This just states the conclusions, without the arguments in support of each conclusion.

            You're totally missing the point. Slashdot "articles" are supposed to be a SHORT SUMMARY of a given newsworthy item, so the detailed arguments that lead to your conclusions are neither necessary nor appropriate there. You can always link to your own blog (or a Slashdot journal) where one can examine your analysis in further detail if readers are interested enough. Slashdot is a tech news aggregation site, not your o
            • Oh OK, so I misunderstood -- you're not primarily saying that the style is too wordy for the argument I'm making, you just think the conclusion should be posted on Slashdot and the supporting argument should be linked somewhere else, thus making the Slashdot-hosted portion much shorter.

              Well, at that point you're essentially saying I should set up a second domain just for hosting the supporting-argument portion, so that the intro text can link to that off-site domain, and then the content would be exactly
  • by ilikenwf (1139495) on Thursday December 12, 2013 @05:06PM (#45675009)
    5 minutes and I made this dork. https://www.google.com/search?q= [google.com]"card+type"+"card+number"+"cvv2"+pastebin&tbs=cdr%3A1%2Ccd_min%3A11%2F1%2F2013%2Ccd_max%3A12%2F12%2F2013
    • by ilikenwf (1139495)
      That is to say, CC#'s are out there, but you'd have to be a complete retard to use them for anything. Everyone is being watched, unless you're behind 7 proxies or VPN's or something :)
  • 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".
  • He should just count himself lucky that he's not being sued and leave it at that.

  • 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.

  • by Wierdy1024 (902573) on Thursday December 12, 2013 @07:03PM (#45676007)

    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.

    • 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.".

      ...and the fun really starts when that system misfires.

  • And you mightn't think that something that is obviously not a bug is a bug.

  • 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

Some people carve careers, others chisel them.

Working...