Robert Hansen Loses His Sh*t Over Google Gadgets

Thomas Ptacek | August 22nd, 2007 | Filed Under: Disclosure, New Findings

  1. RSnake discovers that Google gadgets can be coerced into rendering arbitrary Javascript tags, and reports it to Google.

  2. Google responds, in effect, “that’s one of the reasons why they live under gmodules.com”, continuing, “If you do find a way of executing this code from the context of a google.com domain, though, please let us know.”

  3. RSnake decries a “slap in the face”, saying “Google needs to figure out what XSS is used for”. Attackers can set up phishing sites on “Google-branded domains”.

Um, RSnake.

  1. Phishers can create “Google branding” on any site they want. That “Google branding” is just a GIF. Pretty sure Javascript anywhere can put it on the screen.

  2. That same “vulnerability” appears to be present on Blogspot. Presumably, on Typepad, Livejournal, and Wordpress as well.

  3. Last time I saw a Bank of America phish, the logo wasn’t drawn in Windows Paint. I didn’t blame Bank of America.

  4. Likewise, I’m not sure it’s hard for phishers to find or create infected domain names that start with the letter ‘g’.

What, exactly, do you want them to do? I like your stuff and all that, and if it’ll make you happy, I’ll bribe Dave to give you a Pwnie for “best Google hack” over this —- but, am I wrong about this? Or are you?

