Alex Kladov

Hi @malayladu! I was wondering if you guys had a chance to look into this? Any updates?

Another option is to set the role option as “– No role for this site –”

Yeah, that’s an option. I simply removed the users manually. But I am still hoping that this process could be automated in the future, so that I won’t have to worry about cleaning up expired user accounts manually every time.

Hmm.. I guess I am confused about what HubSpot plugin actually does.

I thought it’s just necessary in order to connect WP to HubSpot services and allow form integrations, chat software etc. In which case why would we ever want an Editor-type user be able to sign in with their own account? I thought only admins should be able to modify those settings.

@mainwp Perfect! Thanks for resolving this so quickly! I just updated and can confirm that this v4.1.5.1 release fixed the bug.

@gnetworkau Use WP Rollback to revert MainWP Dashboard to v4.1.4.1, that will temporarily solve the problem.

@arndtk Unfortunately doesn’t seem like they are in a rush to fix this.. so either switch to a different menu plugin or wait till they will fix this up.

But whatever you do, 100% DO NOT use @sebastienrenaudeau suggestion to downgrade to v2.0.6. There is a very serious vulnerability in Quadmenu versions below v2.0.7, so if you downgrade, your website WILL get hacked. It might not happen immediately, but it definitely will happen eventually – it’s just a matter of time. The security issue they patched up is very serious & hundreds of sites got hacked because of it it.

We have cleaned out the wp-stream files from the File Manager in cPanel, and they were also in the opcache folder, so once you delete them, do another search as it looks like it puts them in a .bin file (trash maybe)

@artayay As I posted before, many many more files were infected, not just the files/folders you mentioned. Basically, you can expect that any files, in any child folder (no matter how deep) under your root website location (e.g. public_html), that had any of the below words in their filename, were probably infected:

1. index
2. header
3. footer

You need to run bulk Search & Remove on all files under root website folder (including all children), removing malicious code from any files that have that code injected into them. Then do bulk Search & Remove of any wp-stream-related files. Then search for all of the above in the DB, if necessary & remove any related suspicious/malicious code from DB too. If you fail to do either one of these, the problem may come back.

We have also run a new/clean Wordfence Scan and it shows the site as Clean at this time. We did not have the ch1,ch2,ch3 type files in the Hack mentioned in OP, but did see them earlier in the week, when it first happened. We rolled back to a clean install, but did not realize it was leaving self-replicating files, which almost acted like timebombs, even after a restore to a good backup.

@artayay Firstly, Wordfence is not bullet-proof, so it may have displayed a false positive. Also, as far as I know it doesn’t check DB for injections (I may be wrong). So if the attack focused on your DB, then it may have shown that everything was fine, when it wasn’t.

Also, sounds like you maybe have gotten hit with 2 separate attacks.

First via a recent File Manager plugin vulnerability & second via Quadmenu plugin vulnerability. And since the vulnerabilities & attacks were very similar in nature, it could be hard to tell them apart. So it may have looked like the problem came back, after you’ve already cleaned everything (which, to be honest, is also possible, since you could’ve missed a script/file & the hack replicated again). While in reality they were just 2 separate vulnerability exploits.

As far as I can tell, the most common File Manager attack seemed to have focused on modifying your DB, as well as some files. While the Quadmenu attack focused on php files alone.

However, keep in mind that both exploits could’ve been utilised by different attackers, so the injected code could’ve been different from site to site. So some people might have found that only their files were effected, some may have only found DB injections and some may have found both.

We are confident that we have resolved our issue, but will be monitoring the site and this thread for any new/additional info.

As long as you update all of your plugins & WP core to latest versions (as of today, 2020.03.01) + perform all of the sanitisation steps I outlined in my previous posts (and possibly also in this article), you should be good.

Many thanks. Yes, one one of my development servers, i have opened 4 sites and have followed all your instructions including wordfence free plugin. There is no re-occurrence so far.

@letswebify Awesome! I am glad I could help & you got it all sorted!

Pls guide how to check and remove db infection, considering we have only phpmyadmin for db administration.

First of all, I did not see any indication of DB manipulation, so you might not need to do anything. If your site seems to be working now & not reverting back to hacked state, then you probably purged everything that needed to be purged.

