And substitute the values with the paths malicious com objects

SYMANTEC ADVANCED THREAT RESEARCH 1

Analysis of the Windows Vista Security Model

introduction, enhancements have been made to virtually all aspects of the Windows security model. These changes should decrease the ease by which the operating system can be compromised.

In this research, Symantec researchers evaluated the security of the Windows Vista February 2006 CTP build. During this research we discovered a number of implementation flaws that continued to allow a full machine compromise to occur. By exploiting these flaws, a low privilege, low integrity level process can bypass User Account Protection, and ultimately execute code at a high privilege, high integrity level.

B.What’s Not Covered

Malicious code that is already running with full LocalSystem privileges is outside of the scope of this paper, since the malicious code has roughly the same capabilities as it had in previous versions of Windows.

A.Introduction

Windows Vista introduces a security feature, User Account Protection (UAP), which is also known as Least-Privilege User Accounts or Limited User Accounts (LUA). User accounts created during a Windows Vista installation are Protected Administrators and are subject to UAP. Protected Administrators are users in the Administrators groups, other than the Built-in Administrator (which is exempt from ever running under a LUA process). This means that when running without restriction, the user is capable of activities such as installing software, writing to HKEY_LOCAL_MACHINE, starting drivers, starting services, etc.

B.Mandatory Integrity Control (MIC)

Mandatory integrity control (referred to here as integrity levels) is a new feature added in Windows Vista. It is controlled by an access control entry (ACE) in the system access control list (SACL) of a securable object (e.g., a file, process, registry key, etc.). Every process will have an integrity level, and child (spawned) processes will inherit the integrity level from the parent process. Integrity levels can be enabled/disabled via the registry key

3.A lower integrity server to impersonate a higher

integrity client using APIs such as ImpersonateNamedPipeClient, as long as the impersonation level of the client allows it.

Directly related to integrity levels is User Interface Privilege Isolation (UIPI), which was added to prevent privilege escalation attacks such as Shatter [6]. If a lower privileged process is able to send window messages (using the SendMessage and PostMessage APIs) to a higher privileged process, the lower privileged process can cause arbitrary code execution in the context of the higher privileged process. To address this, in Vista it is no longer possible for a process of a lower integrity level to send window messages to

SYMANTEC ADVANCED THREAT RESEARCH 3

D.Restricted Process

UAP is synonymous with restricted process. A restricted process is one with a restricted token that has some of the user’s privileges removed and certain SIDs marked as “deny only” (see Appendix B). Restricted processes are setup using the CreateRestrictedToken API.

SeIncreaseWorkingSetPrivilege disabled

SeUndockPrivilege disabled

If a privilege is disabled, it means it is ignored during access checks but can be enabled by the process. If a privilege is removed instead of disabled, as is the case for restricted processes, it cannot be enabled.

Another way in which a process is restricted is with the “Group used for deny only” attribute associated with the Administrators group SID. Normally, a process created by an administrator is granted access to most secured objects, because the Administrators group is explicitly granted access. For a restricted process, the Administrators group SID is set to “Group used for deny only.” This means if the Administrators group is explicitly denied access, the restricted process is also denied access. On the other hand, if the Administrators group is explicitly granted access, this is ignored for restricted processes. Put another way, deny only SIDs match access denied rules but not access granted rules.

87A5-FF6D70BF3E90}

C.Consent Prompts and Admin Brokers

Since Windows Explorer itself runs with a restricted token and medium integrity level, it lacks sufficient privilege to launch the application unrestricted on its own. Instead, it uses a surrogate: the AppInfo Admin Broker service. AppInfo runs as LocalSystem and has more privileges than even a Protected Administrator. Because it is a service, AppInfo runs in Isolated Session 0 (discussed in the next section). The AppInfo Admin Broker service exposes an RPC interface function RunAsAdminProcess. When a process is to be run elevated, Windows Explorer (through the ShellExecute API) uses this RPC interface to request AppInfo launch the application with the user’s full credentials.

IV.SERVICE ISOLATION (“ISOLATED SESSION 0”)

In previous versions of Windows, services and user processes all ran under the same session. With Vista, services run in the “Isolated Session 0” [8]. This means that a normal service cannot show any popup or dialog boxes to the user. If a service tries to generate a popup event or a dialog box to receive user interaction, it will sit forever since the user will not be able to see it. This is true even if the service is configured as interactive (i.e., allowed to interact with the desktop). The interactive session the user logs into is, in fact, a Terminal Server session. Using query.exe, one can see all the interactive sessions. In fact, the Microsoft-sanctioned way to send a message from a service running in the Isolated Session 0 is to use WTSSendMessage which is part of the Windows Terminal Services API.

