Log4J Vulnerability¶
Reference |
Severity |
Date |
---|---|---|
CVE-2021-44228 |
10 |
12/12/21 |
CVE-2021-45046 |
9 |
14/12/21 |
CVE-2021-45105 |
7.5 |
18/12/21 |
Last Updated: 18/12/2021 17:38 PM
Overview¶
On Friday 10th December, Apache announced the discovery of a critical vulnerability in the Log4J logging library for Java, which is used by millions of Java applications and other products and services to log error messages. This vulnerability is known as CVE-2021-44228 or as Log4Shell. Log4J is often installed on both Linux and Windows systems either directly, or often as a requirement of another package or system.
Warning
At 10/10 severity, CVE-2021-44228 is comfortably one of the most serious IT vulnerabilities to have been discovered in recent memory.
The severity of the vulnerability is based on the ease with which this can be exploited – for example, a malformed username will be logged and can contain code which triggers the exploit. An attacker who can control log messages or log message parameters, can execute arbitrary code when message lookup substitution is enabled.
On Tuesday 14th December, a second vulnerability was identified, CVE-2021-45046, as the original mitigation was incomplete in certain non-default configurations. In certain conditions, attackers could craft malicious input data using a JNDI Lookup
pattern resulting in a Denial of Service attack.
On Friday 17th December, CVE-2021-45046 had its severity increased from 3.7 to 9.0 as additional exploits were found against the v2.15.0 release that was intended to resolve these issues.
On Saturday 18th December, CVE-2021-45105 was released after a Denial of Service (DOS) attack was found in all v2.xx releases, including the recent v2.16.0 release. Upgrading to v2.17.x is the recommended mitigation action.
National Cyber Security Centre Guidance¶
The National Cyber Security Centre have released detection and enhanced mitigation advice at the following link.
UKFast’s Response¶
UKFast is encouraging all clients to validate whether their own applications and environments use Log4J and to upgrade to the latest version where possible, applying the appropriate mitigations where upgrade isn’t an option. For our part, UKFast is currently working through all our systems to be absolutely sure we are protected.
Our Security experts are running scans to identify attempts to exploit the vulnerability. Our support teams are looking at not only updating those products and services managed by UKFast, but are also looking into the wider scope of affected applications, with a view to better informing our clients the best mitigation methods with systems they manage.
Identification¶
Linux Server Scan¶
Several different methods have been released in identifying vulnerable applications. An easy way to test this is to check whether the JAR/WAR/EAR files on your server contain the vulnerable version of Log4J. This method can produce several false positives as different vendors have different mitigation methods, so it is essential to review the results and the flagged applications with a member of your development team or with the respective vendor to ensure mitigations are put in place. Utilising a tool called log4j2-scan, UKFast has written an easy-to-execute script to scan your server.
Firstly, login to the server via SSH. From here we will now run the script:
bash <(curl -s https://software.ukfast.uk/pub/CVE-2021-44228-Scanner.sh)
The script will then ask, “Would you like this script to try to automatically remove JndiLookup.class to mitigate?”. This will force remove JndiLookup.class from any JAR/WAR/EAR files found with the vulnerable version of Log4J. We would advise entering n
on the first run to confirm the results.
The output will be something similar to this:
Logpresso CVE-2021-44228 Vulnerability Scanner 1.6.2 (2021-12-16)
Scanning directory: /
[*] Found CVE-2021-44228 vulnerability in /usr/share/logstash/vendor/bundle/jruby/2.5.0/gems/logstash-input-tcp-5.2.3-java/vendor/jar-dependencies/org/logstash/inputs/logstash-input-tcp/5.2.3/logstash-input-tcp-5.2.3.jar, log4j 2.9.1
[*] Found CVE-2021-45046 vulnerability in /usr/share/logstash/logstash-core/lib/jars/log4j-core-2.15.0.jar, log4j 2.15.0
Scanned 51572 directories and 297467 files
Found 2 vulnerable files
Found 0 potentially vulnerable files
Found 0 mitigated files
Completed in 9.23 seconds
As seen above, the output of this command will display the vulnerable JAR/WAR/EAR path, and a summary of the scan.
Windows Server Scan¶
Firstly, login to the server via RDP. Once logged in, download the script on Github. When downloading the logpresso executable, please ensure that it is the win64 zip file. Extract the .exe file to your Desktop.
Open Command Prompt as Administrator and cd
to the Desktop.
C:\windows\system32>cd C:\Users\test\Desktop
C:\Users\test\Desktop>
The last stage is to run the executable to scan the server. Please note, the scan runs across the full system directory structure, which may impact performance due to disk IO utilisation.
log4j2-scan.exe --all-drives
The output will be something similar to this:
C:\Users\test\Desktop>log4j2-scan.exe --all-drives
Logpresso CVE-2021-44228 Vulnerability Scanner 1.6.3 (2021-12-16)
Scanning drives: C:\,D:\
Running scan (20s): scanned 41420 directories, 246150 files, last visit: C:\Windows\servicing\LCU\Package_for_RollupFix~31bf3856ad364e35~amd64~~19041.1348.1.7\amd64_microsoft-windows-help-client_31bf3856ad364e35_10.0.19041.1151_none_e0e8a531e34051a9
Running scan (30s): scanned 70477 directories, 338232 files, last visit: C:\Windows\System32\DriverStore\FileRepository\c_barcodescanner.inf_amd64_266a07997c075b30
Running scan (40s): scanned 106185 directories, 411142 files, last visit: C:\Windows\WinSxS\Temp\InFlight\e21ccf73abd5d70114040000203c3005\amd64_microsoft-windows-syncsettings_31bf3856ad364e35_10.0.19041.746_none_696a462e890ee74f\f
Scanned 115116 directories and 436505 files
Found 0 vulnerable files
Found 0 potentially vulnerable files
Found 0 mitigated files
Completed in 42.07 seconds
As seen above, the output of this command will display the vulnerable JAR/WAR/EAR path, and a summary of the scan.
Affected Versions¶
The Apache project have a security page which contains the latest information.
Vulnerable Versions¶
Version |
Notes |
---|---|
Log4J v1.x |
EOL since 2015. Contains multiple vulnerabilities. |
Log4J 2.0-beta9 to 2.14.0 |
Vulnerable - Partial mitigation available for CVE-2021-45046 and CVE-2021-42288 |
Log4J v2.15.0 |
Incomplete mitigation due to CVE-2021-45046, upgrade to v2.16.0 |
Log4J v2.12.2 |
Vulnerable to CVE-2021-45105. Not vulnerable to CVE-2021-45046 or CVE-2021-42288 |
Log4J v2.16.0 |
Vulnerable to CVE-2021-45105. Not vulnerable to CVE-2021-45046 or CVE-2021-42288 |
Patched Versions¶
Version |
Notes |
---|---|
Log4J v2.12.3 |
All CVEs mentioned in this document are mitigated in this version (for Java 7) |
Log4J v2.17.0 |
All CVEs mentioned in this document are mitigated in this version (for Java 8) |
Mitigations¶
The recommended mitigation is to ensure you are using a patched version of Log4j, which is v2.17.0 or above as of writing. This is likely to be outside of your control if you are relying on software from a vendor. In this case, removing the JndiLookup class from the classpath will mitigate CVE-2021-45046 and CVE-2021-42288 fully in older versions of Log4J:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
For mitigation against CVE-2021-45105, see the Apache project security page.
Discredited Mitigation Measures¶
As explained by the Log4J Apache project, the original mitigation methods of setting the system property log4j2.formatMsgNoLookups
or the LOG4J_FORMAT_MSG_NO_LOOKUPS
environment variable have been discredited. Upgrading log4j or removing the JndiLookup class as described above is the only way to protect fully against these vulnerabilities.
Affected Software Information¶
Note
For a more comprehensive, non-exhaustive, list of affected software, please use the following National Cyber Security Centre link.
Please note that UKFast are not responsible for external links, and the inclusion of any external URL should not be interpreted as an endorsement of that site, its content, or any product or service it may provide.
Vendor |
Service |
Impact |
Mitigation |
Links |
---|---|---|---|---|
Apache |
Solr |
Affected 7.4.0 to 7.7.3, 8.0.0 to 8.11.0 |
Upgrade to 8.11.1 or greater |
https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228 |
AWS |
EC2 |
Not Affected |
Amazon Linux 1 & 2 package versions are not affected. |
https://aws.amazon.com/security/security-bulletins/AWS-2021-005/ |
AWS |
WAF/Shield |
Rule set available to improve detection |
Apply AWSManagedRulesKnownBadInputsRuleSet to ACL |
https://aws.amazon.com/security/security-bulletins/AWS-2021-005/ |
AWS |
OpenSearch |
Affected |
AWS are updating all service domains |
https://aws.amazon.com/security/security-bulletins/AWS-2021-005/ |
AWS |
Lambda |
Not Affected |
Does not include log4j in runtimes or containers |
https://aws.amazon.com/security/security-bulletins/AWS-2021-005/ |
AWS |
CloudHSM |
Affected < 3.4.1 |
CloudHSM JCE versions earlier than 3.4.1, you may be impacted and should upgrade to version 3.4.1 or higher |
https://aws.amazon.com/security/security-bulletins/AWS-2021-005/ |
Azure |
Data Lake Store Java |
Affected |
Update to version 2.3.10 |
|
Cisco |
ASDM |
Upgrade services with ASDM. |
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apache-log4j-qRuKNEbd |
|
Cloudflare |
Rule set available to improve detection |
Cloudflare have actioned network changes to block these attacks, and WAF clients can implement use 3 Log4j Header/Body/URL rules |
https://blog.cloudflare.com/cve-2021-44228-log4j-rce-0-day-mitigation/, https://blog.cloudflare.com/how-cloudflare-security-responded-to-log4j2-vulnerability/ |
|
Commvault |
MSSQL/Oracle Agents |
Affected |
UKFast are working on deploying changes to MSSQL/Oracle Agents. These are the only agents affected. |
|
Commvault |
Infrastructure |
Affected |
UKFast have patched all affected infrastructure to mitigate CVE-2021-44228, and are deploying mitigation for CVE-2021-45046. |
|
cPanel |
cPanel |
Affected |
Update for cpanel-dovecot-solr released. Those without auto updates will need to action manually |
https://forums.cpanel.net/threads/log4j-cve-2021-44228-does-it-affect-cpanel.696249/#post-2890493 |
Docker |
Use ‘docker scan’ to identify if vulnerable, use the environmental variable LOG4J_FORMAT_MSG_NO_LOOKUPS in your Dockerfile, or add -Dlog4j.formatMsgNoLookups=true to commands run in your containers. |
|||
Elastic |
Elasticsearch |
Affected |
Elasticsearch versions 5.0.0+ contain a vulnerable version of Log4j - Security Manager mitigates the remote execution attack in versions 6 and 7, but investigations are still ongoing for version 5. |
|
Elastic |
Logstash |
Logstash versions 6.8.x and 7.x up to 7.15.2, when configured to run on JDKs below 8u191 and 11.0.1, allow for remote loading of Java classes. |
The widespread flag -Dlog4j2.formatMsgNoLookups=true does NOT mitigate the vulnerability in Logstash, as Logstash uses Log4j in a way where the flag has no effect. It is therefore necessary to remove the JndiLookup class from the log4j2 core jar, with the following command: zip -q -d <LOGSTASH_HOME>/logstash-core/lib/jars/log4j-core-2.* org/apache/logging/log4j/core/lookup/JndiLookup.class |
|
Elastic |
Kibana |
Not Affected |
||
Fastly |
WAF |
Rule set available to improve detection |
Apply the CVE-2021-44228 Templated Rule. |
https://www.fastly.com/blog/digging-deeper-into-log4shell-0day-rce-exploit-found-in-log4j |
Google Cloud |
Cloud Armor WAF |
Rule set available to improve detection |
Apply the preconfigured cve-canary WAF rule that has been made available |
|
HPE |
https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US&docId=a00120086en_us |
|||
Java |
Java |
Java lower than 6u212, 7u202, 8u192 & 11.0.2 |
Advised to upgrade Java version above the impacted versions |
|
Java |
Log4j |
Affected between 2.0-beta9 to 2.14.1 |
Upgrade to 2.15 to use mitigation |
|
Jenkins |
Jenkins |
Core not Impacted, plugins might be |
Identify if plugins are affected using the groovy script in link |
https://www.jenkins.io/blog/2021/12/10/log4j2-rce-CVE-2021-44228/ |
Microsoft |
https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/ |
|||
New Relic |
Java Agent |
Affected versions < 6.5.1 or 7.4.1 |
Upgrade to 6.5.1 or 7.4.1 |
|
Tomcat |
Version 5 |
Not Affected |
Does not include log4j |
|
Tomcat |
Version 3 |
Not Affected |
Disabled |
|
Unifi |
Affected |
Upgraded to latest candidate fix 6.5.54 see notes for link |
||
Vmware |
vCentre |
UKFast have actioned network changes to reduce risk to the infrastructure of our eCloud Product. Recommended work arounds have been applied to all UKFast Infrastructure and Private Customers. |
||
UKFast |
DDoSX WAF |
Rule set available to improve detection |
UKFast have deployed additional rulesets to mitigate against this attack - All REQUEST_HEADERS have had mitigation rules added. |
https://coreruleset.org/20211213/crs-and-log4j-log4shell-cve-2021-44228/ |
UKFast |
Dedicated WAF |
Rule set available to improve detection |
UKFast have deployed additional rulesets to mitigate against this attack. |