Configuring Account Lockout – the baseline settings for account lockout changed since the beta (and since previous baselines). This post explains why and the tradeoffs organizations need to consider to determine the right account lockout policy for them.

Changes in the Security Guidance for Windows 8.1, Server 2012 R2 and IE11 since the beta – This post describes the rest of the changes that were made between the beta and the final.

Version 3.5.0.5 fixes an issue in which IE10 was reported as version "9.10.9200.16614"; it now reports a 10.* version number.  (*)

Version 3.5.0.5 also adds text corresponding to new IE security zone settings, adds back in a set of sample files that capture default settings on various vanilla machines, including a new one for IE10 on Win8 x64.

It also includes an IEZoneAnalyzer.exe.config file.  Keep this file in the same directory with IEZoneAnalyzer.exe if you want to run it on a system that has .NET 4.0 but doesn't have .NET 3.5 installed (such as on Windows 8, which does not have .NET 3.5 by default.)

The updated version is attached to this blog post.

(*)  Explanation for that issue, if you want to know... KB article 969393 explains that the correct version number is now stored in a different registry value from where it had been stored in the past.  A colleague explained to me that the previous value had been kept at a 9.* number for application compatibility reasons:  it turns out there are a lot of installers out there that verify the IE version through the old value and that many of them perform the comparison incorrectly, treating the value as text to be compared alphabetically rather than converting to a numeric format before comparing.

The first session is "Sysinternals Primer: Gems", the latest in the Sysinternals Primer series (*).

In the latest edition of the popular Sysinternals Primer series, join Aaron (Mark Russinovich's co-author of The Windows Sysinternals Administrator's Reference) as he goes mining for gems. Uncover buried tips and tricks to get the most out of popular tools such as Process Explorer and Process Monitor. Discover treasures among the least-known Sysinternals utilities -- tools that you would have been using if you had only known about them sooner. The Sysinternals utilities are vital tools for any computer professional on the Windows platform. Mark Russinovich's popular "Case Of The Unexplained" demonstrates some of their capabilities in advanced troubleshooting scenarios. This complementary tutorial series focuses primarily on the utilities themselves, deep-diving into as many features as time will allow.

By the way, Mark Russinovich and I will be at the TechEd US bookstore from 11:30-noon on Wednesday and Thursday to sign copies of our book, Windows Sysinternals Administrator's Reference.  Mark will also be signing copies of the brand new Windows Internals, 6th Edition, Part 1 and his novel Zero Day.  We'll also have a book signing at TechEd Europe -- date/time to be announced.

The second session I'm delivering is "Defense Against the Dark Ages: Your Old Web Apps Are Trying to Kill You":

The web browser is the primary path that malware uses to get on users' computers. Web browser security (especially Windows Internet Explorer) has improved dramatically in the past few years to defend against evolving threats. However, continuing to build and maintain web apps using old practices defeats many of these improvements and leaves your users' computers more vulnerable than ever. In this session, learn why those formerly accepted (or at least tolerated) practices are surprisingly harmful and now must be updated. Learn ways to update web apps quickly so that you can adopt more secure practices without stopping your business.

For those who have been waiting for the "what do I do now" Part II to my blog post, Enabling “Initialize and script ActiveX controls not marked as safe” in ANY zone can get you hurt, bad, I will talk about and demonstrate an economical but safe solution.  It may be the only time in a decade that anyone at a Microsoft conference has demonstrated how Visual Basic 6 might be your best option. (!!!)

(*) Previous Sysinternals Primer sessions are available online:

• Sysinternals Primer: Process Explorer, Process Monitor, and More
• Sysinternals Primer: Autoruns, Disk2Vhd, ProcDump, BgInfo and AccessChk

In this post, I’ll describe what the setting means and why it has sometimes been set to an insecure state.  I will vividly demonstrate the potential harm, and describe some ways to check whether the setting is enabled in your environment.  In a follow-up post I will describe some ways to update web apps so that they can continue to work with the setting in its default, secure state.

