AXIS OS Vulnerability Scanner User Guide

AXIS OS Vulnerability Scanner
Guide

Introduction

AXIS OS Vulnerability Scanner Guide for Axis edge devices
Vulnerabilities and risks
All software has vulnerabilities that could potentially be exploited. Vulnerabilities will not automatically introduce risk. Risk is defined by the probability of a threat exploiting a vulnerability and the potential negative impact that a successful exploit can do. Reduce any of the two and you reduce the risk. Cybersecurity is about managing risks, and risks are very hard to eliminate. The risk level depends on how a device/software is deployed, operated and managed. Reducing exposure (minimizing the opportunity) is an effective way to mitigate risks. AXIS OS Hardening Guide describes several security controls and recommendations for minimizing risks when deploying, operating and maintaining an Axis device. Some vulnerabilities may be easy to exploit while some may require a high level of sophistication, a special skill set and/or time and determination. A threat requires physical or network access to the device.
Some vulnerabilities require administrator privileges to exploit. The CVSS (Common Vulnerability Scoring System) is a commonly used measure to help determine how easy a vulnerability is to exploit and the potential negative impact. These scores are often based on software in critical systems or software that has high exposure to users and/or the Internet. Axis monitors the CVE (Common Vulnerabilities & Exposure) database which publishes known vulnerabilities in software for the CVE entries that relate to the open-source packages used in Axis devices. Vulnerabilities that Axis identifies as limited risk will be remedied in future firmware releases. Vulnerabilities that Axis identifies as an increased risk will be treated with priority resulting in an unscheduled firmware patch or the publishing of a security advisory informing about the risk and recommendations. Scanning tools reporting false- positives
Scanning tools will typically try to identify known vulnerabilities by examining version numbers of software and packages found in a device. There is always the possibility that a scanning tool will report a false-positive remark, meaning that the device does not actually have the vulnerability. All remarks from such scanning tools need to be analyzed to validate that they in fact apply to the device. You need to make sure that the Axis device has the latest firmware version as it may include patches that address several vulnerabilities.

Scope

This guide is written for and can be applied to, all AXIS OS-based products that are running an AXIS OS LTS or active track firmware. Legacy products running 4.xx and 5.xx firmware are also in scope.
The operating system for Axis edge devices.

Quickstart guide Quickstart guide

It is recommended to perform regular vulnerability assessments of the infrastructure the Axis device is part of as well as of the Axis device itself. These vulnerability assessments are usually performed by network security scanners. The purpose of a vulnerability assessment is to provide a systematic review of potential security vulnerabilities and misconfigurations. We would like to emphasize the following recommendations before scanning the Axis device for vulnerabilities in order to maximize the quality of the scanning report as well as to avoid common mistakes and false positives.

• Make sure that the firmware of the Axis device is up to date with the latest available release, either on the AXIS OS long-term support (LTS) track or the active track. The latest available AXIS OS firmware can be downloaded here.
• The recommendations in AXIS OS Hardening Guide should be applied before scanning to avoid false positives as well as make sure that the Axis device is operated according to Axis cybersecurity recommendations.
• It is recommended to perform a so-called credentialed vulnerability scan where e.g. the security scanner is allowed to log in to the Axis device via HTTP(S) or SSH. A credentialed security scan is more effective since the scan surface is widened significantly.
• We emphasize the importance of conducting the vulnerability scan using well-established partners with a broad knowledge and a dedicated set of Axis-specific scanning plugins on the market, such as Tenable, Rapid7, Qualys, or others.

Most common remarks

Outdated software components
Background Security scanners highlight when a device is running an outdated version of a software component. It may even occur that the security scanner is unable to determine what version is actually running and flags it anyway. The security scanner simply compares the version of the software components running on the Axis device against the latest available version. The security scanner then outputs a list of security vulnerabilities, even without confirmation that the device being tested is really affected as such. This has been observed with the Linux kernel, OpenSSL, Apache, BusyBox, OpenSSH, Curl, and others.
Open-source software components do receive new features, bug fixes, and security patches throughout the course of their development, resulting in a high release cycle. Therefore, it is not uncommon that the Axis device being tested is not running the latest version of a software component. However, Axis is monitoring open-source software components for security vulnerabilities that could potentially be deemed critical by Axis and will publish those accordingly in a security advisory.
Common report terms

