System User

Question: With regards to the SYSTEM account, I'm not certain about how windows handles system account privileges, but it seems like to me that using the non-passworded SYSTEM account could be a security breech. I was told it isn't and I assume you guys wouldn't set the default to something that would have issues, but if someone could enlighten me, I'd appreciate it :)

Answer: SYSTEM is actually an account which has even a higher privilege level than Administrator accounts have. Check the properties/security of the %SystemRoot% folder for example. However you cannot log in to a system using the SYSTEM account. It is mainly for services and background system processes. (Note, however, that an Administrator can start processes/executables which run as the SYSTEM user.)

If anybody is able to attack and take over the process context of an application which runs with SYSTEM privileges, then he actually owns the system with full control. But it's quite hard to do that usually. In general only system services are running with SYSTEM privileges. To run a service with SYSTEM privileges you do not have to enter a password. This is still no security breach since only administrators are allowed to modify/create services. In addition nobody knows the SYSTEM user password (does it have one?) and of course nobody can log in interactively using this account.

So it can become a security breach only in case somebody manages to attack a running WPKG service and manages to insert some code which is then executed with SYSTEM privileges (by buffer overflows or similar). This risk is quite low with WPKG as it allows to delay login (no user interaction possible before the service finishes) and it even allows to exit the service (no WPKG client process with SYSTEM privileges running any more) after the job has been finished. So no attack vector possible here.

However there is a possibility to break security using WPKG. If you do not properly set access rights to the WPKG software share (where XML files and installers are stored) then an attacker might insert his own packages and execute them on the workstations. As wpkg.js runs on the local workstation invoked by WPKG client it inherits SYSTEM privileges as well. Inserting a "dummy" package which is running an FTP server for example instead of an installer will allow an attacker to run that FTP server with SYSTEM privileges on client computers.

The same applies to any other software distribution system. If the attacker manages to insert custom packages to the software server they are executed with at least administrator privileges since this privileges are required to install software.

However usually (as recommended) you should read software packages and XML files only from a read-only share (use WPKG client user/password to connect using a read-only user). Use another user to update XML files and software packages. The password of the read/write update user should be kept secure. This prevents intruders to insert unwanted packages and the system is considered to be secure.

By the way: User names and passwords are stored in a secure locker within Windows by WPKG client, there is no easy way to get to this passwords.

So I hope that clarifies some things.

(Rainer / Copied by landersk)