Comments on: Google Search API Worms http://www.gnucitizen.org/blog/google-search-api-worms/ Information Security Think Tank Sat, 30 Aug 2008 10:13:26 +0000 http://wordpress.org/?v=2.6.1 By: TruePath http://www.gnucitizen.org/blog/google-search-api-worms/#comment-116189 TruePath Tue, 11 Mar 2008 19:30:46 +0000 http://www.gnucitizen.org/blog/google-search-api-worms#comment-116189 Ahh, I stand corrected on the key point. Thanks for letting me know. Ahh, I stand corrected on the key point. Thanks for letting me know.

]]> By: pdp http://www.gnucitizen.org/blog/google-search-api-worms/#comment-116085 pdp Sun, 09 Mar 2008 08:41:54 +0000 http://www.gnucitizen.org/blog/google-search-api-worms#comment-116085 TruePath, you have some valid point here although I believe that this is just the beginning of the exploration. The more versatile AJAX technology become the more often it will be used for malicious activities. P.S. you can use Google's own internal key. They use that key for all their examples. That one works everywhere on every domain. TruePath, you have some valid point here although I believe that this is just the beginning of the exploration. The more versatile AJAX technology become the more often it will be used for malicious activities.

P.S. you can use Google’s own internal key. They use that key for all their examples. That one works everywhere on every domain.

]]> By: TruePath http://www.gnucitizen.org/blog/google-search-api-worms/#comment-116079 TruePath Sun, 09 Mar 2008 01:42:05 +0000 http://www.gnucitizen.org/blog/google-search-api-worms#comment-116079 So I have to admit still being confused. Are you advocating that client side scripting languages be denied *ANY* means of retrieving search data? After all the way you stated your example it doesn't matter in the slightest how the JS gets the information so the only way to protect against this would be to deny ANY kind of google query from JS (or require user input or something). I agree the ability to get search results makes JS worms slightly more dangerous but only slightly. After all the author of the worm could merely release 50-100 worms into the wild each of them containing their own subset of compressed search queries (does search beforehand). Additionally I would thin the API key would prevent this sort of attack from going very far. If you are trying to run this as a worm you will need a new API key for every domain you infect no? (And if somehow you can use the same one won't google notice and shut you down?). I suppose there is some chance you could try to grab the API key from the website you are attacking if it has one but that sounds mega-hard and less efficient than just preloading the data. Moreover, if you have a server vulnerable to an SQL injection attack discoverable via google any number of baddies can attack it directly so the extra risk seems like not much to worry about. So I have to admit still being confused. Are you advocating that client side scripting languages be denied *ANY* means of retrieving search data? After all the way you stated your example it doesn’t matter in the slightest how the JS gets the information so the only way to protect against this would be to deny ANY kind of google query from JS (or require user input or something).

I agree the ability to get search results makes JS worms slightly more dangerous but only slightly. After all the author of the worm could merely release 50-100 worms into the wild each of them containing their own subset of compressed search queries (does search beforehand).

Additionally I would thin the API key would prevent this sort of attack from going very far. If you are trying to run this as a worm you will need a new API key for every domain you infect no? (And if somehow you can use the same one won’t google notice and shut you down?). I suppose there is some chance you could try to grab the API key from the website you are attacking if it has one but that sounds mega-hard and less efficient than just preloading the data.

Moreover, if you have a server vulnerable to an SQL injection attack discoverable via google any number of baddies can attack it directly so the extra risk seems like not much to worry about.

]]> By: | urlsearches.info http://www.gnucitizen.org/blog/google-search-api-worms/#comment-52964 | urlsearches.info Wed, 26 Sep 2007 21:03:54 +0000 http://www.gnucitizen.org/blog/google-search-api-worms#comment-52964 [...] Google Search API Worms | GNUCITIZENSome web sites will submit your site to a dozen or so Search Engines for Free. Others will charge unsuspecting surfers from $50 to $200 to announce your URL … [...] [...] Google Search API Worms | GNUCITIZENSome web sites will submit your site to a dozen or so Search Engines for Free. Others will charge unsuspecting surfers from $50 to $200 to announce your URL … [...]

]]> By: Computer Security Tips http://www.gnucitizen.org/blog/google-search-api-worms/#comment-39282 Computer Security Tips Mon, 06 Aug 2007 16:10:44 +0000 http://www.gnucitizen.org/blog/google-search-api-worms#comment-39282 <strong>Computer Security Tips...</strong> I couldn't understand some parts of this article, but it sounds interesting... Computer Security Tips…