• “A vulnerable version of Linux was found to be utilized”
• “According to its banner, the version of Apache running”
• “According to its banner, the version of OpenSSL running…”
• “Server Version Disclosure (Header)…”

Risk and recommendations
From AXIS OS 10.6 and onwards, it’s possible to disable the OpenSSL and Apache header information by disabling the parameter HTTP Server Header Comments in Plain config > System. This may result in vulnerabilities not being detected by security scanners since the package version is not easily identifiable. Axis strongly recommends keeping the device firmware up-to-date and encourages you to perform security audits on your devices.

Apache web server

Background
Axis devices base their web interface and other web-related functionality on the Apache web server. The web server in Axis devices is primarily being used in two scenarios:

• For general purpose machine-to-machine communication between the Axis device and the system it’s connected to, usually, a video management system that is accessing the Axis device via API interfaces such as ONVIF and VAPIX.
• The installer, administrators, and the end user perform (initial) configuration and maintenance tasks.

The Apache web server is a module-based open-source package. These individual modules can contain vulnerabilities. Below is a list of modules that are commonly loaded and used on Axis devices:

core_module (static)| unixd_module (shared)| authn_core_module (shared)| proxy_fcgi_module (shared)| author en- coded_user_file_module (shared)
---|---|---|---|---
so_module (static)| alias_module (shared)| auth core module (shared)| proxy_http_module (shared)| auth access module (shared)
filter_module (static)| rewrite module (shared)| authn file module (shared)| proxy_wstunnel_mod- ule (shared)| trax_module (shared)
brotli_module (static)| cgid_module (shared)| authz user module (shared)| headers module (shared)| iptos_module (shared)
http_module (static)| log_config_module (shared)| authz_owner_module (shared)| http2_module (shared)| axsyslog_module (shared)

Most common remarks

suexec_module (static)| setenvif_module (shared)| auth_digest_module (shared)| systemd_module (shared)| ws_module (shared)
---|---|---|---|---
mime_module (shared)| ssl_module (shared)| auth_basic_module (shared)| authn axisbasic mod-ule  (shared)|
mpm_worker_module (shared)| socache_shmcb_mod- ule (shared)| proxy_module (shared)| authz_axisgroupfile_module (shared)|

A vulnerability that applies to a certain module in Apache needs to be loaded and used by the Axis edge device. Vulnerabilities of modules that are not loaded are not relevant.
Common report terms

• “Apache HTTPD: mod_proxy_ftp use of uninitialized value (CVE-2020-1934)”

Risk and recommendations
Apache vulnerabilities will typically increase the risk for public web services exposed to the Internet targeting public users. The web server in Axis devices should only be used by installers, administrators, and maintainers. It’s not recommended to expose Axis devices to be accessible over the Internet, nor should users have privileges to use a web browser to access a device during daily operations. Additional security controls such as IP Tables, only allowing approved clients to access, and disabling/preventing web browsers from accessing can be applied to further reduce risks.

OpenSSL

Background
Axis devices use OpenSSL as a common security core component to provide security functionality for, e.g., HTTPS, certificate, and encryption use cases. “Outdated OpenSSL version” is a common scanning remark on Axis devices, and new vulnerabilities are discovered frequently in OpenSSL.
Similar to the Apache web server, OpenSSL is a modular-based platform; see below a list of modules that are not utilized by Axis products:

A vulnerability that applies to a certain module in OpenSSL needs to be loaded and used by the Axis edge device. Vulnerabilities of modules that are not loaded are not relevant but may still be flagged by the scanning tool.
Risk and recommendations Vulnerabilities in OpenSSL do not pose any risks if the system is not using services such as HTTPS or 802.1x (TLS), SRTP (RTSPS) or SNMPv3. It is not possible to compromise the device itself as a potential attack would target the TLS connections and traffic. Exploiting OpenSSL vulnerabilities requires access to the network, a high skillset, and a lot of determination.

Self-signed certificate

Background
Axis devices come with a self-signed certificate that is generated automatically upon first boot in order to provide the possibility to access the product via an encrypted HTTPS connection and proceed with the initial setup of the product. Security scanners may highlight the existence of the self-signed certificate as insecure and Axis recommends removing the self- signed certificate from the device and replacing it with a server certificate that is trusted in your organization. The self-signed certificate provides in that sense a confidential and secure mechanism for initial configuration but requires the user to still check the authenticity of the device itself.
Common report terms

