QuicDoc & Office Therapy, a suite of software used in medical billing and documentation produced by DocuTrac, Inc, ships with a number of static accounts which are not disclosed to the end user, and are identical across all installations of the software.
QuicDoc is an Electronic Medical Records software solution which handles all patient information from intake to diagnosis to discharge to billing. It contains confidential information about patients that can include names, addresses, Social Security numbers, prescription information, identifying photographs, therapy notes, intakes notes, and more.
Office Therapy is the billing solution that goes hand in hand with QuicDoc. The purpose of the Office Therapy is to simplify the billing process. It contains confidential information about billing that can contain credit card data, insurance information, bank accounts, billing reports, payment reports, et cetera.
DTISQLInstaller.exe is a required Microsoft SQL Server configuration package, which is downloaded by the DocuTrac Launcher, available at from the vendor. The tested version of DTISQLInstaller.exe was 18.104.22.168.
Both QuicDoc and Office Therapy are typically installed as a single bundle, and are database-driven applications which use a back end Microsoft SQL Server database server as configured by DTISQLInstaller.exe. The typical on-premises installation is one central server and several workstations that connect to this database.
According to the vendor’s website, “DocuTrac’s customers include county and state mental health facilities, addiction clinics, family centers, employee assistance programs, large groups, and other behavioral healthcare facilities and providers.” According to the vendor’s LinkedIn profile, “DocuTrac's customer base is approximately 5,000 plus and growing.”
These issues were discovered by an independent researcher who reported them to Rapid7 for coordinated disclosure.
R7-2018-01.1: Hard-coded Credentials (CVE-2018-5551)
Upon installation of the software, the DTISQLInstaller.exe installation application creates three accounts with significant access to the database. The credentials are:
These accounts are hard-coded in the .NET Framework installer, and were discovered through static analysis, as shown in the figures below.
As shown above, all three accounts are referenced in the installer in the
RunSetup() function in
DTISQLInstaller > DTISQLServerSetup. Additionally, the QDMaster account is also referenced in
DTISQLInstaller > QuicDocDatabaseInstallation > RunSetup().
The end user of the affected product is neither informed of the existence of these accounts, nor able to change these account passwords without impacting the functionality of the application.
R7-2018-01.2: Static Cryptographic Salt (CVE-2018-5552)
The application relies on a static, hard-coded cryptographic salt of
S@l+&pepper for encryption and decryption routines. This salt was discovered in the .NET Framework installer, and was discovered through static analysis, as shown in the figures below.
As shown above, the cryptographic salt is referenced in the installer in the
Crypt() function in
DTISQLInstaller > Crypt.
The end user of the affected product is neither informed of the existence of this salt nor given the opportunity to change the salt to a site-custom value.
R7-2018-01.1 (CVE-2018-5551): Hard-coded Credentials
Because the application relies on network-connected workstations to connect to the backend database, these accounts can be used by attackers to compromise the database of patient information. In addition, since
sa (aka, "SQL Server system administrator") is one of the known accounts, it is likely attackers with SQL database administration knowledge can further compromise the host operating system. For example, a user with knowledge of the
sa credentials typically has access to enable and use the xp_cmdshell stored procedure, can use other stored procedures such as sp_add_job, or leverage other techniques to interact with the host operating system.
R7-2018-01.2 (CVE-2018-5552): Hard-coded Salt
As this was discovered through static analysis of the installer, practical decryption using these values on specific elements in the database has not been performed or confirmed by the researcher or by Rapid7. In other words, it is unknown what encrypted data this salt is applied to.
A vendor-supplied update should ensure that the passwords to these database accounts are randomly and uniquely generated per installation, either as part of initial setup, or as a post-installation step. These passwords, in turn, should be stored in a locally generated configuration file with appropriate file system ACLs.
As for the static cryptographic salt, this too should be generated dynamically per installation, and stored in a locally-controlled configuration file (specifically, not in the database where these cryptographic functions are applied).
In the absence of a vendor supplied update, users of this software should ensure that untrusted users cannot connect to the database of these applications through network ACLs and firewall rules.
- Tue, Jan 9, 2018: Initial contact to the vendor via email
- Mon, Jan 29, 2018: Disclosed to CERT/CC as VRF#18-01-JBPHC / VU#823661
- Wed, Feb 7, 2018: Initial contact the vendor via telephone
- Thu, Feb 8, 2018: Details disclosed to the vendor via email
- Tue, Feb 20, 2018: Disclosed to ICS-CERT
- Wed, Mar 14, 2018: Public Disclosure