ImpersonateNamedPipeClient to elevate privileges

Dear all,

I’m writing a backup/restore utility for Windows NT/2000/XP. Any user
must be able to use the utility and must be able to backup/restore files
he normally does not have access to. Obviously, this involves writing a
service that would normally run the backup utility under a different
account with sufficient privileges via CreateProcessAsUser(). However,
for specific reasons, I’m trying to avoid having to add a dedicated
backup operators account to the machine.

So I tried a different approach by turning the concept of
ImpersonateNamedPipeClient() “upside down”. That is, I wrote a service
that frequently tries to connect to a named pipe the backup utility
creates. When the pipe is available, the service reads a password sent
from the “server side” (the backup utility) and if the password matches,
enables the SE_BACKUP_NAME and SE_RESTORE_NAME in it’s process token,
ensures access of the local system account to the default window station
and desktop and sends back a simple “Hello”, at which point the backup
utility can call ImpersonateNamedPipeClient() to impersonate the
security context of the local system account including SE_BACKUP_NAME
and SE_RESTORE_NAME. This is working fine. I was thinking about solving
the problem of access to network resources by having two threads in the
backup utility, one impersonating thread that does the reading/writing
from/to the local disk, and another, non-impersonating thread that does
the reading/writing from/to the backup media.

My concern here is misuse of my service by hacker utilities. That is,
does anybody know if and how easy it is to enumerate named pipes in the
system and intercept data (my password!) sent over a known named pipe?

I was also thinking about having the service do all the reading/writing
to the local disk where the backup utility would be effectively be only
the “GUI front end” that receives/sends all the data through the pipe
and reads/writes it from/to the backup media. But again, this means the
service eventually sends data across the pipe at which point a malicious
program, knowing the name of the pipe, could elevate it’s privileges to
local system. On another point, are pipes designed to transfer massive
amounts of data or are they a bottleneck?

What other alternatives do I have if I don’t want to use
CreateProcessAsUser()?

Thanks for any insight!

Ralf.


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

> My concern here is misuse of my service by hacker utilities. That is,

does anybody know if and how easy it is to enumerate named pipes in the
system and intercept data (my password!) sent over a known named pipe?

Why invent your own authentication over the network?
If you have some passwords of your own - maybe it is a better idea to add an NT’s user account with this password and then use
system-supplied NTLM/Kerberos instead of your own authentication?
Why reinvent the wheel? I can understand that you do not want to add the user account, but sorry, reinventing the wheel looks worse.

Max


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Maxim,

you wrote on Friday, January 25, 2002, 21:59:15:

> My concern here is misuse of my service by hacker utilities. That is,
> does anybody know if and how easy it is to enumerate named pipes in the
> system and intercept data (my password!) sent over a known named pipe?

MSS> Why invent your own authentication over the network? If you have
MSS> some passwords of your own - maybe it is a better idea to add an
MSS> NT’s user account with this password and then use system-supplied
MSS> NTLM/Kerberos instead of your own authentication? Why reinvent the
MSS> wheel? I can understand that you do not want to add the user
MSS> account, but sorry, reinventing the wheel looks worse.

Thanks, I think you are right. It was just that
ImpersonateNamedPipeClient() “upside down” seemed to be the easiest way
to elevate a standard user’s privileges, but it is maybe too big a
security hole (if you remember the “service control manager predictable
named pipes” vulnerability in W2K).

I think my best bet is to do all the real work in the service, just have
the backup GUI send a “what to do” record through the pipe and
communicate back from the service by some other method of IPC. It will
be interesting to see if I can do a PostMessage() or SendMessage() from
a service to a standard Win32 GUI application. At which point an
interactive service may be even easier to do… oh well, always hard to
go down the right path :slight_smile:

Thanks and have a nice weekend!

Ralf.


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

> I think my best bet is to do all the real work in the service, just have

the backup GUI send a “what to do” record through the pipe and
communicate back from the service by some other method of IPC. It will
be interesting to see if I can do a PostMessage() or SendMessage() from
a service to a standard Win32 GUI application. At which point an

Yes you can, but COM is a much better way for this. It will also allow controlling service from .VBS file or a Web page.

Max


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com