The SANS Internet Storm Center recently featured a post about the increasingly stubborn fake anti-malware "scareware" that has been remarkably successful at infecting machines and convincing people to purchase the fake software. http://isc.sans.org/diary.html?storyid=7066 Among the comments on that post, others who have encountered this kind of malware questioned what protection measures might be effective. Of course, the common ideas of fingerprinting the malware by filename or checksum came up, as did potential ideas for hardening the operating system in small ways. Unfortunately, this malware has already proven that those measures are not enough. This malware changes too fast for fingerprinting, heuristics are unreliable, and improvements in privilege separation in Windows have been ineffective at blocking this malware. Removal of this malware can be a tedious and time-consuming task. I have used Fedora Live media or host systems to perform manual cleaning, then spent hours repairing the damage. If a system is infected, I recommend wiping and reloading the system (as I recommend with any infection on any operating system), but it is much easier to prevent infection in the first place. So, if traditional methods are ineffective, what do you do? An alternative approach that does work against this and most other malware is application whitelisting. In this post, I will run through a quick-start guide to configuring the application whitelisting that is already available in Windows XP and newer releases. There are also more powerful third-party options, and similar capabilities are available for other operating systems. Application whitelisting is not for everyone, but if you manage a large number of computers that need to be defended, it is definitely worth considering.
Application whitelisting allows an administrator to restrict what programs may run on a computer to a trusted list, instead of a normal configuration where all programs are allowed unless explicitly blocked. This is a highly effective way to block malware and unwanted programs from being installed or used on the system. The configuration outlined below is ideal for office setups where most users run as restricted users and only a few people may have administrative access. When set up on a domain, this can dramatically reduce the threat of malware, but it does take a lot of freedom of choice away from the users and increases the administrative burden. Running as an administrator bypasses the protection of this configuration. Windows XP and later have built-in support for application whitelisting. This support is not as robust as that provided by third-party application whitelisting products, but can still be used effectively. Prior to Windows 7, this feature is available as "Software Restriction Policies". In Windows 7 and later, it is available as "AppLocker".
Software Restriction Policies
Software Restriction Policies is a system policy feature that can be configured through local system policies or through Group Policy. To configure Software Restriction Policies as part of Group Policy:
- Launch gpedit.msc (on servers, use the Group Policy management tools; to edit local policy instead, use secpol.msc)
- Select "Computer Configuration > Windows Settings > Security Settings > Software Restriction Policies"
- In the "Actions" menu, choose "New Software Restriction Policies"
- With "Software Restriction Policies" selected, double-click "Enforcement" in the right pane
- Enforce the policy for "All software files" and "All users except local administrators" and hit "OK"
- Double-click on "Designated File Types"
- Select the "LNK" extension and hit "Delete" - this allows the Start Menu and Desktop shortcuts to work normally
- Hit "OK"
- Under "Additional Rules", you can edit the whitelist with paths, hashes, certificates and Internet zones
- By default, the Windows installation and system folders will be unrestricted, as will "Program Files"
- Select "Security Levels"
- Right-click on "Disallowed" and select "Set as default", then click "Yes" when prompted to confirm the change
With these settings, administrators will continue to be unrestricted, while regular users will only be able to run programs that have been installed under the Windows installation folder (typically "C:\WINDOWS") or under "Program Files". They will be able to launch those programs using shortcuts. Administrators must handle program installation on behalf of the system's users.
Network Shares and Mapped Drives
When adding rules for network shares and mapped drives, you must use the UNC path in the rule. Using the mapped drive letter will not work.
More information on Software Restriction Policies is available from Microsoft TechNet at: http://technet.microsoft.com/en-us/library/bb457006.aspx
Comments from this post were discarded during a website migration.