But if you want to make sure, here are my 2c regarding sanitising the DB.

DB cleansing is much trickier, especially considering that I haven’t noticed any DB manipulation myself with this attack, so I don’t know what to look for. What I’d do is I would just go through wp_posts table and look if there is anything unusual going on with the entries, specifically the post_content column. You can use phpMyAdmin’s search feature to search your entire DB.

Something I’d look for is:

1. wp-stream.php or wp-stream string anywhere in the DB.
2. Weird JS script tags at the very beginning of any entries under post_content column in wp_posts table.
3. Any small, but unique/recognisable snippet from the malicious PHP code anywhere in the DB.
4. (if you can figure this one out) Get a couple of consecutive chr values used in the malicious code, combine them with a coma in between (e.g. 115,99,114) and look for those anywhere in the DB (search variant both with spaces and without, e.g. 115,99,114 & 115, 99, 114).
5. Basically look for anything recognisable, taken from the malicious code anywhere in the DB (sorry, I wish I could be more specific, but I already cleansed my site & only vaguely remember what the malicious code looked like).

If you find something fishy, replace it. You can either do with with phpMyAdmin’s built-in “Find and replace” tool (only if your phpMyAdmin version is relatively up-to-date) or you can run an SQL command below to purge it (I personally prefer this, since I have more control this way):

UPDATE table_name set column_name = REPLACE(column_name, "search_for_this_string", "");