I couldn’t understand some parts of this article, but it sounds interesting…

]]> By: GNUCITIZEN » Google AJAX Feed API Dangers http://www.gnucitizen.org/blog/google-search-api-worms/#comment-14935 GNUCITIZEN » Google AJAX Feed API Dangers Thu, 19 Apr 2007 11:20:29 +0000 http://www.gnucitizen.org/blog/google-search-api-worms#comment-14935 [...] Recently Google has released their AJAX Feed API which helps developers to create web mashups by consuming RSS and Atom feeds from 3rd-party web sites. Just like Google’s AJAX Search API, the Feed API can be abused to create and spread web malware. For more information about Google AJAX Search API security aspects, you can read here, here and here. [...] [...] Recently Google has released their AJAX Feed API which helps developers to create web mashups by consuming RSS and Atom feeds from 3rd-party web sites. Just like Google’s AJAX Search API, the Feed API can be abused to create and spread web malware. For more information about Google AJAX Search API security aspects, you can read here, here and here. [...]

]]> By: Simpltry » Blog Archive » Google AJAX Search API (in theory) http://www.gnucitizen.org/blog/google-search-api-worms/#comment-2581 Simpltry » Blog Archive » Google AJAX Search API (in theory) Sat, 20 Jan 2007 14:50:20 +0000 http://www.gnucitizen.org/blog/google-search-api-worms#comment-2581 [...] The fact that there are numerous people concerned about the security of this API, is probably a good reason not to draw attention to the fact that it uses “On Demand” techniques. Under the current browser security model, I believe this is the only way you could write a javascript ONLY api that works cross domain. Personally, I am not that concerned about the security aspect of the API, but I think it is a mistake to use the improper AJAX, as opposed the more widely accepted Ajax. [...] [...] The fact that there are numerous people concerned about the security of this API, is probably a good reason not to draw attention to the fact that it uses “On Demand” techniques. Under the current browser security model, I believe this is the only way you could write a javascript ONLY api that works cross domain. Personally, I am not that concerned about the security aspect of the API, but I think it is a mistake to use the improper AJAX, as opposed the more widely accepted Ajax. [...]

]]> By: anyone http://www.gnucitizen.org/blog/google-search-api-worms/#comment-695 anyone Sat, 18 Nov 2006 06:42:22 +0000 http://www.gnucitizen.org/blog/google-search-api-worms#comment-695 hi, thankx for the useful info :) hi, thankx for the useful info :)

]]> By: Tom http://www.gnucitizen.org/blog/google-search-api-worms/#comment-677 Tom Thu, 16 Nov 2006 18:07:51 +0000 http://www.gnucitizen.org/blog/google-search-api-worms#comment-677 A lot of Joomla sites were compromised by a series of attacks lately. Using GET/POST methods. It wasn't Joomla actually - it was several 3rd party components for the popular CMS. My point is...I do believe that a single attack can effect multiple sites...or let's say a single attack running over and over automated. Someone just unleashes it and it crawls the web like a search engine finding vulnerable sites... however to the point of chown, it has to be the SAME EXACTLY circumstance... To the point of pdp, that's not really all too uncommon - especially because of the one example I just made about the CMS. All this means is developers need to be more careful. Generally speaking - the worm that would run SQL injection is probably easier to cut off at the head than other attacks...because a pattern can VERY easily be established and developers can fix the problem. Hopefully no one is using a compromised application for anything important such as payment transactions, etc. ...if there was a vulnerability with say a paypal site and someone was able to inject some SQL to change around where money is being sent... Well not hard to catch the person but WOW what a mess. There is a big potential for disaster, but it's not a reason to not use Google's APIs. It's just you need to understand you are advertising your system to the world...which many people want to do anyway- we all want more web traffic...just not the malicious kind. Of course google's code search also presents dangers too. Though I'm sure that takes more of a manual labored approach for the script kiddies...where's the fun in that? A lot of Joomla sites were compromised by a series of attacks lately. Using GET/POST methods. It wasn’t Joomla actually - it was several 3rd party components for the popular CMS. My point is…I do believe that a single attack can effect multiple sites…or let’s say a single attack running over and over automated. Someone just unleashes it and it crawls the web like a search engine finding vulnerable sites… however to the point of chown, it has to be the SAME EXACTLY circumstance… To the point of pdp, that’s not really all too uncommon - especially because of the one example I just made about the CMS.

