Wordpress.org: Spam content in blog post?

January 23, 2021 3:14 PM

I have a client site utilizing the Wordpress platform where spam is starting to appear in the actual text of pre-existing blog posts. I am familiar with comment spam. But this actually putting spam into the post itself is a new one on me.

Here’s some example pages. I’ve put the spam content in bold-

* bookmark-failures-successes-coming-soon
* michelles-excellent-flax-adventure
* rhinebeck-and-the-brothers-zinzendorf

I’m sure there are more. I’ve only just discovered this.

Any ideas or insight would be most appreciated!

Additional:

- All of the text is styled normally. There is nothing extra in the meta.
- WP version, themes, and plugins are all up to date with current versions.
- There are only two Admin users on the site. Myself and the site author.
- We have both reset our passwords recently and both employ strong password protocols when doing so.
- The site utilizes a handful of plugins. All are standard and are direct from the WP depository.
- The site is hosted on a solid and trusted web host.

Thanks!

posted by jammy to Computers & Internet (14 answers total)

Did you do the additional work of updating Wordpress and resetting passwords *after* you noticed this happening? It's very possible that if you were running out of date Wordpress or had compromised credentials, that hackers could have installed a more persistent back door to give them the access they need that would survive upgrades. If none of the people with access to post/edit articles have done this, then that would be my guess. It's also possible that your host may have also gotten compromised, or some credential involving database access or hosting was compromised.

Honestly, your safest bet at this point is likely going to be making a backup of your current content, nuking the WP install entirely, and starting fresh. All passwords involved in site access, including passwords for databases, hosting admin access, etc. should all be changed. You may want to have your web host investigate and make sure the compromise doesn't run deeper than your Wordpress install.
posted by Aleyn at 3:51 PM on January 23, 2021 [1 favorite]

Response by poster: Thank you, Aleyn - but as I stated "WP version, themes, and plugins are all up to date with current versions."

Maybe I should have said they *were* all up to date?

They were all up to date before this happened and after it happened. That is what is puzzling me so.
posted by jammy at 4:14 PM on January 23, 2021

Have you installed the Wordfence or Securi plugin & run it to see if they pick up any malware or files that appear to be up-to-date but don't match the current version's code? That's the first thing I'd do.
posted by belladonna at 4:29 PM on January 23, 2021 [1 favorite]

I don't want to make myself sound like an expert (because I'm not), but if this happened to me I would suspect a security breach.

In other words, as you suggest: if all the software you interact with is up to date and has been up to date and has tough passwords which have not been divulged, then it suggests that there has been a breach at some lower level. Is the site hosted on a shared server, what operating system version, database management version, Web front end, is SSL in use with up to date certificates, etc. And once a "back door" is installed you've been "pwned" as they say. I defer to others more knowledgeable than I.

On preview, belladonna's point about version hash codes (I assume) would also be a part of the infrastructure.
posted by forthright at 4:33 PM on January 23, 2021 [2 favorites]

If you're reasonably certain about the server side of things, one other angle to consider is client-side security. Does everyone with access to make posts have their browsers up to date with no malicious extensions installed? Have you checked for malware on any of the machines used to access the post managment interface?
posted by Aleyn at 5:29 PM on January 23, 2021

I'm seeing the spam in the above links even in a browser with javascript turned off, so that's one indicator—it means that the spam isn't being inserted through an XSS attack or javascript supply chain attack or other such process.

If checking all of the usual suspects doesn't uncover anything you might try remote desktoping (or SSHing into a Unix host; maybe a support technician would be the one to do this) into the server and checking whether, if you view the site through something like http://localhost/, the spam is still visible on those pages.

I'm not finding it in cursory googling but in the past I've run across claims of especially sneaky viruses and exploits that actually infect the server's network card firmware, or other parts of the low-level network stack, and modify web pages “in flight” as it were. (In which case it's possible, though not guaranteed, that when viewed locally the pages would not have the spam in them.)
posted by XMLicious at 5:37 PM on January 23, 2021

Are you now or have you ever had the WP File Manager Plugin installed? There was an RCE exploit exposed in October I think. But the issue had existed since March, and while I was able to wipe out the back links someone created, and all the includes and malicious .ico files, little bits kept coming back.
posted by MonsieurBon at 5:46 PM on January 23, 2021

Add-on to previous response: even if you updated the WP File Manager plugin immediately after the exploit was discovered, you could have already been compromised. And changing passwords and hashes has no effect.
posted by MonsieurBon at 5:51 PM on January 23, 2021

infect the server's network card firmware, or other parts of the low-level network stack, and modify web pages “in flight”

