Jürgen Fälchle - stock.adobe.c

DocuTrac medical software is a breach risk, warns Rapid7

Security researchers have issued a security warning about medical billing and documentation software they say puts patients at risk of data breach

The QuicDoc & Office Therapy suite of software produced by DocuTrac contains security vulnerabilities that could allow attackers to gain control of patient data, warns security firm Rapid7.

The software is used in settings such as mental health facilities, addiction clinics and family centres to track patient records and billing, and is installed at more than 5,000 sites, according to DocuTrac.

This means successful exploitation of the security vulnerabilities could expose sensitive patient information, including social security numbers, medication, therapy notes, credit card data and banking details.

According to Rapid7, the software contains a number of static accounts that are not disclosed to the end-user, and are identical across all installations of the medical records software.

Both QuicDoc and Office Therapy are typically installed as a single bundle, and are database-driven applications that use a back-end Microsoft SQL Server database server as configured by DTISQLInstaller.exe, which is downloaded by the DocuTrac Launcher from the software supplier.

The typical on-premise installation is one central server and several workstations that connect to this database.

Two security vulnerabilities were discovered by an independent researcher, who reported them to Rapid7 for co-ordinated disclosure.

The first vulnerability (CVE-2018-5551) relates to hard-coded credentials and the second (CVE-2018-5552) relates to a static, hard-coded cryptographic salt, which should be a random string of data used to modify a password hash.

The researchers found that the DTISQLInstaller.exe installation application creates three accounts with significant access to the database that are hard-coded in the .NET Framework installer, and were discovered through static analysis.

“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,” wrote Tod Beardsley, research director at Rapid7, in a blog post.

“CVE-2018-5551 is an instance of the Common Weaknesses Enumeration list’s CWE-798, Use of Hard-Coded Credentials. The CVSSv3 score for this vulnerability is Critical, at 9.0,” he wrote.

Read more about vulnerability disclosure

Researchers found that 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. However, the researchers have not determined what encrypted data the salt is applied to.

“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,” said Beardsley.

“CVE-2018-5552 is an instance of the Common Weaknesses Enumeration list’s CWE-760, Use of a One-Way Hash with a Predictable Salt. The CVSSv3 score for this vulnerability is 2.9.”

Because the application relies on network-connected workstations to connect to the back-end database, these accounts can be used by attackers to compromise the database of patient information, said Beardsley.

And because one of the accounts is SQL Server system administrator, he said it is likely attackers with SQL database administration knowledge can further compromise the host operating system.

To fix the vulnerabilities, Beardsley said a software update should ensure that the passwords to the database accounts are randomly and uniquely generated for each installation, either as part of the 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 access control lists,” he said.

As for the static cryptographic salt, Beardsley said this should also be generated dynamically for each installation, and stored in a locally-controlled configuration file rather than 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,” he said.

No software update

Although DocuTrac was alerted to the vulnerabilities on 9 January 2018 and two subsequent communications via telephone and email, no software update had been issued by 14 March, when Rapid7 went public with the vulnerabilities.

Rapid7 has a history of working with software and other technology providers to remediate security vulnerabilities and is a strong supporter of responsible disclosure, which means disclosing vulnerabilities to suppliers first to give them the opportunity to fix the problem before going public.

But according to Beardsley, vulnerability disclosures from security researchers are often perceived in a negative light. “It is like someone in the security community telling them their baby is ugly,” he told Computer Weekly in an interview at the DEF CON hacker conference in Las Vegas in August 2015.

This week, Israel-based researchers at CTS Labs were accused of irresponsible disclosure for going public with more than a dozen security flaws discovered in AMD processors just 24 hours after notifying AMD.

The public disclosure of the AMD flaws was in sharp contrast to the way the disclosure of the Meltdown and Spectre chip vulnerabilities was handled.

Although these flaws in the way processors are architected became public sooner than expected by affected chip makers, they already had about seven months in which to plan a response and prepare security updates.

Reacting to the way the AMD chip flaws were disclosed, Jon Bottarini, technical program manager for vulnerability coordination at bug bounty platform HackerOne, said CTS Labs has provided a classic example of what not to do when you discover a software or hardware weakness in the wild.

“Responsible disclosure should be the prime directive for security researchers, and by only allowing AMD 24 hours to respond before CTS Labs notified the press, CTS stood to do more harm than good,” he said.

“Of course, companies shouldn’t be critical of white hat hackers when they find bugs in their software or hardware – they should be thankful. But when disclosure is handled recklessly, you run the risk of eroding trust between white hats and the corporate world, which ultimately ends up helping the bad actors.”

Read more on IT risk management

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchCIO

SearchSecurity

SearchNetworking

SearchDataCenter

SearchDataManagement

Close