Remote WordPress exploits are nearing extinction

Experience the best syntax error you’ve ever had

Polyscripting takes a stand against would-be attackers looking to exploit the most dangerous kind of vulnerability?—?remote code execution.

Four months ago, Blue Gaston introduced the world to Polyscripting?—?the idea of making every WordPress instance speak a different programming language, thus making an attacker’s commands, written in PHP, ineffective.

WordPress is susceptible to a particularly severe kind of vulnerability called a Remote Code Execution, which is exactly what it sounds like: it enables an attacker to run commands and programs remotely on your WordPress. This is possible fundamentally, because every WordPress, everywhere in the world, speaks the exact same programming language?—?PHP.

With the previous update we posted, Polyscripting left a few questions unanswered?—?how would updates, upgrades and plugins work? How would modifying code or debugging work? Would this be easy to use? Would it scale for a hosting provider?

How to get Protected

Run the WordPress you’re used to

Before we get to Polyscripting, let’s run WordPress just like we’re used to already. I’m going to assume you have a directory where you have your WordPress saved (or would like it saved.) We’ll call it $WORDPRESS for brevity and abstraction.

We can launch WordPress using the Polyscripting-enabled container, and mounting this directory:

docker run --rm -d --name wordpress -v $WORDPRESS:/wordpress  --link mysql-host:mysql -p 80:80  polyverse/polyscripted-wordpress:b1805560d812c84e441b0ca0326c66bf5522c5ad

Note the link to the mysql instance. For this example, I launched it in Docker, but you can run MySQL any way you wish.

docker run --name mysql-host -e MYSQL_ROOT_PASSWORD=qwerty -d mysql:5.7

To use any different MySQL instance, modify the wp-config.php under $WORDPRESS where the settings are used from.

You can upgrade WordPress, add or update plugins, and all changes will be reflected in $WORDPRESS. In short, if you already run WordPress and have /var/www/html or some equivalent of that, simply mount it in, and you’re well on your way.

On port 80, you should have WordPress?—?just the way you love it!

Polyscript It

How exactly do we get Polyscripted? We add one environment variable: -e “MODE=polyscripted”, so the command becomes:

docker run --rm -d -e "MODE=polyscripted" --name wordpress -v $WORDPRESS:/wordpress  --link mysql-host:mysql -p 80:80  polyverse/polyscripted-wordpress:b1805560d812c84e441b0ca0326c66bf5522c5ad

It may take a couple of minutes to start up (it is generating a brand new language on the fly, converting all of WordPress including plugins into it, and launching it.)

Polyscripting is so simple and easy there’s no excuse to not be protected.

What’s the Catch?

As with all security, Polyscripting brings a minor inconvenience… and we really did make it a minor one. When Polyscripted, upgrades of WordPress code, the addition of plugins, and upgrades of plugins, don’t work. I’ll explain why this is the case with diagrams in a bit.

If you want to make changes, remove the environment variable -e “MODE=polyscripted” and relaunch the container. Now you’re back in PHP-based WordPress mode.

How does it all work?

Feel free to read the source code for Polyscripted WordPress on Github. All of the magic is captured in two scripts, docker-entrypoint.sh, and scramble.sh.

Two diagrams will make it all clear. This is what non-Polyscripted WordPress looks like inside that container:

Fairly obvious and straightforward. Also why updates, changes, plugins, etc. just work. It’s your $WORDPRESS directory directly serving the user.

However, when Polyscripted, here’s what happens:

Let’s see what’s happening in this mode:

1. A new programming language (based off PHP) is generated and integrated with Apache.
2. A transformer from PHP to this new language is generated.
3. The original $WORDPRESS contents are copied over into /var/www/html (thus making Polyscripting safe and reversible).
4. The contents of the directory /var/www/html are transformed from PHP into the new language using the recently generated transformer.
5. Now WordPress and Apache speak the same new language, which nobody outside of that container knows. Not you, not Polyverse?—?and especially not the attacker. They can’t exploit what they don’t know. It’s that simple.

If you’re a WordPress user, you should be asking your hosting providers to enable this. We couldn’t have made it easier. Polyscripting for PHP is source-available and free for non-commercial use. If you’re a cybersecurity company that specializes in detecting attacks, look out for the best syntax error you’ve ever had, in your logs. If you tweet at @PolyverseCorp, we’ll send you this t-shirt: