Windows Desktop Search – Indirect Script Injection

Background

Windows Desktop Search (WDS) is a popular desktop search tool released by Microsoft. WDS indexes a large variety of files located on the user's computer (as well as network shares, if configured to do so by the user). It then offers fast searching capabilities over these files. Like some of its competitors, WDS uses an embedded Internet-Explorer browser component in order to preview the search results to the user.

Browsers embedded within Desktop Applications have been a favorite research topic of mine for some time now, due to the special security-context issues posed by the embedded-browsers.

One of the interesting challenges of trying to attack Desktop Applications that use Embedded Browser components is trying to discover the injection vector – and it usually requires unusual measures to mount a successful script injection attack in such cases.

A while ago I found a way of indirectly injecting JavaScript code into the WDS embedded-browser. Because of its security-context, I discovered it was possible to access data on any domain (bypassing the Same Origin Policy) and therefore gather some very interesting data from the attacked box.

A fix for the attack described below has been just released by Microsoft. If you use WDS, it is advisable to install the fix.

Vulnerability

WDS previews the search results to the user via an embedded-browser. In order to support non-HTML/XML files, WDS uses converters that transform the files into HTML. As part of this process, potentially hazardous characters are escaped by the converters.

However, it turns out that HTML files do not undergo any sanitation process before being presented. Instead, WDS simply loads the files into its embedded browser from the local hard-drive.

In accordance with the security settings of the embedded browser, the aforementioned local HTML files are loaded with partial JavaScript execution permissions that require no user-approval.

While the ActiveX implementation of XMLHTTP (e.g. new ActiveXObject("Msxml2.XMLHTTP")…) cannot be initiated automatically due to a security restriction, it turns out that the XMLHttpRequest JS object (new XMLHttpRequest()…) can be initiated and used without limitations.

What makes this vulnerability particularly interesting is the fact that in this context the XMLHttpRequest object can freely interact with any domain; sending on the victim's persistent cookies (if there are any). In other words, an attacker exploiting the aforementioned vulnerability can impersonate the victim on sites for which the victim is authenticated. "Example of a Possible Attack" below shows how sensitive information might be hijacked from a Gmail account.

Attack Flow

1. A remote attacker puts a specially crafted HTML file in a directory indexed by WDS. This phase can be accomplished in either of the following ways:
   • Exploiting a "File Dropping" vulnerability (such as the recent "Carpet-Bombing" vulnerabilities in Safari & Google Chrome).
     •  Anecdote: Due to the security evolution of Google Chrome, up-to-date versions ask for user-approval when an .HTM file download attempt takes place (instead of auto-downloading it, as it used to): 
        
       However, I discovered that it is still possible to drop MHTML files by causing an automatic download attempt of an *.mht file:
        
   • Taking advantage of the fact HTML files are presumed by many to be harmless (especially if not even directly loaded by a browser) to mount a social engineering attack.
2. Let's assume the specially crafted HTML filename is: mal.html.
   • The file should contain some likely-to-be-queried keywords as well as JavaScript code. (e.g. "Watchfire IBM Microsoft <script>alert(123)</script>").
3. At that point, mal.html is already indexed by Windows Desktop Search.
4. At some point, the user queries for a word that shows up in mal.html ("Microsoft", for example) via Windows Desktop Search.
5. Due to the lack of sanitation, when mal.html is displayed via the preview pane (which is in fact an embedded IE browser) the script within mal.html is automatically executed.

NOTES:

• If the results pane is ordered by date, it is very likely that mal.html will be selected automatically, without any user interaction.
• In order to amplify the success rate of the attack, multiple files that contain malicious JavaScript code along with likely-to-be-queried keywords can be dropped to the victim's hard-drive.

Example of a Possible Attack

In this scenario, our victim has a Google account ([email protected]) with one mail filled with secret passwords in its inbox.

Like many users, the victim uses the "Remember me on this computer" feature, and persistent Google account authentication cookies are therefore stored on his/her system.

At some point, the victim uses WDS and queries a "poisoned" keyword (in this example, the keyword is "Microsoft").

While the victim views this file via WDS, the following happens:
1. An XMLHttpRequest object is created.
2. Due to the security context of the embedded-browser, a bi-directional connection to Gmail is successfully established (Same-Origin Policy is not enforced).
3. The contents of the inbox page are retrieved (The XMLHttpRequest object uses the persistent cookies for the [email protected] account).
4. The response is parsed and information about the "Secret Stuff" mail message is presented.

 

Final Remarks

Since various Desktop Search Tools use a mechanism similar to Windows Desktop Search in order to present search results to the user it is very likely that similar vulnerabilities and attack vectors might apply to these products too.

Acknowledgments

I would like to acknowledge and thank Microsoft for the highly professional way in which they had handled this security issue.