Due to the interactive nature and required access to exploit, local privilege escalation vulnerabilities have traditionally been thought to have a minimal impact on the strategies enterprise IT departments incorporate to protect networks when compared to other code execution vulnerabilities.
The mentality is, "If an attacker already has interactive access to one of my machines, it's game over anyway." Recently there has been a steady increase in the use of dumb-terminal technologies which is turning the interactive user into a much more common client and an increasingly potent threat. Combine this with the rise in client-side attacks and the increase in ‘least privilege' environments and it becomes easy to see how the influence of local privilege escalation vulnerabilities is quickly escalating.
Microsoft is aiming to get all logged in users to adopt the principle of least privilege, forcing the vulnerability landscape to adapt in reaction. Add in the ever-increasing amount of file-format zero-days in popular user applications, and the opportunity to run code on a remote system is growing. Keep in mind though, that within the ever-increasing networks that truly utilize the principle of least privilege, the exploit impact of "arbitrary code under the context of the logged in user" caused from client-side vulnerabilities will become less and less. This is where our old friend enters: the local privilege escalation vulnerability.
Typically given little credit, this type of vulnerability allows for an interactively logged in user (either at the physical host or using some remote-desktop type of network application) to elevate their privileges to higher-privileged accounts, typically Administrator or SYSTEM. Local privilege escalation vulnerabilities are not a new concept and have been most commonly discussed with regards to UNIX multi-user environments. In the past, Windows systems were not regarded as legitimate multi-user environments because it was not designed with proper privilege restrictions in mind. Windows systems were traditionally used as stand-alone workstations or servers where the interactive users had to typically have administrator access to accomplish day-to-day tasks. However, with Microsoft's increased least privilege (especially within Vista) focus and the increasing amount of multi-user systems, this threat has re-emerged as a ‘new' important threat to today's Windows networks. This has an especially high impact in environments where anonymous users are allowed to log into terminals or use remote-desktop applications to log into other systems interactively.
For example, say your company has a terminal set up in the main lobby to allow visitors to check their email. This terminal has limited functionality, but does allow the user access to a web browser, which has minimal security, and "oops!" it allows for the download of an executable from an arbitrary site. An attacker then anonymously logs into the host and runs a remote executable file to elevate user privileges to SYSTEM, which then allows for the installation of a backdoor to access the system later from a remote location.
This is not necessarily a new class of attack; most public terminals are thought to be insecure systems used "at your own risk." But, let's look at this from another perspective; what if an attacker were able to piggyback this local privilege escalation vulnerability on a remote vector, such as a file-format vulnerability?
A normal-privileged user in a Windows 2000/XP/Vista environment receives a document (‘resume.doc') from an unknown source, which happens to be a malicious attacker. Because resumes tend to originate from unknown sources, this is not thought to be abnormal and the user opens the untrusted file. The malicious file then uses a Word vulnerability to run arbitrary code under the context of the logged-in user. However, the "arbitrary code" is actually a separate exploit, which launches a separate attack against the local system. The second exploit has elevated the final payload code to SYSTEM level, allowing for full system compromise, including the installation of a rootkit or backdoor.
This scenario definitely alters the interpretation of the ‘local' nature of privilege escalation vulnerabilities.
These threats are not a threat of the future or only used in research-lab proofs of concept; they are actively being discovered and documented by the industry's top security researchers. The threat exists and will become a much more common attack method in the near future, especially when zero-day local privilege escalation vulnerabilities are released publicly and remain unpatched. For instance, the "Windows MessageBox/NtRaiseHardError"has had a public proof of concept exploit for more than two months that affects all supported versions of Windows, including Vista. This vulnerability allows the previously mentioned ‘local' exploit scenario to be accomplished with minimal knowledge. If an attacker fuses this vulnerability with a zero-day vulnerability in Word, attackers can use a multi-phase exploit to take over systems, using publicly disclosed unpatched vulnerability exploits to launch an attack previously described in the ‘remote' exploit scenario.
Mitigation for local privilege escalation vulnerabilities tends to be difficult, especially with the large attacker surface, since this threat can be launched both locally and remotely. Also, for environments where users are able to log in interactively, denying such a privilege would cause a major continuity disruption. More importantly, some of these vulnerabilities are being disclosed publicly as zero-day exploits prior to any patch.
These threat factors place the burden of protection upon the host itself rather than the network, as well as requiring a level of protection that is uncommon in today's security market. For instance, simple memory-protection security solutions may not catch all types of local privilege escalation vulnerabilities since they do not always require a buffer overflow vulnerability to exploit. Also, the increasing zero-day threat makes it increasingly difficult to identify vulnerable hosts, making a vulnerability assessment feature a huge advantage to identify hosts with proper zero-day mitigations in place. Zero-day threats also require a non-signature based solution for malware, making heuristic and emulation anti-virus solutions increasingly more important.
At the time of this writing, we are currently tracking three local privilege escalation vulnerabilities, two of which affect Vista. Attackers are utilizing these zero-day vulnerabilities to launch blended exploits using techniques similar to those described in the exploit scenarios. This exploit trend will continue to increase in the near future, coinciding with the rise in zero-day disclosures as well as increased exploit knowledge as demonstrated in the "Windows MessageBox/NtRaiseHardError"zero-day exploit. The threat is obvious and "local" privilege escalation vulnerabilities should not be quickly dismissed as minor impact bugs.