Viewing 19 Comments

    • ^
    • v
    So, I'm an end user who cares about security. I see a mail that points to:

    http://www.gmodules.com

    and another that points to

    http://89.40.17.232

    Both ask for my Google credentials once I've clicked on them. Now, if I've seen the gmodules.com site before and know it's owned by Google, I may trust that content hosted on their domain isn't going to screw me over as opposed to some other random IP or domain. How as a user can I tell the difference between a Google owned site I should trust to enter my credentials into versus one I should not?

    Let's take it one step further... Let's say someone starts using it to host javascript malware. Doesn't Google have any responsibility to make sure that content that is hosted within their domains doesn't propagate malware?
    • ^
    • v
    About as much responsibility as they have for making sure Blogger blogs don't. And Blogspot also asks for your Google credentials.

    As for your example: why don't your hypothetical "other" attackers get to use domain names? Is "gmodules.com" the only hijackable namespace in the DNS?
    • ^
    • v
    I disagree with RSnake's view on this, but I think you're presenting this unfairly.

    As he sees it, Google is going to lean on anyone who blacklists a Google URL as a phishing page:

    "the answer is they would be far more likely to put their credentials in that site because the anti-phishing lists will never blacklist Google’s domains (per Google’s request). It’s far more difficult to put your username and password on a site that your browser is telling you is a phishing site." - RSnake

    Now, while I don't know of any precedent for thinking this, its not something I'd be shocked at. And if they do start doing this, I'd be fairly pissed off, but I think they still have an opportunity to redeem themselves here.

    Essentially, its the same thing as the redirect issues he's been talking about for a while - users are stupid, and don't understand the web, *shrug*, maybe they are, maybe they aren't, but all the people getting phished point to "they are".
    • ^
    • v
    You didn't state if Blogger allowing arbitrary javascript is good, bad, or "who cares", but I'd say that it's just as bad if not worse then the case RSnake wrote about. It would be a fairly trivial exercise to mimic the login frame they use to steal credentials.

    Google shouldn't place the responsibility of determining which of their domains are trustworthy on the end users.
    • ^
    • v
    So, choose your own adventure:

    (1) Blogger should disallow Javascript entirely, eliminating the entire constellation of Blogger add-ons (stat trackers, tag cloudy things, and what-have-you) to prevent it from being used as a phishing platform.

    (2) Google should solve the halting problem, inventing a technique to determine whether code written in a Turing-complete language is malicious or not.
    • ^
    • v
    Kuza55: does blogspot.com appear in anti-phishing blacklists? Also, what percentage of users even use these blacklist-driven anti-phishing tools? And don't they work by knowing that Bank of America doesn't live at gmodules.com? Why does Google care if their domain is listed as "not Bank of America"? And is there any evidence that Google has leaned on anyone to keep gmodules.com off any legitimate list?
    • ^
    • v
    Thomas:
    I have no clue, I'm just saying that Robert seemed to be more worried about Google leaning on filters.

    "does blogspot.com appear in anti-phishing blacklists?"

    All the phishing site details that I found (google search for site:phishtank.com -inurl:user.php blogspot)on phish tank (except for one) had no vote details, since they were all offline, and so phishtank didn't display any info. That one was voted as not a phish: http://www.phishtank.com/phish_detail.php?phish... even though the screenshot clearly shows it was (It now hosts ads for viagra or something).

    I can't get any data from Google using their Safe Browsing API, since that sends only hashes.

    "And don’t they work by knowing that Bank of America doesn’t live at gmodules.com?"

    They 'work' (though whether they work or not is arguable) by someone entering a URL into a blacklist, the user never knows why its marked as a phishing site, by who, etc.

    "Why does Google care if their domain is listed as “not Bank of America”?"

    As I said above, the user doesn't get told that, they just get told the site is bad, obviously this would cause the user to lose trust in Google (or at least I think that's the assumption)

    "And is there any evidence that Google has leaned on anyone to keep gmodules.com off any legitimate list?"

    Well, it hasn't really been utilised yet afaik, so there's nothing really to lean on.



    Anyway, I'm not the person to ask, ask Robert, he was the one who made those claims, not me, I'm just as curious and sceptical myself.
    • ^
    • v
    Firstly, let me say I'm surprised to be called out like this on this site (of all sites). I wish you had read all the comments before posting this. It would have at least concentrated your post to something I was actually saying/claiming. There's a lot more going on here than meets the eye that your post completely skipped over. This isn't about branding (at least in that sense) it's about consumers getting phished because anti-phishing toolbars stop working when Google gets turned into phishing sites and the fact that Google actively choses not to fix holes in their sites (and yes, this DOES include Blogspot and dozens of other sites, I agree with you on that, in fact in my comments I even said I think the blogspot hole is worse).

    Secondly, yes blogspot is very likely whitelisted (I can't tell for sure since I don't work on anti-phishing technology anymore, but from what I recall it probably is). Any Google property that they want to protect is inherently whitelisted, even if it isn't currently whitelisted if someone tried to blacklist them they'd remove the blacklist entry it or whitelist the domain. No one wants Google's lawyers after them.

    I'm not telling Google what to do with any domains, I'm simply pointing out that what they are allowing is a whole host of malicious activity that already has been exploited. I'm only saying if they are a phishing site they should allow the anti-phishing technology to work as it should since they are a phishing site. If they don't want to do that to save their own branding, fine, but fix the hole. Read the post and the comments for more details.

    To your last question, the whitelists are stupid. They don't say "brand bankofamerica lives at bofa.com" they just say "bofa.com" so no, although that sounds like an interesting idea, it would be very hard to implement because the whitelists have no idea who should own where you are (that's especially true on marketing sites that are still owned by the banks). It would be a nightmare to code that even if you leaned on SSL certs since none of those marketing sites, or gmodules.com etc... use SSL. And more importantly it would really cause performance issues on the browsers.

    You probably wouldn't be asking these questions if you were familiar with how anti-phishing technologies worked but trust me, this is a very real problem that Google has contributed to for years now.

    Lastly, I'm sorry you wrote this post in this way without fully reading the post and comments. I neither lost my sh*t, nor claimed that people couldn't put phishing kits on other domains. I'm simply tired of how Google treats this issue, and security researchers. This is a battle I've been involved in for over three years and there's still minimal headway.

    Anyway, I did a more thorough writeup on Darkreading that might help explain why this is a problem: http://www.darkreading.com/blog.asp?blog_sectio...

    I'm not looking for awards or fame or fortune in disclosing this, I just want Google to fix their stuff so that consumers can protect themselves with the technologies available to them. I hope you of all people can understand this.

    @kuza55 - There is precedence for them asking to be removed from blacklists. They've done it a number of times that I am personally aware of - even though they were being used in phishing scams at the time. It's not public record, but I used to work on said anti-phishing technology and had to deal with their reports, which is why I know about it.
    • ^
    • v
    I read your comments, RSnake. You claim that the embedded Javascript in Blogspot templates is an even bigger vulnerability than the Google Gadgets "problem". Come on. You're defending an untenable position. Javascript isn't an accidental feature of Blogger; it's a core feature.

    I'm not cowed by appeals to your authority about "secret anti-phishing technology". We both have NDAs. So I'll respond by asking you the same question your commenters asked, repeatedly, and didn't get an answer to:

    What, exactly, do you think Google should do here to mitigate the problem? The choices you seem to be offering them are to (1) eliminate embedded Javascript in widgets, thus neutering the platform, or (2) solving the halting problem. I find the answer "they should at least admit it's a problem" hollow. A problem with what? The Internet? Human nature? Google is so important a brand that they should sacrifice active content to avoid even the possibility of someone being scammed?
    • ^
    • v
    (With all due respect, Robert).
    • ^
    • v
    I never said the technology was secret - in fact, I think I just told you and everyone on my blog how it works. Of course I can't speak to the finer points of it, but the basics (and indeed one of the most important aspects of the anti-phishing technology) should be pretty clear and easy enough to reverse engineer. If you whitelist a domain (EG: blogger.com) that neuters the anti-phishing filters for that domain - pretty simple problem.

    I understand JS is a feature of blogspot and indeed of gmodules, but it's a feature that can hurt users. It was their choice to build the feature - it may suck to be a consumer on their sites taking your chances, but we can't put the genie back in the bottle (well we could but as you pointed out there are negatives to doing that). But, why would I want to visit a site like that? More importantly why should they have control over anti-phishing technology in my browser that lies about the nature of the site I'm on? The site is not safe by definition since it's under the control of whomever injected JS into it.

    I hope you don't think I'm trying to evade your or anyone else's question here. I didn't say this is an easy problem to fix - far from it. There are many things they could do. They could fix the problem, by removing JS, but as you accurately pointed out that would neuter the usefulness of many of their tools. They could limit the JS to known whitelists of verified JS scripts that they host. On gmodules, they could simply link to the scripts off host, since there really is no advantage to having them on their own domain other than to keep people on their own domain. They could force content restrictions into the browsers (they are as close to owning Firefox as it gets without actually owning them). They could iframe everything with the security=restricted tag for users who use IE to limit it to non JS styles and forms. There's probably a few dozen other options that I haven't posted here, that are either short term or long term solutions. The point is, they have lots of options but they haven't admitted that it's a problem. Which leads me to your last set of questions - about the "problem".

    It's a problem for consumers who use Google and who have no way to identify phishing sites other than the technologies in place in the browser. Google removes the most critical security components in a consumer's arsenal to protect themselves from this very threat. The reason why Blogspot is worse comes down to the fact that consumers are used to typing in their passwords on blogspot.com, and less so on gmodules.com. I wasn't implying anything else by those comments.

    So to summarize, I believe we are in agreement that it is a hard problem. We are also in agreement that JavaScript is an intended feature. I _think_ we are in agreement that JS can be used to do bad stuff. The only thing I think you may still disagree with me on is that Google should do "something" about it. Or more accurately that there is nothing they can reasonably do about it without sacrificing too much. Am I correct?
    • ^
    • v
    We don't agree that it's a problem. As you say, the Blogspot incarnation of attacker-controlled-Javascript-on-Google-SOA is "worse" than the gmodules incarnation. You offer no tenable solution to that problem, because there is no tenable solution. Stage a worldwide binding ballot: Google "whitelists" "approved" Javascript, or users suck it up and deal with malicious blogspot blogs. Malicious blogs will win in a landslide. Users would be furious if Google revoked Javascript from Blogspot templates, and not because they are dumb.

    Propose a security technology that relies on Google not allowing user-controlled Javascript, even if properly sandboxed in different domains. That technology is broken. Dead on arrival. Move on.
    • ^
    • v
    (Again: I'm being blunt, but don't intend disrespect).
    • ^
    • v
    Ah, I now see what you're getting at. But I'm not sure I agree with the sentiment that it's not a problem because users want it over the alternative. I agree they do want it. As they always do. Consumers love that stuff. They love it until their identities are stolen. Then they love it a lot less.

    Maybe we haven't reached a critical mass where the ballet would be swung anywhere close to landing in the secure court. Maybe I deal too often with the people who ARE affected by this kind of thing, rather than happily posting my docs all over MySpace looking to hook up. Maybe I'm being overly cynical of Google's situation. Or maybe we're both right. It's a problem because it can be abused, but it's not a problem because consumers haven't demanded that Google fix it - or at least not enough consumers.

    However, you asked me to propose a different solution that didn't require sandboxing on different domains, and I did - whitelisted JS modules. They would have to be inspected and signed to be non-malicious and hosted on the gmodules.com domain. In this way you could be certain it was not malicious and un-tampered with. That solution is a bit of a non-starter because it would require someone build something to inspect the JS and/or manual assessment, which leaves all sorts of other holes, but it's quite a bit better than where they are currently, which is zero mitigation. Someone also suggested blacklisting when they see someone is doing something malicious. They tried that with their redirects, and that was a flop, but it's still better than nothing.

    I'd be happy with anything at this point, because right now there's nothing. As it stands consumers are better off on IP addresses, because at least the anti-phishing technology is free to do its job there.
    • ^
    • v
    You propose that Google launch an unprecedented campaign to individually audit Google web widgets (and, as a side effect, assume responsibility for the integrity of those widgets, and endure the 15,000 "XSS" reports they will get in them), and prevent users from deploying widgets until those audits complete.

    And the reason Google is obliged to build what will, in effect, be the world's first standing Code Police Force is to enable "anti-phishing technology" that can be fooled into believing gmodules.com is the Google front page?

    If your tech works only in the presence of the Code Police, or fails to work when confronted with Javascript, your tech is broken. You're a talented guy, Rob. This is a dead end. Move on.
    • ^
    • v
    I said that was an option in the larger list of options above. I suggested other options above as well and I'm sure there are literally dozens more that I haven't documented. I also didn't say any of this solved the problem. I said something was better than nothing, which is what they have now in terms of mitigating the risk of malicious JS. Clearly some of the options are better than others for various reasons, you will get no arguments from me there.

    I guess my only point here, which has somehow got lost in a huge tangle of side tangents here is this:

    1) JavaScript can do bad things.
    2) Google allows other people's JavaScript on their domain(s).
    3) Google does not indemnify anti-phishing technologies to blacklist them.
    4) Some users rely on the anti-phishing technology to protect themselves.
    5) As a result some amount of users can/will and have been phished by this issue.

    You do have a very good point about the anti-phishing technology not being perfect or even very good in the face of JS though. That's a very big known issue actually. It's not a very easy problem to solve, but it absolutely could get a lot better (and probably will need to be if/when we start seeing a rise in JS-only phishing kits). It's another very hard problem for probably another huge post.

    But one last point - people can manually submit reports to almost all the anti-phishing lists which lessens the responsibility of the automatic detection. People can manually add phishing URLs to the lists, but with the whitelists in place, even those manually entered URLs won't alert users as whitelists always take precedence over blacklists.
    • ^
    • v
    Ok, I'm glad we're converging on an understanding here, RSnake. But let's return to the context of your original post. You said you reported a "vulnerability" to Google, and that the response could be read as a failure for Google to responsibly handle the disclosure.

    Here's where I'm not letting you off the hook:

    You didn't find a vulnerability in Google. You found a policy dispute between anti-phishing vendors and Google. Normal users, including security-savvy users, would be surprised and dismayed to find that Google was attempting to audit and filter their Javascript code; what would be the point? Nobody has the resources to meaningfully tackle that problem.

    Do you have further evidence to document Google's irresponsible incident handling practices? Or will you back off your claim that Google gave you a bad-faith response?
    • ^
    • v
    Actually I think I said "hole" not "vulnerability", neither of which probably accurately describes what I disclosed. But, I'll get to that in a second.

    I think what I found was that there is yet another place on Google's array of domains that allows potentially malicious JS that could potentially phish users. Nothing more. The policy dispute has been well known between myself and Google for years. That's nothing new to me, so that is definitely not what I found in my post, although it might seem new to people who are just now hearing about it.

    Honestly, if I had known what a mess this would have created, and how the community would have reacted on blogs such as this I never would have said a thing. In particular the "Loses His Sh*t" part of this post really sucks, as it's accrediting an emotional response to my post where I actually had almost the opposite reaction. It's your blog of course, and I can't stop you either way, but it doesn't accurately reflect how I acted or felt.

    To accurately describe my emotional state in the moments that I posted this would be "defeated". You can only have so many bad interactions with one company before they completely ruin your day. Then it got worse - consumers aren't more safe because I told the world. Google isn't going to fix it, even if they could, and many security researchers think it's not even worth discussing. I disagree and think it's an important discussion, although I wish someone else had disclosed it instead of me. Anyway....

    While I do agree, that this isn't a vulnerability per se - I know it can be used to phish users. Let's put it this way. If I were a product manager sitting in the Googleplex and someone were to ask me, "Do you think it's bad that people can phish usernames and passwords off of gmodules or blogspot and that we force anti-phishing lists to whitelist those sites?" I'd honestly have to answer yes. While not a vulnerability, it's a hole. It's a problem. However you want to define it, it's bad. That's what I'm disclosing - the bad. I may not know the right words to articulate that, but I know it's bad, and I know it's been used before, and I would bet it gets used again if unchecked.

    So yes, their response was at least in part bad faith. They know it's bad. And in fact the first two emails I received after the form letter included thank yous, because they saw it the same way I did initially - something looks and feels wrong here. It may be expected behavior in retrospect, but that doesn't discount the bad that can and has happened with similar issues.

    In regards to irresponsible incident handling, you only have to look as far as Google's own CTO, Douglas Merrill (from the Wall Street Journal): 'Regarding security-flaw disclosure, Mr. Merrill says Google hasn’t provided much because consumers -- its primary users to date -- often aren’t tech-savvy enough to understand security bulletins, and find them "distracting and confusing." Also, because fixes Google makes on its servers are invisible to the user, notification hasn’t seemed necessary, he says.'

    That quote was in regards to their web server vulns, however if you just want a few other examples look at two other issues I disclosed regarding the Google desktop MITM and the rebinding attacks. They simply said they were looking into it in both cases. They never came back and told the public that it was or was not a vulnerability. So yes, I have plenty of evidence. It's been almost nothing but bad experiences when dealing with Google security flaws (to their credit and to be fair they did fix a few holes in under a day). Incidentally, the problems in policy probably doesn't have much to do with the security guys working there, who are all nice enough people, one of whom I've known for more than a decade. It's just their policies that I'm not in love with.

    I don't claim to have the right answer to solve the issue I posted about on my blog, but I do know that it is bad to get phished, and that makes them at least partially responsible for that badness since it's on their domains.
    • ^
    • v
    I'll leave you with the last word. Thanks for the response!

Trackbacks

close Reblog this comment
Powered by Disqus · Learn more
blog comments powered by Disqus