All this means is developers need to be more careful. Generally speaking - the worm that would run SQL injection is probably easier to cut off at the head than other attacks…because a pattern can VERY easily be established and developers can fix the problem. Hopefully no one is using a compromised application for anything important such as payment transactions, etc. …if there was a vulnerability with say a paypal site and someone was able to inject some SQL to change around where money is being sent… Well not hard to catch the person but WOW what a mess.

There is a big potential for disaster, but it’s not a reason to not use Google’s APIs. It’s just you need to understand you are advertising your system to the world…which many people want to do anyway- we all want more web traffic…just not the malicious kind.

Of course google’s code search also presents dangers too. Though I’m sure that takes more of a manual labored approach for the script kiddies…where’s the fun in that?

]]> By: GNUCITIZEN » Maluc on JavaScript Worms http://www.gnucitizen.org/blog/google-search-api-worms/#comment-234 GNUCITIZEN » Maluc on JavaScript Worms Wed, 11 Oct 2006 03:23:01 +0000 http://www.gnucitizen.org/blog/google-search-api-worms#comment-234 [...] This is where pdp’s work with public services shows destructive potential. It’s still not a headless worm, but utilizing a server like google to search for vulnerable services .. http://www.gnucitizen.org/blog/google-search-api-worms .. allows a worm of any size/load. Google has been used for years to do this - in PHP, Perl, asp, c++, java, flash, etc - but until recently it’s been thought impossible to use javascript for it. That gives XSS and SQL vulnerabilities a very dangerous weapon. The javascript spider expands this to other common services like proxies. [...] [...] This is where pdp’s work with public services shows destructive potential. It’s still not a headless worm, but utilizing a server like google to search for vulnerable services .. http://www.gnucitizen.org/blog.....-api-worms .. allows a worm of any size/load. Google has been used for years to do this - in PHP, Perl, asp, c++, java, flash, etc - but until recently it’s been thought impossible to use javascript for it. That gives XSS and SQL vulnerabilities a very dangerous weapon. The javascript spider expands this to other common services like proxies. [...]

]]> By: pdp http://www.gnucitizen.org/blog/google-search-api-worms/#comment-199 pdp Fri, 06 Oct 2006 01:29:11 +0000 http://www.gnucitizen.org/blog/google-search-api-worms#comment-199 wasnewbie, persistency is definitely a big plus. However, worms that abuse Google AJAX Search API can use some sort of semi persistent method with dynamically generated <a href="http://www.gnucitizen.org/blog/backdooring-quicktime-movies" rel="nofollow">MOV</a>, <a href="http://www.gnucitizen.org/blog/backdooring-mp3-files" rel="nofollow">MP3</a> or <a href="http://www.gnucitizen.org/blog/backdooring-flash-objects-receipt" rel="nofollow">SWF</a> objects through the method I discussed <a href="http://www.gnucitizen.org/blog/self-contained-xss-attacks" rel="nofollow">here</a>. For example the worm can generate dynamic SWF that mimics Google Video or YouTube video player. After the movie is previewed the user will be asked to share the object with others or blog it on their website. I know that it requires user interaction but let's me honest, people will happily do what they are asked for. wasnewbie, persistency is definitely a big plus. However, worms that abuse Google AJAX Search API can use some sort of semi persistent method with dynamically generated MOV, MP3 or SWF objects through the method I discussed here.

