Protecting Windows RemoteApp Servers
As mentioned previously, many GUI applications running under the RemoteApp feature in Windows Server 2008 or Citrix Application Publishing can be coaxed into running an unintended application for a remote advisory. Although it appears that the user is only running a single application, the server launches a full desktop environment in the background.
It's also easy to do without the proper security in place. For example, although an administrator can hide the address bar and menu bar in IE, an attacker could just as well right click, choose View Source, then File > Open from the Notepad window that appears. Although this can also be blocked, there are other methods waiting in the wings. In fact, I've found at least 10 ways to break out of Internet Explorer alone. The following technique can help prevent these issues.
Software Restriction Policies using GPO
Microsoft introduced restricting the software that can run via GPO in Windows Server 2003. This often ignored feature, when implemented correctly, can restrict users to just the applications they need to run. This is particularly useful on remote terminal servers, where you will probably want to restrict what most users can execute. GPO management has been improved in Server 2008 which makes editing, applying, and verifying proper functioning even easier. By using these Software Restriction Policies, we can prevent users from breaking out of RemoteApps, as you can see in the following image:
A Word About Positive Security
I have been suggesting that positive security models - identifying the good rather than the bad - are much easier and more secure for years now, and this is no exception. It would be very difficult to try to consider every executable that an advisory may try to use and what could go wrong. By changing the default Software Restriction Policy Security Level to Disallowed, only executables that have been defined as permissible for the user will be allowed.
When using this mode, I found a number of executables that will have to be explicitly allowed for a user to successfully connect. The following list is from a lab environment, so you may need to test these:
- C:\Users\*\AppData\Local\Temp\*\getpaths.cmd
- C:\Windows\Application Compatibility Scripts\acregl.exe
- C:\Windows\Application Compatibility Scripts\END.CMD
- C:\Windows\Application Compatibility Scripts\ROOTDRV.CMD
- C:\Windows\Application Compatibility Scripts\SETPATHS.CMD
- C:\Windows\helppane.exe
- C:\Windows\system32\DllHost.exe
- C:\Windows\System32\LogonUI.exe
- C:\Windows\system32\net.exe
- C:\Windows\system32\rdpclip.exe
- C:\Windows\system32\rdpinit.exe
- C:\Windows\system32\rdpshell.exe
- C:\Windows\system32\rundll32.exe
- C:\Windows\system32\sethc.exe
- C:\Windows\system32\subst.exe
- C:\Windows\system32\TSTheme.exe
- C:\Windows\system32\userinit.exe
- C:\Windows\system32\USRLOGON.CMD
- C:\Windows\system32\verclsid.exe
- C:\Windows\system32\wbem\wmiprvse.exe
- C:\Windows\system32\wermgr.exe
Add to that list your applications that you would like the user to execute.
Other Necessary Steps
There are couple other things you may need to do for a usable Software Restriction Policy. First, you'll probably want the Software Restriction Policy GPO to apply to the users only when they are logged into the terminal servers (so they can run their usual software from their assigned PCs). You can do that using GPO loopback processing. Usually GPO settings are applied at the machine first, then the user account. Enabling loopback processing essentially reverses this process, so that the machine settings (in this case, the Terminal Servers) override the user's GPO, as you can see in this screenshot:
Second, you should consider setting permissions on the GPO object, especially with loopback processing enabled. Otherwise the SRP GPO will apply to everyone who logs into the server, including Administrators logging in on the console! Restricting access to reading the GPO can also allow you to separate groups of users - useful if you want different sets of users to have access to different applications.
Third, keep in mind that these policies will prevent application execution. It does not prevent other types of issues, such as data disclosure due to browsing data on the server that you don't intend. Don't forget that you'll need proper NTFS DACLs in place to prevent users from browsing the server's drives.
Used in conjunction with other security mechanisms for defense in depth, Software Restriction Policy GPOs can help keep RemoteApp (and Citrix Application Presentation) users under control. They also have applications that go far beyond protecting Terminal Servers, but that's an article for another time.
Comments
2 comments postedChester Wisniewski has mentioned that it is possible to use SRP to mitigate and prevent the Stuxnet trojan from executing. I have spent countless hours working on this, and have not been able to reproduce Chester's results.
Can someone elaborate how SRP can be used to prevent the shortcut icon vulnerability from executing?
I'd suggest reading Didier Stevens' blog post on "Mitigating .LNK Exploitation With SRP". Basically, he creates a software restriction policy that sets the C: drive to be unrestricted, and then by defaults blocks all other execution.
His method probably wouldn't help against some infection vectors - namely embedded execution from office documents or from within ZIP files.
Also, this could have unintended consequences in complex environments (such as domain environments) where you may need to execute code from network shares, for example. Just make sure you test thoroughly.
Best of luck,
Christopher