Remote Code Execution Vulnerability Disclosed
Shame on us for not catching this a month ago when it was first reported, but it seems that two of the biggest caching plugins in WordPress have what we would classify a very serious vulnerability – remote code execution (RCE), a.k.a., arbitrary code execution:
…arbitrary code execution is used to describe an attacker’s ability to execute any commands of the attacker’s choice on a target machine or in a target process. – Wikipedia
It appears that a user by the name of kisscsaby first disclosed the issue a month ago via the WordPress forums. As of 5 days ago both plugin authors have pushed new versions of their plugins disabling the vulnerable functions by default. The real concern however is the seriousness of the vulnerability and the shear volume of users between both plugins.
There are a few posts, released within the past few hours that do a great job of explaining what the issue was and what was being exploited. You can find some good after action thoughts on Frank Goosens’ blog and on Acunetix’s blog as well.
Why Such a Big Deal?
Between the two plugins they’re looking at something close to 6 million downloads, granted not all current and some will be updates, but assuming even 25% are unique sites that’s an impressive number for any plugin. The real issue comes in that it applies to any WordPress blog that has comments enabled.
If you’re using a third-party service, like Disqus, this won’t affect you. A really simple way to test is leave yourself a comment like this:
< !–mfunc echo PHP_VERSION; –>< !–/mfunc–>
If it works, it’ll show you something like this:
5.2.17
You can see that it’s showing the version of my server’s PHP install. No big deal right? Wrong. This means I can pass any commands I want to your server and they’ll execute, hence the term remote command execution (RCE).
In this instance all I said was echo, or print out, the version of my PHP, in it of itself is benign. Replace my echo with an eval and encode a payload and now it’s a different ball game. Case in point, a backdoor shell, all while going via your comments and bypassing all other authentication controls.
Again, not an issue to be taken lightly, this is a very serious vulnerability, further exacerbated by the fact that any user can exploit it. The easiest way to protect yourself is to upgrade. You can find the latest updates on the WordPress.org repository:
WP Super Cache
W3TC Total Cache
Kudos to the plugin developers for acting quickly on the issue. Now it’s your turn end-users, update!
p.s.
quickfind:
find . -type d -iname "w3*"
find . -type d -iname "wp-super-*"
bettafind:
#touch w3-wpsc-find.sh
insert:
!/bin/bash
#Find out-dated versions of w3 total cache / wp super cache
#find files and versions:
echo '*******ALL wp-super-cache installs/versions*******'
find /home*/*/public_html/ -type d -name wp-super-cache -exec grep -H 'Version:' {}/wp-cache.php \; | tee /tmp/supercache
echo '*******ALL w3-total-cache installs/versions*******'
find /home*/*/public_html/ -type f -name w3-total-cache.php -exec grep -H 'Version:' {} \; | tee /tmp/totalcache
#grep out current versions (already updated installs)
#current total cache: 0.9.2.9
#current super cache: 1.3.2
echo '*******Only outdated versions of super cache listed below:*******'
grep -v '1.3.2' /tmp/supercache | tee /root/outdated-supercache
echo '*******Only outdated versions of total cache listed below:*******'
grep -v '0.9.2.9' /tmp/totalcache | tee /root/outdated-totalcache
#Clean up
rm /tmp/supercache /tmp/totalcache
echo "full lists of outdated installs are in /root/outdated-supercache and /root/outdated-totalcache"
run
chmod +x w3-wpsc-find.sh
sh w3-wpsc-find.sh