For example the worm can generate dynamic SWF that mimics Google Video or YouTube video player. After the movie is previewed the user will be asked to share the object with others or blog it on their website. I know that it requires user interaction but let’s me honest, people will happily do what they are asked for.

]]> By: wasnewbie http://www.gnucitizen.org/blog/google-search-api-worms/#comment-195 wasnewbie Thu, 05 Oct 2006 13:27:39 +0000 http://www.gnucitizen.org/blog/google-search-api-worms#comment-195 I wonder if XSS on victim sites have to be persistent XSS types in order for this worm to spread on a much larger scale. I wonder if XSS on victim sites have to be persistent XSS types in order for this worm to spread on a much larger scale.

]]> By: GNUCITIZEN » Google Search API Worms 3 http://www.gnucitizen.org/blog/google-search-api-worms/#comment-191 GNUCITIZEN » Google Search API Worms 3 Thu, 05 Oct 2006 02:08:14 +0000 http://www.gnucitizen.org/blog/google-search-api-worms#comment-191 [...] All that reminded me of my discussion about Google AJAX Search API worms. So, I decided to try and see how far an attacker can go with Michaels’ findings and my AttackAPI. [...] [...] All that reminded me of my discussion about Google AJAX Search API worms. So, I decided to try and see how far an attacker can go with Michaels’ findings and my AttackAPI. [...]

]]> By: pdp http://www.gnucitizen.org/blog/google-search-api-worms/#comment-181 pdp Wed, 04 Oct 2006 03:55:32 +0000 http://www.gnucitizen.org/blog/google-search-api-worms#comment-181 Google AJAX Search API works with SCRIPT elements. This technique is also known as JavaScript on demand or JSON. Basically, a dynamic SCRIPT element is created that points to a remote URL which upon visit generates JavaScript that is evaluated inside the current browser. Since there are no restrictions on SCRIPT elements, this mechanism is quite suitable for implementing cross-domain functionalities. Google AJAX Search API works with SCRIPT elements. This technique is also known as JavaScript on demand or JSON. Basically, a dynamic SCRIPT element is created that points to a remote URL which upon visit generates JavaScript that is evaluated inside the current browser. Since there are no restrictions on SCRIPT elements, this mechanism is quite suitable for implementing cross-domain functionalities.

]]> By: pato http://www.gnucitizen.org/blog/google-search-api-worms/#comment-180 pato Wed, 04 Oct 2006 03:51:07 +0000 http://www.gnucitizen.org/blog/google-search-api-worms#comment-180 If a browser sandbox doesn’t allow to obtain data from a different domain, how can any site show dynamic google content? How does Google AJAX API works? Isn’t it using XMLHTTP? If a browser sandbox doesn’t allow to obtain data from a different domain, how can any site show dynamic google content? How does Google AJAX API works? Isn’t it using XMLHTTP?

]]> By: GNUCITIZEN » Google Search API Worms 2 http://www.gnucitizen.org/blog/google-search-api-worms/#comment-178 GNUCITIZEN » Google Search API Worms 2 Wed, 04 Oct 2006 02:11:47 +0000 http://www.gnucitizen.org/blog/google-search-api-worms#comment-178 [...] I covered Google Search API functionalities a week ago. I also provided my view why this service is practically dangerous and how it can be used by AJAX/JavaScript based worms to propagate. It seams that the situations have become worse since Google released a full blown AJAX Search Service called SearchMash. [...] [...] I covered Google Search API functionalities a week ago. I also provided my view why this service is practically dangerous and how it can be used by AJAX/JavaScript based worms to propagate. It seams that the situations have become worse since Google released a full blown AJAX Search Service called SearchMash. [...]

]]> By: links for 2006-10-02 at Marsmenschen http://www.gnucitizen.org/blog/google-search-api-worms/#comment-174 links for 2006-10-02 at Marsmenschen Mon, 02 Oct 2006 18:17:04 +0000 http://www.gnucitizen.org/blog/google-search-api-worms#comment-174 [...] GNUCITIZEN » Google Search API Worms (tags: ajax google Javascript security search json) [...] [...] GNUCITIZEN » Google Search API Worms (tags: ajax google Javascript security search json) [...]

]]> By: atomic1fire http://www.gnucitizen.org/blog/google-search-api-worms/#comment-170 atomic1fire Fri, 29 Sep 2006 22:43:14 +0000 http://www.gnucitizen.org/blog/google-search-api-worms#comment-170 idiot style worm sees hole worm uses google to find more copys of that hole idiot style
worm sees hole
worm uses google to find more copys of that hole

]]> By: pdp http://www.gnucitizen.org/blog/google-search-api-worms/#comment-167 pdp Fri, 29 Sep 2006 06:43:20 +0000 http://www.gnucitizen.org/blog/google-search-api-worms#comment-167 really, :) Ok, let’s imagine that there is popular blogging software that is vulnerable to SQL Injection. The vulnerability occurs when SQL meta characters are submitted into a unsanitized hidden field from submit comments form. In that respect if someone inputs single quote into this field, the resulting page will be an error dump. Is it possible for a JavaScript worm to propagate via this vulnerability? I am saying that it is absolutely possible. You are saying that it is not. Let's have a look in the test scenario specified above. The worm can enumerate blogs by using Google AJAX Search API. Once the blog is found the worm will blindly submit a comment with special SQL statements inside to tamper the backend database. This can be quite simple or complex depending how the application is written. Here you go, the worm is spreading. How do we submit comments you may ask? The answer is via GET and POST. Can JavaScript applications do blind GET and POST? Yes! Some blogging software accept only POST, others accept both. If it is a Java Servlet application there is high chance for the second. But this doesn’t matter. Both GET and POST can be performed from JavaScript. Not to mention that the entire process can be automated absolutely 100% because the application is known and its behavior can be studied in order to make the worm more stable. Do you still believe that it is impossible? There are no impossible things my friend. There are only limits defined by your own mind. What I am providing here is a scenario which IMHO is quite possible today. JavaScript attacks have been considered quite lame for too long. really, :)

