Hikvision’s Senior Director of Cybersecurity Covers Details About the Newly Found Log4Shell Vulnerability
This is part of Hikvision’s cybersecurity blog series, designed to help you stay abreast of the latest trends and critical information to keep your networks and security systems safe. In today’s blog, Hikvision’s Senior Director of Cybersecurity, Chuck Davis, covers details about the newly discovered Log4Shell vulnerability and what you need to know about it.
INTRODUCTION TO LOG4SHELL
Log4Shell is the December 2021 critical zero-day remote-code execution vulnerability, and subsequent vulnerabilities in the popular Log4j software library that is developed and maintained by the Apache Software Foundation. Apache has patched these vulnerabilities in version 2.17.1, however, vendors who use this library will need to patch their affected systems. Amit Yoran, CEO of the cybersecurity firm Tenable, called it “the single biggest, most critical vulnerability of the last decade” – and possibly the biggest in the history of modern computing. In addition to the remote-code execution capabilities of this vulnerability, one of the reasons this is so critical, is that Log4j is being used in systems all over the Internet that will not be updated automatically.
According to Matthew Prince, the CEO of cybersecurity company, Cloudflare, the earliest evidence of exploitation was on December 1, 2021, which was 9 days before the vulnerability was publicly disclosed. Since the disclosure, the flaw is being widely exploited in the wild.
WHICH VERSIONS OF LOG4J ARE VULNERABLE?
Version 2.15.0 was released to patch the vulnerability but according to the Apache Software Foundation, “…the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations” so they issued CVE-2021-45046 and released version 2.16.0.
Version 2.16.0 was originally rated as low severity CVSS 3.7, but this has been changed to a critical severity 9.0 score when it was shown that an attacker could abuse the vulnerability and execute code remotely.
Version 2.17.0 was released on Friday, December 18th to patch a vulnerability in all previous versions of Log4j 2, which “…did not protect from uncontrolled recursion from self-referral lookups.” according to Apache.
Version 2.17.1 was released to patch a remote code execution vulnerability in all versions prior to and including 2.17.0. However, as of this moment, an attacker would need permission to modify the logging configuration file, so install this patch when you can.
NOTE: If you are running any version up to and including 2.16.0, upgrade to at least version 2.17.0 of Log4j as soon as possible. Since you will be upgrading, you should probably just move right on to 2.17.1.
As of the writing of this blog, there is no evidence that version 1 of Log4j is vulnerable to these CVEs, but running old, outdated software is not recommended. If you are using version 1, you should consider upgrading to at least version 2.17.0 of Log4j.
This is the type of vulnerability that will take months or years to effectively mitigate across the Internet. To stay informed and follow the latest developments, you can refer to the CISA Log4j Guide, or review the additional references at the end of this blog.
If you are testing systems to see if they are vulnerable, Huntress Labs created a Log4Shell vulnerability testing page. This won’t execute code, but still be sure you have permission to test your target system.
CALL FOR SBOM
The past month has been very busy for IT Security and IT teams around the world. Part of the problem with responding quickly is that most organizations have a poor inventory of the systems and software that exist in their enterprise. Even organizations who are good at keeping inventory will likely struggle to manage this vulnerability because so many of the products and services that we use are made up of a combination of open source and proprietary software, but vendors tend not to reveal the code that they use. If vendors were required to share a Software Bill of Materials (SBOM), then organizations would be able to take a quick inventory of the software that runs in, and supports, their enterprise, and make quick risk assessments to determine what is vulnerable and how to mitigate the risks.
While SBOMs are not widely available and used today, there are efforts to move in this direction. Earlier this year, President Biden signed an executive order that called for the U.S. government to publish the minimum elements for an SBOM. You can learn more about this effort from the National Telecommunications and Information Administration’s (NTIA) SBOM site.
Stay tuned on our website, as Hikvision will soon be releasing a white paper about the critical nature of SBOM.
Sign up for our HikWire Blog to stay apprised of current information about Log4Shell and other cybersecurity trends.
REFERENCES:
Subscribe to newsletter
Subscribe to our email newsletter to get the latest, trending content from Hikvision
Hikvision.com uses strictly necessary cookies and related technologies to enable the website to function. With your consent, we would also like to use cookies to observe and analyse traffic levels and other metrics / show you targeted advertising / show you advertising on the basis of your location / tailor our website's content. For more information on cookie practices please refer to our cookie policy.
Product Selector
Core Technologies
Legacy Products
Hikvision License Activation
Hikvision App Store