What is “Initialize and script ActiveX controls not marked as safe for scripting”?

In the early days of the World Wide Web, the functionality provided by HTML was very limited. ActiveX provided a means by which the richer UI and capabilities of Windows desktop applications could be incorporated into web pages.

ActiveX is a software re-use technology built on Microsoft’s “Component Object Model” (COM).  For example, ActiveX allows a Word document to embed an Excel spreadsheet and for Excel to expose parts of its user interface through Word when Word opens the outer document.  ActiveX allows any program to incorporate Word’s spell-checker if it is installed.  ActiveX enables “scriptable” interfaces through which the full capabilities of binary components can be exposed to scripting languages such as VBScript and JScript (this is also known as “OLE automation” or simply “Automation”).  And most importantly here, ActiveX is Internet Explorer’s “plug-in” model, allowing IE to load and use custom binary components from within web pages.  Those web pages often interact with ActiveX components through scripting interfaces.

Because ActiveX is a general-purpose code re-use technology and is not designed solely for web page use, not all ActiveX components are appropriate to use from within web pages.  There are limits to what a web site you visit should be able to do on your computer through your browser.  For example, a web site that you visit should not be able to run arbitrary programs on your computer without your consent.  This and other guidelines for evaluating whether an ActiveX is safe for use on a web page are described in Designing Secure ActiveX Controls.

An ActiveX component is assumed not to be safe for use within a web page unless it asserts its safety through one of several available mechanisms (described here*).  The component must assert that it is both safe for initialization and safe for scripting.  “Safe for initialization” basically means that the component won’t violate the user’s security even if initialized with untrusted or malicious data.  “Safe for scripting” means that its scripting interfaces can’t be abused by maliciously-intended script to cause harm to the user.

By default, Internet Explorer will refuse to load an ActiveX component that is not asserted to be safe for scripting and initialization when referenced by a web page hosted on a remote computer; that is, from a site in any IE security zone other than the Local Machine zone.  This can be controlled through a security setting, “Initialize and script ActiveX controls not marked as safe for scripting.”  This setting can be defined separately for each security zone through user settings or mandated through Group Policy.  Beginning in IE7, it is set by default to “Disable” for all zones (except the Local Machine zone in which it is set to “Prompt”).

Microsoft Word provides a good example of an ActiveX component that is not intended to be used from a web page.  While Word’s automation interfaces have many legitimate uses in Office and other desktop applications (e.g., using Visual Basic for Applications (VBA)), those interfaces include the ability to create and delete files, and instantiate and invoke other ActiveX components.  Ultimately, its scripting interfaces allow it to be used to perform almost any action that the user is allowed to perform.  The Windows Script Host interfaces are an even more powerful example of unsafe ActiveX components.  They provide scriptable interfaces to perform registry and file manipulation, and the launching of arbitrary programs and command line options.

(*) Note that the section on “Internet Explorer Security Levels” is about fifteen years old and is a bit out of date. (Here, “a bit” should be read as a polite euphemism for “extremely”.)

Why have developers ever relied on relaxing this setting?

Quite frankly, it was easy and even natural to relax the setting.  Business workflows often require the creation of Microsoft Office documents.  But back when many of these applications were developed, there was only so much that you could do with HTML and script, and Microsoft provided no server-side solutions for generating Office documents.  However, Office applications did (and still) have very rich client-side interfaces that are incredibly easy to use from VBScript or JScript, and even come with a full-featured macro programming environment that makes it even easier to write that script.

On top of that, using ActiveX “not marked as safe” has not always been forbidden.  In Internet Explorer 6 and earlier, the Trusted Sites zone was configured with the “Low” security level template and was almost completely wide open.  In Trusted Sites, the default setting for “Initialize and script…” was set to “Prompt”, not to “Disable”.  When client-side script in a Trusted Sites page invoked an “unsafe” ActiveX, IE displayed the dialog shown below to the user.  If the user clicked “Yes”, the ActiveX would run.

