Reset

Using Ethical Hackers to Help Your Company Uncover Vulnerabilities Part 2

November 19, 2018

Using Ethical Hackers to Help Your Company Uncover Vulnerabilities Part 2

Last week, in Part 1 of this blog series, we took a look at a Security magazine article about ethical hackers, examining reasons for hiring an ethical hacker and ways to recruit one. This week, we're delving into the definition of vulnerabilities in general, and in video surveillance in particular.  

What are vulnerabilities?
Vulnerabilities are bugs or flaws in computer code that, when exploited, cause a negative impact to confidentiality, integrity, or availability (according to Mitre). We call this the "CIA triad." Vulnerabilities can be found in both software and firmware and are prevalent in most code. The more lines of code, the more likely there are vulnerabilities.

Vulnerabilities In Video Surveillance
It is important to understand that all devices on a network are computers. This includes IP-based video surveillance equipment and other IoT devices. Yes, your smart light bulbs are actually computers and most IP cameras and NVRs are Linux computers running a web server.

There are five indisputable facts we have to accept:

  1. All computers have vulnerabilities. Every month, your Windows, MacOS, Android, and iOS devices are sent security patches for newly discovered vulnerabilities.
     
  2. All IoT devices are computers: The Internet of Things (IoT) is a term use to reference all of the “things” that we now connect to the Internet, to make our lives easier and more convenient and make us feel more secure. Your smart light bulbs, smart refrigerator, smart thermostat, and anything else that you connect to your network, are actually computers. They have an operating system, network interface, memory, and storage.
     
  3. All IP-based video surveillance equipment are IoT devices: IP cameras and network-connected recording devices are part of the Internet of Things, as they are computers. In fact, the video camera that may be looking at you now is likely a Linux web server.
     
  4. All IP-based video surveillance equipment has vulnerabilities: It doesn’t matter who the manufacturer is, all of these devices have had, and will continue to have, vulnerabilities.
     
  5. Companies should not be judged on how many vulnerabilities they have. If that were the case, we wouldn’t be using any products from Microsoft, Apple, Google, or IBM, as they have some of the highest counts. Rather, companies should be judged on how quickly they fix the vulnerabilities, how they communicate those vulnerabilities and patches to customers and end users, and whether they responsibly disclose information.

The Responsible Disclosure Process
The responsible disclosure process is a generally accepted concept that is followed by most ethical hackers/security researchers and by software developers. While the general steps defined below can differ from company to company, these are the basics at a high level.

  1. Products are created, and despite all of the vulnerability scanning, code analysis, software security scanning and testing, it is arguably impossible to create code that does not contain vulnerabilities.
     
  2. Products are released to the public.
     
  3. Ethical hackers/security researchers decide to test the product. They use advanced tools, experience, and minds that loves to solve puzzles, to find ways to circumvent the security controls that are put in place.
     
  4. When a vulnerability is discovered, the ethical hacker/security researcher contacts only the software developer and reports what was found. They typically announce that the software developer has 90 days to patch or fix the vulnerability, or else the ethical hacker/security researcher will publicly disclose the vulnerability.
     
  5. The developer verifies the vulnerability and works with the researcher to understand and then patch or fix the vulnerability.
     
  6. On a predetermined date, the software developer discloses that there is a vulnerability by creating a CVE in the CVE database and announces that there is a patch to fix it. No details are shared with the public at this time. Typically, the ethical hacker also announces that they were the one who discovered the vulnerability.
     
  7. At this point, end users are given some time, usually 90 days, to patch their systems before the ethical hacker publicly release the details on how to exploit the vulnerability. When this happens, many of the malicious scanners that are constantly looking across the Internet for vulnerable systems, are updated to try and “hack” into unpatched devices.

To verify the above statements, let’s look to the globally accepted, de facto standard for disclosing vulnerabilities: the CVE database. You can access this at https://cve.mitre.org. Once there, just enter in the name of a company that makes software.

The author of the Security magazine article offers a few best practices for engaging hackers, which include:

  • Ethical hackers are a community with a diverse skillset who focus on different types of vulnerabilities, so it’s important to clearly define the type of data you are trying to protect.
     
  • Engage hackers with respect for what they do, and acknowledge them properly if a reported vulnerability is significant. According to the author, hackers want to be “paid for their time – or at least acknowledged for their contribution.”
     
  • Provide a clear line of communication and assign a point person that hackers can reach out to. “As hackers, when we find a vulnerability, we search across the Internet to see which organizations might be affected. I once woke someone up at 3 a.m. to report a vulnerability that could have been a company shutdown event.”

Lastly, the article advises readers to remain in communication with the hacker after the vulnerability is reported. You’ll need to patch it first, then test to ensure it has been fixed, and finally re-engage the hacker to ensure the solution worked.

For companies engaging hackers for the first time, bug bounty platforms can support the process. For more about this and to read the entire article, click here.

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.

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).