Hikvision’s Senior Director of Cybersecurity Covers Details About the Newly Found Log4Shell Vulnerability

January 21, 2022

Hikvision HikWire blog article 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?

  • Versions up to and including 2.0-beta9 to 2.14.0 are vulnerable to CVE-2021-44228 (CVSS 10)
  • Versions up to and including 2.15.0 is vulnerable to CVE-2021-45046 (CVSS 9.0)
  • Versions up to and including 2.16.0 is vulnerable to CVE-2021-45105 (CVSS 7.5)
  • Versions up to and including 2.17.0 are vulnerable to CVE-2021-44832 (CVSS 6.6)

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:

Cybersecurity

IMPORTANT! This model requires non-standard firmware. Do Not Install standard firmware (e.g. v.4.1.xx) on this model. Doing so will permanently damage your system. You must use custom firmware v.4.1.25 from the iDS-9632NXI-I8/16S product page.

View the most updated version of this document here:

https://techsupportca.freshdesk.com/en/support/solutions/articles/17000113531-i-series-nvr-firmware-upgrade-instructions

 

The I-series NVR (such as the DS-7716NI-I4) is one of Hikvision's most popular and feature-rich recorders. As such, many firmware revisions have been introduced over the years to continually ensure the product is compatible with the newest technology available. Due to the many revisions, we recommend that the user closely follows the instructions below in order to reduce the amount of time spent as well as the chance of failure.

 

Database Optimization and Repair

As more affordable IP cameras are introduced over time with greater video resolution and data sizes, more efficient database management also becomes necessary. The introduction of firmware v4.0 brought about a new database architecture in order to be futureproof.

 

After upgrading to v4.X, the recorder database will need to be converted and optimized. If you are experiencing issues where playback is expected but not found, make sure "Database Repair" is performed as indicated in the procedures and scenarios below.

 

Preparing the Upgrade

Before proceeding with upgrade, it is recommended that NVR configuration file is exported from the NVR over the network or on to a local USB drive.

 

Upgrading from v3.4.92 build 170518 or Older

  1. All recorders must reach v3.4.92 before proceeding further. Upgrading from versions before v3.4.92 directly to any version of v4.X will likely cause the recorder to fail.
  2. If the recorder is already at v3.4.92, a full factory default is highly recommended before upgrading to any version of v4.X. There is a high chance of unit failure (requiring RMA) if the unit is not defaulted before upgrade.
  3. After reaching v3.4.92 and performing a full factory default, an upgrade directly to v4.50.00 is acceptable.
  4. After the upgrade is completed and the recorder is reprogrammed, it may be beneficial to perform a Database Repair. For details, refer to the section "Database Optimization and Repair" above.
  5. To verify repair progress, you may refer to the HDD status, or search the recorder log for repair started and stopped entries. Note that while the HDD is repairing, new recordings are still being made, but some existing recordings may not be searchable until repair is complete.
  6. If you continue to observe playback issues after database repair, ensure there are no power, network, or motion detection issues. Should the problem persist, contact technical support.

 

Upgrading from Any v4.X Build to v4.50.00.

  1. Any v4.X build can be upgraded directly to v4.50.00.
  2. Export configuration is highly recommended before performing the upgrade.
  3. If upgrading from any v4.X version that was not v4.22.005, a Database Repair is recommended. Refer to Step 4 and onwards in the previous section.

 

Downgrading

Downgrading is not recommended. Due to new features and parameters constantly being added, downgrading may cause the NVR to factory default itself or require a manual default to operate properly.

View the most updated version of this document here:
K-Series DVR upgrade instruction
The Turbo 4 Hybrid DVR K series has multiple models and across different platform and chipset. It also has similar firmware development of other recording product line; DVR K series has also introduced the GUI4.0 to ensure the series to be compatible to the newest technology available. The new database architecture is also brought into the DVR firmware v4.0 to be future proof and for better recording search experience. 
 