So what do you suppose users did?  Do you think the text in the dialog box made any sense to them, if they bothered to read it at all?  “An ActiveX control on this page might be unsafe to interact with other parts of the page.”  Gosh!  What other parts?  The green banner?  The disclaimer near the bottom?  The company logo?  Asking end users to make security decisions is rarely a good idea, and doing so without providing any useful information is silly.  Users learned to read the question as, “Do you want this web page to work correctly so you can do your job?” and always to click “Yes” – on that and all other such dialogs.  Users also asked, “Can you please get rid of those annoying and time-wasting prompts?” which was easily accomplished by changing the setting from “Prompt” to “Enable”.  Doing so did not degrade security because users were trained always to click Yes anyway.

So what’s wrong with enabling this setting?

There are a significant number of businesses with important web apps that rely on being able to use Word, Excel or other ActiveX components not marked as safe for scripting.  Why not just continue to allow them to work?

The problem is that there is no way to restrict the setting to apply only to “these specific ActiveX components and only for these specific purposes.”  When you enable the setting in a security zone, you allow any and all web sites in that zone to perform any actions on users’ computers that the user would be allowed to perform, silently and without the user’s knowledge or consent.  That means anyone who can control any content – any file – on any web server in that entire zone can easily mount a successful attack on all site visitors’ computers.  The attacker could install spyware (yes, malware can be designed not to require administrative rights), configure programs to run whenever that user logs on, capture and send private information to an external recipient, delete calendar appointments, or modify or delete files.  (If the end user has administrative rights, the computer now belongs entirely to the attacker.)  The attacker can do all this while being nearly impossible to trace.  For example, an attacker could add a few lines of script to an HTML file for a day, infect hundreds or thousands of users, and then restore the original HTML before anyone knew they were infected.  Good luck tracing that back to a root cause.

Show me the demo, then.

Let’s take a look.  Here is a simple HTML file hosted on a web server in the Intranet zone.  There’s nothing much to it, except that it references a separate script file, like most HTML files do these days:

What happens if someone adds just a few unfriendly lines into that script file, or into another script file that the first script file references, or yet another deeply obscured and embedded bit of content in the site?  How much work does it take to create havoc?  Here are a few lines that create ten batch files on the user’s desktop and then launch them along with ten instances of Calculator.  If this script actually runs, it will be noisy and obvious.  (Don’t count on real-life malicious actors being so courteous.)

Let’s browse the site, first with the Intranet zone’s default setting disabling the use of unsafe ActiveX.  As you can see, the result is that nothing particularly bad happens, except that Internet Explorer shows an error icon in status bar (lower left corner).  If we are very curious we can double-click on that error icon to find out a little about what went wrong (see the next graphic).  If we are turbo-nerds we might even understand what “Automation server can’t create object” means.  In any case, no harm.

Now let’s configure the security setting to the insecure “Enable” setting and browse the site again.  The results are markedly different this time.  Attacker-controlled files are being dropped on the desktop, and programs are being launched as the logged on user and can perform any actions the user is allowed to perform.

But we have had the setting enabled for years with no problems!

Well, perhaps you have!  Two questions for you, though: 

1. If the setting had been abused in the past, are you quite certain that you would have known about it?  Are you sure that strange problems that have occurred over the years were not due to abuse of this setting?
2. Given how easy it is to exploit without detection, are you quite certain that if you leave it enabled that it won’t be abused in the future?  In the near future?  By tomorrow?

Given the legitimate concern today about targeted attacks, insider threats, and “Advanced Persistent Threats” (APTs), leaving a door this wide open seems foolhardy.

How can I check whether it is enabled in my environment?

“Initialize and script ActiveX controls not marked as safe for scripting” can be configured separately for each security zone through Group Policy (Computer Configuration or User Configuration), through Machine Preferences or through User Preferences, as described in this post.  That post also describes the precedence rules that determine which of those settings takes effect.  I also recently discovered that when machine preferences are in effect there are separate settings for 32- and 64-bit processes.  So just considering the Intranet and Trusted Sites zones, there are up to ten separate registry locations that could need to be checked.