I'm struggling to understand how this particular attack could work against a HTTPS site; TLS encryption happens at application level, so from the low-level network stack's point of view, everything in flight is encrypted gibberish.

It would be interesting to find out how long it takes for the garbage you're seeing to come back after you eliminate it. If it's seconds, there's probably something running locally inside your host that you really don't want to have in there. If it's hours, it's more likely a person doing it via some form of back-door access and you might be able to figure out where from by looking at logs.
posted by flabdablet at 8:51 PM on January 23, 2021 [2 favorites]

If you find the answer, please share it here. Thanks.
posted by theora55 at 8:33 AM on January 24, 2021 [2 favorites]

Not a direct answer as to how it happened, but I'm going to suggest this issue isn't limited to just your blog site.

The links in your posts point to an otherwise legitimate (as far as I can tell) website, but the spam pages linked to by your blog post appear to have been surreptitiously added to that site behind the scenes as well. From their main website there appears to be no links to these spammy pages, and they are formatted slightly different than the legit pages as well. It would appear the site of the medical office was hacked too.

I wonder if contacting them would answer some questions? I'm guessing they don't know their site has been compromised either. How your site linked to theirs is anyone's guess. It's interesting that the wording of the spam paragraph appears unique to your blog post; googling some of the sentences in it brings back only your post, which is weird.
posted by SquidLips at 1:01 PM on January 24, 2021

In addition, googling the site address brings back numerous results of these spam URLs being inserted into other blog posts as well, pointing to this being some sort of larger scale compromise of WP since they all look on the surface to have been created with it.
posted by SquidLips at 1:08 PM on January 24, 2021

You are definitely hacked, 99% likely via a bot rather than a human sitting in a basement somewhere.

I've dealt with this sort of thing a few times over the years, one just a few weeks ago for a friend whose PHP version was woefully out-of-date.

To solve this you need to do the following, generally. You'll need a FTP program and a text editor and some patience.

Overview:

1. Make SURE your hosting is running a currently supported version of PHP (7.3 or later)
2. Make notes about your current setup: plugins, theme, and text contents of wp-config.php in your site root
3. Delete all files that you can.
4. You will have to do a bit of "auditing" of the files you cannot delete
5. Make a couple of changes to your wp-config.php file
6. Re-upload WordPress, plugin and theme from fresh copies downloaded directly from the repository
7. Go into settings, steer to permalinks, and click "save" to ensure your htaccess file is written
8. Install and use Wordfence, the free version is fine for small-site purposes

More details on the points, above:

1: Decent hosting

