Internet Explorer Groundhog Day Critical Vulnerabilities

Internet Explorer Groundhog Day Critical Vulnerabilities

What Happened

This past Friday night (2020-01-17), Microsoft quietly released a new Internet Explorer (IE) critical vulnerability that was found being exploited in limited cases in the wild, however, no public exploit exists for the vulnerability – https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV200001.  This issue impacts all versions of IE10 and 11 across all versions of Windows, from 7/2008 up to 10/2019.  There is currently no patch for this threat to your IE environment, but there is a mitigation, which may or may not be feasible for your organization, depending on why IE is still used.

The vulnerability is similar to many previous IE issues, a bug in the component that allows ActiveX and other Windows COM objects to integrate into IE, jscript.dll.  If a browser that does not have the mitigation in place visits a site that has an exploit in place for this vulnerability, the attacker could run remote commands and potentially gain access to whatever context the browser is running in, e.g., as the user or administrator on the machine.

What Should I Do & How Do I Fix It

First, determine your internal use of IE and if there’s a reason for it to be used at all.  This workaround is the same as previous workarounds from Microsoft for vulnerabilities related to IE, Blumira expects to see this workaround presented again by Windows in the future again.  If you do not have a legacy use case for using Internet Explorer, you should remove the browser from all Windows machines in your environment – Removing IE Section below. This action alone will significantly improve your security posture across endpoints and servers.

Blumira does recommend applying the mitigation found within the above Security Guidance, however, it’s likely that if you have a legacy need for IE this mitigation will break needed functionality.  If you do have a legacy need for IE, Blumira recommends restricting the sites that IE can go to through whitelisting to ensure that IE is only used within a limited scope – Mitigating IE Section below.  IE should never be used as a main browser, it is not secure and if legacy needs exist they should be limited when/where possible.

As active campaigns are identified using this threat and IPS’ add signatures associated with this CVE, Blumira will be updating blocklists and conditions to ensure appropriate coverage for their customers.

Removing Internet Explorer

When and where possible IE should be removed from hosts, servers and endpoints.  If there is no legacy need for IE, and another browser can be utilized, then IE should not be available for use.  Removing IE is a simple Powershell command that can be deployed out to your environment. As always, Blumira recommends testing this in a limited test group to ensure efficacy and reduce issues as the deployment moves forward.

Disable-WindowsOptionalFeature -FeatureName Internet-Explorer-Optional-amd64 -Online

If on Windows x64 Architecture

Disable-WindowsOptionalFeature -FeatureName Internet-Explorer-Optional-x86 -Online

If on Windows x86 Architecture

Mitigating Internet Explorer

If you must use IE within your environment, it’s important to first test the jscript.dll workarounds found in the advisory – https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV200001#ID0EUGAC.  These workarounds change the permission of the jscript.dll file in an effort to generally remove the ability of the file to be leveraged in a threatening manner.  By default, IE 9-11 use jscript9.dll, which is not impacted by this vulnerability, but certain webpages will trigger jscript.dll as the needed scripting engine.

If these workarounds do not break the legacy sites or needed functionality in IE, then you are safe to proceed using IE with jscript.dll being limited in its access.  If they do break the sites being accessed by IE, then you should move into mitigating Internet Explorer risk by reducing the number of sites it can access to only your limited sites.  Additionally, ensuring you have layers of security in place, by having a robust endpoint solution on these hosts, is essential.

Limiting Internet Explorer Scope

In situations where IE must be used due to legacy needs, Blumira recommends limiting the ability for IE to access sites.  By doing this, you can significantly reduce the scope of risk to your environment, which is inherently increased by retaining IE for browsing.  This change does not limit all browsers, only IE, to ensure that the browser is only used for specific needs rather than general browsing.

We are assuming that you are on IE11 and likely have a newer DC in place, which changes how IE is customized within environments.  Any server with IE10 is EOL and should be replaced ASAP – there is an IEAK for IE10, but, it really should be avoided if possible.

  • Download the Internet Explorer Administration Kit 11 from Microsoft, MSI\en-us\ieak.msi version is likely the one you’re looking for.
    https://www.microsoft.com/en-us/download/details.aspx?id=40903 
  • Install the downloaded iaek.msi onto your DC or related controller server for your internal use.
  • Open the Internet Explorer Customization Wizard 11, step through the initial setup process and leave the default storage location.  
  • You will get to the Platform Selection page, you will need to complete this process for every OS platform separately.
  • Process per Platform:
    • Leave your Target Language as English, if that’s your organization’s primary language, and click Next.
    • Uncheck Full Installation Package and check Configuration-only package, click Next.
    • Click Clear All on the right and then check Security Zones and Content Ratings from the left pane, click Next.
    • Go through the Automatic Version Synchronization process, click the Synchronize button to ensure your local machine has the correct information to push, click Next once synchronization is complete.
    • Under Security Zones and Privacy select Import the current security zones and privacy settings, then click Modify Settings.
      • Set the Home Page to about:blank or the intended allowed site.
      • Click on the Security tab
      • Ensure that the Internet tab is at High for Security Level and enabled protected mode like a Server would have, this will halt any threats against random internet browsing – and be annoying to use.

      • Select the Trusted sites zone, leave at Medium or whatever is required for your legacy applications to function.  Click on the Sites button and add the site(s) required available for access; you can leave the secure site requirement unchecked if necessary.  Click OK and leave the preferences. You can use asterisks as well, e.g., http://*.acme.local for more broad matching.
      • Leave content ratings as is unless you need to modify, then click Next.
    • You have completed customization for this platform; your MSI file that will configure IE is now in C:\builds\<dateofthebuild>\BrndOnly\<platform>\EN-US\IE11-Setup-Branding.msi and exe.  You can deploy this MSI through GPO or similar automation onto the respective platform, which will then configure IE to go into high security mode outside of the trusted sites you have seeded onto it.  
  • You should also validate at this point that you have defined the GPO that does not allow users to modify this setting. The policy value for Computer Configuration -> Administrative Templates -> Windows Components -> Internet Explorer Security Zones: “Do not allow users to change policies” should be enabled.
  • We recommend testing this in a small batch of computers previous to widespread deployment.  There are other methods of going about this, but, this is the best way to maintain your IE11 deployment without heavily impacting the host beyond the purview of IE11, e.g., changing local proxy settings, modifying registry, etc.

As always, if you are a Blumira customer, feel free to reach out to [email protected] with any questions pertaining to threat remediation.