Ok, let’s imagine that there is popular blogging software that is vulnerable to SQL Injection. The vulnerability occurs when SQL meta characters are submitted into a unsanitized hidden field from submit comments form. In that respect if someone inputs single quote into this field, the resulting page will be an error dump.

Is it possible for a JavaScript worm to propagate via this vulnerability? I am saying that it is absolutely possible. You are saying that it is not. Let’s have a look in the test scenario specified above.

The worm can enumerate blogs by using Google AJAX Search API. Once the blog is found the worm will blindly submit a comment with special SQL statements inside to tamper the backend database. This can be quite simple or complex depending how the application is written. Here you go, the worm is spreading.

How do we submit comments you may ask? The answer is via GET and POST. Can JavaScript applications do blind GET and POST? Yes! Some blogging software accept only POST, others accept both. If it is a Java Servlet application there is high chance for the second. But this doesn’t matter. Both GET and POST can be performed from JavaScript.

Not to mention that the entire process can be automated absolutely 100% because the application is known and its behavior can be studied in order to make the worm more stable.

Do you still believe that it is impossible?

There are no impossible things my friend. There are only limits defined by your own mind. What I am providing here is a scenario which IMHO is quite possible today. JavaScript attacks have been considered quite lame for too long.

]]> By: chown http://www.gnucitizen.org/blog/google-search-api-worms/#comment-165 chown Fri, 29 Sep 2006 04:12:43 +0000 http://www.gnucitizen.org/blog/google-search-api-worms#comment-165 "SQL injection vulnerability can be exploited with a single URL." That's not possible. You cannot exploit multiple different vulnerabilities with a single attack. Nearly all databases are completely different, and saying you can gain access to any database with a single URL is quite simply ludicrous. Believe me, if it were at all possible, in any way, shape or form, to create an effective Javascript worm - one that could effect multiple domains, it would have been done a long time ago. “SQL injection vulnerability can be exploited with a single URL.”

That’s not possible. You cannot exploit multiple different vulnerabilities with a single attack. Nearly all databases are completely different, and saying you can gain access to any database with a single URL is quite simply ludicrous.

Believe me, if it were at all possible, in any way, shape or form, to create an effective Javascript worm - one that could effect multiple domains, it would have been done a long time ago.

]]>