OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Laura A. Robinson (larobinsbellatlantic.net)
Date: Mon Apr 08 2002 - 11:38:49 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    A few things-

    First, administrative access to the print server had already been specified,
    so accessing the spool file would, indeed, be quite trivial. Now, as for how
    easy it would be to retrieve the content of the spooler for purposes of
    retrieving printed documents, all an admin would have to do would be to
    configure the printer (driver) properties to hold printed documents and
    print them out again. A no-brainer, but this setting would be viewable in
    the properties of the printer, so let's assume that we're looking for
    something sneakier.

    Rather than go into all the mechanics of client-server printing in NT, I'm
    just going to post this link:
    http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/prodtechn
    ol/winntas/support/printing.asp

    In a nutshell, printed files are not exactly sitting on the print server in
    a "pretty" format. Additionally, once a file has printed, the shadow file in
    the spooler is deleted (unless the print server is configured to hold
    printed documents, as I mentioned earlier). Over the course of a day's
    printing, the area on disk where the file was temporarily housed is likely
    to be overwritten again and again. So, in order to snag the file, one would
    either need to configure the print server to hold printed documents,
    actively monitor the spool file and copy the shadow file while it exists,
    fire up a low-level disk utility, or sniff the packets as they arrived at
    the print server. One could always disable spooling at the print server and
    run the risk of losing the print jobs, but again, this isn't going to stop
    an administrator from snagging the incoming packets. The only way to prevent
    an administrator from being able to access formerly printed jobs would be to
    print to a local printer (with all associated cautions there, as well).

    In other words, Thor is right on (no surprise there). ;-)

    Laura
    ----- Original Message -----
    From: <Matthew.van.Eerdehbinc.com>
    To: <ThorHammerofGod.com>; <shartmannfujifilmesys.com>; <genius28gmx.de>;
    <focus-mssecurityfocus.com>
    Cc: <Matthew.van.Eerdehbinc.com>
    Sent: Friday, April 05, 2002 12:17 PM
    Subject: RE: Windows NT 4.0 Print Spooler Security

    > In my understanding
    > C:\Winnt\system32\spool
    > is not shared - rather,
    > C:\winnt\system32\spool\drivers
    > is print$.
    > Therefore getting access to the print job spool files is nontrivial - you
    > would need administrative access to the print server to get in through
    > admin$ or c$, or you would to log on to the server locally. (Please tell
    me
    > your servers are physically secured.)
    > The print queue is not built by copying files from the client to the
    server.
    > Rather, the server builds the spool file based on a TCP/IP conversation
    with
    > the client.
    >
    > > -----Original Message-----
    > > From: ThorHammerofGod.com [mailto:ThorHammerofGod.com]
    > > Sent: Friday, April 05, 2002 08:12
    > > To: shartmannfujifilmesys.com; genius28gmx.de;
    > > focus-mssecurityfocus.com
    > > Cc: Matthew.van.Eerdehbinc.com
    > > Subject: RE: Windows NT 4.0 Print Spooler Security
    > >
    > >
    > >
    > > -----BEGIN PGP SIGNED MESSAGE-----
    > > Hash: SHA1
    > >
    > > At 07:26 AM 4/5/2002, Seamus Hartmann wrote:
    > > >Florian, Thor, Matt, and all the others who wrote to me privately.
    > >
    > > You're welcome ;)
    > >
    > >
    > > >Basically, this would be a non-trivial attack on our network
    > > topology, and
    > > >would require installation of software on the target server,
    > > or the use of a
    > > >hub/tap/mirrored switch port on the network near the server
    > > itself. It would
    > > >also require console access to the print spooler server, or a remote
    > > >installation of a remote control package.
    > >
    > > I don't know if I would say that... Now that I know that you
    > > are looking
    > > for specifics, there are some things I would caution you about,
    > > particularly if you were made to believe that it is
    > > non-trivial... Let's
    > > forget about console access, remote control, sniffers, etc
    > > for a second and
    > > just look at the spool file. There is no magic there... It is just a
    > > file. If you have not changed the default location of the
    > > spool file or
    > > its permissions, then everyone will have change permissions on the
    > > \winnt\system32\printers\spool directory. If you pause the
    > > printer, you
    > > can simply copy the file to wherever you want. the .sp_ file
    > > has the owner
    > > name in clear text, so it would be really easy to pick which
    > > files you
    > > wanted. From there, you can just copy the spool file to
    > > whatever print
    > > queue you want. I would call that trivial.
    > >
    > > I could simply open the shared printer queue, pause the
    > > printer, look at
    > > the jobs as they came through and process the uninteresting
    > > ones, and when
    > > one came along that I wanted I could just copy the file and
    > > then send it
    > > through. No muss, no fuss, and no real technical abilities
    > > required. Of
    > > course, a sophisticated recon over time would be easy with a
    > > bit of API
    > > programming skill where the process could be automated.
    > >
    > > Thought I would bring that up...
    > >
    > > Have a good one.
    > >
    > > AD
    > >
    > >
    > >
    > >
    > >
    > > -----BEGIN PGP SIGNATURE-----
    > > Version: PGP 7.1
    > >
    > > iQA/AwUBPK3MxIhsmyD15h5gEQLm+ACg8QOVlq/OQl5k6sFjaL5lMpWqZp0AoIYf
    > > YdElXAbLpuzkwP3n0pfZd9MH
    > > =6DWf
    > > -----END PGP SIGNATURE-----
    > >