Under each of these registry keys, the “1” subkey contains settings for the Local Intranet zone and the “2” subkey contains settings for Trusted Sites.  In those subkeys, the registry value named “1201” corresponds to the “Initialize and script…” setting.  A setting of 3 means “Disabled” (preferred); 1 means “Prompt” and 0 means “Enabled.”  You can query these locations using the built-in command line utility reg.exe using this syntax:

reg.exe query "hklm\software\microsoft\windows\currentversion\internet settings\zones\1" /v 1201

If the key or value isn’t present then reg.exe writes an error message to its standard error pipe.  If the setting is found, the result will be reported like this (where “0x3” is the desired result):

HKEY_LOCAL_MACHINE\software\microsoft\windows\currentversion\internet settings\zones\1
    1201    REG_DWORD    0x3

PowerShell provides richer scripting capabilities that allow you to perform more advanced operations on the results without having to first pick out the relevant text from the output.  For example, this simple script searches for the setting in all policy and preference locations for the Intranet, Trusted Sites, Internet and Restricted Sites zones and reports any that have a configured setting different from 3:

'hkcu:\software\policies',
'hklm:\software\policies',
'hkcu:\software',
'hklm:\software',
'hklm:\software\wow6432node' |
%{  $key = $_ + '\microsoft\windows\currentversion\internet settings\zones\'
    1..4 |
    %{ $key + $_ }} | %{
    if (Test-Path $_) {
        $val = (gp $_)."1201"
        if ($val -ne $nul -and $val -ne 3)
        { "Problem:  1201 is set to " + $val + " in key " + $_ }
    }
}

A third and simpler option is to run the IEZoneAnalyzer utility.  Not only can you view and compare settings in a sortable view, IEZoneAnalyzer also determines the effective settings based on precedence order and policy settings.  You can also copy/paste or export results to Excel.  To group all the “not marked as safe” settings together, use the “View/Compare Entire Collections of Settings” feature and sort on the ID or Name column in the resulting view by clicking the column header.

How can I keep it from getting enabled?

You can configure the “not safe for scripting” setting in Computer Configuration or User Configuration.  The setting is in each of the security zone folders under Windows Components | Internet Explorer | Internet Control Panel | Security Page. The Group Policy editor shortens the name of the setting to “Initialize and script ActiveX controls not marked as safe”.  It’s one of those confusing settings where you need to Enable the policy in order to Disable the feature, as shown in the screenshot below.  I strongly recommend that you set it to Enabled:Disable under Computer Configuration for the Intranet, Trusted Sites, Internet and Restricted Sites Zones.  Note that while Group Policy settings are read by programs from the registry, those settings should be configured through Group Policy and not by directly manipulating the registry.

How can I fix the apps that rely on this setting?

This will be the topic of my next post.  Stay tuned!

Forward this link to your management and executives.  If you are a manager or an executive, forward it to your colleagues and friends:

The Deploy Depot Blog

Writing forward-compatible software is really hard. You carefully write your programs strictly according to the current specifications for your target platform, and it works perfectly well on that platform.  But eventually that platform and its specifications will be updated.  It will effectively become a different platform, and you really have no way to know whether the implicit assumptions you had made will still hold.  Some internal implementation detail may have changed that breaks your program, or the rules for the new platform disallow behaviors you had depended upon, such as storing data in a particular location, or expecting that since “foo” was not a language keyword it wouldn’t become one in the next version.

The makers of the Java programming language and Java Runtime Environment (JRE) thought they had it figured out.  Their answer was that different versions of Java could be installed and run side by side, and if your app was known to work with a specific JRE (say, version 1.2.2 Update 14), you could always just specify that version and use it.  If a newer version of the JRE were installed, everything would be fine as long as the version you needed were also still installed.  Your app would simply continue to use the older version.  Write once, test once, run forever.  Forward compatibility guaranteed!  Brilliant!

