Engineering Analysis

At Altamente we are tasked with managing a wide range of client communications and web infrastructure, which encompasses areas such as email, web, and messaging systems. With over two decades of experience in this field, we have a unique understanding of the cyclical nature of threats, attempted breaches, phishing efforts, and various forms of spam.

Observations suggest a significant effort is currently being deployed with the intention of undermining public trust in government, public health, and societal institutions. This report serves to highlight an instance of such attempts, demonstrating the recent trend of misinformation.

Recent misinformation campaigns have shown a concentrated focus on vaccination efforts, attempting to foster mistrust towards the medical community and governing bodies. The following illustration presents a portion of a spam comment aimed at promoting a common conspiracy theory related to the Covid-19 vaccines, namely, the myth of "vaccine shedding".

For a factual overview of "vaccine shedding", please refer to the related Wikipedia article. The concept of "virus shedding" is not a concern associated with modern vaccines, and these efforts aim to generate confusion by referring to outdated practices from the 1950s.

These concerted disinformation efforts, which involve significant time and resources, often raise questions about the motivations behind such campaigns. Why is there such commitment to disseminating spam and misinformation? This question brings us to the intersection of technology and human action.

The Interplay Between Technology and Human Activity

An in-depth analysis of these campaigns reveals that the individuals or organizations behind these attempts are not merely concerned citizens expressing their views. They are often employed to propagate this misinformation. A review of our server logs indicates that a substantial amount of the traffic to our hosted websites originates from regions such as China, Russia, Ukraine, and Belarus. Given that the content we host holds little relevance for individuals in these regions, it becomes evident that the primary motive is exploitation of WordPress's popularity for disruptive and potentially harmful purposes.

This scenario necessitates the implementation of measures like captchas, designed to filter out automated spam posts. However, it's important to remember that human beings are sometimes paid to execute these tasks, illustrating that these campaigns are indeed orchestrated efforts.

To those who may find these posts credible, it's crucial to understand that these operators are not acting in your interest. They are manipulating public sentiment to achieve their own goals, often at the expense of national unity, faith in public institutions, and scientific discourse. The resultant divisions and societal disruption serve their objectives, often to the detriment of political and economic stability.

We run a small sitewide multi-domain Wordpress installation for blogs and simple sites.  Wordpress (and before that Wordpress MU) is easy to install, manage, hack, and looks nice out of the box.

The only problem is that it is just not that well engineered, and I have done more than my fair share of double takes as to how primitive the system is.

Overestimate the quality of Wordpress code at your own peril.

Here is a specific example and my method for working around a particular limitation (without patching the core). 

First, the problem.  Even with CAPTCHA, WP-Hashcash, and Apache no-referrer denials in place, spambots can still post to wp-comments-post.php and enter their Viagra crap to the comments moderation queue.  How is this possible, you ask?  How would they get around Apache directives that mandate the request have a referral from the same site?  Are they actually injecting a fake referral in their bot?

Yes. Yes they are.  It is trivial to do with curl.  Here is an example:

curl -e "http://yoursite.com/2010/07/02/your-post-permalink/" -d "param1=value1&param2=value2" http://yoursite.com/wp-comments-post.php

-e is the post permalink (the string used as the referrer to gain access to wp-comments-post.php)

-d is some set of variables like, "name= and comment=" where you inject the actual comment.

The last argument is the destination, which would be your default wordpress comment post handler.

I have read all over the Internet where admins are under the false pretenses that the following Apache directives nullify direct access to wp-comment-post.php

RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} ^/?wp-comments-post\.php.*
RewriteCond %{HTTP_REFERER} !.*yoursite.com.* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule .* - [F]

I can assure you they do not, and reliance on this technique shows the distinct lack of experience of some of our newer Apache admins.  Every single http request is a direct request to the webserver.  Referrals are generated on the client-side and can be ANYTHING, anything at all. Remember, a good sysadmin never trusts his users or their input. 

Every http request is unvetted user input.

How could, the developers have avoided putting any security into wp-comments-post.php?  How could they allow direct access to that file?  Why is there not some sort of token or hash that is generated from the comment form and passed via the POST?  It seems reasonable to me that WP-Hashcash could pass its approval (based on some hash) upon POST and wp-comments-post.php could accept that as part of the environment.

Yet, there is no hook and no template post variables that can be extended by plugins without hacking wp-comments-post.php.  If comments are permitted by anonymous users on a post wp-comments-post.php will happily process the remote request and pass it to your moderation queue. You can inject any browser string, referral, or comment you wish, all day, every day. 

The solution, it turns out is to take your fresh Wordpress installation and rename the following files to something unique to your installation (you can make it random if you wish):

• wp-trackback.php
• wp-comments-post.php
• wp-signup.php

and then run

grep -rl wp-comments-post.php wordpress/ | while read file
do
   sed -i 's/wp-comments-post.php/hidden-comments-post.php/g' "$file"
done

and repeat that for each of other files wp-trackback.php and wp-signup.php (obviously modifying the targets appropriately).  You can just automate the process with a little shell script every time you update your wordpress installation (which is how we do it).

The result: now spammer bots do not know the name of the comment post script in your Wordpress installation.  They would have to pull the name from your particular instance (by looking at your comment form) and modify their bots to target you directly after that.  That is too much work, and I suspect they would not bother.  Better to go after the lower hanging fruit.

But still, I am left scratching my head.  How could direct access still be granted to wp-comments-post.php in 2010?  My solution is only a workaround based on obscurity and does not resolve the issue.  A true fix would involve wp-comment-post.php working in concert with the session of the user, javascript, or/and other parts of Wordpress.

I thought I would throw in a link to a howto I wrote over at OG Consulting. I would wager there are a few people out there that have legacy data in an old MySQL installation (4.0.x and below), and need to bring their installation up to date. I believe the MySQL folks are going to EOL (end of life) MySQL versions less than 4.1.x, so it is now a necessity to get it up to speed. For those of you with a lot of legacy data, I've written a little tutorial on stuffing your mixed character encoded data into a fresh shiny new MySQL installation.

Take a look here.