• “SSL Certificate Cannot Be Trusted…”
• “SSL Self-Signed Certificat”
• “X.509 Certificate Subject CN Does Not Match the Entity Name…”

Risk and recommendations
Self-signed certificates provide network encryption but do not protect from man-in-the-middle attacks (a rouge service impersonating a legitimate network service). If using services like HTTPS or 802.x it’s recommended to use Certificate Authority (CA) signed certificates. These must be supplied by the system owner using a public or private CA. If not using HTTPS or 802.1x there are no risks, and vulnerabilities in the underlying OpenSSL cannot be used to compromise the Axis device. For Axis devices features Axis Edge Vault, the self-signed certificate was replaced by the IEEE 802.1AR device ID certificate.
RSA key length
Background
As Axis devices come with a pre-loaded self-signed certificate, some devices have a shorter key length for the certificate than the 2048-bits. The certificate is also of a non-standard bit length to ensure most reputable CA’s will reject a signing request of this. Security scanners may highlight this as insecure and it is recommended to replace this certificate before production deployment as it is only intended for initial setup.
Common report terms

• “SSL Certificate Chain Contains RSA Keys Less Than 2048 bits…”
• “Length of RSA modulus in X.509 certificate: 1536 bits (less than 2048 bits)…”

Risk and recommendations
This vulnerability cannot be used to compromise the device. The default self- signed key length of Axis devices is set to 1536 bits in order to reduce the connection latency and time to generate the certificate and key. This key length provides enough protection for administrative tasks such as resetting device account passwords and initial setup of the Axis device. It’s recommended to replace the default certificate with a CA-signed certificate that should be provided by the system owner.
Cipher settings
Background
Throughout regular firmware updates, the list of available ciphers of the Axis device may receive updates without the actual cipher configuration being changed. Changing cipher configuration must be user-initiated, either by performing a factory default of the Axis device or via manual user configuration. From AXIS OS 10.8 and onwards, the list of ciphers is automatically updated when the user initiates a firmware update.
Common report terms

• “Weak Cryptographic Key…”
• “TLS/SSL Server Supports The Use of Static Key Ciphers…”

It is recommended to always use the strongest ciphers for HTTPS encryption when possible.
TLS 1.2 and lower: When using TLS 1.2 or lower you can specify the HTTPS ciphers to be used in Plain Config > HTTPS > Ciphers followed by a restart of the Axis device. Axis recommends selecting all or any of the following strong- considered ciphers (updated September 2021), or doing the desired selection of your own.
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA- AES256-GCMSHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305 :ECDHE-RSA-CHACHA20POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM- SHA384
TLS 1.3: When using TLS 1.3, the HTTPS ciphers parameter in Plain Config has no effect as per default, only strong ciphers according to TLS 1.3 will be selected. The selection cannot be changed by the user and is updated through a firmware update if needed. Currently, the ciphers are (updated September 2021):
TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384Web server remarks

Web server remarks

Boa web server
Background
Axis devices with firmware version 5.65 and lower utilize the Boa web server for the web interface and web-related functionality. The web server in Axis devices is being primarily used in two scenarios:

• For general purpose machine-to-machine communication between the Axis device and the system it is connected to, usually, a video management system that is accessing the Axis device via API interfaces such as ONVIF and VAPIX.
• For configuration and maintenance tasks performed by installers, administrators, and end users.

Similar to the newer Apache web server that is utilized by Axis devices with newer firmware, the Boa web server can be affected by vulnerabilities. Security scanners may not recognize the web server used in older Axis devices and will therefore simply assume that these devices utilize the Apache web server. A vulnerability that applies to the Apache web server does not apply to the Boa web server by default if not stated otherwise.
Common report terms

• “According to its banner, the version of Apache running…”
• “The version of Apache HTTPd installed on the remote host is prior to 2.4.46. It is, therefore, affected by multiple vulnerabilities…”

Apache Struts and Apache Tomcat
Background
As described in the Apache web server on page 4 , Axis devices base their web interface and web-related functionality on the open-source Apache web server. Other flavors of the Apache web server exist, such as Apache Struts or Tomcat, but are not utilized in Axis devices. Axis utilizes the plain open-source Apache web server implementation of the Apache Software Foundation (ASF).
Common report terms

• “A vulnerability has been discovered in Apache Tomcat…”
• “The Jakarta multipart parser in Apache Struts…”

Web user sessions
Background Axis devices base their web interface and other web-related functionality on the Apache web server. The web server in Axis devices is primarily being used in two scenarios:

• For general-purpose machine-to-machine communication between the Axis device and the system, it’s connected to, usually is a video management system that is accessing the Axis device via API interfaces such as ONVIF and VAPIX.
• When the installer, administrators, and the end user perform (initial) configuration and maintenance tasks.

Currently, Axis devices do not support traditional web user-based sessions where it’s possible for the web session to e.g. log out or automatically expire after a certain amount of time of user inactivity while the browser window is open. Every request through the web server on an Axis device has to be authenticated properly in order to be processed before the specific web session is open for further communication. In order to actively close a web session, the browser has to be closed.
Common report terms

• “Concurrent User Sessions…”
• “Insufficient Session Termination and Expiry…”
• “Application Lacks Logout Feature…”

Risk and recommendations
Axis recommends accessing the device through an application, such as a video management system (VMS), as the primary video client instead of using the web browser if this would be the subject of concern. However, if the web browser is the only video client available, have the following guidelines in mind:

• Do not visit untrusted websites or open e-mails from untrusted senders (this is of course a general cyber protection recommendation).
• Use a different browser, which is not the system’s default, to configure the Axis device.
• Create a viewer account on the device and use this when viewing the video stream. The viewer account has minimal privileges and no rights to change the configuration of the Axis device.
• Do not leave the browser open unattended after configuration in order to minimize the attack window.

Firmware remarks

Axis firmware version string
Background
Axis discloses vulnerabilities and provides updated firmware with security fixes so that customers can update and mitigate potential risks. Security scanners usually perform only a limited comparison of the firmware version the Axis product is running against older, outdated firmware that may contain vulnerabilities. A security scanner may not recognize the Axis firmware correctly, causing the scanner to flag the firmware running as vulnerable or insecure. Always consult the release notes for the firmware version of the product being tested since serious or critical vulnerability patches are listed in this document.
It may cause confusion if the Axis device is running a custom firmware version or if the security scanner is not updated with the latest information of available Axis firmware. Below are some examples of Axis firmware version strings:

• 9.70 .1
• 9.70 .1_ beta
•  9.70 .1. 5

Common report terms

• “Axis Multiple Vulnerabilities (ACV-128401)…”

Linux distribution and built-in package manager
Background
Security scanners may support a so-called “credentialed scan” using login data via web login (HTTP) or via maintenance access (SSH) in order to get more information about the device, its operating system and other software that might run on it. The Linux distribution is a Poky (OpenEmbedded) version with both local and upstream patches that may not match or can be recognized as such by the security scanner. Furthermore, the security scanner may expect the usage of a package manager, which is not used in Axis products.
Below is a comparison of the naming scheme between the Axis-used distribution and a standard Linux distribution. Note that the latter may be recognized by the security scanner and pass while the Axis version may not. To illustrate this, we have the Axis-specific 4.9.206-axis and Linux-generic 54.9.206-generic version strings.
Common report terms

• “Local security checks have NOT been enabled because the remote Linux distribution is not supported…”

Unencrypted firmware and chip
Background
Security scanners may highlight the usage of flash chips used in the Axis device and mark them or the filesystems as such with “unencrypted”. Axis devices do encrypt user secrets such as passwords, certificates, keys and other files without necessarily encrypting the filesystem. Removable local storage such as SD cards are encrypted using LUKS encryption.
Common report terms

• “The flash chip that contains the root file system of the device is not encrypted….”
• “Information was extracted from the unencrypted firmware image, including….”

Risk and recommendations
This vulnerability cannot be used to compromise the device. The firmware does not contain any secrets by default and needs no other protection than the firmware signature to validate the integrity. Encrypted software makes it harder for security researchers to identify new (unknown) vulnerabilities, and encrypted software may be used by vendors to hide deliberate flaws (security through obscurity). For Axis devices, root access is required to access the filesystem of the device to gain access to it. Sensitive information such as passwords are stored encrypted on the filesystem and require a high level of sophistication, skillset, time, and determination to extract. Make sure to use a strong root password and keep it protected. Using the same password for multiple cameras simplifies management but increases the risk if one camera’s security being compromised.
Bootloader
Background Security scanners may believe that they have identified the make and model of the bootloader implementation used in Axis devices and could therefore highlight vulnerabilities related to secure boot or the bootloader itself. Axis network video and network audio products utilize an in-house developed bootloader referred to as and boot/netboot.
Common report terms

