Article at ... http://www.hacker.co.il/security/ie/css_import.html
Google Desktop Exposed: Exploiting an Internet Explorer Vulnerability to Phish User Information
Overview
It was bound to happen. I was recently intrigued by the possibility of utilizing Google Desktop for remote data retrieval of personal user data (such as credit cards and passwords) through the use of a malicious web page. Now, thanks to a severe design flaw in Internet Explorer, I managed to show it's possible to covertly run searches on visitors to a web site by exploiting this vulnerability. In this article I will detail what the vulnerability in IE is and how it is used to exploit Google Desktop. If you have IE 6 and Google Desktop v2 installed you can test it for yourself in my proof of concept page.
Detailed analysis
Normally, browsers impose strong restrictions for cross domain interaction through the web browser. A certain web page can make a user browse to a different domain. However, it may not read the content of the retrieved page nor manipulate any of its DOM objects. This restriction is imposed so one site owner wouldn't be able to spy on a user's surfing habits using Javascript. Also, if a user is already logged on to a certain service (such as Gmail or hotmail) a malicious web page could have executed certain operations in the user's account (such as opening an email and reading it) if the restrictions weren't in place. In IE these restrictions are kept thoroughly but they are broken when it comes to CSS imports. I call this attack CSSXSS or Cascading Style Sheets Cross Site Scripting.
A certain web page can import CSS rules from a different domain using the "@import" directive. IE also has a handy javascript function called "addImport" which operates just like "@import" but in runtime. CSS rules can later be read by accessing the "cssText" property in the document.styleSheets collection. But what happens when a web page imports a URL that is not a valid CSS file? It appears that IE's lenient CSS parsing allows this to happen and in the "cssText" property one can read snippets of html code from the remote site that were mis-parsed as CSS rules. Since CSS rules require a certain structure the amount of code that's retrieved from the remote site may vary depending on the site's code.
CSS rules determine the look of a site and normally have a selector, a property and a value. The property and value are seperated by a colon and surrounded by curly braces. For example, to color all the links on a certain web page one would define the CSS rule "a {color: white}". In order to retrieve code from a certain URL that is not valid CSS, the target page must contain some characters that are used in CSS, namely curly braces. Luckily, most modern web pages contain them as curly braces are used extensively in javascript code and CSS rules embedded in pages. Once the IE CSS parser hits curly braces it will try to interpret the data after it as CSS. Even if the resulting CSS rules don't make any sense to the browser, IE will still let you see them in the "cssText" property. The combination of curly braces, colons and semi colons as they appear in the target's HTML code determine which snippets of code can be read.
When using the CSSXSS technique an attacker will mostly get javascript code. However, he can improve his luck by injecting CSS characters into the target page. Since most modern sites are dynamic and get parameters through the URL, injecting these characters is usually trivial. This is very much like injecting javascript into a target page as used in classic XSS vulnerabilities only here an attacker injects characters which most sites consider harmless.
Much like classic XSS holes, this design flaw in IE allows an attacker to retrieve private user data or execute operations on the users behalf on remote domains. The difference is that in this case the target site doesn't have to be vulnerable to script injection. All an attacker has to do is lure a user to a malicious web page. Thousands of web sites can be exploited and there isn't a simple solution against this attack at least until IE is fixed. That means millions of IE users are affected by this design flaw.
This vulnerability has been tested to work on a fully patched Microsoft Internet Explorer 6 browser and earlier versions are possibly vulnerable as well. Mozilla Firefox seems to adequately keep domain restrictions in CSS imports and doesn't seem to be vulnerable to this type of attack. Opera isn't vulnerable because it doesn't support the styleSheets collection. Possible solutions for users to mitigate this attack would be to disable Javascript in IE or use a different browser.
Google Desktop Logo
The Google Desktop Exploit
To demonstrate what this vulnerability is capable of, I cooked up a little demonstration that exploits Google Desktop Search (GDS) to search and fetch private user information from a remote web site. But before detailing how this is done, I will give a brief background on how GDS works.
Google Desktop Search is a useful piece of software that indexes a user's local data such as documents, emails, spreadsheet files etc. Once data is indexed, a user can search through his local files in the familiar Google interface. The search is done using a web server installed on the local machine. The local web server listens on port 4664 and is bound only to the 127.0.0.1 address to make it impossble to access remotely from the Internet.
Google added an extra security measure so remote web pages won't be able to access the local web server and try to exploit XSS holes. In order to access the GDS web interface, there is a randomly generated secret key which has to be passed as a parameter in the URL. Once a user clicks on the GDS icon, a secret key is generated on the web server and the default web browser opens with a URL containing the key. If the key is not present or wrong, GDS will not allow any execution of queries and instead it will return an error page. The only thing remote web pages can access is a gif file which shows the Google logo.
Google also integrates GDS with their regular search services on google.com. Once a user installs GDS a new link appears in google.com above the query box called "Desktop". This link points to the URL of the local web server including the secret key. This is done so the user will be able to go to his local search without even noticing ever leaving the Google web site. The desktop link that appears doesn't actually come from Google's web site. The link is injected by GDS using a browser plugin whenever it detects that the user surfed to the Google web site. This prevents the key from being leaked to the Internet.
Google Main Page with desktop link
In order to exploit GDS an attacker must first have a valid key to access the GDS web server. As I mentioned earlier, the key appears in a link on Google's web sites so naturally, this is where the key can be grabbed by the attacker using the CSSXSS attack. Due to Google's design, grabbing the "Desktop" link isn't possible on most of their search sites. However, after some trial and error I discovered the link can be returned using this attack on the Google News site, news.google.com, by injecting curly braces into a query. Then it's only a simple matter of extracting the key using a regular expression and doing a CSS import on the URL of the local web server with the chosen query. I also add a "{" character to the query so the results will be visible in the "cssText" property after CSS parsing. This character is ignored by the search engine and doesn't change the results.
The proof of concept works on a fully patched IE browser (default security and privacy settings) with Google Desktop v2 installed. It will not work on any other browser unless the browser is derived from IE. The results you will get from this demonstration may vary, depending greatly on the Google News page design and the content in the user's hard drive (and possibly the language of the GDS installation) . I got the best results using the english version of GDS and the english Google News page. A complete exploit can also iterate through the result pages to get more data and log the results on a remote server. Needless to say, I don't log any of the results. Also note that this proof of concept code is supplied for educational purposes only.
Google Desktop proof of concept exploit
Back to hacker.co.il main page.
Matan Gillon (matan <[_at_]> hacker.co.il)
30/11/2005
Google Desktop Exposed: Exploiting an Internet Explorer Vulnerability to Phish User Information
Overview
It was bound to happen. I was recently intrigued by the possibility of utilizing Google Desktop for remote data retrieval of personal user data (such as credit cards and passwords) through the use of a malicious web page. Now, thanks to a severe design flaw in Internet Explorer, I managed to show it's possible to covertly run searches on visitors to a web site by exploiting this vulnerability. In this article I will detail what the vulnerability in IE is and how it is used to exploit Google Desktop. If you have IE 6 and Google Desktop v2 installed you can test it for yourself in my proof of concept page.
Detailed analysis
Normally, browsers impose strong restrictions for cross domain interaction through the web browser. A certain web page can make a user browse to a different domain. However, it may not read the content of the retrieved page nor manipulate any of its DOM objects. This restriction is imposed so one site owner wouldn't be able to spy on a user's surfing habits using Javascript. Also, if a user is already logged on to a certain service (such as Gmail or hotmail) a malicious web page could have executed certain operations in the user's account (such as opening an email and reading it) if the restrictions weren't in place. In IE these restrictions are kept thoroughly but they are broken when it comes to CSS imports. I call this attack CSSXSS or Cascading Style Sheets Cross Site Scripting.
A certain web page can import CSS rules from a different domain using the "@import" directive. IE also has a handy javascript function called "addImport" which operates just like "@import" but in runtime. CSS rules can later be read by accessing the "cssText" property in the document.styleSheets collection. But what happens when a web page imports a URL that is not a valid CSS file? It appears that IE's lenient CSS parsing allows this to happen and in the "cssText" property one can read snippets of html code from the remote site that were mis-parsed as CSS rules. Since CSS rules require a certain structure the amount of code that's retrieved from the remote site may vary depending on the site's code.
CSS rules determine the look of a site and normally have a selector, a property and a value. The property and value are seperated by a colon and surrounded by curly braces. For example, to color all the links on a certain web page one would define the CSS rule "a {color: white}". In order to retrieve code from a certain URL that is not valid CSS, the target page must contain some characters that are used in CSS, namely curly braces. Luckily, most modern web pages contain them as curly braces are used extensively in javascript code and CSS rules embedded in pages. Once the IE CSS parser hits curly braces it will try to interpret the data after it as CSS. Even if the resulting CSS rules don't make any sense to the browser, IE will still let you see them in the "cssText" property. The combination of curly braces, colons and semi colons as they appear in the target's HTML code determine which snippets of code can be read.
When using the CSSXSS technique an attacker will mostly get javascript code. However, he can improve his luck by injecting CSS characters into the target page. Since most modern sites are dynamic and get parameters through the URL, injecting these characters is usually trivial. This is very much like injecting javascript into a target page as used in classic XSS vulnerabilities only here an attacker injects characters which most sites consider harmless.
Much like classic XSS holes, this design flaw in IE allows an attacker to retrieve private user data or execute operations on the users behalf on remote domains. The difference is that in this case the target site doesn't have to be vulnerable to script injection. All an attacker has to do is lure a user to a malicious web page. Thousands of web sites can be exploited and there isn't a simple solution against this attack at least until IE is fixed. That means millions of IE users are affected by this design flaw.
This vulnerability has been tested to work on a fully patched Microsoft Internet Explorer 6 browser and earlier versions are possibly vulnerable as well. Mozilla Firefox seems to adequately keep domain restrictions in CSS imports and doesn't seem to be vulnerable to this type of attack. Opera isn't vulnerable because it doesn't support the styleSheets collection. Possible solutions for users to mitigate this attack would be to disable Javascript in IE or use a different browser.
Google Desktop Logo
The Google Desktop Exploit
To demonstrate what this vulnerability is capable of, I cooked up a little demonstration that exploits Google Desktop Search (GDS) to search and fetch private user information from a remote web site. But before detailing how this is done, I will give a brief background on how GDS works.
Google Desktop Search is a useful piece of software that indexes a user's local data such as documents, emails, spreadsheet files etc. Once data is indexed, a user can search through his local files in the familiar Google interface. The search is done using a web server installed on the local machine. The local web server listens on port 4664 and is bound only to the 127.0.0.1 address to make it impossble to access remotely from the Internet.
Google added an extra security measure so remote web pages won't be able to access the local web server and try to exploit XSS holes. In order to access the GDS web interface, there is a randomly generated secret key which has to be passed as a parameter in the URL. Once a user clicks on the GDS icon, a secret key is generated on the web server and the default web browser opens with a URL containing the key. If the key is not present or wrong, GDS will not allow any execution of queries and instead it will return an error page. The only thing remote web pages can access is a gif file which shows the Google logo.
Google also integrates GDS with their regular search services on google.com. Once a user installs GDS a new link appears in google.com above the query box called "Desktop". This link points to the URL of the local web server including the secret key. This is done so the user will be able to go to his local search without even noticing ever leaving the Google web site. The desktop link that appears doesn't actually come from Google's web site. The link is injected by GDS using a browser plugin whenever it detects that the user surfed to the Google web site. This prevents the key from being leaked to the Internet.
Google Main Page with desktop link
In order to exploit GDS an attacker must first have a valid key to access the GDS web server. As I mentioned earlier, the key appears in a link on Google's web sites so naturally, this is where the key can be grabbed by the attacker using the CSSXSS attack. Due to Google's design, grabbing the "Desktop" link isn't possible on most of their search sites. However, after some trial and error I discovered the link can be returned using this attack on the Google News site, news.google.com, by injecting curly braces into a query. Then it's only a simple matter of extracting the key using a regular expression and doing a CSS import on the URL of the local web server with the chosen query. I also add a "{" character to the query so the results will be visible in the "cssText" property after CSS parsing. This character is ignored by the search engine and doesn't change the results.
The proof of concept works on a fully patched IE browser (default security and privacy settings) with Google Desktop v2 installed. It will not work on any other browser unless the browser is derived from IE. The results you will get from this demonstration may vary, depending greatly on the Google News page design and the content in the user's hard drive (and possibly the language of the GDS installation) . I got the best results using the english version of GDS and the english Google News page. A complete exploit can also iterate through the result pages to get more data and log the results on a remote server. Needless to say, I don't log any of the results. Also note that this proof of concept code is supplied for educational purposes only.
Google Desktop proof of concept exploit
Back to hacker.co.il main page.
Matan Gillon (matan <[_at_]> hacker.co.il)
30/11/2005
Comments
Post a Comment