lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: Mon, 5 Aug 2019 00:01:01 +1000
From: Aaron Blair via Fulldisclosure <fulldisclosure@...lists.org>
To: fulldisclosure@...lists.org
Subject: [FD] Fortinet FortiRecorder Hardcoded Password

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

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)


_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists