Month: November 2023

Sonicwall Configuring High Availability Monitoring settings

Description

On the High Availability | Monitoring page, you can configure both physical and logical interface monitoring. By enabling physical interface monitoring, you enable link detection for the designated HA interfaces. The link is sensed at the physical layer to determine link viability. Logical monitoring involves configuring the SonicWall to monitor a reliable device on one or more of the connected networks. Failure to periodically communicate with the device by the Active unit in the HA Pair will trigger a Failover to the Idle unit. If neither unit in the HA Pair can connect to the device, no action will be taken.

The Primary and Backup IP addresses configured on this page are used for multiple purposes.

  • As independent management addresses for each unit (supported on all physical interfaces).
  • To allow synchronization of licenses between the Idle unit and the SonicWall licensing server .
  • As the source IP addresses for the probe pings sent out during logical monitoring.

When using logical monitoring, the HA Pair will ping the specified Logical Probe IP address target from the Primary as well as from the Backup SonicWall. The IP address set in the Primary IP Address or Backup IP Address field is used as the source IP address for the ping. If both units can successfully ping the target, no Failover occurs. If both cannot successfully ping the target, no Failover occurs, as the SonicWalls will assume that the problem is with the target, and not the SonicWalls. But, if one SonicWall can ping the target but the other SonicWall cannot, the HA Pair will Failover to the SonicWall that can ping the target.

Resolution for SonicOS 7.X

This release includes significant user interface changes and many new features that are different from the SonicOS 6.5 and earlier firmware. The below resolution is for customers using SonicOS 7.X firmware.

The configuration tasks on the High Availability | Monitoring page are performed on the Primary unit and then are automatically synchronized to the Backup.

  1. Login as an administrator to the SonicOS user interface on the Primary SonicWall.
  2. Go to Device In top menu , navigate to High Availability | Monitoring Settings .
  3. Click Configure icon for an interface on the LAN, such as X0.
  4. To enable link detection between the designated HA interfaces on the Primary and Backup units, leave the Enable Physical / Link Monitoring checkbox selected.


    Image
  5. In the Primary IP Address field, enter the unique LAN management IP address of the Primary unit.
  6. In the Backup IP Address field, enter the unique LAN management IP address of the Backup unit.

    Configuring unique management IP addresses for both units in the HA Pair allows you to log in to each unit independently for management purposes. Note that non-management traffic is ignored if it is sent to one of these IP addresses. The Primary and Backup SonicWall security appliances’ unique LAN IP addresses cannot act as an active gateway; all systems connected to the internal LAN will need to use the virtual LAN IP address as their gateway.

    The management IP address of the Backup/Idle unit is used to allow license synchronization with the SonicWall licensing server, which handles licensing on a per-appliance basis (not per-HA Pair). Even if the Backup unit was already registered on MySonicWall before creating the HA association, you must use the link on the Device | Settings | Licenses page to connect to the SonicWall server while accessing the Backup appliance through its management IP address.
  7. Select the Allow Management on Primary/Backup IP Address checkbox. When this option is enabled for an interface, a green icon appears in the interface’s management column in the Monitoring Settings table on the High Availability | Monitoring page. Management is only allowed on an interface when this option is enabled.
  8. In the Logical Probe IP Address field, enter the IP address of a downstream device on the LAN network that should be monitored for connectivity.Typically, this should be a downstream router or server. (If probing is desired on the WAN side, an upstream device should be used.) The Primary and Backup appliances will regularly ping this probe IP address. If both can successfully ping the target, no failover occurs. If neither can successfully ping the target, no failover occurs, because it is assumed that the problem is with the target, and not the SonicWall appliances. But, if one appliance can ping the target but the other appliance cannot, failover will occur to the appliance that can ping the target.

     NOTE: The Primary IP Address and Backup IP Address fields must be configured with independent IP addresses on a LAN interface, such as X0, (or a WAN interface, such as X1, for probing on the WAN) to allow logical probing to function correctly.
  9. Optionally, to manually specify the virtual MAC address for the interface, select Override Virtual MAC and enter the MAC address in the field. The format for the MAC address is six pairs of hexadecimal numbers separated by colons, such as A1:B2:C3:d4:e5:f6. Care must be taken when choosing the Virtual MAC address to prevent configuration errors.

    Note:There is a design change on Gen7 in the way MAC Addresses are handled for the HA native vs. monitoring. GEN7 uses the Virtual MAC for all interface IPs, both the Virtual IPs and Primary / Secondary Monitoring IPs, Hence the MAC addresses of the X0 Interface IP(Or any VLAN under X0), will have the same MAC address as of the Primary firewall X0 monitoring IP, the same applies for all the interfaces X1, X2, wherever monitoring IPs will be configured.

    Image
  10. To configure monitoring on any of the other interfaces, repeat the above steps.
  11. When finished with all High Availability configuration, click Accept. All settings will be synchronized to the Idle unit automatically.

Resolution for SonicOS 6.5

This release includes significant user interface changes and many new features that are different from the SonicOS 6.2 and earlier firmware. The below resolution is for customers using SonicOS 6.5 firmware.

