Over at InfoWorld, Roger Grimes has written The one essential truth of computer security, saying much the same thing:

…the risk from reckless end-users unwittingly executing Trojans and installing their own software is so high that all the other intrusion methods and their resulting mitigations are but a small percentage of the overall attacks in the wild.

Back in February, CIO Magazine also promoted the idea, citing a security vendor claim that “The vast majority of critical Microsoft vulnerabilities — 92% of them — could have been mitigated by stripping users of administrative rights”.

With a little research, you can also see for yourself. Take the Top Twenty Malware for June 2009 from Viruslist and look at the infection method of each… nearly all malware relies on the user’s local permissions to infect the machine:

Out of the top ten malware, only one exploits a vulnerability to infect the target machine. The rest require the user to have local admin rights.

From the attacker’s perspective this makes sense. Why bother with tricky exploits when the majority of Windows users already have local admin rights? When the malware executes, it inherits those rights and thus has all it needs to insert code, change the Windows registry, and modify the kernel.

As the Grimes article points out, removing admin rights also prevents users from installing their own software, codecs, and drivers. That’s directly in line with the policy of most organizations, though it does force the organization to get better at responding to user requests for new software and otherwise managing the desktops.

Since writing the article in 2006 I’ve audited or reviewed safeguards at nearly a hundred organizations… private sector, government, military, huge financial and accounting firms, and the majority still run their user desktops with local admin rights.

One large global firm went through the contortions of rolling out Windows Vista to all desktops. But they chose to keep all users as local admins, and also disabled the limited additional protection of Vista’s UAC. Sigh.

Removing local admin rights is extremely unpopular with users. But so is every other security safeguard. Users tolerate firewalls, anti-virus, full disk encryption, network access control, attachment filtering, web site blocklists. Though local admin rights for Windows users has been the norm since the days of DOS and Windows 3.1, is it is really impossible to remove this huge vulnerability without facing a user revolt?

Related posts:

• Free host intrusion prevention for Windows
• CWSandbox: automating malware analysis
• The most important Windows security tool

Like the various Windows OSs themselves, the .NET framework uses cryptographic signatures for libraries and other components to identify unauthorized alteration. However, Microsoft chose to ignore them. From the paper:

…the SN [strong name] mechanism does not check the actual signature of a loaded DLL but just blindly loads a DLL from inside a directory containing the DLL signature string.

So although components in the .NET runtime are cryptographically signed by Microsoft, the signature is ignored. An attacker can insert their own  modified library just by putting it into a directory that has the right name and voila! the malware is completely trusted.

I can guess that Microsoft chose this shortcut to speed up the framework. The .NET framework was created to destroy compete with Java, which is often criticized for taking too long to initialize. By ignoring signatures, .NET apps can start up faster, with the minor disadvantage of not being able to trust anything written in .NET.

Subverting the .NET class libraries is a fantastic vector of attack:

• MS has long been pushing developers to use the .NET framework rather than create native Windows executables. Most corporate in-house apps (often considered the most trustworthy) are now written for .NET.
• The framework is a standard part of Windows 2003 server, Windows Vista and higher.
• Though an optional download for XP, most people have installed it because an application required it.
• Forensic investigators ignore the framework when trying to find how a Windows machine was compromised.
• Anti-virus and other malware scanners may also ignore the framework libraries or cannot scan MSIL / CIL bytecode (but I need to research this)

Microsoft has dismissed this vulnerability as not a concern since an attacker needs to have administrator privileges. Well, since nearly all Windows desktop users run with full administrative rights (and therefore so do all their apps, including email client and web browser), administrator privileges is a given. So why does the Windows OSs bother with any self protection mechanisms at all?

Related posts:

• The most important Windows security tool
• Cleaning up after rootkits
• Free host intrusion prevention for Windows

Well, ZDNet blogger George Ou has tried it and yes, Vista will obey speech audio embedded in a web page!