Naturally, many responsible and conscientious developers continue to leverage this feature to ensure that their code continues to perform as originally tested.  “It was developed, tested and known to work on 1.2.2_14 and so we require that version.”  In particular, I see many custom, internal line of business (LOB) apps at my customers that require a specific, old JRE version.

The Promise Revised

Well, it seemed like a good idea at the time.

Back then, “older version” was not automatically considered to be synonymous with “riddled with easily exploitable security bugs.”  However, many JRE updates are Critical Patch Updates (CPUs) that fix such bugs.  You cannot keep the older version and be protected against exploits.  Why?  Because any web app can specify any vulnerable JRE you happen to have installed and run attack code on your computer. Further, the older JRE families (JRE 1.5/5.0 family and earlier, as well as JInitiator) are no longer supported and so while malware authors can continue to develop attacks for those older versions, the vulnerabilities are not being fixed and just remain exploitable.  Further, Oracle points out that older, unsupported versions may also be vulnerable to newly-discovered flaws found in newer, supported versions:

“Unsupported products, releases and versions are not tested for the presence of vulnerabilities addressed by this Critical Patch Update. However, it is likely that earlier versions of affected releases are also affected by these vulnerabilities. Hence Oracle recommends that customers upgrade their Oracle products to a supported version.”

“Critical Patch Update patches are not provided for product versions that are no longer supported. We recommend that customers upgrade to the latest supported version of Oracle products in order to obtain patches.”

Meanwhile, vulnerable versions of Java have become the most widely attacked software component on Windows computers.  It was about a year ago that the Microsoft Malware Protection Center first reported observing a sudden, large spike in attacks on Java, following a more modest but significant rise reported earlier by Symantec.  The latest Microsoft Security Intelligence Report (v11) confirms that Java remains the top target of malware, with Java exploits “responsible for between one-third and one-half of all exploits observed in each of the four most recent quarters.”

Should you continue to use older versions of Java, or even have them installed on your systems?  Probably not – the risk is obviously high.  Oracle (which acquired Sun Microsystems and Java) specifically recommends that you do not.  Says Oracle:

We highly recommend users remove all older versions of Java from your system.

Keeping old and unsupported versions of Java on your system presents a serious security risk.

A customer recently asked me what the risks would be to standardize on 1.6 Update 17.  (As of this writing, the current public JRE is 1.6 Update 27.)  Here are the JRE updates that have shipped since Update 17, going back to March 2010.  They fix a total of 94 separate vulnerabilities, which are listed on the bottom of each of these pages:

• March 2010, affecting Update 18 and earlier:  https://www.oracle.com/technetwork/topics/security/javacpumar2010-083341.html
• October 2010, affecting Update 21 and earlier:  https://www.oracle.com/technetwork/topics/security/javacpuoct2010-176258.html
• February 2011, affecting Update 23 and earlier:  https://www.oracle.com/technetwork/topics/security/javacpufeb2011-304611.html
• June 2011, affecting Update 25 and earlier:  https://www.oracle.com/technetwork/topics/security/javacpujune2011-313339.html

In addition, only the latest versions of Java work on Windows 7, and versions of JRE 1.6 before Update 24 won’t work with IE9.

So What Do You Do Now?

So what can you do if you are using Java?  First, you should follow Oracle’s recommendation and uninstall all but the latest supported version.  Next, you should remove the requirement from your Java apps tying them to a specific version.  Won’t all those apps break?  That can be determined only through testing, but Oracle says that “the latest available version is always compatible with the older versions,” and goes on to say:

However, some Java applications (or applets) can indicate that they are dependent on a particular version, and may not run if you do not have that version installed. If an application or web page you access requires an older version of Java, you should report this to the provider/developer and request that they update the application to be compatible with all Java versions.

If that compatibility expectation is as reliable as Oracle says, then keeping your JRE patched should be as regular and uneventful as deploying Windows “Patch Tuesday” updates.  Nobody performs comprehensive regression tests of all their applications before deploying Windows patches, because those patches almost never cause an app not to work.

Quite honestly, the alternative is too risky.  Your Java developers should no longer insist that your house be protected with broken locks.