Lucene search

K
packetstormXORcatPACKETSTORM:153977
HistoryAug 07, 2019 - 12:00 a.m.

Fortinet FortiRecorder 2.7.3 Hardcoded Password

2019-08-0700:00:00
XORcat
packetstormsecurity.com
195

0.002 Low

EPSS

Percentile

60.7%

`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  
`

0.002 Low

EPSS

Percentile

60.7%

Related for PACKETSTORM:153977