So, it’s possible for a malicious web site (or any malware) to play voice commands to control a Windows Vista computer. This exploit is more cute than it is actually dangerous… voice recognition barely works even when it’s been trained to understand a specific voice, speakers would have to be turned to a high enough volume for the sound to be picked up by the microphone, etc.

The obvious fix would be for the speech system to screen out audio that the computer itself is playing, but that might be difficult to code. Of course, now that Vista has been released to the general public it’s too late for a large change like that.

Update: Microsoft has now commented on the issue here.

No related posts.

I’ve mentioned application whitelisting before. A couple years ago I researched this for the Canadian military… they were looking for what they initially called a "super anti-virus" to protect their unclassified networks. Management understood that traditional anti-virus is essentially useless since it works as a blacklist, allowing all code to execute unless it happens to appears on the vendor supplied blacklist. AV also has a hard time identifying malware that’s been altered… switch around a few bytes or compress the EXE with a packer and often it will sail right by many AV products. The military wanted something that could protect Windows desktops against unknown malware and targeted attacks, even when the malware was obfuscated.

When the platform being protected is Windows and it has access to the Internet, this is essentially an impossible task. Obviously almost all web sites use some combination of Javascript, Java applets, Flash or other "mobile code". So much for being able to control what code gets executed on the workstation. Worse, fundamental design flaws of Windows allow fun attacks like DLL injection and "shatter" permit any executable from controlling and compromising any other executable running on the desktop.

At first we looked at simple code execution controls. Third party products have been around for years that let you to create a whitelist of EXEs allowed to run. Most use a cryptographic hash to identify the files and detect changes, such as when a virus is attached to the executable. Nowadays Windows XP and higher have a simple built-in EXE whitelist called software restriction policies.

The problem with execution controls is they only make a simple "go/no-go" decision. Once a whitelisted app is running it still inherits all the permissions of the users and so can do anything the user themselves can do. When the app talks to untrusted networks and executes arbitrary code, such as a web browser or email client, that’s just not good enough.

About the time I was explaining and demonstrating this to senior management, a new category of software called host intrusion prevention was emerging (also mentioned previously). These products claimed not only provide the "go/no-go" execution control, but also control what each application could do once running. If the email client was not supposed to write to the registry, HIP products claimed to be able to stop those actions. Essentially, HIP extends the Windows reference monitor so that code doesn’t necessarily gain all the rights of the user that launched them.

So we tested the few intrusion prevention products available at the time, beating on them with various malware and custom-written attacks, including some internal stuff that was way ahead of malware in the wild at the time. The most HIP popular product turned out to be complete snake oil (for one, just renaming an EXE allowed the user to bypass all restrictions). Others weren’t as easy to circumvent but relied on vendor supplied databases of permitted actions.

Now, predefined rules save a lot of work for admin staff. Few people have the knowledge or patience to sit down and discover rules that allow a behemoth like MS Word to function yet still prevent a macro virus from pillaging your network. Vendor-supplied rules eliminate that drudgery for most off-the-shelf software.

The problem was that most HIP products that provided their own rules either didn’t allow you to define define your own at all, or only had a limited ability. For an organization that uses a lot of weird custom code and legacy apps that wasn’t going to work. Another concern was exceptions… what if they had to allow an action that the vendor blocked? The only solution from the vendors was that we had to disable all restrictions on those apps. Again, not good enough.

The other concern was what Marcus discovered with PrevX… vendor databases continue the antivirus-like dependence on continual update subscriptions from the vendor.

Yet another shortcoming in products was that most didn’t protect all the critical areas. For example, desktop firewalls like Sygate had pretty good execution control but only controlled network access. Filesystem, registry, interprocess communications were left completely unrestricted.

In the end we tested around 12 different products. Being government, the process took a ridiculously long time but that was fortunate because the host intrusion market was evolving… second versions of products were a lot more capable that the first.

