Back to BlogInternet Explorer Groundhog Day Critical Vulnerabilities
Internet Explorer Groundhog Day Critical Vulnerabilities
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 allowlisting 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: