A report by ZDNet outlines how hundreds of thousands of CMS plugins and PHP libraries are putting users at risk.
Last week Catalin Cimpanu of ZDNet reported on an issue that was first raised by Scott Arciszewski of Paragon Initiative Enterprise: a staggering number of CMS plugins and PHP libraries are disabling SSL/TLS certificate validation.
To make matters worse, many of these plugins and libraries are used to establish connections to payment provider servers, connections through which they later transmit sensitive user data or handle financial transactions.
The result is that millions of internet users interacting with popular websites built on Content Management Systems (CMSs) – like WordPress – are potentially vulnerable as a result of poor configuration by the authors of a troubling number of plugins.
So, what does that mean? Why is it troubling and what can you do to ensure you’re not inadvertently endangering your customers?
Let’s hash it out.
A quick rundown of Content Management Systems and their Plugins and Libraries
Let’s start from the top, rather than build out their own solution, many websites rely on a ready-built CMS (like WordPress, Drupal, etc.) that can be configured to their needs. We do that for Hashed Out. The SSL Store runs on its own home-brewed CMS that is managed by our development team, but given Hashed Out’s need to publish daily, we use WordPress.
One of the most attractive features of a lot of these CMS platforms is that they use plugins and libraries that help you avoid building out your own web applications and putting in tons of extra dev work. The plus side of these plugins is that when they work correctly, and most do, it saves you a lot of time and work. The downside is you’re placing an awful lot of trust in a third party, and when that third party makes a mistake it could end up hurting your site and its users.
Now that we’ve got that established, let’s talk about what’s going wrong with these plugins and PHP libraries.
Misconfigured Code and cURL options
cURL is a library and command line tool that is ubiquitous on modern servers. It’s used for transferring data to and from remote servers, and is baked into many CMS plugins and PHP libraries. Many time its preferential to use cURL instead of opening up an actual browser session to make a connection.
cURL supports a number of protocols, but the two most germane to this discussion are HTTPS and SSL/TLS.
Let’s look at a practical example. Let’s say you’re running running a WordPress site that’s using a plugin that handles the transmission of payment card information to the payment provider’s servers. The typical way to do this would be via cURL that’s configured for HTTPS—cURL will also handle the SSL/TLS authentication for the connections.
But Arciszewski has recently discovered that developers of many CMS plugins and PHP libraries are disabling cURL security features for when cURL is used to download or send data via HTTPS connections…
This is obviously problematic because disabling either of the following settings could lead to myriad problems.
The first setting is “CURLOPT_SSL_VERIFYPEER,” which should be set to TRUE (or have a value of 1).Unfortunately, many of these plugins have it set to False (0), meaning it is disabled and cURL is no longer verifying the URL of the website it’s connecting with. I really feel like that sentence doesn’t need a whole lot of additional context for anyone to understand why that would be incredibly dangerous.
Literally the only thing that a website would need for cURL to connect with it when “CURLOPT_SSL_VERIFYPEER” is set to false is a valid SSL/TLS certificate. Doesn’t matter who issued it, doesn’t matter if it’s a free DV from any number of free CAs, as long as it’s valid then cURL will connect.
The other cURL setting that is being misconfigured is “CURLOPT_SSL_VERIFYHOST.” This also relies on a value. It should be set at 2, which requires a more stringent verification of the server’s SSL/TLS certificate. Many plugins have it set to 0, which means that cURL will even accept self-signed certificates. Again, not much context is needed to understand why this is dangerous—especially when we’re talking about payment plugins.
[H/T to Dan Healy for the correction]
Why is this happening and what can I do?
Let’s start with the why. This isn’t so much an act of malice on the part of the authors of these plugins and libraries so much as it is an act avoidance. When these plugins and libraries are configured with more of a security-first focus they tend to create a number of errors that rightly alarm users. This is bad, especially when conversion rates hang in the balance.
So, to avoid the negative fallout from the error messages and warnings, these authors are betting that ignorance is bliss and disabling these features to avoid causing a scene.
The reason for those errors, as Arciszewski explains, is that cURL needs to verify the certificates of remote HTTPS servers against a list of known and valid SSL/TLS certificates. This list of authentic Certificate Authorities –organizations allowed to issue SSL/TLS certs– is available for download in many places. Unfortunately, some web hosting services don’t store this list at all, while many store it in different server locations, making it impossible to configure cURL settings for CMS plugins and PHP libraries in a universal manner that works seamlessly on all servers.
As a fix, Arciszewski has created a custom PHP library named Certainty that downloads a file called CACERT.pem from the cURL homepage at regular intervals and hosts it locally so that all websites always have a list of up-to-date CAs.
It’s always amusing to me that an issue like this, which has the potential to be truly disastrous, can stem from something as simple as a server not having a list of valid CAs on hand.
But, if you’re running your site on a CMS and you’re worried that you might be having a problem with one of your plugins, give Scott’s solution a shot. You definitely can’t afford to have anything undermining your SSL/TLS encryption.
As always, leave any comments or questions below…