Undefined array key “HTTP_REFERER”

[gunfacts]

Thanks @scrambler, but … ough!

When we were first mass-hacked last year, we had to go through all that (as well as updating all plugins, WP versions, etc.) and clearing old stuff (and changing passwords, @weaver). Hate the idea of redoing everything instead of finding a surgical approach.

@weaver, I don’t have anything against WordFence, but I’m hesitant of any automated fixes. If they get something wrong, I can get hosed. Not off-the-table, but a last resort.

[scrambler]

I am not sure what you are talking about.

Deleting and reinstalling theme and plugins is extremely easy and quick (nothing to reconfigure are all configurations are preserved in the database).

A lot easier than the surgical approach and much more efficient.

And I think you fears on Wordfence security are unfounded. Never had or heard of an issue with it.

[gunfacts]

I found a surgical approach. You might want to log this for other customers.

(FIRST: WordFence spotted the appending to functions.php, but on my other website, where I use a child theme, if also identified my custom functions.php file as foreign. Needless to say, it I had allowed it to delete that file, heck would have followed).

This malware not only appends the functions.php file, it also creates a directory and file in /wp-content/plugins. In this case, /plugins/weaver-xtreme-template-plugin.

In there is one file that single function to load_template and an add_action call.

If you comment both those lines out:

1. The warning messages go away.
2. You can rename/delete the weaver-xtreme.template file.

I’ll fix my other sites tomorrow after I see if the test site gets reinfected … or worse.

[gunfacts]

1. Many thanks again.
2. Please not that though AddThis might have problems, they were not involved in the warning messages which started this thread.
3. I have performed the surgical approach on three of my four site (the 4th is the one used in this thread, so it is still infected), and it works well plus it is simple if you have command line access.
4. As @weaver warned, the hack does modify the active_plugins row in wp_opations. I have not cleaned that out.
5. It also infected Weaver Pro II (I used that before Xtreme on one site).

If I recall the execution order of WP correctly, what their hack does is:

1. Using code inserted at the bottom functions.php, it:
   1. Unzips a file named weaver-extreme-template which has PHP code
   2. Loads that content via load_template
2. It also creates uses plugin logic
   1. Creates a plugin named weaver-xtreme-template-plugin
   2. Adds that the the active_plugins row in wp_options
   3. The plugin
      1. Also finds and loads the code from the zip file
      2. Uses add_action to engage

If you good folks are at all interested, I could share the core files from the remaining infected site.

[hkp]

@gunfacts

Thanks for the update.

Just curious, from the dates on the uploaded files, a) were all your sites infected at the same time and b) approximately how long has it been since the infection, before you saw there was a problem?

Regards!

 

 

[gunfacts]

Sadly, @hkp, I didn’t preserve the files from the cleaned sites, so I can’t compare now.

[Weaver]

I just read an article about a fairly big hack to one theme + plugin. The hack in that case involved a theme that somehow was allowing users to set/request a different member levels than simply just a member – perhaps a custom membership level with slightly more privileges than a simple member. That would be custom PHP code on the part of the theme/plugin, and it was apparently defective.

So it seems one attack path to WP is to try to get admin access, which obviously is a problem. Another hack path has been to attack hosting companies via shared servers. That is unlikely to be successful with reputable hosts.

Weaver Xtreme and plugins rely completely on standard WP login access, and only admins can change/add privileges to users/members. The only way any user gets access to a Weaver Xtreme site is using standard WP the user profile editor, and presumably that has been pretty well protected.

I don’t think Weaver has a big enough user base to be a major target. Even though the hack you had involved creating plugins with Weaver in their name, I would suspect that at a higher level, a hack once in could easily determine the theme name and create files that look like they belong to whatever theme is in use. That would be an attempt to hide in plain sight by trying to appear to be legit files.

Wordfence does not need to be used to do auto fixes, but it is pretty good at finding files an directories that don’t belong. Their strategy is to keep up with the latest official version of WP, themes, and plugins, and compare the files on your site to see if they are really legit. I don’t know if they do a 100% comparison, or simply use a length or checksum approach. But is has detected obsolete files on my own sites fairly often – ususally old plugins.

[user]

@Weaver  Thanks for the update.  Food for thought…..

The Covid lockdown certainly brought increased and more sophisticated hacking attempts.  Especially through and in emails.

Of our front door attacks, 1/3 are now Brute Force User Emulation and 2/3 are WP Comments.

The increases caused us to remove all WP Contact Forms etc. and domain email contact addresses, and change to a Gmail account for public use.  Not so good for the Brand Image… but users don’t seem to notice and continue to continue to correspond to the Gmail account, even after contacted from the domain account.

The other things we did to aid Security were:

1. Remove the WP “admin” named account completely from the DB.
2. Establish new admin accounts with un-guessable names.
3. Make sure these admin accounts are never used publicly (e.g. as a post’s author).
4. Make sure the site owners names only have author (or lower) accounts, NEVER admin level accounts.
5. Downgrade all inactive authors/users to Subscribers.
6. Vary the username formats as much as possible.
7. Require long high secure passwords for all.
8. Install the “iThemes Security” plugin and change WP’s /wp-admin/ sign-in slug to a new random/new-sign-in-location-here/ slug for the WP  admin sign-in url.
9. Receive notifications of all new WP admin sign-ins.
10. Set the 404 page as the “About” page.
11. Keep the theme and plugins up to date.
12. Set all plugin updates to manual, so all updates can be monitored and the site checked for problems immediately at the updating.
13. Keep the site continually and automatically backed up in remote locations, and occasionally test that the backup recovery install actually woks.

Hope this helps.

If anyone has more to add to the list, I’d love to know about them!

Some say “Code is Poetry” but I say, “Good Security is a good night’s sleep…..”

[gunfacts]

First, thanks to all for jumping into this mess. You quality of support is why I recommend you to others.

There seems to be no way to determine the vector of this theme+plugin hack. Once infected, all my sites were infected, but I can find no solid way to determine the dates (since I cleaned-up files before thinking to look at the create dates). But that it nailed (a) all of my sites (b) on the same shared server and (c) all were using a Weaver theme, it gets even harder to peg.

That said, the sundry sites were on different versions of WP and one was likely still on Weaver II Pro at the time. Again, might not have been Weaver specific given the structure of the file and plugin naming conventions.

Since the hack required uploading a zip file into a directory of each of the sites, I would intuitively suspect a server-level hack (jumping from WP code in one site to infect another site seems unlikely).

Anyway, made sure to change my SSH and FTP passwords ass well as admin passwords and such. Also deleted all spammy users that created null accounts long ago when we had  active blogs on other sites.

[Author]

Posts