Tag Archives: Henry Schein Practice Solutions

UPDATE: Shortly after the initial draft of this blog was written (but days before it was published), David mailed again shortly after my reply to apologize and clear up that any notion of a legal threat was not intended. Note that his reply was not sent to the same addresses he originally mailed, or the ones that were added in our reply, so it was not immediately seen. He went on to say that he “fired off an email quickly on my own in frustration without talking to anyone before hand or letting anyone else preview it“. As such, we have edited this post to mostly redact the company name as well as fully redact David’s last name. It is not our intent to punish anyone and we understand and appreciate that such actions are often misunderstood and not intended. We now hope that this blog post can serve as a lesson to everyone, ourselves included, about how emails can be perceived from both vendors, and vulnerability databases.

As most people who follow the OSVDB project know, we strive for the most complete and accurate information about vulnerabilities. We take it very seriously, almost to a fault. We actively seek out information from the community and routinely contact vendors and researchers directly to confirm we have a clear understanding of the information published. When we are provided more clarity we update our entries without hesitation. However, when we receive an email from a vendor with a “legal issue” in the subject and it tells us to change an entry without new evidence, this concerns us as it goes against the core of the project to provide accurate, detailed, current, and unbiased technical security information.

In keeping with our mission to help educate both vendors and researchers on how best to handle the vulnerability disclosure process, we believe it is in the interest of the community to publish details if a software vendor uses legal action, or the implied threat of legal action, to silence vulnerability information. Typically when we have vendors contact us they want to have an entry removed completely, but that was not the case in this situation. In this case, rather than try to work with us to ensure the entry is accurate we received an email from a large medical vendor that “suggested” we change published information so that it would no longer be factual.

David, who sent the mail, said he would follow up the next day with us but did not. As we shared with him on Friday in our reply, we would write a blog about the incident on Monday to ensure that everyone was made aware of the situation. Below are the two emails exchanged, only edited for formatting. No content has been removed or altered.

We respect vendor concerns about entries, and will flag “Vendor Disputed” immediately when we are contacted. We will then examine their concerns and make changes appropriately. In this case, the vendor has verified the vulnerability itself, but they are disputing the access vector. This may not seem like a big deal, but we take the “accurate information” guiding principle very seriously. Our vulnerability entry is currently using the CVSSv2 scoring from NVD at 4.3 publicly. The associated CERT/VU scoring has it at 7.4. We believe the score should really be 10.0 due to the vulnerability being remote default hardcoded credentials that allow full access to the database. Changing the access vector from remote to local, as the vendor requested, could result in a score as low as 1.9. Remember, while CVSSv2 has some faults, the base scoring system is still done according to the “constant with time and across user environments”. That means that third-party protection mechanisms like firewalls, routers, or other screening devices are not factored into scoring.

If any entry containing technically inaccurate information needs to be updated, we are happy to do so immediately provided there is sufficient evidence available. This has been our policy for almost 10 years now, and it will not change. Threatening legal action over something so trivial, without trying to resolve it amicably, seems counterproductive.

2) Contains a fundamental misrepresentation of the original CERT posting which we will dispute with any and all means necessary. Please correct the post to indicate that the issue is not remotely exploitable which is clearly evident in the CERT post description, the remediation steps and is evident in the CVSS score itself. Ex: http://www.kb.cert.org/vuls/id/948155 “…the attacker would need network access to the database in order to obtain sensitive patient information.”

Please correct it immediately and ensure any other entities that receive a feed from your site also have corrected this misrepresentation. I will make our security response team aware of this posting and we will follow up with you tomorrow to ensure its corrected.

Thanks,
David

[..]

Please consider the environment before printing this email.

E-mail messages may contain viruses, worms, or other malicious code. By reading the message and opening any attachments, the recipient accepts full responsibility for taking protective action against such code. Henry Schein is not liable for any loss or damage arising from this message.

The information in this email is confidential and may be legally privileged. It is intended solely for the addressee(s). Access to this e-mail by anyone else is unauthorized.

Subsequent to this email, we had two comments left on other entries meaning the problem with comments causing a 500 are intermittent. Regardless, email is always a better way to ensure reaching us to discuss an issue.

: 1) When clicking on comment the web site returns a 500 error. As a
: result comments are not allowed on VBD items and owners of the software
: are not able to dispute misrepresentations in the posts.
:
: http://osvdb.org/92817

Please note that in emailing the moderators, you are in fact disputing the
entry. This is a faster and more reliable method of raising a question
with us. During a recent upgrade, the comment functionality broke, and you
are the first to notice. That is why it has remained unfixed, as it is
considered very low priority to us.

: 2) Contains a fundamental misrepresentation of the original CERT
: posting which we will dispute with any and all means necessary. Please
: correct the post to indicate that the issue is not remotely exploitable
: which is clearly evident in the CERT post description, the remediation
: steps and is evident in the CVSS score itself. Ex:
: http://www.kb.cert.org/vuls/id/948155 “…the attacker would need
: network access to the database in order to obtain sensitive patient
: information.”

Between your subject line calling this a “legal issue” and including “any
and all means necessary” in the body, the Open Security Foundation (OSF)
is considering this email a threat of intended legal action and will reply
accordingly. We already strive for accuracy in our data and have a long
history of going out of our way to ensure it, frequently contacting
vendors for additional information, bringing issues to their attention,
and engaging in emails such as this to figure out details.

First, our entry does not misrepresent the CERT posting at all. Looking at
CERT VU 948155, specifically the Solution section:

As a general good security practice, only allow connections from trusted hosts and networks. Restricting access would prevent an attacker from using the hard-coded credentials from a blocked network location.

Do not allow the Dentrix G5 database to be accessed by unauthorized users on an insecure wireless network. If the Dentrix G5 database is accessible from an insecure wireless network, a remote attacker may be able to gain access using the hard-coded credentials.

Further, looking at the CERT page that includes what they call a “vendor
statement”, implying it came from Henry Schein Practice Solutions:

It is important to note, however, that the disclosure of the internal database password only posed a vulnerability for practices whose network was unprotected (i.e. practices who lacked a firewall and/or other basic network safeguards).

Between CERT and your company statement, it is abundantly clear that our
classification of this issue is accurate. In both cases, it explicitly
says that this may be a remote issue, and it relies on having third-party
hardware and software installed to protect the database from a remote
attacker. While most companies would follow these guidelines as part of a
regular security posture, we cannot make that assumption because history
has shown us that companies routinely fail to practice the most basic of
security measures. Our entries are added and updated with _factual
information_ pertaining to the issue. We do not account for network
configurations or the possible presence of third-party devices because
that does not happen 100% of the time.

With that, I have updated the entry to reflect that Henry Schein Practice
Solutions stresses that proper network protection be implemented to help
mitigate this issue. It does not change the fact that this can be remotely
exploited in some circumstances.

: Please correct it immediately and ensure any other entities that receive
: a feed from your site also have corrected this misrepresentation.

Now that the information is updated in our site, anyone viewing or
accessing the information has the latest updates.

: I will make our security response team aware of this posting and we will
: follow up with you tomorrow to ensure its corrected.

Likewise. I have made the other moderators aware of this situation and I
will be authoring a blog post on this entire matter (which will also be
Tweeted to our followers, and included on the ISN mail list that goes out
to ~ 6,000 security professionals), including the implied threat of legal
action to be posted Monday during business hours. We feel it is important
for the industry to know when a vendor uses such tactics in an attempt to
stifle vulnerability disclosure, and to unfairly pressure an organization
into displaying inaccurate information, which you are attempting to do.