Fortinet FortiRecorder 2.7.3 Hardcoded Password

2019.08.08
Credit: XORcat
Risk: Medium
Local: No
Remote: Yes
CWE: CWE-798


CVSS Base Score: 7.5/10
Impact Subscore: 6.4/10
Exploitability Subscore: 10/10
Exploit range: Remote
Attack complexity: Low
Authentication: No required
Confidentiality impact: Partial
Integrity impact: Partial
Availability impact: Partial

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


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2024, cxsecurity.com

 

Back to Top