Mitigate Stuxnet with Least Privilege and AppLocker

There is a lot of concern about the LNK (shortcut) vulnerability which exists in all current versions of Windows. Basically, viewing a malicious link file or favicon in a web site will cause Windows to execute the malicious code which can be hosted remotely on an SMB network or a WebDAV server on the Internet.The vulnerability is actively being exploited by very sophisticated bad guys and there is no patch available, yet.

So what can be done to mitigate the risk in lieu of a patch?

Microsoft has a “Fixit” solution that involves disabling Windows’ ability to load icons resources on shortcuts. This solution basically makes Windows unusable because all icons in the Start menu and task bar become generic white documents.

The other recommendation is disabling the WebClient service but this breaks integration with Sharepoint and other services based on WebDAV.

I’m not sure why it isn’t being recommended by Microsoft but the AppLocker feature of Windows 7 should provide a robust mitigation without these side-effects.

AppLocker is a policy technology which allows an administrator to define which executables are allowed to run on a computer. The rules can be based on a any combination of trusted paths, file names and cryptographic hashes of files.

Least Privilege

The first step, though is to make sure that your day-to-day account is not an Administrator. UAC is not really a security boundary. If you are an Administrator it is a warning system to be careful but nothing more. If you are a non-administrator it works to elevate your rights to perform administrative tasks. If your account is in the Administrators group, create another account or enable the built-in Administrator account and remove yourself from the Administrators group.

For example, my main system—which is not joined to a domain—has only the Administrator in the Administrators group. (Be sure to create yourself an administrator account before removing your main account from Administrators or you will lock yourself out of your machine.)

Without Administrator-level privileges, most worms—including the Stuxnet worm exploiting the Windows LNK vulnerability—will fail to deliver its payload. That’s because they usually try to install a rootkit which means installing drivers which requires Administrator privileges. If you don’t have those privileges, the OS can’t be compromised.

Trusted Apps with AppLocker

As worms become more sophisticated, they may find ways to do their work without requiring Administrator privilege. Certainly, Administrator privilege isn’t required in order to steal your personal data because your account has access to personal data. This is where AppLocker comes in. AppLocker creates a concept of trusted applications. Only trusted applications are allowed to run. The default ruleset is pretty good. It simply says that normal users can only execute programs in the Windows directory or the Program Files directory. Those directories have permissions set on them so that only Administrators can put files in there. Hence the applications installed there are trusted.

In order to configure AppLocker, you first need to start the “Application Identity” service and set it to start automatically.

Next use the local security policy editor to configure AppLocker. If you are running as a non-admin, the command-line is this:

runas /user:Administrator "mmc secpol.msc"

Or you can search for “Local Security Policy”, right-click and choose Run as Administrator from the menu. (If you are running as a non-admin, you have to provide a password or smart card for the administrator-level account.)

Navigate to Security Settings | Application Control Policies | AppLocker | Executable Rules. Right-click on Create Default Rules. AppLocker will generate the reasonable set of defaults that I described above.

Unfortunately a few useful application don’t install themselves in Program Files. For example, Google Chrome installed itself on a per-user basis in the application data folder structure of each user. I believe the primary reason it does this is to be able to silently update itself on a least-privilege machine. It also makes it possible for users to install in an enterprise environment where users don’t have administrator privileges. With the default AppLocker settings, Chrome will be blocked from running.

If you want to run Chrome, the simplest solution is to trust the Google signing key and allow any applications published by Google to run.

Right-click on Executable Rules. Choose Create New Rule… Click “Next” through all the screens until you get to the screen asking to browse for an executable. For this purpose, any binary signed by Google will do but I’m going to use chrome.exe. For me, chrome.exe lives in

C:\users\breiter\AppData\Local\Google\Chrome\Application\chrome.exe.

After selecting Chrome.exe, slide the selector up to Publisher and click next until you are allowed to choose create.

Now we are trusting Google not to let someone steal their signing certificate and do something bad with it. Chrome runs and so do any other executables signed by Google.

Also, anything installed in C:\Program Files or C:\Program Files (x86) or C:\Windows runs.

Windows won’t let any other executables run.

This should posture completely mitigate the Stuxnet attacks because no untrusted code is ever allowed to run.

Developers

AppLocker creates a problem for developers that want to run as a limited-rights user. They won’t be able to execute and debug binaries that they compile!

This problem should primarily affect people creating directly executable code. Dynamic code (perl, python, ruby, vbscript, powerhsell script, etc.) executed by a trusted interpreter will work as will Java class and jar files because they are executed by java.exe or javaw.exe.

The issue is really directly executable Portable Executable (PE) binaries. It doesn’t matter if they are native or managed binaries. AppLocker won’t let them run.

The solution is straightforward. You have to relax the policy enough so that developers can work. The risk is that developers will execute stuff that they shouldn’t or some malware will leverage the knowledge of the location of the developer sandbox. It’s a risk you have to accept.

Put all of your source code into a directory tree and create a rule in AppLocker to allow any executables in there to run. For example, you could create a Developers security group and a “C:\source\*” directory. Grant Administrators and System “Full Control” and grant Developers “Modify” on C:\Source. In AppLocker grant Developers the right to execute on “C:\Source\*”.

Limitations

Unfortunately the biggest limitation is that AppLocker is only available in Windows 7 Enterprise and Ultimate or any version of Windows Server 2008 R2.

EDIT

Amazon Kindle for PC also installs itself into %localappdata%. Cisco’s WebEx installs itself onto the “all users” application data directory (%allusersprofile%). They need AppLocker publisher exlusions in order to run.