Recently the OSVDB Blog had an interesting article regarding vulnerability duplication via the “hazard of 0day” wherein a vulnerability being exploited in the wild was mistaken for a new vulnerability when in fact it was not.  This caused many of the vulnerability database vendors to issue new IDs, send out threat warnings, bring in the livestock from the impending storm, and so forth.  The resulting fallout from realization that it in fact was not a new vulnerability ranged in varying degrees between one vendor’s complete backtrack and removal of the vulnerability from their database to another vendor’s nearly ignoring the mistake altogether.

While this is definitely a serious problem, resulting in various degrees of erroneous or duplicated vulnerability information, it’s not nearly as bad as the real topic of this post, intentional vulnerability duplication.

Many research labs and vulnerability clearinghouses have been guilty of this to varying degrees in the past, but none have been quite so blatant about it as VoIPShield Labs, the research division of VoIPShield Systems, Inc.  Coinciding with a product launch at the beginning of April, they released just over forty vulnerability advisories to the public (claiming having upwards of one hundred). At the initial announcement many were fairly impressed, however after taking a cursory look at the advisories themselves, it seemed fairly obvious to me that an attempt was being made to pad these numbers out through vulnerability duplication.  At the time I felt compelled to call them out on this behavior, however I did give them the benefit of the doubt, as this type of thing is regularly pulled by clueless marketing types and sometimes the researchers involved don’t have direct control over distribution of the information.

Unfortunately, a few days ago they did it again, releasing another huge batch of vulnerability advisories riddled with duplications.

The problem with these advisories, at their core, is that they are not actually vulnerability advisories at all.  They do involve vulnerabilities, and some of the vulnerabilities are in fact quite significant, having a serious impact to the vulnerable system as well as in some cases a fairly large install base of the vulnerable system and therefore lots of potential targets for attack.  What the bulk of these advisories really amount to however are attack vector or payload advisories.

Let’s take for example VoIPShield’s “DRF * Command Injection” advisories from their first batch released back in April.  They all appear to be the same vulnerability, which is that the system accepts unauthenticated command messages.  What they’ve done is released a vulnerability advisory for every potential payload (command action) that they can activate via this vulnerability.  Anyone that works in the information security industry and deals directly with vulnerability advisories and security researchers likely understands the anatomy of an attack and can differentiate a vulnerability from it’s exploits, possible payloads, and the available attack vectors.  You’ll also notice that Cisco apparently agrees with me in this case, because each of those VoIPShield advisories all link to the same, single, Cisco advisory, which properly identifies this issue as a single vulnerability.  This batch of advisories can be more accurately thought of as “payload advisories”, which really aren’t worth writing up individual advisories for.  One advisory for the one vulnerability in question would have been much more appropriate.

A second example from VoIPShield’s more recent batch of advisories are the “Message Storage Server * Arbitrary Command Execution” advisories.  The vulnerability here is likely that some underlying processing code has a flaw that allows arbitrary commands to be executed, however there is not enough information in the advisories to confirm this.  This duplication appears akin to finding a single vulnerability in a web site’s input parser, and then writing a separate advisory for every single web page on that website that accepts input.  These are not individual vulnerabilities, rather they are individual attack vectors used to reach the same vulnerability.  These could be thought of as “attack vector advisories”.  While having a little more value than the advisories from the last example, as some vendors tend to patch individual attack vectors rather than vulnerabilities themselves, these are still not worth authoring individual advisories for.

Finally, the “Serviceability Monitoring Tool Unauthenticated Access to * Function” advisories make another good example. The single vulnerability here sounds like the API or management interface that these functions are exposed through allows for unauthenticated access.  The way this vulnerability was duplicated was by essentially writing an individual advisory for every single administrative action (function), or “payload” in this case, that you could possibly perform through that vulnerable interface.  Again, it appears that all of these advisories map back to a single Cisco advisory.  While the Cisco advisory was written to cover two distinct vulnerabilities, it still indicates that this group of VoIPShield advisories are actually describing a single vulnerability.  As indicated in the first example, payload advisories are simply unheard of.  Disclosure of information about new exploit payloads generally lies well within the realm of exploitation research and is usually disclosed by either being found in the wild and an analysis paper published, added to a publicly-available exploitation framework like Metasploit, or presented as new research at security conferences.  This also really only applies to actual byte-code payloads like would be present in a traditional buffer overflow exploit, not payloads of the type indicated here, which are essentially just the normal, expected triggers for the intended functionality of the vulnerable system.

Again, I feel compelled to call VoIPShield out on this behavior both here as well as on the VoIPSec email list, however this time they do not get the benefit of the doubt.  It’s one thing to make a mistake, or an error in judgement, as I was hoping was the original case with the first batch of advisories.  It’s something entirely different to repeat that behavior again, especially after having been called out on it the first time.  At that point, it’s no longer a mistake or error in judgement, but a diliberate dishonest action.  This time I have openly challenged VoIPShield Labs to either stop duplicating vulnerabilities and clean up their duplicate advisories, or to add enough vulnerability information to the advisories to decicively differentiate them as individual, different vulnerabilities.  Now it’s up to VoIPShield to decide whether or not to do the honest and responsible thing, or continue polluting the vulnerability information space with their duplicate advisories.