Be Wary of DefenseCode’s Advisories
In contacting developers about vulnerabilities in their WordPress plugins, whether they are ones we discovered or ones discovered by others where the discoverer didn’t contact the developer, we have fairly regularly had responses that we must be wrong about there being a vulnerability in the plugin. We have found that a bit odd, why would someone take the time to notify someone of a vulnerability that doesn’t exist? But as we have had more interactions with companies and individuals putting out reports of vulnerabilities that we have identified problems with, it has become clear that others are not always as careful as we are (we have also found that they are just as assured that issues we raise about their reports must be wrong, so both sides have something in common at least).
The latest example involves a company named DefenseCode, which we previously mentioned as we had both independently discovered a number of vulnerabilities in plugins by BestWebSoft. They also put out a report of a vulnerability in Magento recently that received a fair amount of coverage, despite the fact that the report could charitably be described as misleading (as part of the claimed issue didn’t exist unless you intentionally disabled Magento’s protection against it).
Last week they released a report of a vulnerability (PDF) in the plugin Ultimate Form Builder Lite. From the report it wasn’t clear if the vulnerability had been fixed. For example, the Solutions section reads as follows:
Vendor did not respond to our repeated attempts to send this advisory. All users are strongly advised to update WordPress AccessPress Social Icons plugin to the latest available version.
Beyond the wrong plugin listed there, it suggests updating the plugin, which wouldn’t do anything if the vulnerability hadn’t been fixed, but nowhere in the report is stated that is fixed.
The version impacted is just listed as “Various” and the timeline provided makes no mention of the vulnerability being fixed:
03/24/2017 Vendor contacted
04/12/2017 Vendor contacted
04/13/2017 Vendor contacted
04/19/2017 Still no response. Advisory released to the public
When we went to test out the vulnerability we found that the proof of concept did not work with the current version of the plugin. Looking over things we found that the vulnerability had been fixed in version 1.3.3, which was released on March 13, and the developer credited 0xSec Team for reporting it:
- Fixed XSS issues on preview page and backend form settings page
- Special Thanks to 0xSec Team for reporting the security bugs
That made DefenseCode’s claims to have contacted the developer for the first time on March 24 seem rather odd, as that was 11 days after the vulnerability was fixed. What we thought might explain is that the dates matches the ones in their report of a claimed vulnerability (PDF) in AccessPress Social Icons, which is the plugin mentioned in the Solution section, so maybe they had just included the wrong dates in the advisory and they had notified the developer after the 0xSec Team did, but before it was fixed.
When we contacted DefenseCode to let them know that something wasn’t right, as they claimed to have contacted a developer about a vulnerability well after it was fixed, they responded by providing a list of dates they contacted the developer, which were the same as the advisory, and a copy of the email they sent. That obviously didn’t address the issue at hand or even seem to be an attempt to do that.
In several more emails back and forth we never got clear answer to what was going on here, reading between the lines it seems to be possible that they discovered the vulnerabilities some time before they contacted the developer and didn’t bother to make sure that it still existed when they contacted them or before they released the advisory. That really shouldn’t be happening and it is likely to make it harder to get developers to respond promptly to report of vulnerabilities that actually exist in the current version of their plugins.
They seemed to be surprised that the developer didn’t respond to them, despite the fact that it is fairly common for developers not respond, and seemed to placing the blame for the situation on the developer not responding. They also seemed to not even grasp our point that it wouldn’t be all that surprising that the developer didn’t respond to someone claiming that a vulnerability existed in their plugin that had been fixed a week and half before.
Since the company at best is lax in their handling of claimed vulnerabilities, it would be wise to be wary of information included in their advisories and make sure you double check it before rely on it or repeating their claims (considering that security journalists don’t seem to care about the accuracy of what is in their articles they are unlikely to head this).