Fortinet FortiRecorder Hardcoded Password

Background

In June of 2019 I discovered a vulnerability in Fortinet’s FortiRecorder product which impacts the FortiCam devices that are connected to a FortiRecorder.

The FortiRecorder is a network video recorder product which administers and manages footage from FortiCam devices connected to it.

Version 2.7.0 GA of the FortiRecorder VM is what was initially used to discover this vulnerability, however I have since tested all versions through to v2.7.3, and they are all vulnerable to the same flaw.

I have confirmed that this vulnerability affects the FortiCam FCM-MB40 device, however it is very likely that the majority of other FortiCam models are also affected.

Fortinet has provided a fix for this issue in FortiRecorder v2.7.4.

CVE-2019-6698 has been assigned to refer to this vulnerability.

CVE-2019-6698 - FortiRecorder Hardcoded Password

Summary

Fortinet FortiRecorder Hardcoded Password Vulnerability

1
2
3
4
5
Product: FortiRecorder - All Models
Version: v2.7.3 and prior versions
Vendor: Fortinet
CVE-ID: CVE-2019-6698
CWE-798: Use of Hard-coded Credentials

The FortiRecorder appliance sets a hardcoded administrative password on all FortiCams which join it. This password is identical for all FortiRecorder instances, and for all cameras connected to each FortiRecorder.

Details

Upon joining a FortiCam to a FortiRecorder, the FortiRecorder changes the account passwords for the FortiCam’s web administration interface.

The password set by the FortiRecorder for the fcamOperator administrative account is identical across different FortiCams, and across different FortiRecorder installations.

Because the username and password for the web administration interface on the FCM-MB40 is stored in cleartext on the filesystem, it is trivial for an attacker with access to a FCM-MB40 device to read these credentials, and use them to illegitimately access other FortiCam devices.

The username and password which are set by the FortiRecorder, and stored in plaintext on the FCM-MB40’s filesystem in /etc/appWeb/appweb.pass appear as follows:

1
2
3
$ cat /etc/appWeb/appweb.pass
admin:**************
fcamOperator:1268**********

This file can only be accessed by gaining access to the filesystem of the FortiCam device. I describe some methods of gaining FCM-MB40 filesystem access in this post.

Recommended Remediation

• Securely generated random passwords should be created for each new FortiCam device which joins the FortiRecorder, and all existing cameras should have their passwords replaced with securely generated random passwords.

Recommendations For Users

If you are using a FortiRecorder device, consider the below tips in order harden your devices, and protect your network.

• Keep these devices in a segregated environment with firewall rules preventing them from communicating with the Internet, or other networks in your environment, and preventing other devices on your network from communicating with them. If possible, prevent all devices except the FortiRecorder from communicating with FortiCam devices.
• Ensure the FortiRecorder device and it’s attached cameras are all up to date.

Fix Information

Fortinet has provided a patch for this issue in FortiRecorder v2.7.4, released on August 2nd, 2019.

An account on support.fortinet.com is required to gain access to the patch.

I have yet to confirm how or whether the patch successfully fixes the vulnerability.

Timeline

2019-06-21

• Reached out to Fortinet PSIRT, providing full vulnerability information including intended date of disclosure 45 days from the date, 2019-08-05.

2019-06-25 (+4 days)

• Received acknowledgement of receipt from PSIRT.
• PSIRT asked for more information regarding discovery of the vulnerability.
• I respond with detail describing where I found the plaintext password.

2019-07-05 (+14 days)

• Received a response from PSIRT stating the issue was already known, and had been reported by an internal team, and that it is scheduled to be fixed soon.

2019-07-16 (+25 days)

• Received an email from PSIRT stating that they expect me to wait at least 90-120 days before publicly disclosing the vulnerability.
• I respond with details describing why the 45 day disclosure was chosen, and that I will be publicly disclosing details about this issue on 2019-08-05, the original date which I advised of in the first email.

2019-07-23 (+32 days)

• Received a response from PSIRT stating that the customer risk created by this vulnerability is reduced because FortiRecorder is usually deployed in a closed network environment, though PSIRT still consider the issue to carry a high severity. This message also stated that fixing the vulnerability may not be as simple as I envision because deep consideration and planning would be involved to create an improved solution. Fortinet repeated their request for a 90-120 day disclosure period, stating that if I complied, I would be acknowledged in the PSIRT advisory. PSIRT also asked how I gained access to the filesystem of the device to find the plaintext password file.
• I respond stating that I still believe 45 days is a reasonable time period for a fix to be developed, documented, tested, QA’d and released. I re-iterate that I will be publicly disclosing details of the vulnerability on 2019-08-05, 13 days from the response.
• My response also provides a link to my previous post describing how I gained access to the FortiCam’s filesystem.
• I ask PSIRT whether Fortinet will be assigning a CVE ID for the issue.

2019-07-25 (+34 days)

• Received a response from PSIRT stating that they will be assigning a CVE for the issue. PSIRT also ask for a copy of my disclosure advisory in advance of publication to help coordinate their disclosure.
• I respond stating that I will provide a full copy of my disclosure to PSIRT two business days prior to public release.

2019-07-31 (+40 days)

• Received an update stating that a fix for this issue is planned for release in FortiRecorder v2.7.4.
• I send PSIRT a full copy of my intended disclosure details.
• Fortinet confirm that my disclosure details are acceptable.

2019-08-02 (+42 days)

• Fortinet releases FortiRecorder v2.7.4, which they state fixes the issue.

2019-08-05 (+45 days)

• This post is published.

Closure

Text archive available here, with the first update available here.

Thank you for reading.

XORcat