• “A vulnerability in all versions of the GRUB2 bootloader has been detected…”
• “An issue was discovered in Das U-Boot through 2019.07…”

Network remarks

TCP/ICMP timestamp response
Background
While TCP and ICMP timestamp information is most often used as network tools to measure the performance and availability of hosts, it can also be used to find time-related information about the network device itself. The ICMP timestamp information in ICMP type 13 (timestamp request) and ICMP type 14 (timestamp reply) communication provides information that could be used to calculate the actual device time in UTC. The TCP timestamp information can be used to calculate the so-called round-trip time (RTT) information between two network hosts, which would make it possible to calculate the current uptime of the Axis device.
Security scanners may flag the existence of TCP and ICMP timestamp responses from Axis devices and recommend disabling TCP and ICMP timestamp responses whenever possible. Axis follows the recommendation of the Linux open-source community which does not consider the actual date/time information provided from these responses as a security risk by itself. Therefore the TCP/ICMP timestamp responses are still enabled by default. Furthermore, in newer Linux Kernel versions the actual calculation is considered unreliable as counter- measures ensure to make it unreliable to calculate the date/time information. As of today (February 2022), no known vulnerabilities or exploits have been disclosed that would justify disabling these services in Axis devices.
Common report terms

• “TCP timestamp response found…”
• “ICMP timestamp response found…”

HTTP(S), HSTS policy
Background
Axis devices are configured by default to allow HTTP and HTTPS connections. It is recommended to make use of the first-boot generated self-signed certificate in order to perform the first initial configuration of the Axis device in HTTPS mode and to switch the configuration to only allow for HTTPS connections. HTTPS can be enforced e.g. from the web interface of the Axis device following Settings > System > Security. Furthermore, using HSTS (HTTP Strict Transport Security) to further increase device security is automatically enabled only when the Axis device is operated in HTTPS-only mode. HSTS is supported in the 2018 LTS (8.40), 2020 LTS (9.80) and the AXIS OS 10.1 active track.
Security scanners may highlight that the Axis device being tested is configured to allow HTTP only or HTTP & HTTPS at the same time. The detection is usually performed by validating the response from and checking the port status of the standard HTTP port 80. Axis recommends using the device in HTTPS mode only by configuring this accordingly. Many security scanner audits are performed on Axis devices where this specific HTTPS-only configuration is not enforced by allowing the Axis device to respond to HTTP and/or HTTPS connections.
Common report terms

• “HTTP (Port 80) insecure channel detected…”
• “Web Portal Allows Unencrypted HTTP Connections By Default…”
• “The remote web server is not enforcing HSTS, as defined by RFC 6797…”
• “Insufficient Transport Layer Security…”

Hardware remarks

Architecture vulnerabilities
Background
Certain vulnerabilities may depend on the processor architecture that a device is using. Axis edge devices, such as cameras, encoders, wearables, audio and intercom products, are based on MIPS and ARM architecture and are, e.g., not affected by x64 or x86 architecture-based vulnerabilities.
Common report terms

• “OpenSSL rsaz_512_sqr overflow bug on x86_64 (CVE-2019-1551)…”
• “x64_64 Montgomery squaring procedure…”

UART / Serial console
Background
Physical inspection of the hardware of an Axis device may highlight the existence of a UART (Universal Asynchronous Receiver Transmitter) or serial console. Axis refers to this as a debug port. The debug port is only used for development and debugging purposes during engineering projects. While no sensitive information is exposed while being unauthenticated, the access to the debug port is password restricted and only the root user may login. From AXIS OS 10.11 and onwards, the UART/serial console is disabled by default and can only be enabled after unlocking it via a device-unique custom firmware certificate. This is provided by Axis only and cannot be generated in any other way. Common report terms

• “Information Disclosure via UART/Serial Console…”
• “Root Shell via UART/Serial Console…”
• “On the PCB, the headers exposed a UART console…”

AXIS OS Vulnerability Scanner Guide © Axis Communications AB, 2022
Ver. M3.2 Date: August 2022
Part No.

Documents / Resources

| AXIS OS Vulnerability Scanner [pdf] User Guide
OS Vulnerability Scanner, OS Scanner, Vulnerability Scanner, Scanner
---|---

Read User Manual Online (PDF format)

Read User Manual Online (PDF format)  >>

Download This Manual (PDF format)

Download this manual  >>