Windows Printer Sharing Vulnerability

DESCRIPTION
One of the new "features" of Windows ME that immediately caught my eye was that as soon as I got networking up and running it had gone ahead and created shortcuts to all visible network shares and installed all networked printers without even hassling me with one "are you sure" dialog. How nice.

At first glance it appeared to be nothing more then an annoyance. Later I came to thinking that naturally host machines must keep a list of files needed to install their printer. What if we were to replace one of these files with a trojan? Or perhaps add a trojan onto this list of files? After some searching I found this:

    HKEY_LOCAL_MACHINE\System\CurrentControlSet
    \Control\Print\Environments\Windows4.0\Drivers

Within this key lies a list of installed printers. Within a printers key lies a binary value named "Dependent Files" which contains a null (00) separated and double null (00 00) ending list of files that must be transferred to a client in order for this printer to work for them.

Replacing any of these files or adding files to the list will cause them to be transferred to a client if they choose to install your printer (or in the case of Windows ME automatically). Paths are preserved on file transfers. Ex: from SYSTEM to SYSTEM and from SYSTEM\color to SYSTEM\color. So big deal, you can put a trojan on the clients machine but how can you execute it? This is the part that I can't find a solid answer to. To the best of my knowledge files can only be placed in the SYSTEM folder or its subfolders.

Here are some of the ideas I came up with given this limitation:

(1) Replace an existing file that runs at startup. The problem with this method is that most (if not all) files that start automatically with windows are still running and therefore cannot be overwritten.

(2) Replace a system file that will eventually be run. This can be done and can be done silently by creating a small wrapper program that contains version information claiming to be newer then the target binary. However, when will this file be run? I don't have the patience to wait. Of course this can also be used as a DoS attack since an attacker can silently overwrite any binary that is not currently running. The best candidate for replacement I found is the "uninstall" executable which probably has the highest chance of being run since the annoyed victim will probably want to remove the printer that ME decided he needed.

(3) Start the trojan through the installation. Not to sure about this one but at least one printer (notably the Compaq IJ200) displays a small license agreement window directly after installation. Surely there must be a way to automatically start something else.

(4) Replace the files necessary for printing. Maybe the user likes your printer and feels like printing something. The printing monitor executable for example would have to run on every print, this can be replaced or even wrapped with a trojan. This in combination with replacing the "uninstall" executable will probably give you the best chance of success.

After countless attempts at trying to put the trojan in a location other then the SYSTEM folder I gave up. If someone figures out a way, do share I'd be very interesting in hearing the solution.

Here is what I tried: (1) ".." in Dependent Files key. Doesn't work. But did answer another question of mine. I was wondering earlier in the process how windows knew to look in SYSTEM and install in SYSTEM. The answer is that it uses the hidden system share PRINTER$ which points to the system folder. So a "..\folder" simply refers to \\MACHINE\folder (another share) instead of \\MACHINE\PRINTER$\..\folder (windows\folder) as I had hoped.

(2) ".." plus a share named "start menu". Long shot, and it didn't work.

(3) Share another folder as PRINTER$ It works on my end, I can refer to files in my startup folder (I want to copy a file to victims startup folder). However, the victims PRINTER$ still points to SYSTEM and hence will not copy files into another directory up the hierarchy.

The easy fix to this problem is disabling the "Automatically search for network folders and printer" option which can be found under "tools\folder options".