The configuration tasks on the High Availability | Monitoring page are performed on the Primary unit and then are automatically synchronized to the Backup.

  1. Login as an administrator to the SonicOS user interface on the Primary SonicWall.
  2. Go to Manage In top menu , navigate to High Availability | Monitoring Settings .
  3. Click Configure icon for an interface on the LAN, such as X0.
  4. To enable link detection between the designated HA interfaces on the Primary and Backup units, leave the Enable Physical / Link Monitoring checkbox selected.
    Image
  5. In the Primary IP Address field, enter the unique LAN management IP address of the Primary unit.
  6. In the Backup IP Address field, enter the unique LAN management IP address of the Backup unit.

    Configuring unique management IP addresses for both units in the HA Pair allows you to log in to each unit independently for management purposes. Note that non-management traffic is ignored if it is sent to one of these IP addresses. The Primary and Backup SonicWall security appliances’ unique LAN IP addresses cannot act as an active gateway; all systems connected to the internal LAN will need to use the virtual LAN IP address as their gateway.

    The management IP address of the Backup/Idle unit is used to allow license synchronization with the SonicWall licensing server, which handles licensing on a per-appliance basis (not per-HA Pair). Even if the Backup unit was already registered on MySonicWall before creating the HA association, you must use the link on the System | Licenses page to connect to the SonicWall server while accessing the Backup appliance through its management IP address.
  7. Select the Allow Management on Primary/Backup IP Address checkbox. When this option is enabled for an interface, a green icon appears in the interface’s management column in the Monitoring Settings table on the High Availability | Monitoring page. Management is only allowed on an interface when this option is enabled.
  8. In the Logical Probe IP Address field, enter the IP address of a downstream device on the LAN network that should be monitored for connectivity.Typically, this should be a downstream router or server. (If probing is desired on the WAN side, an upstream device should be used.) The Primary and Backup appliances will regularly ping this probe IP address. If both can successfully ping the target, no failover occurs. If neither can successfully ping the target, no failover occurs, because it is assumed that the problem is with the target, and not the SonicWall appliances. But, if one appliance can ping the target but the other appliance cannot, failover will occur to the appliance that can ping the target.

     NOTE: The Primary IP Address and Backup IP Address fields must be configured with independent IP addresses on a LAN interface, such as X0, (or a WAN interface, such as X1, for probing on the WAN) to allow logical probing to function correctly.
  9. Optionally, to manually specify the virtual MAC address for the interface, select Override Virtual MAC and enter the MAC address in the field. The format for the MAC address is six pairs of hexadecimal numbers separated by colons, such as A1:B2:C3:d4:e5:f6. Care must be taken when choosing the Virtual MAC address to prevent configuration errors.When the Enable Virtual MAC checkbox is selected on the Manage | High Availability| Base Setup page, the SonicOS firmware automatically generates a Virtual MAC address for all interfaces. Allowing the SonicOS firmware to generate the Virtual MAC address eliminates the possibility of configuration errors and ensures the uniqueness of the Virtual MAC address, which prevents possible conflicts.
  10. To configure monitoring on any of the other interfaces, repeat the above steps.
  11. When finished with all High Availability configuration, click Accept. All settings will be synchronized to the Idle unit automatically.

Resolution for SonicOS 6.2 and Below

The below resolution is for customers using SonicOS 6.2 and earlier firmware. For firewalls that are generation 6 and newer we suggest to upgrade to the latest general release of SonicOS 6.5 firmware.

The configuration tasks on the High Availability | Monitoring page are performed on the Primary unit and then are automatically synchronized to the Backup.

  1. Login as an administrator to the SonicOS user interface on the Primary SonicWall.
  2. In the left navigation pane, navigate to High Availability | Monitoring.
  3. Click Configure icon for an interface on the LAN, such as X0.
  4. To enable link detection between the designated HA interfaces on the Primary and Backup units, leave the Enable Physical Interface Monitoring checkbox selected.
    ImageImage
  5. In the Primary IP Address field, enter the unique LAN management IP address of the Primary unit.
  6. In the Backup IP Address field, enter the unique LAN management IP address of the Backup unit.

    Configuring unique management IP addresses for both units in the HA Pair allows you to log in to each unit independently for management purposes. Note that non-management traffic is ignored if it is sent to one of these IP addresses. The Primary and Backup SonicWall security appliances’ unique LAN IP addresses cannot act as an active gateway; all systems connected to the internal LAN will need to use the virtual LAN IP address as their gateway.

    The management IP address of the Backup/Idle unit is used to allow license synchronization with the SonicWall licensing server, which handles licensing on a per-appliance basis (not per-HA Pair). Even if the Backup unit was already registered on MySonicWall before creating the HA association, you must use the link on the System | Licenses page to connect to the SonicWall server while accessing the Backup appliance through its management IP address.
  7. Select the Allow Management on Primary/Backup IP Address checkbox. When this option is enabled for an interface, a green icon appears in the interface’s Management column in the Monitoring Settings table on the High Availability | Monitoring page. Management is only allowed on an interface when this option is enabled.
  8. In the Logical Probe IP Address field, enter the IP address of a downstream device on the LAN network that should be monitored for connectivity.Typically, this should be a downstream router or server. (If probing is desired on the WAN side, an upstream device should be used.) The Primary and Backup appliances will regularly ping this probe IP address. If both can successfully ping the target, no failover occurs. If neither can successfully ping the target, no failover occurs, because it is assumed that the problem is with the target, and not the SonicWall appliances. But, if one appliance can ping the target but the other appliance cannot, failover will occur to the appliance that can ping the target.

     NOTE:The Primary IP Address and Backup IP Address fields must be configured with independent IP addresses on a LAN interface, such as X0, (or a WAN interface, such as X1, for probing on the WAN) to allow logical probing to function correctly.
  9. Optionally, to manually specify the virtual MAC address for the interface, select Override Virtual MAC and enter the MAC address in the field. The format for the MAC address is six pairs of hexadecimal numbers separated by colons, such as A1:B2:C3:d4:e5:f6. Care must be taken when choosing the Virtual MAC address to prevent configuration errors.When the Enable Virtual MAC checkbox is selected on the High Availability| Advanced page, the SonicOS firmware automatically generates a Virtual MAC address for all interfaces. Allowing the SonicOS firmware to generate the Virtual MAC address eliminates the possibility of configuration errors and ensures the uniqueness of the Virtual MAC address, which prevents possible conflicts.
  10. Click OK.
  11. To configure monitoring on any of the other interfaces, repeat the above steps.
  12. When finished with all High Availability configuration, click Accept. All settings will be synchronized to the Idle unit automatically.

Related Articles

Categories

Source :
https://www.sonicwall.com/support/knowledge-base/configuring-high-availability-monitoring-settings/170505779399776/

Know Your Malware Part Two – Hacky Obfuscation Techniques

Ram Gall
November 1, 2023

In the first post in this series, we covered common PHP encoding techniques and how they’re used by malware to hide from security analysts and scanners. In today’s post, we’re going to dive a little bit deeper into other obfuscation techniques that make use of other features available in PHP.

Obfuscation Redux

In the first post in this series, we defined Obfuscation as the process of concealing the purpose or functionality of code or data so that it evades detection and is more difficult for a human or security software to analyze, but still fulfills its intended purpose. One of the main contributing factors to the popularity of PHP is its ease of use, but the same functionality that makes it easy to use also makes it easy to abuse, often in ways that were never intended.

The techniques covered in this post are often simpler and “hackier” than the ones listed in the previous article, and most of them are less reliable as indicators of malicious activity individually, as several of them typically need to be combined in order to achieve sufficient obfuscation. These techniques are also often easier for a human analyst to spot, but they are also more difficult to detect using scanning tools due to the wide variety of permutations available. Such simpler obfuscation methods can also be creatively combined with encoding techniques, granting malware authors a formidable array of tactics to avoid detection.

While it is not practical to cover every possible technique in active use, this article will detail the more commonly found methods, and help illustrate the wide range of possibilities when decoding obfuscated malware. Several of the methods we will cover today, such as comment abuse, can be combined into almost infinite variations with minute changes, thus rendering them completely undetectable to traditional hash-based malware scanning and even partially slowing down regular expression-based scanning of the type used by Wordfence.

Fortunately, while these methods do make analysis more difficult, and can slow down scanning, their presence in certain combinations is a strong signal of malicious activity, and the malware detection signatures used by the Wordfence plugin and Wordfence CLI are tuned to detect these combinations with astoundingly few false positives. Wordfence CLI in particular is useful in these cases, as it is highly performant and can run multithreaded jobs, compensating for any speed penalties imposed by these techniques.

Comment Abuse

PHP has several methods of adding code comments that you may already be familiar with. Well-commented code is considered a best practice, as it makes it much easier to maintain software and pay off technical debt, but comments can also be used for illicit purposes.

PHP uses three styles of comments:

//, denoting a single line comment that ends on the next line.

#, likewise a single line comment that ends on the next line, though this is less common than ‘//’.

/*, the beginning of a multiline comment, which can only closed with */.

Multiline comments are particularly useful to malware authors because they are ignored by PHP, and do not have to extend over multiple lines. This means that an attacker can “break up” their code to evade scanners using comments. For instance, the following code block prints “Hello, World!”:

1234<?phpecho/*blah*/"Hello, World!"/*blah*/;

While this is a very basic example, more complicated examples can be found in real malware, such as the following snippet, which makes use of several additional obfuscation techniques, including octal escape sequences and invisible null bytes:

12,<?php        function/*ti*/ed_ixpn(){     echo/* o_lpl*/20508;  }$disdcrxh_/* ohgvr*/= 'disdcrxh_'/*  _jnsm  */^       '';$zggkgqda= "\146".     "\151".  $disdcrxh_(361-253)   ./* qts   */"e"."_".$disdcrxh_(564-452)/* rxw*/.     $disdcrxh_(1006-889)     . "t".$disdcrxh_(952-857) ./*  w  */"c".$disdcrxh_(111) ./*fcup  */"n".$disdcrxh_(162-46)/*   djtrl   */./*  pwdn  */"e".$disdcrxh_(407-297)      .      $disdcrxh_(854-738) . $disdcrxh_(115);

While we’re not going to fully analyze this malware today, it already presents problems for many scanners. For instance, a scanner searching for the very first line of code, function ed_ixpn() would fail to find it because of the comments. While detection using regular expressions, such as the ones used by the Wordfence Plugin scanner and Wordfence CLI are capable of detecting malware of this type, it still imposes a performance penalty on detection due to the enormous number of possible variations.

Concatenation Catastrophe

PHP makes string concatenation very simple via the dot . operator. This allows programmers to join two separate strings with minimal hassle. For instance, the following code outputs “Hello, World!”:

1<?php echo“He”.”llo,”.”wor”.”ld”;

There are a large number of legitimate use cases for string concatenation, so it’s generally only an indicator of malicious activity when combined with several other obfuscation techniques. The malware sample we shared earlier provides a good example of this, with octal encoding concatenated with the return values of various functions, which we’ll get to in a later section.

Index Fun

PHP, like most languages, stores text strings as arrays of characters, each with a defined position or index. This makes it possible to assemble arbitrary commands and data from a string containing the required characters, using the array index of each character and the concatenation operator. For instance, the following code prints “Hello, World!”:

1234<?php$string="Wow, what a cool Helpful research device!";echo$string[17].$string[18].$string[19].$string[19].$string[1].$string[3].$string[4].$string[0].$string[1].$string[25].$string[15].$string[34].$string[40];

PHP arrays start with an index of 0, meaning that $string[0] in the example above would be “W”, the first letter of “Wow, what a cool Helpful research device!”. By concatenating letters from different parts of that text string, it’s possible to assemble an entirely different text string.

This method can be very helpful for hiding the underlying text being assembled from human researchers and security scan tools alike, and though it does have the occasional legitimate use in selecting chunks of text, when used extensively it is a strong indicator of malicious activity, though it typically needs to be combined with additional techniques such as evaluating the resulting string or passing it to a function.

Math, Not Even Once

PHP allows mathematical operations within other functionality. One of the interesting features in the malware snippet – $disdcrxh_(564-452) – demonstrates this, with it turning out as $disdcrxh_112 due to the subtraction of 564 and 452 in the parenthesis. This functionality can likewise be combined with the string index technique mentioned above. For example, the following code prints out “Hello, World!”:

123<?php$string="Wow, what a cool Helpful research device!";echo$string[(15+2)].$string[(20-2)].$string[(10+9)].$string[(29-10)].$string[(5-4)].$string[(1+2)].$string[(2+2)].$string[(5-5)].$string[(12-11)].$string[(5*5)].$string[(5*3)].$string[34].$string[(160/4)];

This adds an additional obfuscation layer that can make it even more difficult to determine the code’s functionality without executing it. However, it is incredibly rare for this type of code to be used legitimately, so the presence of this technique is typically an indicator of malicious activity.

String Reversals

One of the most basic functions in PHP’s text string manipulation libraries is strrev, which is used to reverse strings of text. For instance, the following code snippet prints out “Hello, World!”:

1<?php echostrrev("!dlroW ,olleH");

While not particularly effective at obfuscation on its own, it can be combined with the techniques in this article as well as nearly all of the techniques in our previous article on encoding to make it even more difficult to decode malicious functionality. While it has a number of legitimate use cases, the presence of strrev alongside two or more additional encoding or obfuscation techniques is often a reliable indicator of compromise.

Variable, Dynamic, and Anonymous Functions

PHP has the ability to use variables to store function names as variables and then invoke those functions using the variable. This is widely used by legitimate software, but can also be combined with several other techniques, such as string concatenation, in which case it is often an indicator of malicious activity. For instance, the following code snippet prints out “Hello, World!”:

123<?php $hello='pri'.'ntf';$string='Hello, World!';$hello($string);

This can also be combined with dynamic function invocation using methods such as call_user_func, which accepts a function for its first parameter and any arguments to be passed to that function in subsequent parameters. As with variable function names, this is widely used in legitimate code, but it can still make analysis more difficult, especially for automated tools looking primarily for more basic function call syntax. For example, the following code snippet prints out “Hello, World!”:

1234<?php $hello='pri'.'ntf';$string='Hello, World!';$call='call_user_func';$call($hello, $string);

Finally, PHP also allows for anonymous functions, which are exactly what they sound like – functions without a name. These can be combined with variable assignment as shown:

12345<?php$hello= function() {    printf("Hello, World!");};$hello();

While anonymous functions are widely used in legitimate code, it is possible to use them in combination with other features to make it more difficult for automated scanning tools or human analysts to keep track of code flow and as such are useful for obfuscation.

We’ve begun to combine obfuscation layers in our examples to provide a better picture of the type of obfuscation often found in the wild, and there’s still more to come.

GOTO Labels

One of the oldest and most basic code functions is the goto statement. While some legitimate software still uses GOTO statements, the functionality is considered poor coding practice and is not widely used, though it reflects how the code operates at a fundamental level far more accurately than more modern syntax. Its primary use in obfuscation is similar to comment abuse in that it breaks up the code so that it is more difficult to determine the control flow.

For example, the following code snippet prints out “Hello, World!” if and only if $_GET['input'] is present and set to ‘hello’, otherwise it prints “Sorry”:

123456789101112131415<?php $hello='pri'.'ntf';$string='Hello, World!';if(isset($_GET['input']) && $_GET['input']=='hello'){gotoprintyes;}elsegotoprintno;printyes:echo"Hello, World!";gotoend;printno:echo"Sorry";end:?>

Include/Require of non-PHP files

PHP uses the include and require functions to include and execute code located in a separate file. This is almost universally used, and occasionally the .inc extension is used instead of PHP for files to be included. However, one particular feature that is ripe for abuse is that PHP will include files with any extension and execute them as code. This allows attackers to upload the bulk of their malicious code as a file with an allowed extension, often an image extension such as .ico or .png, and then simply include that file from a loader file with a PHP extension. Inclusion of files without a .php or .inc extension is thus almost always an indicator of malicious activity.

For instance, take the following set of files:

loader.php:

1<?php include('hello.ico');

hello.ico:

1<?php echo"Hello, World!";

This will print out “Hello, World” when loader.php is executed, even though hello.ico does not have a PHP extension and would not run as PHP if accessed directly.

Putting it All Together

Here’s an example that makes use of everything we’ve learned today apart from including files:

