search menu icon-carat-right cmu-wordmark

CERT Coordination Center

Open Dental uses blank database password by default

Vulnerability Note VU#619767

Original Release Date: 2016-09-06 | Last Revised: 2016-09-13

Overview

Open Dental is medical dental records management software. Open Dental version 16.1, and previous versions, installs with a blank root database (MySQL) password by default.. An attacker with network access to an Open Dental MySQL database could read, modify, or delete data.

This Vulnerability Note initially, and incorrectly, stated that Open Dental used hard coded credentials. The Impact section also implied that in its default configuration, the Open Dental database was available over remote networks such as the internet. An Open Dental database would need to be specifically configured to allow remote network access.

Description

Open Dental provided the following statements.

This vulnerability note by [CERT/CC] that Open Dental hard-codes credentials in its software is factually false. Open Dental feels that it is detrimental to our reputation to state this. In fact, there is indeed a default blank password, but it can be changed, and is not hard-coded. http://www.opendental.com/manual/securitymysql.html .

We recommend that users change it, each customer receives direction with a link to http://www.opendental.com/manual/computernetworksetup.html see the step linking to http://www.opendental.com/manual/securitymysql.html .

NOTE: setting a MySQL password does not mean that a bad actor who has access to the data on your server cannot access the data. If I have a copy of your MySQL database, all I have to do is replace the grant tables and I have access to your database. You must encrypt your database to prevent this http://www.opendental.com/manual/encryption.html , and securing your network is always the first step http://www.opendental.com/manual/securityoverview.html .

Open Dental would like to respond to the revised VU#619767. While it is true that Open Dental does not force clients to use MySQL passwords, it is important to give more context for what would be needed to exploit this. It is not true that an unauthenticated remote attacker can gain access just because an Open Dental user does not have a root password on a database. It would be true if an administrator of the database host network edge router also had added a specific port forwarding rule to forward traffic from a designated port to the database host server on the same port MySQL was set to send traffic from, which is a terrible idea. Users do not need to take action in this case, they need to continue to not intentionally expose Open Dental MySQL databases directly to the internet without our Middle Tier product(http://www.opendental.com/manual/middletier.html). If a bad actor has sufficient access to your network set up a port forwarding rule without you knowing, you are already completely compromised and a MySQL password is not helpful.

Impact

An attacker with network access to an Open Dental MySQL database could read, modify, or delete data. The attacker would most likely need local network access.

Solution

Update MySQL database credentials and enable further protections

Open Dental uses a MySQL database backend. The default blank database credentials can be changed. For instructions see

http://www.opendental.com/manual/mysql.html

For further information on securing Open Dental, see

http://www.opendental.com/manual/computernetworksetup.html

http://www.opendental.com/manual/securitymysql.html

Restrict network access

Use a firewall or similar technology to restrict access to trusted hosts, networks, and services.

Vendor Information

619767
 

Open Dental Affected

Updated:  September 09, 2016

Statement Date:   September 07, 2016

Status

Affected

Vendor Statement

This vulnerability note by [CERT/CC] that Open Dental hard-codes credentials in its software is factually false. Open Dental feels that it is detrimental to our reputation to state this. In fact, there is indeed a default blank password, but it can be changed, and is not hard-coded. http://www.opendental.com/manual/securitymysql.html .

We recommend that users change it, each customer receives direction with a link to http://www.opendental.com/manual/computernetworksetup.html see the step linking to http://www.opendental.com/manual/securitymysql.html .

NOTE: setting a MySQL password does not mean that a bad actor who has access to the data on your server cannot access the data. If I have a copy of your MySQL database, all I have to do is replace the grant tables and I have access to your database. You must encrypt your database to prevent this http://www.opendental.com/manual/encryption.html , and securing your network is always the first step http://www.opendental.com/manual/securityoverview.html .

Open Dental would like to respond to the revised VU#619767. While it is true that Open Dental does not force clients to use MySQL passwords, it is important to give more context for what would be needed to exploit this. It is not true that an unauthenticated remote attacker can gain access just because an Open Dental user does not have a root password on a database. It would be true if an administrator of the database host network edge router also had added a specific port forwarding rule to forward traffic from a designated port to the database host server on the same port MySQL was set to send traffic from, which is a terrible idea. Users do not need to take action in this case, they need to continue to not intentionally expose Open Dental MySQL databases directly to the internet without our Middle Tier product(http://www.opendental.com/manual/middletier.html). If a bad actor has sufficient access to your network set up a port forwarding rule without you knowing, you are already completely compromised and a MySQL password is not helpful.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.


CVSS Metrics

Group Score Vector
Base 8.3 AV:A/AC:L/Au:N/C:C/I:C/A:C
Temporal 7.5 E:F/RL:W/RC:C
Environmental 1.9 CDP:ND/TD:L/CR:ND/IR:ND/AR:ND

References

Acknowledgements

Thanks to Justin Shafer for reporting this vulnerability.

This document was written by Garret Wassermann.

Other Information

CVE IDs: CVE-2016-6531
Date Public: 2016-09-06
Date First Published: 2016-09-06
Date Last Updated: 2016-09-13 08:27 UTC
Document Revision: 55

Sponsored by CISA.