Impersonating to ASPNET or SYSTEM Identities

  • Thread starter Thread starter Picho
  • Start date Start date
P

Picho

Hi all,

I am trying to write a secure application and some of you have been very
helpful on that subject.

the only question remaining open after implementing certain methodologies is
this:

from a hacker point of view, is it possible to impersonate to SYSTEM or
ASPNET windows identities on a local machine?

a simple yes or no will not do (actually a simple yes would...). I need to
base my assumptions so if you can, please provide an explaination.

Thanx,

Picho
 
It is certainly possible to "get" some code run under the worker process
identity. In the case of ASP.NET, someone may be able to run some code under
the configured account of your wp (ASPNET by default or Network Service in
W2K3). If you change the wp account to SYSTEM, you are virtually giving away
the control of your machine to the code that may get this identity (this is
usually done with the "RevertToSelf" API).
So use the ASPNET account or any other "low privilege" account whenever you
can (I mean always).

Regards.
--
Hernan de Lahitte
Lagash Systems S.A.
http://weblogs.asp.net/hernandl


This posting is provided "AS IS" with no warranties, and confers no rights.
 
Hi,
Logon as system is only available for registered Windows Services. Only
administrator has rights to register service with SCM. Service running as
System could start processes that will inherit SYSTEM credentials. If you
try to impersonate SYSTEM that is calling your process by means of LPC/RPC -
you'll get guest's identity in thread's impersonation token (not SYSTEM).
Last couldn't be used as an excuse for letting SYSTEM service to call back
less trusted code, because it greatly increases possible attack surface. If
attacker manages to run code of his choice in the process that is running as
SYSTEM - you lost your system to that attacker. That means that
services/programs that are designed to run some add-hook code should never
be running as SYSTEM. Exploitable errors of service/program that is running
as SYSTEM (like f.e. buffer overruns) could be abused by malicious code for
gaining unlimited Local System access. Limiting amount of interaction
between service that is running as SYSTEM with the rest of the world helps
reducing attack surface. If service is doing a lot of IO - consider not
running it as system - reduces possibility of exploiting errors related to
handling of malformed data. Backdoors/rogue services is another possibility
of getting SYSTEM access. If attacker manages to get system access on your
DC you lost you domain to the attacker. That means that you should limit
amount of services running on your DC to bare minimum if you want to have it
secure.

-Valery.
http://www.harper.no/valery
 
Back
Top