Database Optimization and Repair

As more affordable cameras introduced over time with greater video resolution and data sizes, more efficient database management also becomes necessary. The introduction of firmware v4.0 brought about a new database architecture in order to be futureproof.
After upgrading to v4.X, the recorder database will need to be converted and optimize. If you are experiencing issues, where playback is expected but not found, please make sure to perform "Database Rebuild" as indicated in the procedures and scenarios below.
 


Preparing the Upgrade

Before proceeding with upgrade, it is recommend exporting DVR configuration file from the DVR over the network or on to a local USB drive.

 

Action after firmware upgraded 

1. Upgrade the DVR according to the chart above. 

2. Reconfirming Channel's Recording Schedule 

    - Confirm channel's recording schedule is enable. 

    - Check if the channel is on correct recording schedule.

3. Double Check Storage Setting

    - Make sure all channel are assigned to record on its HDD group when the Storage setting is under Group Mode. 

4. Perform Database Rebuild locally. 

    • Some version above support Database Rebuild via web access - K51 and K72

    • Perform Database Rebuild regardless if system is having any database issue symptom. 

    • Database Rebuild process is average ~30 to 60min per TB. The process may still varies depends recording data.

    • After Database Rebuild - Check log to confirm Database Rebuild has went thru properly. 

    • If Database Rebuild Started and Stopped log has been log only within few minutes. Database rebuild may not has been completed properly. It is strongly recommend performing the Database Rebuild again.

    • To check log > System > Log > Information > Database Rebuild Started and Stopped.

    • If the log option is not available - access system via SSH can also obtain similar result.

5. Recording Data is still missing after database rebuild process. 

If the data has not been recorded or has been overwritten, Database rebuild process is not able retrieve those lost data. Have the system upgraded to the latest available firmware version above to prevent any future data lost is strongly recommended for all application.

 

 

 

 

In light of the global semiconductor shortage, Hikvision has made some hardware changes to the DS-76xxNI-Q1(2)/P NVRs, also known as “Q series.”

 

These changes do not have any effect on the performance, specifications, or the user interface of the NVRs. For the ease of reference, these modified units are known as “C-Version” units. This is clearly indicated on the NVR label and on the box by the serial number.

 

The only difference between the “C-Version” and “non-C-Version” is the firmware. The firmware is not interchangeable:

 

  • The C-Version NVRs must use firmware version v4.31.102 or higher.
  • The non-C-Version (Q series) NVRs must use firmware version v4.30.085 or older.

 

Please do not be alarmed if a “Firmware Mismatch” message pops up on the screen during the firmware upgrade. This simply means that the firmware does not match the NVR’s hardware. Simply download the correct firmware and the upgrade will go through without any issue.

In light of the global semiconductor shortage, Hikvision has made some hardware changes to the Value Express Series NVRs

These changes do not have any effect on the performance and specification of the recorders. For ease of reference, these modified units are known as “C-Version” units. This is clearly indicated on the NVR label and on the box by the serial number.

The only difference between the “C-Version” and “non-C-Version” is the firmware. The firmware is not interchangeable:

  • The C-Version NVRs must use firmware version v4.30.216 or higher.
  • The non-C-Version (Q series) NVRs must use firmware version v3.4.104 or older.

Please do not be alarmed if a “Firmware Mismatch” message pops up on the screen during the firmware upgrade. This simply means that the firmware does not match the NVR’s hardware. Simply download the correct firmware and the upgrade will go through without any issue.

By downloading and using software and other materials available via this website, you agree to be legally bound by HIKVISION General Terms of Use . If you don’t agree to these terms, you may not download or use any of those materials.

If you are agreeing on behalf of your company, you represent and warrant that you have legal authority to bind your company to the General Terms of Use above. Also you represent and warrant that you are of the legal age of majority in the jurisdiction in which you reside (at least 18 years of age in many countries).