Since an administrator on a Windows system can install a service that logs on as LocalSystem, is it considered bad practice to allow that service to execute programs in a directory known to be protected?

For example, the administrator loads a 3rd-party service that uses CreateProcess to launch an arbitrary executable from a folder (say Program Files). Since that administrator can also change the executable in that folder, is it safe to assume that this is also secure?

Or, could this be abused by someone who happens to gain administrator access, but then use the service to launch a custom process as LocalSystem, which could theoretically hide their tracks, or be a risk for some other reason?

The concern is allowing a Windows service we control to be used to execute arbitrary code, even if it is controlled by a local administrator. Or, should all code executed by the service be signed, and known to the service?

  • 1
    This isn't answerable by this forum. It's your policy, and your policy should be dependent on your threat model. Executing arbitrary 3rd party exes as local system isn't great, but if you have other controls in place maybe it's not practically exploitable. – Steve Feb 13 at 23:48
  • Well, that's the question, if it isn't great, why? I want to know what could happen in a worst case scenario, rather than rely on other measures to cover for a weakness here (under the theory that this is a weakness). – g01d Feb 14 at 0:07
  • An admin could commandeer any existing Windows or third-party service configured to run as local system via modifying the ImagePath of the service. I guess they would need to restart the modified service for it to launch the "new" service. So that's worth thinking about. I guess, one thing to check is if the service runs the binary files using a quoted path. Could it run something as system from a directory which doesn't require admin rights to modify - commonexploits.com/unquoted-service-paths – HelpingHand Feb 16 at 16:17

From an authorization perspective, the difference between Administrator and LocalSystem is nearly meaningless. Either one can launch arbitrary programs as the other (although, assuming the process running as LocalSystem doesn't have access to the Administrator's password, it would need to either reset the password or create an unauthenticated Administrator token, and unauthenticated tokens have limits). So, for that purpose, there's absolutely no reason to worry about the Administrator being able to launch arbitrary processes as LocalSystem; that's already possible (with only a little work).

From an auditing / non-repudiation / incident response perspective, well, that depends what events you have the system log capturing and how well the log is protected. If you're worried about an attacker "covering their tracks", the solution is to track, quite closely, what sensitive operations are being performed (and do it to a logging system that even a privileged attacker cannot edit/erase). Create a service? Shows up in the log, with who did it. Start a service? Shows up in the log, with who started it, what file, and who it ran as. Modify an Administrators-only program? Shows who did it (and hopefully you have backups of the old version). Audit logs (and monitoring for active attacks) are very important in sensitive systems, but setting them up is not simple enough for the scope of a single StackExchange question.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.