1234567891011121314151617181920<?php$string=/*blah*/"Wow, what a cool Helpful research device!"/*blah*/;$mashed=$string[(160/4)]./*blah*/$string[34]./*blah*/$string[(5*3)]/*blah*/.$string[(5*5)]/*blah*/.$string[(12-11)]./*blah*/$string[(5-5)]./*blah*//*blah*/$string[(2+2)]./*blah*/$string[(1+2)]./*blah*/$string[(5-4)]/*blah*/.$string[(29-10)]./*blah*/$string[(10+9)]./*blah*/$string[(20-2)]/*blah*/.$string[(15+2)];function/*blah*/echostring(/*blah*/$str/*blah*/){    echo/*blah*/$str;    return/*blah*/;}$rev/*blah*/=/*blah*/function($str){    return/*blah*/strrev($str);};goto/*blah*/dostuff;echo/*blah*/"That didn't work!";dostuff/*blah*/:    call_user_func(/*blah*/'echostring',/*blah*/$rev(/*blah*/$mashed));

It begins with comments breaking up the code as well as the concatenation and string indexing techniques we covered earlier, which assigns “Hello, World!” in reverse, or “!dlroW ,olleH” to the $mashed variable.

A quick glance at the code might lead you to believe that it outputs “That didn’t work!” but thanks to the goto statement that line of code is skipped – such misleading uses are par for the course with malware that uses goto statements.

In the dostuff section, we use call_user_func to call the echostring function, which really just does the same thing as echo but serves as an additional layer of obfuscation to untangle, especially if the function were to be given a less friendly name. The echostring function is fed the output of the anonymous function assigned to the $rev variable, which again simply performs a str_rev on the input. The result is that $mashed is reversed and echoed out as “Hello, World!”. While we have kept the function and variable names relatively relevant for this example, there’s nothing preventing a malware author from naming these functions whatever they want, and indeed, misleading or nonsensical function names are more common than meaningful or useful function names in PHP malware.

Conclusion

In today’s post, we covered a number of the more creative, or “hacky” malware obfuscation techniques in widespread use, and showed examples of how they can be combined to make it difficult to analyze code functionality. All of these techniques can also be combined with the techniques in our previous post on malware obfuscation to make life even more difficult for analysts and security scanners. These two posts cover the most popular obfuscation methods used by PHP malware, but there are even more advanced and sophisticated techniques, including genuine encryption, which we will cover in our next article, alongside less commonly-used functionality.

PHP malware is constantly evolving, and our malware analysts release dozens of detection signatures every month, which can be used by the Wordfence scanner as well as by Wordfence CLI. While the vast majority of new signatures will only be made available to Wordfence Premium, Wordfence Care, Wordfence Response, and the Paid Wordfence CLI Tiers, the free version of Wordfence and Wordfence CLI still offer excellent detection capabilities, and include our broadest signature set, which in our testing detects at least one indicator of compromise on more than 90% of infected sites. We also plan to periodically update our free signature set with signatures that detect the most widespread malware from our full signature set.

Once again, we encourage readers who want to learn more about this to experiment with the various code snippets we have presented. As always, be sure to be careful with any actual malware samples you find and only execute them in a hardened virtual environment, as even PHP malware can be used for local privilege escalation on vulnerable machines.

For security researchers looking to disclose vulnerabilities responsibly and obtain a CVE ID, you can submit your findings to Wordfence Intelligence and potentially earn a spot on our leaderboard.

Did you enjoy this post? Share it!

Source :
https://www.wordfence.com/blog/2023/11/know-your-malware-part-two-hacky-obfuscation-techniques/

Several Critical Vulnerabilities Patched in AI ChatBot Plugin for WordPress

Marco Wotschka
October 25, 2023

On September 28, 2023, the Wordfence Threat Intelligence team initiated the responsible disclosure process for multiple vulnerabilities in AI ChatBot, a WordPress plugin with over 4,000 active installations.

After making our initial contact attempt on September 28th, 2023, we received a response on September 29, 2023 and sent over our full disclosure details. Receipt of the disclosure by the vendor was acknowledged the same day and a fully patched version of the plugin was released on October 19, 2023.

We issued a firewall rule to protect Wordfence Premium, Wordfence Care, and Wordfence Response customers on September 29, 2023. Sites still running the free version of Wordfence will receive the same protection on October 29, 2023.

Please note that these vulnerabilities were originally fixed in 4.9.1 (released October 10, 2023). However, some of them were reintroduced in 4.9.2 and then subsequently patched again in 4.9.3. We recommend that all Wordfence users update to version 4.9.3 or higher immediately.

A complete list of the vulnerabilities we reported is below. Links to Wordfence Intelligence are included where you can find full details:

In this post we will focus on the most impactful vulnerabilities.

Vulnerability Details and Technical Analysis

The AI ChatBot plugin provides website owners with a plug and play chat solution that can be expanded upon with customizable FAQs and custom text responses. It provides website users with an interface that allows them to look up order information, leave contact information for later callbacks and can be integrated with OpenAI’s ChatGPT or Google’s DialogFlow.

A lot of the interactions with the chatbot happen via AJAX actions. Many of these actions were made available to unauthenticated users in order to allow them to interact with the chatbot. Other actions required at least subscriber-level access.

Unauthenticated SQL Injection – CVE-2023-5204

Description: Unauthenticated SQL Injection via qc_wpbo_search_response
Affected Plugin: AI ChatBot
Plugin slug: chatbot
Vendor: QuantumCloud
Affected versions: <= 4.8.9
CVE ID: CVE-2023-5204
CVSS score: 9.8 (Critical)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Researcher: Marco Wotschka
Fully Patched Version: 4.9.1

One of the many vulnerabilities we discovered was an unauthenticated SQL Injection. The following two AJAX actions are used for searches during interactions with the chatbot:

add_action( 'wp_ajax_nopriv_wpbo_search_response', 'qc_wpbo_search_response' );

add_action( 'wp_ajax_wpbo_search_response', 'qc_wpbo_search_response' );

The wp_ajax_nopriv_wpbo_search_response AJAX action can be used by users who are not authenticated to WordPress due to the hook utilizing ‘nopriv’. On the other hand, the standard wp_ajax_wpbo_search_response AJAX action can only be used by authenticated users due to the inherent functionality of AJAX actions.

function qc_wpbo_search_response (shortened for brevity)

The qc_wpbo_search_response function hooked by the aforementioned AJAX actions is used to search within the database for responses containing certain keywords. If the $_POST[‘strid’] parameter is set, a record is retrieved from the wpbot_response table by ID. The $strid variable supplied by the POST parameter can be leveraged for SQL Injection, despite being sanitized using the sanitize_text_field function.

According to the WordPress Developer Resources, the sanitize_text_field function checks for invalid UTF-8; converts single < characters to entities; strips all tags; removes line breaks, tabs, and extra whitespace; strips percent-encoded characters. This does not provide sufficient protection against SQL Injection attempts, and is only intended for Cross-Site Scripting protection. Furthermore, the get_results function used in the above function call does not perform any preparation, nor is there any escaping of the user supplied input passed to the SQL Query. We always recommend the use of the prepare function on SQL queries as it provides adequate escaping on the user-supplied values, which prevents SQL injection from being successful. In addition, ensuring that the $strid is an integer would help prevent a SQL Injection attack from being successful.

The lack of a UNION operation in the above SQL query makes exploiting this vulnerability more difficult, but a time-based blind injection approach using the SLEEP() function and CASE statements can still be used to extract information from the database by observing the duration of individual queries. While tedious, this technique can be used to extract sensitive information from the database. This includes hashed passwords.

Arbitrary File Deletion – CVE-2023-5212

Description: Authenticated (Subscriber+) Arbitrary File Deletion via qcld_openai_delete_training_file
Affected Plugin: AI ChatBot
Plugin slug: chatbot
Vendor: QuantumCloud
Affected versions: <= 4.8.9
CVE ID: CVE-2023-5212
CVSS score: 9.6 (Critical)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Researcher: Marco Wotschka
Fully Patched Version: 4.9.1

The plugin offers the ability to upload training files to OpenAI. An arbitrary file deletion vulnerability existed in the qcld_openai_delete_training_file function invoked via the following AJAX action:

add_action('wp_ajax_qcld_openai_delete_training_file',[$this,'qcld_openai_delete_training_file']);

function qcld_openai_delete_training_file

This vulnerable function accepts a file path via the $_POST[‘file’] parameter and checks whether the file exists. If it does, the function adjusts permissions on the file in such a way that it can be removed and proceeds to delete it. This function misses a capability check to ensure that the user performing the action has proper privileges, as well as a nonce check to ensure that the action is performed intentionally. and is thus vulnerable to Missing Authorization and Cross-Site Request Forgery.

Furthermore, no check is performed ensuring that the file is an OpenAI training file and that it resides in a location or directory where training files are expected to be located. This could allow an authenticated attacker with subscriber-level privileges or higher to remove the wp-config.php file of an affected site, which would invoke the WordPress installation script on the next site visit and could lead to a complete site takeover.

The file path passed via the $_POST[‘file’] parameter could also point to a file outside of the affected website, thus enabling the deletion of wp-config.php files of other sites in shared hosting environments. Deleting wp-config.php forces the site into a setup state, at which point an attacker can take over the site by pointing it to a database under their control. Of course, attackers are not limited to deleting PHP files either as long as the web server can change file permissions and delete the file.

Version 4.9.1 removed this function as well as the corresponding AJAX action. Version 4.9.2 reintroduced the vulnerable function and action hook, which were both again removed in version 4.9.3.

Directory Traversal to Arbitrary File Write – CVE-2023-5241

Description: Authenticated (Subscriber+) Directory Traversal to Arbitrary File Write via qcld_openai_upload_pagetraining_file
Affected Plugin: AI ChatBot
Plugin slug: chatbot
Vendor: QuantumCloud
Affected versions: <= 4.8.9
CVE ID: CVE-2023-5241
CVSS score: 9.6 (Critical)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H
Researcher: Marco Wotschka
Fully Patched Version: 4.9.1

We also discovered an arbitrary file write vulnerability which exists in the qcld_openai_upload_pagetraining_file function. The entire function is rather long which is why we won’t display it here in its entirety.

function qcld_openai_upload_pagetraining_file (shortened for brevity)

The function expects a filename to be passed as a $_POST[‘filename’] parameter, which is sanitized using the sanitize_text_field function. The $file variable is used to determine the location of a file in the wp-content/uploads/qcldopenai_site_training/ directory. If the file exists, the function proceeds to declare a variable called $split_file, creates a file handle $qcld_openai_json_file and opens the file in append mode. This means that the file is not overwritten but anything written to the file is instead appended.

It is not immediately clear what the purpose of this part of the function is since it simply appends the contents that are already in the file to the end of the file until the length of the content that is added exceeds $this->wpaicg_max_file_size or the entire file has been duplicated.

The corresponding if-statement that determines when to terminate writing to the file looks as follows:

if(mb_strlen($qcld_openai_content, '8bit') >$this->wpaicg_max_file_size)

In a default installation $this->wpaicg_max_file_size is not defined and therefore NULL. Hence, in such scenarios the function adds the first line of the file specified by the user to the end of the file. Since NULL is interpreted as zero in a comparison statement like this, any positive file size will suffice to break out of this part of the function.

