Original posting:
https://xor.cat/2019/08/05/fortinet-fortirecorder-hardcoded-password/
Text archive available here:
https://xor.cat/archive/2019/08/05/fortinet-fortirecorder-hard Original posting:
https://xor.cat/2019/08/05/fortinet-fortirecorder-hardcoded-password/
Text archive available here:
https://xor.cat/archive/2019/08/05/fortinet-fortirecorder-hardcoded-password.txt
## Background
In June of 2019 I discovered a vulnerability in Fortinet's
FortiRecorder[1] 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[2] has been assigned to refer to this vulnerability.
## CVE-2019-6698 - FortiRecorder Hardcoded Password
### Summary
Fortinet FortiRecorder Hardcoded Password Vulnerability
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:
```
$ cat /etc/appWeb/appweb.pass
admin:**************
fcamOperator:12680b17534491
```
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[3].
### 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[4] 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][3] 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
Thank you for reading.
[1]: https://www.fortinet.com/content/dam/fortinet/assets/data-sheets/FortiRecorder.pdf
[2]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6698
[3]: https://xor.cat/2019/06/19/fortinet-forticam-vulns/
[4]: https://support.fortinet.com/
--
XORcat
PGP Key: 0xA528A62C
https://keybase.io/xorcat