Pantheon protects you from the latest WordPress security exploits

Recently, I came across an article on the Sucuri blog about a new attack vector for malware on WordPress sites: MU plugins. 

Sucuri has long established a reputation for being one of the best platforms for website security and has a deep history in the WordPress ecosystem. I’ve trusted them since their inception in 2009, so when they say their researchers have found a new trend, I pay attention.

MU plugins (or must use plugins) are somewhat unique in the execution of WordPress – it makes sense why they would be exploited to inject malware. In my early days of freelancing, malware would frequently stuff code into the wp-config.php file to execute when WordPress initializes and reads it. Similarly, MU plugins are always executed. The idea is that you want to have code that just runs across your entire site and is always on, as opposed to a standard plugin that can be activated or deactivated. 

Image

At Pantheon, we maintain our own MU plugin. It contains things like the modified login page you see on WordPress sites (with the Return to Pantheon button), which are nice, but not essential. It also includes functionality that is vital to operating on our platform, like the built-in Pantheon Page Cache handling. In 1.5.0 of the MU Plugin, we added a “Compatibility Layer,” which runs checks against plugins installed on your site, evaluates them based on known issues and alerts you via the Site Health page about any recommended  improvements.

Image

MU plugins are important. They were one of the ways my agency developer colleagues put their stamp on a site as a mark of quality of a stress-free site for our clients. 

Making users decide whether to activate or deactivate a plugin isn’t something your clients necessarily need to worry about—especially when you know the site requires specific functionality. If you’re building functional code, the best practice is to put that code into plugins, not the site’s active theme (although I’ve certainly seen my fair share of that). MU plugins ensure that code which is necessary for a site's operation cannot accidentally be removed or disabled with a single click.

That’s why this new attack vector is alarming. While it’s not so different from hacking a wp-config file, it’s more insidious. MU plugins are often a single file to perform a particular task. Because they exist outside the scope of WordPress plugins, themes and core code, they can frequently be ignored. They’re basically set-it-and-forget-it. 

To further complicate things, the filenames the Sucuri researchers found sound innocuous. For example, /mu-plugins/index.php could just be an empty index file similar to what you’d find in the /wp-content directory. Other discovered files, such as redirect.php  and custom-js-loader.php, mask themselves as the type of thing you might expect to find in mu-plugins. This makes them harder to notice without actually inspecting the code.

You’re safe on Pantheon, though

Brandfolder Image

Check out the original article on the Sucuri blog, but rest assured, this is not a risk for your sites on Pantheon. In spite of the alarming nature of these new findings, there are a couple of reasons why you don’t need to worry about your Pantheon sites. The most pertinent is our locked-down filesystem. Malicious actors can't inject code onto your live site because version-controlled PHP files are writable only by our Git-based deployment system. 

This means that the only code that gets promoted to your live environment has to go through our Dev, Test, Live workflow. A human has to intentionally commit the code and then deploy that code to live. These sorts of attacks typically exploit file permissions, which must be permissive enough to let WordPress generate and save files. But that’s just not the case on Pantheon. Unless you’re doing on-server development in SFTP mode (which is only available on the Dev environment or in Multidev), there’s no way for permissions to be exploited. SFTP connections themselves require a valid SSH key that has access to the Pantheon site to even access the application filesystem.

As a Developer Advocate, being sold on the Pantheon platform isn’t a big stretch for me. But I have strong memories of code injection techniques being used against my sites when I was freelancing and working in the WordPress agency space. Not knowing as much about file permissions and security, I would sometimes leave files on my own sites in a globally writable state because I needed WordPress to just work (likely after hours of fighting with file write permissions). 

It’s as reassuring as it is validating to know that even when new, unexpected security vectors crop up, some of the foundational architectural decisions made by Pantheon's founders are still paying off over a decade later.