Get this blog as an RSS Feed

When does poor design become a vulnerability?

15:19 CET, 28th February 2008 By Thomas Kristensen.

Lately there has been discussion about some SIP vendors not validating authentication certificates in their PEAP implementation, which can lead to a hacker gaining access to your computer if you inadvertently connect to a malicious server.

First there was a report that Vocera phones do not validate certificates due to "the processing overhead required".

As soon as we got this report, Secunia Research immediately assessed it, and during our investigation it became clear that Vocera was upfront about their design decision not to implement certificate validation for PEAP, and the possible impact of that decision. In addition, PEAP was not enabled by default and was simply one of several protocols supported by their IP phones. Users were ultimately responsible for choosing a protocol that works best for their needs.

In other words, this is not a vulnerability nor a "feature". At most it is an inappropriate design decision.

Second there was a report about the very same problem in certain Cisco phones. They reportedly also failed to validate certificates in their PEAP implementation.

Secunia Research initiated dialogue with Cisco, in which we clarified if the report was indeed true, and whether this decision was documented and publicly known prior to the report. In the course of our dialogue, our Cisco PSIRT contact verified that Cisco's PEAP implementation on certain phones indeed failed to validate certificates. In addition, and this detail is especially relevant, our contact failed to provide us with publicly available documentation regarding this issue.

Obviously, when such poor security isn't documented then the user doesn't have a chance of rectifying the problem. It then becomes an undocumented security flaw. For this reason, Secunia published an advisory to let users of the Cisco IP 7921 phone know that the problem exists.

The logic is quite simple: if the vendor properly documents and explains the risk of configurations and implementations to their customers, then they allow their customers to make proper decisions. Customers can then reconfigure settings for themselves to fit their own specific requirements. This is a poor design decision, we agree, but it's not like Vocera forced them to use PEAP - there were clearly alternatives available.

This can be compared to other products that Secunia regularly receives vulnerability reports on, such as Joomla. Joomla clearly warns administrators in both the installer and the administration section of the CMS that the security of the product relies on e.g. "Register Globals" in PHP being disabled - in other words all the reports we receive about "vulnerabilities" in Joomla which require "Register Globals" to be enabled are skipped as non-issues.

Another example would be default passwords in software, such as the Oracle database. In Oracle, some accounts created during installation have default passwords, and administrators can secure them after the installation has completed, this is also considered non-issues. The fact that these accounts should be secured after installation reasonably falls within the realm of common sense, but Oracle has also included it in their security checklist, in case it doesn't occur to you that installing an enterprise database requires a modicum of security.

We are not saying that vendors just can document their way out of any poor design decision or any error they may have made in their products.

We at Secunia do not find it acceptable that Vocera and in general Wi-Fi Access Point (WAP) manufacturers deliberately design their products with documented weak implementations and insecure default settings, however, it does not make it vulnerabilities. It is reasonable for a vendor to assume that users get reasonably acquainted with the documentation of a product for proper and safe usage such as e.g. enabling WPA2 encryption on a WAP. Naturally, we would be most happy if the WAP manufacturers only would make it possible to activate the access point after a couple of big fat dialogue boxes full of warnings.

If our competitors and certain journalists still believe that the issue with Vocera should be considered a vulnerability then we wish them endless joyful days writing "vulnerability" reports, articles, and blogs about all the "vulnerable" Wi-Fi Access Points out there, which don't have enabled encryption. We at Secunia will continue doing what we do best: publish the most accurate, most reasonable vulnerability information in the world.

Kind regards,

Thomas Kristensen, CTO

Discuss this blog entry
A new thread in our forum is created. Activate the thread by commenting/discussing below.

Subject: When does poor design become a vulnerability?

No posts yet
You must be logged in to post a comment.