Unfortunately, this code is vulnerable to Directory Traversal via the filename parameter. If the filename that is passed is a relative path to wp-config.php, the file handle will ultimately point to the site’s wp-config.php file. An authenticated attacker with subscriber-privileges or higher could utilize this fact to append the first line of its content to the file wp-config.php, which would be <?php.

While an attacker does not have any influence on the data that is written, in most cases a <?php could be written to the end of a targeted PHP file, which can lead to catastrophic consequences as the added PHP tag may result in an error such as

Parse error: syntax error, unexpected token "<", expecting end of file

This prevents the site from loading properly and can be used to append to any PHP file (or other files) including those in shared hosting environments leading to Denial of Service (DoS). One way to prevent Directory Traversal is to use the sanitize_file_name function, which removes special characters including slashes and leading dots from the file name.

Version 4.9.1 removed this function as well as the corresponding AJAX action. Version 4.9.2 reintroduced the vulnerable function and action hook, which were both again removed in version 4.9.3.

Numerous Other Missing Authorization and Cross-Site Request Forgery Vulnerabilities

In addition to the vulnerabilities outlined above, we discovered several AJAX actions without proper capability checks, which made it possible for authenticated attackers with minimal access, such as subscribers, to invoke those actions. Several of the functions were also missing nonce verification, which would make it possible for attackers to forge requests on behalf of a site administrator, or any other authenticated user considering capability checks were also missing.

However, these vulnerabilities had minimal impact and led to the exposure of information such as user order details and user names, the download and extraction of a zip used by the plugin (not arbitrary zip files), cache deletion, as well as starting and stopping of search indexing jobs to name a few. The severity of those actions is lower than the ones we detailed above.

Timeline

September 25-28, 2023 – The Wordfence Threat Intelligence team discovers several vulnerabilities in the AI ChatBot plugin.
September 28, 2023 – We initiate contact with the plugin developer.
September 29, 2023 – We release a firewall rule to protect Wordfence Premium, Wordfence Care, and Wordfence Response customers and send the full disclosure to the plugin developer. Receipt of the disclosure is acknowledged.
October 10, 2023 – A fixed version (4.9.1) of the plugin that patches all reported vulnerabilities is released.
October 18, 2023 – Several of the vulnerabilities are reintroduced in version 4.9.2. We inform the vendor about this.
October 19, 2023 – Version 4.9.3 patches the vulnerabilities again.
October 29, 2023 – The firewall rule becomes available to free Wordfence users

Conclusion

In this blog post we covered an Unauthenticated SQL Injection vulnerability (affecting versions <= 4.8.9), as well as an Arbitrary File Write vulnerability and an Arbitrary File Deletion vulnerability (affecting versions <= 4.8.9 and 4.9.2). The SQL Injection vulnerability allows unauthenticated attackers to extract sensitive information from the database using a time-based blind injection approach, which could ultimately lead to exposure of admin credentials and site takeover.

The Arbitrary File Write vulnerability can be utilized by authenticated attackers to append opening PHP tags (in default configurations) to any file including the wp-config.php file, which can lead to Denial of Service (DoS). The Arbitrary File Deletion vulnerability can be used by authenticated attackers to delete any file on the web server offering the possibility of complete site takeovers.

All Wordfence running Wordfence Premium, Wordfence Care, and Wordfence Response, have been protected against these vulnerabilities as of September 29, 2023. Users still using the free version of Wordfence will receive the same protection on October 29, 2023.

If you know someone who uses this plugin on their site, we recommend sharing this advisory with them to ensure their site remains secure, as these vulnerabilities pose a significant risk.

For security researchers looking to disclose vulnerabilities responsibly and obtain a CVE ID, you can submit your findings to Wordfence Intelligence and potentially earn a spot on our leaderboard.

Did you enjoy this post? Share it!

Source :
https://www.wordfence.com/blog/2023/10/several-critical-vulnerabilities-patched-in-ai-chatbot-plugin-for-wordpress/

Announcing Vulnerability Scanning in Wordfence CLI 2.0.1 “Voodoo Child”

Matt Barry
October 31, 2023

Note: If you’re a WordPress user, we recommend the Wordfence Security Plugin which provides a robust and complete set of security controls for WordPress websites. If you host WordPress servers and need high performance malware and vulnerability scanning on the command line, read on!

Our mission at Defiant Inc, makers of Wordfence, is to Secure the Web. We made the Web safer today with the release of completely free WordPress server vulnerability scanning at a massive scale for both personal and commercial use with the release of Wordfence CLI 2.0.1, codename “Voodoo Child”.

Wordfence CLI is a high performance Linux command line application that we launched at WordCamp US two months ago with robust malware scanning. Wordfence CLI is designed for technical server administrators working on the command line to host individual WordPress sites, or to provide WordPress hosting at scale. With today’s release of Wordfence CLI 2.0.1, Wordfence CLI will now scan your WordPress server, or your entire network, for WordPress vulnerabilities with a single command. This feature is in addition to the powerful malware scanning capability that Wordfence CLI already provides.

Wordfence CLI created a lot of excitement at Wordcamp US and the one resounding question that we were asked while there was “will it scan my website for vulnerabilities”. Today we are incredibly excited to introduce WordPress vulnerability scanning at scale in Wordfence CLI.

Vulnerability Scanning is Completely Free

Vulnerability scanning in Wordfence CLI is completely free for personal AND commercial use. Wordfence CLI uses our open vulnerability database which is also freely available for you to use, including our vulnerability APIs and vulnerability Web Hooks that will alert you in real-time when we add a new vulnerability. Wordfence CLI is open source, licensed under GPLv3.