result in a regression to a Windows XP application compatibility pass rate of 56 percent.”
To work around this, Microsoft has introduced file and registry virtualization to retain applications backwards-compatibility. When lower privileged processes that attempt to modify global locations fail due to lack of permission, the data is instead transparently written to a per-user location (known as virtualization). These per-user locations are checked before global locations. In other words, the per-user location overrides the global location.

B.Registry Virtualization

File virtualization is implemented by the file system filter driver luafv.sys. When running under a LUA process, file write attempts that fail (due to insufficient permission) have their location changed from:
C:\Progra~1 (C:\Program Files)
to:

%UserProfile%\AppData\Local\VirtualStore\C\P

Virtualization for Low Rights Internet Explorer is not done by the file system driver that handles normal file and registry virtualization. Instead this is done by an AppCompat shim DLL located in %WinDir%\AppCompat\iebrshim.dll (IE Broker Shim). A low integrity process cannot even write to the user-specific locations used for LUA file and registry virtualization. That is, a low integrity process cannot even to write %UserProfile%\AppData\Local\VirtualStore used for medium integrity level file virtualization or HKEY_CURRENT_USER\Software\Classes\Virtual used for medium integrity level registry virtualization. This is to prevent low-to-medium privilege escalation attacks, as LUA processes run at the medium integrity level.

Since all files and registry keys have a default integrity level of medium, a low integrity process is only able to write to locations that have been explicitly allowed (by setting the integrity level to low integrity).

SYMANTEC ADVANCED THREAT RESEARCH 6

HKEY_CURRENT_USER\Software\Microsoft\Interne

indows\CurrentVersion\Internet

Settings\5.0\LowCache

nternet Explorer\Toolbar

Most settings are controlled by

Windows Resource Protection (WRP) replaces the System File Protection (SFP) that existed in previous versions of Windows. WRP now protects more than just files, it also

protects registry keys. All signed executable code and drivers in an OS manifest are protected by WRP.

A.Introduction

Windows Vista has unique challenges in trying to prevent privilege escalation attacks compared to the approach taken by UNIX derivatives. This section will focus on the privilege escalation attacks that result from the approach Microsoft has taken with Windows Vista.

SYMANTEC ADVANCED THREAT RESEARCH 7

C.Windows Visa Security Model

Scenario:
A user browses a malicious website using Low Rights Internet Explorer 7. The malicious website then exploits a previously unknown vulnerability, resulting in arbitrary code execution in the context of IExplore.exe (running at the low integrity level). The goal of the malicious code at this stage is to obtain execution on the target and reach medium integrity level.

Internet Explorer is the only process running at low integrity on a default Windows Vista installation. At the low integrity level, Internet Explorer is running below the default integrity level of other services. On the February build, we discovered that a low integrity process that reconnects to the same machine over the network (i.e., loops back) via SMB can again enjoy slightly elevated privileges.

rosoft\Windows\Start
Menu\Programs\Startup\malicious.exe.” This is because a write operation through a file share will use the default integrity level of medium. This share is enabled by default and normally only available to Administrators. Since the attacker is connecting to a local share, no username/password is needed by the malicious code. The primary ways to exploit this vulnerability are to:
1.Place a malicious executable in the Startup folder.

This is the most straightforward attack, but the malicious program will not be run until the user’s next login.

• Find a shared memory section used by a high
integrity process that is writable with medium
integrity level, similar to the technique used in [11].

• Find a configuration file or registry key that is
writable from a medium integrity process and used as input in a high integrity process.

COM objects are frequently represented as DLLs. So when a process wants to load the COM object, it is loaded using rundll32.exe to load the COM object into a surrogate process like svchost.exe or dllhost.exe. If the COM object requires administrative privileges, then CoCreateInstanceAsAdmin is called and the user is prompted for consent. Presumably, the DLL of the COM object can also be overwritten in the same manner as executables can. If so, then the user can also be misled during elevation of COM objects. At the time of publication, this conjecture has not been experimentally verified.

G.From Medium Integrity Level – Method 2

While the attack described in this section was found to exist in the February CTP, it has been fixed as of the public Windows Beta 2 (build 5384). Later Vista builds only refer to HKEY_LOCAL_MACHINE registry keys for COM elevation and ignore entries under HKEY_CURRENT_USER so this exploit path is no longer possible.

H.From Medium Integrity Level – Method 3

