How Vulnerabilities Were Intentionally Built Into Pipdig
Don’t just pay attention to the man behind the curtain, tear the curtain down and burn it. That’s been the general sentiment among the InfoSec community on Twitter this past week in the wake of the discovery of multiple vulnerabilities intentionally built into the popular pipdig Power Pack (P3) plugin. I could easily write 3,000 words digging into the code, but that’s been covered incredibly well already by other researchers. Instead, I’m going to focus more on the effects of this situation, and on how we as a security-minded community can make a difference going forward.
What Happened?
Last week, two security researchers, were independently looking into similar issues that were becoming apparent in the P3 plugin. These researchers were expecting to find a vulnerability within the plugin, or even evidence that malicious code had been injected by adversaries. However, they were surprised to find that the plugin itself included malicious code without having been compromised. Built into the plugin was the ability for pipdig to change the password of any site user, a remote wipe function to delete the full contents of the website, a function that disabled Bluehost caching, and even some code that appeared to attack a competitor of pipdig, among other potentially malicious functions.
After concerns were brought to pipdig, they released an updated version of the P3 plugin, and denied accusations brought against them. In a post on their blog, which they updated on Sunday, pipdig explained their side of the situation. This was met with a large amount of ridicule on social media platforms and in blog responses from researchers. The explanations provided by pipdig did leave a lot of room for close examination. For example, their blog post lists seven plugins that are deactivated when P3 is installed and activated, however, in the plugin code, there are seventeen plugins that are disabled. They claimed that these plugins interfered with their own, but there are a number of them, including the Hello Dolly plugin, that would in no way interfere with other plugins.
The killswitch that pipdig built into P3 has also received a lot of negative responses. They claimed to include this killswitch to combat pirated versions of their products. The problem is that the kill switch doesn’t just make the pirated product unusable, it wipes out the entire contents of the site. pipdig removed their public repositories with the older versions of the plugin and replaced them with new repositories that did not have the malicious code included.
Who Can I Trust?
While some bloggers have actually spoken out in support of pipdig, the question of whether any theme or plugin developer can be trusted has also been brought up a lot in the past week. This is a valid question and not necessarily an easy one to answer. In all likelihood, pipdig didn’t start out with the intent to build backdoors into their customers’ websites, or to use those same sites to attack competitors. I firmly believe that the majority of theme and plugin developers are doing what they do because they see a problem and a solution. The issue of combating piracy is a common issue with premium plugin and theme developers. The issue with pipdig’s solution is that it effectively wipes all of the site content, rather than using the typical solution of disabling the theme or plugin if it is a pirated copy. Often when we see problems with themes or plugins, the problems are unintentional, or due to code that is not following the latest coding standards.
You should never blindly trust a developer to have influence over the code on your website. Just like when malware ends up on your website, code from a malicious developer can have disastrous effects on your website and its visitors. Now, taking a step back, don’t take that as a paranoid, “trust no one,” but more as “trust but verify.” Before you install anything, research the developer.
How Do I Research The Developer?
One of the simplest steps in researching theme and plugin developers is to head over to Google and search for reviews. Read their reviews on multiple sites, see what problems people have encountered with them, and learn how they handle complaints. Be wary of developers who have nothing but positive reviews, as this can be an indication that they have paid for reviews instead of acquiring them naturally from their customers.
If you see results indicating issues like we’ve seen with pipdig this week, it’s probably best to avoid the developer. You want a developer with a history of honesty, integrity, and preferably a refund policy. In the case of pipdig, there are plenty of customers who now have to find a new theme or plugin, and have no way to get their money back, because pipdig does not offer refunds for any reason.
Authored by Topher Tebow, SiteLock Web Security Research Analyst