Eventually we found a product that met all the criteria and survived lab testing well enough. It was quite an ordeal, and few other organizations would go to so much trouble. However, as the use of the custom-written targeted attacks grows I think more commercial organizations will start accepting that hardening the endpoint requires tools like host intrusion prevention, not just antivirus.

Related posts:

• Free antivirus – what’s available now
• Free host intrusion prevention for Windows
• CWSandbox: automating malware analysis

The vulnerability can be used for many evil purposes such as downloading executables, phishing, stealing login credentials. The nasty part is that anyone can attach Javascript to a link to any PDF, even PDF files on other servers, and the Adobe Viewer will happily execute the Javascript as the user. The vulnerability even exists in Adobe Viewer for Linux (not sure about Macintosh). The black hats are going to steal a lot of money using this vulnerability.

One fix is to upgrade the version of PDF Viewer to version 8. However, given the history of Adobe’s PDF viewer I think it’s better to replace it with a viewer not so “feature rich”. The Foxit PDF viewer is not vulnerable to this exploit (though it also has an optional internal Javascript engine) and makes a very good alternative PDF viewer for Windows. A side benefit is the FOxit reader is also much faster.

On my Windows systems I keep both Foxit and Adobe Viewer installed, with the default action for PDF files set to Foxit. That way I can still use Acrobat viewer to open the few PDFs that use special features unique to the Adobe product.

Related posts:

• Disarming Adobe PDF Viewer
• Remote exploit in Adobe Flash player
• Port scanning with Adobe Flash

Windows has always been a nightmare to automate. Unlike Unix and Linux, most Windows programs assume a human is sitting at the console clicking GUI dialog boxes with a mouse. There’s very little you can do from the command line. Admins have gotten around this by installing VNC, PCAnywhere or some other remote GUI tool on each system. That saves trips to the server farm and to each desktop, but each system still needs to be tended to one at a time.

Lack of a standard shell has been another obstacle. Up to now the only standard "shell" for Windows operating systems have been the outrageously primitive cmd.exe and command.com. Microsoft came up with "Windows script host" (wsh) and most admins use VBscript or "JScript" in some way for login scripts but they are limited and enabling WSH leaves systems vulnerable unless you carefully configure Software Restriction Policies. Many organizations have resorted to proprietary scripting utilities like WinBatch, AutoIt or KiXtart which are very capable, but non-standard.

Having a standard scripting language is important. When you hire a Unix admin you can be sure they will be able to automate tasks using bash or similar standard shell. Many have worked with enterprise-wide automation like cfengine. Not so with Windows admins: to many the entire concept of automation is foreign, and those who have done it may have experience with WinBatch but none with VBscript or whatever your organization has wound up using.

Finally Windows has one standard scripting shell provided by the vendor and supported by them. It will be years before PowerShell fully replaces the jungle of DOS, VBscript, JScript and other automation efforts currently in use (assuming it actually does… PowerShell doesn’t seem to provide a way to script the GUI), but at least we can start expecting Windows admins to be able to automate tasks using this shell. Knowledge and experience can now grow around one standard, rather than being scattered across multiple solutions. Too bad MS chose to re-invent the wheel and create yet another language rather than building on proven admin languages like Bash, Perl or Python. But that’s to be expected… MS hardly wants admins to have transferable skills.

PowerShell has been in development for long time… it has been known as "monad" and MSH and was originally intended to be included with the Vista series of operating systems. According to the PowerShell FAQ, none of the various versions of Vista or "Longhorn" server will ship with PowerShell. It is available as a download for those operating systems, as well as for Windows XP and 2003 Server. As a language it looks fairly capable: it provides associative arrays and one type of regular expressions.

On the security side, it appears that Microsoft has learned some things from the debacle of Windows Scripting Host. There are a few additional safeguards with PowerShell (summed in this article about the recent PowerShell malware). Fundamentally MS is still relying on code signing, however, and we all know how well that security model worked for ActiveX.

Related posts:

• U.S. military to standardize Windows hardening
• The most important Windows security tool
• Free host intrusion prevention for Windows