In most cases this would not result in any elevation, because high integrity processes are almost never running under LUA, and thus don’t make use of the malicious AppInit_DLLs in the registry VirtualStore. However, uxss.exe, the User Experience Subsystem, is an exception. It is a high integrity process and also has the UI Access Mandatory Level. This is necessary because uxss.exe controls the desktop, so it is responsible for sending window messages to all GUI programs that interact with the desktop. Uxss.exe also needs to run at high integrity in order to send messages to other high integrity processes that may interact with the desktop (such as consent.exe which runs as LocalSystem). Unfortunately, this permits uxss.exe to conduct Shatter attacks against

SYMANTEC ADVANCED THREAT RESEARCH 9

Scenario:
The attack discussed in the previous section was used by malicious.exe to prepare its malicious.dll to be loaded into uxss.exe. Once the user logged off and logged back on, “malicious.dll” was loaded into the address space of uxss.exe, a high integrity but restricted process.

At this stage, Vista is a step away from becoming checkmated and full compromise is trivial. Microsoft ignored its own advice, stated in [12]:
“Applications that use restricted tokens should run the

Since malicious.dll has high integrity, the SetWinEvent and SetWindowsHookEx APIs can be used. These allow a DLL to be launched into all processes interacting with the same desktop. So all malicious.dll has to do is use one of these APIs and wait for a high integrity, unrestricted process to be launched. While an effort was made to reduce the interaction of high privilege services with the user’s desktop (by placing them in an isolated session as discussed previously), it was not possible to eliminate the interaction entirely. Namely, csrss.exe, ctfmon.exe, LogonUI.exe, WinLogon.exe, and consent.exe are all processes running with LocalSystem capabilities within Session 1. So, as soon as one of these processes interacts with the desktop, the module specified in the hModule parameter of SetWinEvent or SetWindowsHookEx will be loaded and its DllMain will be called.

While the attack described in this section was found to exist in the February CTP, it has been fixed as of the public Windows Beta 2 (build 5384). There is no longer an uxss.exe in the latest Vista builds and it was the only process known to be exploitable.

K.Failed Attacks

This section includes attacks that were unsuccessful. In some cases, the attack scenario was thoroughly tested and Windows Vista seems to properly defend against it. Conducting blackbox testing as we did, there always exists the possibility of a false negative – a probe that succeeds with a subtle side-effect we did not notice, may eventually be used to mount a successful attack upon the operating system’s security perimeter. This section will highlight the areas of Windows Vista where attacks were unsuccessful:
Silent installs do not result in any silent elevation. Instead, a silent install runs with the credentials of the user and the install fails if more privileges are later required, without prompting the user.

IconIndex=-173

LocalizedResourceName=@shell32.dll,-12693

Although we discovered several weaknesses in Windows Vista Feburary 2006 build, later builds have corrected the implementations and closed the exploit paths. Windows Vista’s out-of-the-box security is a significant improvement over previous versions of Windows. It is likely that the security community will aggressively probe and seek to undermine Vista’s security improvements once it is released. The author expects several other privilege escalation vulnerabilities to be discovered. There are two areas we can expect to be scrutinized heavily by malicious code authors and Spyware vendors trying to work around the additional security restrictions:

• Ways to acquire medium or high integrity from low integrity. This is of great interest to malicious code authors and Spyware vendors trying to break out of the Low Rights Internet Explorer sandbox.

[1] Microsoft. (2005, September). Developer Best Practices and Guidelines for Applications in a Least Privileged Environment. MSDN [Online].

[2] Online].

APPENDIX A.Protected Administrator, Low Rights Internet Explorer

USER INFORMATION
User Name SID
hpvista\matt S-1-5-21-3571944088-1297126955-1855943037-1000 GROUP INFORMATION

B.Protected Administrator, LUA (Medium Integrity)

USER INFORMATION
User Name SID
hpvista\matt S-1-5-21-3571944088-1297126955-1855943037-1000 GROUP INFORMATION

Privilege Name Description State SeChangeNotifyPrivilege Bypass traverse checking Enabled SeTimeZonePrivilege Change the time zone Disabled SeIncreaseWorkingSetPrivilege Increase a process working set Disabled SeUndockPrivilege Remove computer from docking station Disabled SeShutdownPrivilege Shut down the system Disabled

C.Protected Administrator, Unrestricted (High Integrity)

User Name SID
nt authority\system S-1-5-18

GROUP INFORMATION

Privilege Name Description State SeTcbPrivilege Act as part of the operating system Enabled SeChangeNotifyPrivilege Bypass traverse checking Enabled

E.RunAsAdmin privileged COM Objects

None

F.File Extensions Excluded from Virtualization

H.Added System Calls (between Windows XP SP2 and Windows Vista)

I.Removed System Calls (between Windows XP SP2 and Windows Vista)