Dealing with login attacks

For the past month or so, my main site (this one) plus a couple others I have on the same hosting account have been under constant brute force login attack. A long time ago I had set up the Limit Login Attempts plugin and it seemed to be helping. But it doesn’t stop the attacks. It just makes the attackers change their IP addresses more frequently.

Like a lot of WordPress developers, I have a number of sites I’ve thrown together to show someone something or to test things out. I usually clean them up when I am done with them but every once in a while I forget about them. It looks like one of the really old ones I had forgotten about was compromised in early August. As a result I had some malware all over my hosting account. Bah. What a PITA to clean up.

I did a few things fairly quickly:

  1. I deleted all of the sites I no longer needed. I should have done this a long time ago as there was some really old stuff just sitting around in my hosting account.
  2. I installed a fresh copy of the latest WordPress release to overwrite any files which were infected.
  3. I installed Securi Scanner plugin which was pretty good and identifying a bunch of files which shouldn’t be present. Unfortunately it doesn’t handle the wp-content folder (where plugins, themes, and uploads all live by default).

These things cleaned up a lot. This left me to find what else was suspect. The suspect code had a pattern to it where the one or two variables, $qV[] and $sF[], was always present. I used a couple “find” commands to find all of the PHP files which contained these variables.  Some I found, some I edited, some I simply removed.


find . -type f -name '*.php' -exec grep -l '$sF' {} \;
vi `find . -type f -name '*.php' -exec grep -l '$sF' {} \;`
rm `find . -type f -name '*.php' -exec grep -l '$sF' {} \;`

Similarly, there was a suspect Javascript files.  In the end, it took me the several hours a day across 2-3 days to clean up the mess.  Yuch.  Since this happened I’ve installed Sucuri Security and it seems to have helped.  The one downside I ran into was using some of the “hardening” features seems to have created a .htaccess file in the wp-includes folder which prevented the Visual Editor from working.  That took a little while to track down.

 

Email User 4.7.6 released

About a week ago I got a notice from WordPress.org letting me know Email Users had been de-listed from the plugin repository due to potential security exploit. While the odds were low, it was still a vulnerability which required fixing. This came at a time I was heading to Taiwan for work so my ability to fix it quickly was limited.

This morning I had some cycles to work on it while traveling home. I made the necessary fixes, committed them to Subversion, and informed WordPress.org. I just received a notice from WordPress that Email Users has been listed again. It may take a day or two to propagate through their cache.

Look for the version update notice on your Dashboard and I highly recommend installing this update. There is one other fix for users who use the Ithinx Groups plugin which had a bug in it.

wp-SwimTeam v1.45 released

Today I released wp-SwimTeam v1.45 which fixes a possible security problem I was alerted to as well as addresses a number of bugs.  The CSV roster export bug was the primary issue holding up getting this release out, I fixed the security problem last week.

It turns out I had implemented a method in both a parent class and (redundantly) in a child class as well.  The RE1, SDIF, and HY3 exports all (properly) used the method from the parent class but the CSV export was using the child class version.  It took me a while to sort it out as I was staring at the wrong code trying to determine what was wrong. It turns out, nothing was wrong, I was just looking in the wrong place.  Once I removed the redundant method declaration, everything resumed working as it should.

I think I have resolved all of the multi-site issues, please let me know if you run into any more.

This update is available via the WordPress Dashboard or from the WordPress Plugin Repository.

wp-Swimteam v1.45 beta 3 now available

Earlier today I received a report of a security bug in wp-SwimTeam.  While the security flaw is true, I believe the ability to take advantage of the exploit is pretty hard is it would require knowing the value of a WordPress site’s ABSPATH value.  It is certainly possible to guess the value in some cases but without knowing the proper value, the exploit simply fails.

None the less, I have fixed it employing WordPress Nonce Verification.  All downloads now perform a verification before proceeding.

There is still one know bug in this build, the CSV Roster export from the Manage tab doesn’t do anything.  The RE1, HY3, and SDIF Roster Exports all work correctly.

There may also still be some oddities when running on WordPress Multi-Site.  I’ve been chasing them down slowly, if anyone runs into anything please report it.

There is a good chance I’ll release a new version once I fix the CSV export in order to get the security fix out in production release.

wp-SwimTeam Beta (11568 downloads )

Understanding Email Users Options

Periodically I get support questions (on the WordPress Support forum) or comments here on my web site asking why Email Users doesn’t send email to some or all users as the plugin user expects it to.

Sometimes a user is dealing with an odd server restriction (e.g. email limits per hour, too many email addresses in the BCC field and others) but more frequently the target recipients don’t have their Email Users permissions set correctly.  This most frequently happens on a site where Email Users is added to a site that  already has a large set of users.

Email Users employs two options settings at the user level.  No matter what the settings are, any user within WordPress can always sent an email IF they are the only recipient.  This is by design.

The two settings are:

  • Allow Mass Emails:  Mass emails means that the user will accept email (Dashboard > Emails Users > Send to Users or Dasboard > Email Users > Send to Groups) where the resulting recipient list has more than one (1) recipient.  For a user in the WordPress database to receive email this permission must be enabled.
  • Allow Notifications:  Email Users has the ability to generate a notification email from a Post or Page (custom post types as well).  When using post or page notifications, only those users who have Notifications enabled will receive it.

