MOSEB-15: Vulnerabilities at images.google.com

20:47 15.06.2007

Next participant of Month of Search Engines Bugs is Google. It is the most popular search engine in the world.

The vulnerabilities are at Google Image Search (images.google.com, on others domains such as images.google.com.ua the same situation). These are Cross-Site Scripting and Content Spoofing holes which I found 03.06.2007. There were similar security issues at Yahoo in MOSEB-02 and at search.live.com (and others engines) - vulnerabilities in image search are common for search engines.

XSS:

The vulnerability is in imgrefurl parameter:
http://images.google.com/imgres?imgurl=http://194.84.161.5/MetDoc/Gdtran/NTS/Teplovoz/Bezop_dv/L_R/2_1.gif&imgrefurl=http://websecurity.com.ua/webtools/xss_r.html&h=512&w=818&sz=19&tbnid=3IYCwB3Is49zAM:&tbnh=90&tbnw=14

I called this type of XSS attacks Remote XSS/HTML Include (in this case remote HTML including as remote XSS including are possible). First time I found this type of holes 12.11.2006 in site’s search at one site of one security company wich developed their security scanner (which is lame because not found a lot of holes at their own site) ;-) . I didn’t write about holes at that site in my news yet, because I’m very overloaded with hundreds (even thousands) of vulns which I found on sites all over the web. But I’ll certainly do it with time.

Content Spoofing:

Bad guys also can make content spoofing attack with Google Image Search. Because they can spoof not just a page in image preview (imgrefurl parameter), for remote XSS/HTML inclusion as mentioned above, but also imgurl parameter. And because Google save links to images thumbnails in tbnid parameter, so it is possible to find any useful image in Google and use it for attracting users while imgrefurl and imgurl parameters can be spoofed (because they are not checking in connection with tbnid). And these parameters can be arbitrary, so attackers can create special image preview page with custom image, custom previewed html page and custom links (to image and page).

Moral #1: searching for images even in top engines can be dangerous.

Moral #2: pupular search engines need to take care of their and their users security (especially top engines).

P.S.

Also I prepared another hole concerned with Google. So wait for today’s bonus post ;-) .


7 відповідей на “MOSEB-15: Vulnerabilities at images.google.com”

  1. Alex каже:

    This Remote HTML Include just hijacks a frame in a foreign frameset, doesn’t it? Perfect phishing tool. And a funny one, because it’s not a bug, it’s by design. Good catch!

  2. MustLive каже:

    Yes, Alex, Remote HTML Include (RHI) is perfect phishing tool :-) . Using a frame in a frameset of other site (for malicious purposes) is hole by design. But in case of malicious purposes this become a real security hole. It is Abuse of Functionality by WASC classification (for RHI), or it is Abuse of Functionality + XSS (for RXI).

    In case of Remote XSS Include (RXI) it is possible to execute malicious code in browser when user is at another site (so attack is hidden). Two mentioned redirectors are just for an example, that bad guys can redirect visitors. But others attacks are possible, so on the whole it is code execution vulnerability.

  3. Alex каже:

    Malicious code doesn’t have access to sibling documents in the frameset because of Single Origin Policy, nor to cookies. That limits the number of attacks which are possible with such XSS.

  4. MustLive каже:

    Alex, in this case Same Origin Policy (SOP) prevent access to sibling documents (and attacker can’t get cookies). So RXI is less dangerous than other types of XSS, but don’t forget about SOP bypassing methods ;) (in particular using bugs in browser to bypass SOP).

    And there are many others attacks vectors, than cookies stealing. Like XSS for remote controlling, redirecting (as I show in the post) for phishing and others attacks, and especially code execution as I said before. By code execution I mean that bad guys can execute malicious code in user’s browser (while hiding behind other site) - it can be used for malware, spyware, viruses, trojans and exploits execution.

    So number of attacks is limited for RHI/RXI, but still wide. Therefore this type of vulns are dangerous and web developers need to be aware of it.

  5. John каже:

    Since I’m being accused of using this vulnerability to hack a site, let me see if I understand the vulnerabilities as you see them.

    First, by putting in whatever url I want for the imagerefurl, I can make someone believe they are going to images.google.com but simply have the path go to whatever site I want them to go to. This would require the attacked to click on a link, and for me to get them that link somehow. I think this is what you’re referring to as the content spoofing attack, right?

    Second, the XSS attack. I seriously don’t even have a clue how I would have used that to attack a site, but regardless, it is the same thing, right? I construct a link that would be the hack, I then have to get the target to click on the link. I’m not creating a link and clicking on it myself to attack a third site?

    Seriously, I’m not trying to play stupid. I’m being accused of hacking someone’s site using the vulnerability listed on this page and my black hat knowledge is focused in the click fraud world (where I’m the one fighting click fraud.)

  6. MustLive каже:

    Since I’m being accused of using this vulnerability

    John

    Concerning this particular vulnerability at images.google.com, which allowed Cross-Site Scripting and Content Spoofing attacks, then this hole is already fixed by Google. It was done some time ago - I found it this year. But there are way how to “resurrect” this hole and conduct these attacks again :-) (and sometime I’ll write article about this method).

    But there are many other Remote XSS Include (RXI) holes (aka Frame Injection) in Internet, so you can easily find such ones for your testing. Including such major sites as Google and Yahoo, as on babelfish.altavista.com and babelfish.yahoo.com and other sites.

    I think this is what you’re referring to as the content spoofing attack, right?

    Creating a link which must be visited by victim is a way to trigger the attack (which concerns both XSS and Content Spoofing attacks), but it’s not Content Spoofing. If one link to one site leads to another site, it’s Redirector vulnerability (aka URL Redirector Abuse in WASC v.2.0). By content spoofing I mean that many parameters can be spoofed, such as small image (i.e imgurl leads to one site and imgrefurl to another).

  7. MustLive каже:

    Second, the XSS attack. I seriously don’t even have a clue how I would have used that to attack a site, but regardless, it is the same thing, right?

    In case of RXI holes at images.google.com and some other sites (which I wrote about in my news), it’s not possible to use XSS to attack users of that site, i.e. to steal cookies. Because code executes on other site (not target site). It’s only possible to execute JS code (malicious one), e.g. for spreading of malware.

    But there are other RXI holes at other sites, like in case of RXI at webpark.ru, where it’s possible to conduct XSS attacks directly on users of this site (because code executes at this site).

    I’m being accused of hacking someone’s site using the vulnerability listed on this page

    From above-mentioned you can see, that you can’t use this hole to attack somes sites dirrectly with using this hole (i.e. by stealing someone’s cookie and get into his account), which can be made by other RXI holes. But this vulnerability at images.google.com can be used for phishing and malware spreading ;-) .

Leave a Reply

You must be logged in to post a comment.