Tuesday, June 26, 2018

Windows Search service vulnerability - Bookworm

What is Bookworm?

  • Bookworm is an information disclosure vulnerability affecting all versions of Microsoft windows at least back to Windows 7
  • Bookworm affects the default configuration of Windows operating systems

Is Microsoft aware?

I have disclosed this vulnerability to Microsoft Security response. The vulnerability has been acknowledged but is not planned to be fixed at this time.

How does it work?

Bookworm is an issue with how SearchProtocolHost.exe consumes .url files. Specifically, .url files which have a value in the URL field representing an FTP site on the internet.

A needle in a needle stack

I was examining FTP traffic from a machine that didn't make sense. The traffic occurred at seemingly random intervals for seemingly no reason. I copied a portion of a batch script from the internet for a loop and modified it to dump the connection table to a file every 5 seconds. After waiting for the attempt to connect again, I was able to observe that the image attempting to initiate the traffic was SearchProtocolHost.exe.


This behavior really didn't make sense. Why would an indexing service attempt to make an FTP connection outside of the country? The PTR record for resolves to "gunpowder.gitorious.c.bitbit.net" and resides in Norway. I needed to determine how this IP was getting in to  SearchProtocolHost.exe's memory space. Process explorer to the rescue!

Digging in to the process

Using Process explorer, I examined the handles on the image SearchProtcolHost.exe and found this one referencing FTP. Notice that the FTP site is ftp.qt.nokia.com.The string is a file handle, pointing to a URL file in the favorites folder. This is a file created when a site is bookmarked in Internet Explorer.

Dirty, Dirty DNS

The string found is FTP directory –qt-source- at ftp.qt.nokia.com.url. The link in the .url file is ftp.qt.nokia.com.url - this resolves to Someone left their "A" hanging out! Reverse DNS for this IP is nothing related to Nokia. In retrospect, Norway should have been a clue.

What does the traffic look like?

SeachProtocolHost actually does quite a bit. It will login as anonymous, give the password "User@", change to the first specified directory, change the mode, and ask for a list of files, among other commands. Here's a pcap, with the example '48_hour' as the directory

The culprit

In the end, what I discovered as a .url file with the following pattern will trigger this vulnerability: ftp://<anysite>/<dir>/<dir>. Example:

The vulnerability is triggered as follows:
  • On a regular basis when the folder containing the file is indexed 
  • Single clicking on the file
  • Inserting a USB or other drive with the file on the drive
It should be noted that single clicking on the file can cause the process explorer.exe to hang, potentially causing a denial of service condition.

Versions of Windows affected

I tested this in Windows 7, Windows 10, and Server 2012. All are fully patched. Antivirus did not detect this.

What's the value?

We know, at a minimum, the following about a user when exercising this vulnerability
  • The machine is on, and it is at the following public IP
  • The user is not behind a firewall or is behind a firewall allowing FTP
  • The user has taken a desired action, such as inserting a USB
  • We could transfer data out as the directory

Final thoughts

I billed this as a zero-day because I have not observed this before. I was not able to find anything like it on the Internet and MSRC did not appear to have observed this before. If you have evidence of previously disclosing this, please let me know and I will update accordingly.


  1. Any idea how this infects a machine? I understand how it works now thanks to your write up. Do you think this is being actively exploited in the wild?

    1. To infect the machine you would need to create the .url file on a machine or otherwise get it on the machine. I don’t think this is being used in the wild. Thank you for your comment!

  2. Found your page after seeing the same behaviour.

    So I had windows search service disabled for many months, as I didnt need it.
    Today I enabled it as it is required for the file history feature.
    My firewall is configured deny by default outbound and prompt when a request is made where no specific rule exists.
    About 3 hours after I enabled the service the firewall popped up with a request for searchprotocolhost.exe to access the internet.

    Now been aware microsoft tries to phone home and maybe trying to add internet results this didnt immediatly startle me (although this is win 8.1 not the cloud heavy win 10).

    However after another look at the prompt two things stood out.

    1 - It was over ipv6 whilst ipv6 was set to low preference in the windows configuration.
    2 - the remote port was port 21 (ftp), I have never ever seen microsoft requests use this port before.

    I checked the ip whois and a 3rd alarm bell was that the ip is not owned by microsoft or akamai.