Email Users has a default setting for these values which the WordPress admin can control.  It is on the plugin settings page (Dashboard > Settings > Email Users).

Email-Users-User-Options-1

These settings apply to all new users and when the plugin is activated the first time, are applied to all existing users.  The third option allows users to change their own settings by visiting their profile page.  When this option is enabled and a user visits their profile page, the following options are available for the user to change.

Email-Users-User-Options-2

 

The easiest way for the site administrator to review and change users’ settings, particularly on a site which has a lot of users, is to visit the User Settings Page (Dashboard > Email Users > User Settings).  This page will present all of the users (the number of users per page is set on the plugin settings page – see the image above for User Settings Table Rows) and their current settings.  The ability to perform bulk actions on a group of users is offered on this page.

Email-Users-User-Options-3

 

So if your users aren’t receiving emails, check their settings before heading down the debug path, often the solution is as simply as turning on the Mass Email option for the various users.

Google Forms Date and Time Fields

At some point Google added support for Date and Time fields to Google Forms.  When building the form, the Question Type now includes the “Date” and “Time” options.  These are pretty handy options because requesting dates and times from users is a very typical requirement.

GForm_SS_83Earlier this week a user posted on the WordPress Support Forum asking why their date field didn’t look the same on their web site using the plugin as it did when looking at the form within Google Drive.  The user assumed the plugin was doing something to change the form inputs.

The Google Forms plugin does not add or remove input fields (except the optional CAPTCHA field) – it simply retrieves the HTML from Google, strips of the content which falls outside of the form itself, and renders it within the WordPress context.

So why would the input fields be different when the form is viewed within WordPress versus viewing the Google Drive version of the form?

GForm_SS_85

Google Form in WordPress

GForm_SS_84

Native Google Form viewed in Firefox

Native Google Form viewed in Chrome.

Native Google Form viewed in Chrome.

As seen in the images above, the native Google Form is rendered differently in Google Chrome than it is in Firefox.  Having done some work with jQuery Mobile I know that Chrome recognizes HTML5 input tags where as Firefox does not.  I suspected this was the source of the problem.

I ran a couple of tests playing with cURL commands and different user agent strings and sure enough, Google is returning different HTML for different user agent strings.  I quickly added the user agent string to the parameters I was passing to the HTTP API to retrieve the HTML from Google and sure enough, the form, when viewed in Chrome, now matches what is seen when viewing the native form.

GForm_SS_87

I have committed the change to the plugin to pass the user-agent through the HTTP API.  This change will allow Chrome users to see the forms as intended.

What about other browsers?  Unfortunately the trick Google uses to add the date picker to the forms when viewed in Firefox, IE, or others which don’t recognize HTML5 input, or that Google thinks don’t support HTML5 input, isn’t easily passed through the HTTP API.

For now, I don’t see any simple way to solve this problem.  Over time it should go away as more browsers support HTML5 input types but for now, it is a limitation for non-Chrome users.  I fully expected it to work on the iPhone as the iOS browser is fully HTML5 compliant for input but it too is sent separate select inputs for the various fields.  I am not sure why, but it appears Google is treating their own browser differently than all other browsers.

The user-agent addition will be added to the next version of the plugin which will go out shortly with another validation bug fix.

 

 

Email Users with WP Better Emails

I recently worked with a user who reported Email Users wasn’t working correctly in conjunction with the WP Better Emails plugin.  The user posted a code sample he had used to correct the problem.

Looking at the code sample and his description of what WP Better Emails expected to receive as input, I added a new filter, mailusers_html_wrapper, that when present, would not add the default HTML wrapper around the email content but instead would expect the filter to perform the desired operation.  This new filter was released in the 4.7.2 version of Email Users.  There is an example usage of the new filter in my post announcing Email Users 4.7.2.

Shortly after releasing 4.7.2 I was contacted by the user again letting me know the filter didn’t solve the problem.  Confused, I download WP Better Emails to try and figure out what could possibly be wrong.  It took me the better part of two hours to trace through the WPBE code and figure out what it is doing – it turns out, WPBE wants emails to be “plain text” and not HTML formatted.  This is counter intuitive and had me looking in the wrong place for quite while.  It seems backwards to me but that is how the WPBE plugin works.

So how to make WPBE work with Email Users?  It turns out, it isn’t that hard at all.  There is a WordPress filter, wp_mail_content_type, which influences wp_mail(), the function WordPress uses to send email.

If a wp_mail_content_type filter is defined to force the content type to “text/plain”, Email Users and WPBE will work together correctly.  Below is the filter I defined and tested the interaction of Email Users and WPBE with.  Place this filter in your theme’s functions.php file or somewhere else where it will be loaded.

add_filter( 'wp_mail_content_type', 'mailusers_set_content_type' );
function mailusers_set_content_type( $content_type ) {
return 'text/plain';
}

Google Forms Custom Confirmation

I tend to get a lot of question regarding how to implement a custom confirmation page with the Google Forms plugin.  This morning I wrote up a step by step process which walks through all of the steps I use to define a confirmation page and make the process as smooth as possible for the end user.

Email Users v4.7.3-beta-1 available

This morning I posted beta-1 of Email Users v4.7.3.  This build addresses an out of memory error during plugin activation which was recently reported on the WordPress Support Forum.  This error would likely only happen on sites which very large numbers of users, 1500 or more, and is very dependent on the amount of memory the server has access to.

Email Users Beta (27347 downloads )