Bugtraq mailing list archives

Windows (me) printer sharing vulnerability


From: Pedram Amini <pedram.amini () TULANE EDU>
Date: Wed, 25 Oct 2000 21:18:17 -0500

I'm not sure how much of this is common knowledge or not but since a quick
search showed nothing I felt it appropriate to share with the community. I
apologize in advance for the length of writing.

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? I
set to work with the help of my friend Shawn, who happens to be the best
machine restarter this side of the Mississippi. After some searching I found
this:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Print\Environments\Windo
ws 4.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, and numerous expertly executed machine restarts by
Shawn, 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".

On a side note, is it well known that one can browse through SYSTEM folders
simply by connecting to the PRINTER$ share?

Oh, and none of this work could have be accomplished without the amazing
machine restarting abilities of Shawn Pitz.

-pedram


Current thread: