gorbulalagram

The Security FAQ was not particularly helpful.

I don’t think the exploit was a weak password.

When my site was attacked, I was notified that a new user signed up — even through new registrations are disabled.

I am the only administrator, and if the new account was created from my compromised administrator account, I would not have been notified of a new user. This is evidence that the vector was a WordPress exploit that allows new users to sign up even if new registrations are disabled. I just tested this by creating a new user account with my administrator account, and I did not receive an email notification.

The Joomla .htaccess file seems to address the specific Base64 technique I observed in WordPress:

## Mod_rewrite in use.

RewriteEngine On

## Begin - Rewrite rules to block out some common exploits.
# If you experience problems on your site block out the operations listed below
# This attempts to block the most common type of exploit <code>attempts</code> to Joomla!
#
# Block out any script trying to base64_encode data within the URL.
RewriteCond %{QUERY_STRING} base64_encode[^(]*\([^)]*\) [OR]
# Block out any script that includes a <script> tag in URL.
RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]
# Block out any script trying to set a PHP GLOBALS variable via URL.
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
# Block out any script trying to modify a _REQUEST variable via URL.
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
# Return 403 Forbidden header and show the content of the root homepage
RewriteRule .* index.php [F]
#
## End - Rewrite rules to block out some common exploits.

Does a WordPress have a similar mechanism to prevent a maliciously crafted URL from tricking the system into decoding a Base64 string?

On reviewing the server logs, I should clarify that the exploit appears to be a maliciously crafted http referrer, not url, that contained the base64 string.

I can decode the string from the referrer and see that it is executable PHP that includes a chmod, so this would seem to be an escalation of privileges attack. I also want to reiterate that there is a binary payload.

This seems like a really novel delivery mechanism that wouldn’t be necessary if the issue was a bad password.

@ipstenu

Yes, correct, the same WordPress access privileges on my server that allows WordPress to upload content also allowed these hackers to add new PHP files.

The server log excerpt I posted above lists the response code as 404 because I removed the malicious files and later observed a remote server issue a command to my site. The files did not exist and returned a 404 because I removed them, but I do have the files.

I don’t think it’s a brute force attack. I’ve noticed both of these exploits on a site that uses a login locker that kicks in after 5 failed access attempts.