Replace table_name & column_name with your target table & column and search_for_this_string with malicious code you want to purge from the table (make sure to escape double quotes, ", if they are present inside the string). However, DO THIS AT YOUR OWN RISK. You can brick your whole site by messing around in the DB, without understanding of SQL. Export/Backup your entire DB, before you do anything.

Here is an article dealing with a very similar attack, where the code got injected both into PHP files & DB entries. Read their article (they also posted a YouTube video) & follow the steps, but look for this “Quadmenu attack”-related activity & code.

• This reply was modified 3 years, 9 months ago by Alex Kladov. Reason: fixed typos & modified instructions a little
• This reply was modified 3 years, 9 months ago by Alex Kladov. Reason: added a reference to phpMyAdmin's "Find and replace" tool

@letswebify And you are sure you replaced all of the malicious code?

Another final step I forgot to mention is installing a Wordfence Security plugin and running a full scan of your site files with it (after you manually clean up the code, of course). It will help you uncover any other potential hidden vulnerabilities & will tell you which steps you may take to resolve them.

It may also be handy to run a search in your DB (via phpMyAdmin, for example) to see if maybe an attacker inserted code directly into your DB as well. But at that point we are getting pretty technical and you can really mess things up, if you don’t know what you are doing. In which case the best course of action is either hire security experts to clean up the mess for you, or to simply rollback your site to a backup prior to the break-in (hopefully you have it & also keep it off-site on your remote cloud storage/Google Drive/Dropbox).

Are you 100% sure you cleaned ALL of the malicious code from your website’s code base? Because if not, the problem would keep coming back, as the code seems to be self-replicating.

WHAT THIS ATTACK DID:

The attack focused on files containing the following words in their file names (not sure if the list is 100% complete, these were just my findings):

1. index
2. header
3. footer

So files like index.php (an empty/almost empty file in many directories), wp-blog-header.php, admin-header.php, admin-footer.php and many many others that have one of those words in the filename, they all got effected.

The attack replaced the 1st line of code that has <?php tag with a malicious code that looks like <?php MALICIOUS_CODE_HERE ?><?php. Sometimes, where there was no <?php tag on the 1st line (like in empty index.php files or files that don’t start with php code right away), they simply inserted the malicious code (<?php MALICIOUS_CODE_HERE ?> at the start of the file.

The attackers also uploaded malicious wp-stream.php file in various places & modified wp-config.php file.

HOW TO CLEAN YOUR SITE FROM THIS MALICIOUS CODE:

If your web hosting provider has a global file Search & Replace feature, then skip steps 1 & 7 and do everything from your cPanel’s file manager.

1. Pull your ENTIRE website code base to your computer.
2. Open the root directory in a code/text editor that supports multi-file Search & Replace.
3. Find one of the effected files and copy the malicious code that looks like <?php MALICIOUS_CODE_HERE ?> to your clipboard (make sure to not copy the regular <?php opening tag at the end of the line, as it’s supposed to be there).
4. Run multi-file Search & Replace on all files (paste copied code into Search For field and leave Replace With field empty), removing the malicious <?php MALICIOUS_CODE_HERE ?> code.
5. Find & remove wp-stream.php file anywhere in your code base.
6. Open your wp-config.php file and compare it against what it’s supposed to look like. Malicious code was inserted somewhere around the /* That's all, stop editing! Happy publishing. */ line for me, so look a the core’s code and compare it against what you have. If yours is different, replace it with code from the matching clean config lines from the core wp-config-sample.php file.
7. Once all of the above is done, upload the changed site files back onto your server & you should be good to go.

• This reply was modified 3 years, 9 months ago by Alex Kladov. Reason: fixed broken HTML tags
• This reply was modified 3 years, 9 months ago by Alex Kladov. Reason: added missing info about the attack
• This reply was modified 3 years, 9 months ago by James Huff.

I am almost 100% sure that it has something to do with this change right here.

They changed the key from nonce to login-nonce & action string from quadmenu to quadmenu-login, but forgot to reflect that change during a security check in this file on line 102.

I believe line 102 should be updated to this:

    if (!check_ajax_referer('quadmenu-login', 'login-nonce', false)) {

Also WARNING! DO NOT DOWNGRADE TO v2.0.6! There is an VERY SERIOUS/CRITICAL security vulnerability present in versions below 2.0.7! Hundreds of websites just got hacked because of it (one of my clients did too). So UPGRADE to 2.0.7 IMMEDIATELY and wait for a fix for this problem. It’s better to have a broken login box, than to have your site broken completely.

• This reply was modified 3 years, 9 months ago by Alex Kladov. Reason: removed non-working php tag in the markdown code block
• This reply was modified 3 years, 9 months ago by Alex Kladov. Reason: fixed broken links
• This reply was modified 3 years, 9 months ago by Alex Kladov. Reason: fixed another missed broken link

I’ve got the same errors being logged over and over too:

[29-Nov-2020 12:30:24 UTC] PHP Warning:  strpos() expects parameter 1 to be string, array given in /home/website/public_html/wp-content/plugins/litespeed-cache/src/optimize.cls.php on line 227
[29-Nov-2020 12:30:24 UTC] PHP Warning:  strpos() expects parameter 1 to be string, array given in /home/website/public_html/wp-content/plugins/litespeed-cache/src/optimize.cls.php on line 227
[29-Nov-2020 12:30:24 UTC] PHP Warning:  strpos() expects parameter 1 to be string, array given in /home/website/public_html/wp-content/plugins/litespeed-cache/src/optimize.cls.php on line 231

Running PHP v7.4, WP v5.5.3 & LiteSpeed Cache v3.5.2

Hi Malay,

Do you have any specific email which WordPress (or other plugin) is sending to users? We will be able to implement a solution After that information.

One example that comes to mind is iThemes Security plugin’s admin notifications. E.g. in case of site lockouts or that suspicious file changes. I set for those notifications to be sent out to admins and every admin got them, even the ones that were expired, which is obviously an issue.

We can do that but the problem is, some plugins are also tracking the user activities. If we delete temporary users from the table, the activity of that user will also be deleted and the store admins don’t know what happened on their store.

That makes total sense, I didn’t even think that some people might want to keep record of that info. In that case, why not give the admin an option to select whether they want to disable the temporary user account or simply wipe it completely upon expiry? That way, we can decide, so if we need those activity logs, we can keep the user simply disabled (it can even be the default behaviour, or you can let admins configure what the default will be). So if we know that it’s some support account that won’t even be changing anything on the site, we can set for that account (and all of it’s meta) to self-destruct upon expiry.

Regards,
Alex

@janimo I didn’t see any solution, even though someone marked this as resolved. I had to re-write my JS responsible for add-to-cart action, to check for this specific issue caused by this plugin.

@qtwrk here you go https://paste.ubuntu.com/p/CPkdDgm6vJ/

Hi @qtwrk,

I have just sent the report to LiteSpeed. The number is CWOBAUUB.

Cheers,
Alex