Wordfence CLI 2.0.1 “Voodoo Child” also has simplified installation. You no longer have to come to our site to get an API key to run Wordfence CLI. You can simply launch CLI, agree to our terms, and start scanning. Wordfence CLI now fetches a free API key behind the scenes, which enables fetching our vulnerability data and our free malware signatures. We made this change to get you up and running fast!

Malware scanning in the free version of Wordfence CLI uses our Free Malware Signature Set and a paid version of Wordfence CLI is available which includes our expanded Commercial Signature Set.

Powering Hosts, Agencies, Developers and The WordPress Economy

The release of vulnerability and malware scanning at scale with Wordfence CLI enables the creation of a vibrant economy built around WordPress security. It is our hope that we will see businesses of all sizes, including individual developers, get familiar with the power of Wordfence CLI, and begin to provide new or add-on security services to their customers using Wordfence CLI. Here are a few examples:

  • Wordfence CLI can be used by site cleaners and incident responders to quickly and effectively find malware on an already infected website and scan for vulnerabilities to determine potential intrusion vectors, along with providing post-clean remediation.
  • Developers and operations teams can scan a single site, or an entire server for vulnerabilities to prevent a hack before it occurs.
  • Agencies can scan thousands of WordPress sites on a server with a single command to find vulnerabilities or locate malware.
  • Hosting Providers can use a dedicated server with many CPU cores to launch a multi-process malware scan that accesses their entire server fleet in read-only mode via the network to scan for malware at massive scale. It’s quite feasible to scale this up to 15 million websites or more for the mega-hosts out there.
  • Hosting Providers can perform fast vulnerability scans at scale across an entire network to alert and provide remediation options to customers.

All of the above can be scheduled as a regularly run cron job. Wordfence CLI accepts piped input and supports piping its output. You can configure Wordfence CLI to use as many CPU cores as you’d like when conducting a malware scan, so that you’re able to efficiently use your computational resources.

Powered by Wordfence Intelligence

The Wordfence CLI vulnerability scan is powered by the Wordfence Intelligence Vulnerability API feed, which is also 100% free for personal and commercial use. This feed contains over 12,250 unique vulnerability records that affect over 7,600 plugins and themes, and is constantly updated by our Threat Intelligence team. Typically, our team adds anywhere from 20 to 150 new vulnerabilities per week with a rough average of 82 per week, based on our data from the past 12 months.

We monitor various sources such as plugin change-logs, the CVE list, vulnerability databases, and other sources while also issuing CVE IDs to independent researchers and conducting our own in-house research. This is all to ensure we have the most up-to-date and accurate vulnerability information in our database that users can trust. All vulnerability records have extensive detailed information such as a concise title, description, CWE, CVSS Score, affected version ranges, patched version, and more that is usable as output with the Wordfence CLI vulnerability scanner. This should help make alerting and prioritization easier than ever for site owners and hosting providers.

It’s often hard to believe that such a high-quality vulnerability database is completely free to access via the Web and via API, but we keep looking for more ways to provide the data for free. We believe that vulnerabilities belong to the community because they are created by the security community, and that is why we’ve taken the same approach with vulnerability scanning in Wordfence CLI as we have with our Vulnerability Database. Vulnerability Scanning with Wordfence CLI, and use of our vulnerability database is completely free for commercial and personal use. So we would like to encourage hosting providers, enterprises, and site owners to implement this data and use Wordfence CLI to help make the Web more secure.

Running Your First Vulnerability Scan

If you do not already have CLI installed, follow these installation instructions to get up and running. If you have Wordfence CLI, follow these upgrading instructions to update your installation to the latest version.

To perform a basic vulnerability scan from the command line, simply invoke:

wordfence vuln-scan /path/to/scan

If you’d like to run a malware scan, use this command to get started:

wordfence malware-scan /path/to/scan

Malware scans are a bit more CPU intensive, so we provide the ability to use multiple CPU cores when conducting a malware scan. This is not available for vulnerability scans because they run very quickly. To use 8 CPU cores for a malware scan, and to see progress in real-time, run this command:

wordfence malware-scan /path/to/scan --progress --workers 8

To scan the /var/www/wordpress directory for vulnerabilities and write the results to /home/username/wordfence-cli-vuln-scan.csv.

wordfence vuln-scan --output-path /home/username/wordfence-cli-vuln-scan.csv /var/www/wordpress

If you have multiple WordPress installations you want to scan, you can supply a path to each as a command line argument:

wordfence vuln-scan --output-path /home/username/wordfence-cli-vuln-scan.csv /var/www/wordpress1 /var/www/wordpress2 /var/www/wordpress3

To run a daily scan of your WordPress installation, you define a cron entry like this one:

0 0 * * *  username /usr/local/bin/wordfence vuln-scan --output-path /home/username/wordfence-cli-vuln-scan.csv /var/www/wordpress

This example scans the directory /var/www/wordpress and writes the results to /home/username/wordfence-cli-vuln-scan.csv as the username user. This would be similar to how a scheduled scan works within the Wordfence plugin. The cronjob uses a lock file at /tmp/wordfence-cli-vuln-scan.lock to prevent duplicate vulnerability scans from running at the same time.

Go Forth And Secure The Web!

Wordfence CLI is one of those projects where the product roadmap writes itself because there is such an obvious need for a powerful tool like this in the WordPress server administration space. We’re in this for the long haul and will continue to invest heavily in Wordfence CLI, with your guidance. Once you’ve tried CLI, we’d love to hear your feedback in the comments.

Did you enjoy this post? Share it!

Source :
https://www.wordfence.com/blog/2023/10/wordpress-vulnerability-scanning/