Make double-sure your host is running PHP 7.3 or later. Sometimes hosts (godaddy is notorious for this) will not actively maintain your PHP version, sometimes it being dependent on your hosting plan. (If your host doesn't support 7.3+, find a new host, the stuff below will just be wasted time otherwise.)

2: Preparing to nuke old install

1. Make a list of the plugins you have installed so you can reinstall them later.
2. Hopefully your theme is an out-of-the-box theme (free or paid) which is currently maintained...if so, cool. If not, see auditing, below. (A "custom" theme doesn't mean one giving you options via a control panel in the admin area, but rather one that you, or a developer, wrote custom PHP code or built from scratch)
3. Find wp-config.php in your site root on your server and make a local copy of it. We'll need to edit it a bit and add that edited file to the new WordPress files you'll be uploading.
4. Go to the repository and download WordPress and all of the plugins you're using. If you're using a theme from somewhere which you haven't modified the code of, go and download that.

3: Delete files

1. After making a copy of the wp-config.php as mentioned above, delete all of the files (not directories) in your site root
2. Delete the entire "wp-admin" directory
3. Delete the entire "wp-includes" directory
4. Open the "wp-content" directory, open the "plugins" directory, and delete everything in it
5. Still within "wp-content", open the "themes" directory and delete everything in it assuming you have a fresh copy of the theme. If the theme is a custom coded or modified theme, leave it, but delete all other themes
6. Still within "wp-content", delete the "upgrade" directory

4. Audit remaining files

Now we have to go through your uploads directory and maybe your theme directory (assuming you have a custom theme which you couldn't get a fresh copy of) and look for files which should be there. This will potentially be tedious. In the case of a custom theme it may be very tedious and require specialized knowledge. Hopefully your theme is something you can just upload from a known fresh and secure copy.

1. In "wp-content" open your "uploads" file. In the root of this should mostly be directories named for years, but there may be additional directories if a plugin you have installed creates directories
2. For every directory and sub-directory in "uploads" you will need to open them and look for suspicious files. Suspicious files are any of the following:
   • Any file with a "php" extension; any and all of these should be deleted with extreme prejudice; there should never be php files in the uploads directory
   • Any file without an extension, same as php files
   • Any files with "js" extensions should also be nuked
   • In the year-based directories are sub-directories by month of pictures and media files you uploaded (and there are probably plenty of empty months). Any file which is not a media file (png, jpg, pdf, mp4) should be regarded with extreme suspicion, unless you know you personally uploaded it via the media library
   • Check the file dates. There is no guarantee (you might have edited an old file), but finding a new file in a directory of old files is suspicious; you should look at the contents of that file in a text editor. Most media files will be incoherent batches of garbage characters when examined in a text editor; if you find anything coherent and especially anything that looks like php or javascript code in the file, it should be deleted (note, I have never seen a disguised media file in a hack, so odds are against it)


3. If you have to audit the theme...go into the "wp-content" directory, and then "themes" and then into your theme's main directory.
   • The easiest way to spot anomalies is to look at the file date. All of the files in the theme were probably written at the same time, within a few seconds of each other, like "2018-01-01 12:05:03". Any files which are newer than the bulk of them are definitely suspicious.
   • There might be completely new files with oddball names, perhaps garbage character strings or just not in keeping with the naming convention of the rest of the theme. These should be examined in a text editor. See below.
   • You will need to venture into any sub-directories in the theme, looking for the same signs.

What would be suspicious code within a PHP file that you think is part of the theme? Sadly, spotting this is generally an "art", often readily apparent to an experienced developer but hard to spot if you're not one. If you have a custom theme and you think it has been compromised by looking at the timestamps...you are probably beyond this brief (!) guide and need pro help.

One thing to look for is a call to "base64_decode"...I can't think of any but the most esoteric (and generally not well-thought-through) reasons this call would be in a theme's code base, but nearly every hack I've seen uses it to obfuscate information.

5. Make some changes to the wp-config.php file you saved earlier

The key here is to edit this with a text editor and compare it to the "wp-config-sample.php" in the root of your freshly downloaded copy of wordpress. The structure should be largely identical, except with your database details in the top few constants instead of the empty ones in the sample file. Your host may add their own constants, usually near the bottom, but unless you're on a big managed farm with wpengine, that's pretty unusual.

The only function you should see (a function being a word or words separated by underscores with a parenthesis immediately following) is "define(". If there are any other functions, your old config file is very suspicious.

The most important thing you MUST do to this file is get a new set of authorization salts and paste them into the file. Go to https://api.wordpress.org/secret-key/1.1/salt/ and copy the text from there, replacing those same lines in your wp-config.php file, generally around line 49 of the file. If your existing file still has the "put your unique phrase here" placeholder text in it, oof, not good...that definitely made the hacker's lives easier.

Changing the salts is critical, because it will force the log out of any and all users of the site. It's possible for hackers to create an admin user, log in as that user, get the admin cookie set, delete the admin user, and still be logged in as an admin, invisibly. Changing the authorization salts ensures that scenario is nullified.

Place your updated wp-config.php file in the root of your newly downloaded copy of WP that you unzipped on your local computer.

6. Upload new files to the server

Because we left the media files on the server (you've audited those per the above, right?), you need to do this in a few steps.

1. In your LOCAL copy of WordPress, delete the "wp-content" directory
2. Unzip and upload your fresh plugins to the now empty "plugins" directory in "wp-content" on your server
3. Do the same with your fresh theme directory, to the "themes" directory in "wp-content" on your server
4. Now copy all of the files in the root of your local WordPress copy, and the "wp-admin" and "wp-includes" directories to the root of your server install

7. Log in and go to settings -> permalinks and hit "save changes"

The actual settings should still be as they were, but hitting "save changes" will ensure that the .htaccess file is written.

Change your admin passwords again, and I would recommend following all of the recommendations WordFence has regarding admin user names and such. (No "admin" username, no user with an id of "1", etc.)

8. Install WordFence

The free version works pretty well. I would follow its suggested guidelines. Under all options, I would definitely consider turning down the number of attempts that trigger lockouts for various bots and humans, and extend the lockout periods.

Whew. I'm not a security expert, but this will get most bot-hacked sites up again.
posted by maxwelton at 11:31 PM on January 24, 2021 [4 favorites]

You will need to manually edit your compromised pages once you're up and running again.

Also, if you have a plugin which allows you to insert PHP code onto pages or posts...consider getting rid of it. But if you have one, you need to go through EVERY page, post or other place it allows such code to be injected and make sure there is not code in there injected by the hack. Again, such plugins are a Really Bad Idea. If you're advanced enough to want to insert PHP code, you're advanced enough to just do it properly via writing a plugin or directly modifying your theme.
posted by maxwelton at 11:49 PM on January 24, 2021