GeSWall Server Edition Protects your network from intruders in a gentle way!

Know the Facts - Protect Your Network

There is a great risk running network services as privileged account, e.g. LocalSystem or Administrator. If an intruder breaks in to an unpatched or misconfigured service, he gains sufficient access to conduct various attacks to gain control of the server host, related infrastructure and the entire organization's network.

This threat is widely accepted and recognized. However, most are not aware that nearly the same risk is present for a service configured to run on behalf of non-privileged account such as Network Service, Local Service or a unique user. Please read the facts below to evaluate the threat. Note, that demo exploits are included into Evaluation Kit, which is available as a part of free evaluation of GeSWall Server Edition.

Network Service account context can be easily elevated to LocalSystem.

The Network Service account is used to run critical services which use impersonation for privileged clients, e.g.: Remote Procedure Call (RPC) service. Due to this fact, weakness of Windows impersonation and the nature of the Windows ACL model an intruder can reliably gain administrative privileges from a Network Service context. Considering the ease of this elevation you should consider the Network Service account as equivalent to LocalSystem.

The context of the MS SQL service running as a unique user account can be elevated up to LocalSystem

The MS SQL service provides interfaces used by privileged clients such as Distributed Transaction Coordinator. Due to a weakness of the Windows impersonation model, MS SQL service context of a unique user can be reliably elevated up to LocalSystem. There is little difference between running MS SQL as LocalSystem and an unprivileged account. An intruder who achieves running their code within MS SQL service context, gains the most powerful administrative privileges anyway.

Any service context could be elevated to LocalSystem

The problem with privilege elevation is not limited to Network Service and MS SQL. It is a general threat for any service. Because any service has "Impersonate a client" privilege and this privilege is sufficient to exploit weakness of the impersonation model.

In the Windows 2000 days, we had a number of privilege elevation exploits based on impersonation. The threat led to the separation of "Impersonate a client" privilege. Therefore, in Windows XP and Windows 2003 only LocalSystem, Administrators and Service have this privilege. This has prevented such attacks from regular interactive users, but services are still vulnerable. As many services expose interfaces used by privileged clients, exploiting impersonation is essentially easier with services. That of course implies that an intruder has already successfully attacked a service.

Network Service account has permissions to sniff network traffic

The Windows Raw Socket feature allows network traffic sniffing. This feature requires administrative privileges but is also available in the context of the Network Service account. Therefore, even if an intruder fails to elevate privileges he can sniff all traffic coming though the host's interfaces. Depending on the host role, this can reveal sensitive and confidential information such as passwords, mail messages, documents and so forth.

Windows security based on discretionary Access Control Lists is inadequate for reducing the attack surface and attack damage isolation

The Inability of Windows to control access on a per-process basis is often compensated by running processes on behalf of unique or restricted users. Although this approach may help prevent certain attacks, it is not adequate in general because of four main reasons:

1. Impersonation model weakness allowing privilege elevation
2. The discretionary nature of the ACL's model - the owner of the resource manages who gets an access.
3. The complexity and obscurity of setting ACLs, see Windows Access Control Demystified
4. Not all objects can be controlled by ACLs and, therefore, protected, e.g.: windows messages, tcp/ip networking.

An intruder can conduct attacks without introducing additional executable files.

An intruder can:

1. Integrate whole code into an attack input, e.g. CodeRed did not run any executable file
2. Use code already present on the target, e.g. about 20 lines of VBS script is required to provide a remote shell.

This means all security solutions based on checking code signatures are ineffective at blocking such intrusions.