We are pleased to announce the release of a new version of Wallarm Node and the completion of our SOC2 Type II audit.

Here are some highlights on Wallarm Node 4.0.

Deployment

• New CDN-based Deployment: Spin up new nodes in minutes right on the CDN edge to analyze traffic in the cloud.
• Token-based Registration: Release 4.0 enables you to register nodes with the token on any supported platform.
• Improved multi-tenancy mode.

New OS and Kubernetes Support

• Kubernetes Support: Wallarm Ingress controller is now based on the latest version of Community Ingress NGINX Controller, 1.2.1.
• New OS Support: Added support for AlmaLinux, Rocky Linux, and Oracle Linux 8.x instead of the deprecated CentOS 8.x.

Attack Detection:

• Improved Detection: Gain even more accuracy with an updated libdetection library.
• Customized Blocking Page: New layout and additional debug data.

Potentially Impactful Changes

• The Wallarm Node now uses port 443 instead of port 444 to connect to the Wallarm Cloud.

Wallarm Node 4.0 also incorporates dozens of other improvements. A more detailed changelog and instructions on safe module upgrade from previous versions are published in the official documentation.

You can request an updated report regarding our latest SOC 2 Type II certification by contacting security@wallarm.com.

If you have any questions, feel free to contact our support team at support@wallarm.com.

Quick update

• There are two vulnerabilities: one 0-day in Spring Core which is named Spring4Shell (very severe, exploited in the wild no CVE yet) and another one in Spring Cloud Function (less severe, CVE-2022-22963)
• Wallarm has rolled out the update to detect and mitigate both vulnerabilities
• No additional actions are required from the customers when using Wallarm in the blocking mode
• When working in a monitoring mode, consider creating virtual patches for the Spring Core vulnerability and for the Spring Cloud Function vulnerability

Log4Spring

Spring Framework is an extremely popular framework used by Java developers to build modern applications. If you rely on the Java stack it’s highly likely that your engineering teams use Spring. In some cases, it only takes one specially crafted request to exploit the vulnerability.

On March 29th, 2022, information about the POC 0-day exploit in the popular Java library Spring Core appeared on Twitter. Later it turned out that it’s two RCEs that are discussed and sometimes confused:

Later it turned out that it’s two RCEs that are discussed and sometimes confused:

• RCE in "Spring Core" (Severe, no patch at the moment) - Spring4Shell
• RCE in "Spring Cloud Function" (Less severe, see the CVE)

The vulnerability allows an unauthenticated attacker to execute arbitrary code on the target system. Within some configurations, it only requires a threat actor to send a specific HTTP request to a vulnerable system. Other configurations may require additional effort and research by the attacker

At the time of writing, Log4Spring is unpatched in the Spring Framework and there is a public proof-of-concept available. We see exploits in the wild.

Wallarm update

Wallarm automatically identifies attempts of the Spring4shell exploitation and logs these attempts in Wallarm Console.

Mitigation

When using Wallarm in blocking mode, these attacks will be automatically blocked. No actions are required.

When using a monitoring mode, we suggest creating virtual patches for the Spring Core vulnerability and for the Spring Cloud Function vulnerability.

You can search for the relevant events in Wallarm Console by using Spring4Shell filter.

Feel free to reach out to support@wallarm.com if you need assistance.

The new event grouping method enables the grouping of hits originating from the same IP address into one attack that optimizes the view and analysis of attacks generated by bots and third-party scanners.

Generally, a bot or a third-party scanner generates the set of hits with different malicious payloads and sends it from the same IP address. Each such hit is displayed as a separate event in Wallarm Console by default. The number of such hits can reach hundreds or even thousands taking a significant amount of time for its analysis. With the new hit grouping method enabled, hits generated by the bot or third-party scanner can be analyzed as a single entity since they are grouped into one attack.

To enable new grouping of hits, configure the special trigger:

Restriction: Hits of the Brute force, Forced browsing, Resource overlimit, Data bomb and Virtual patch attack types cannot be grouped into attacks using the new method.

The new version of Wallarm Node is released. We recommend planning an upgrade soon.

The main changes for Node 3.6:

• Added support for AlmaLinux and Rocky Linux
• CentOS 8 is no longer supported, as it was declared End-of-Life
• Wallarm Ingress controller based on the latest version of Community Ingress NGINX Controller 1.1.1
• Some configuration parameters renamed due to the terminology standardization
• Updated blocking page /usr/share/nginx/html/wallarm_blocked.html to be displayed in the user's browser when an attack is blocked
• New configuration parameter to specify the NGINX service port of inside the Docker image

Before upgrading the nodes, please carefully review the list of changes and general upgrade recommendations. If you have any questions, feel free to contact our support team at support@wallarm.com

A new Log4j attack vector can potentially lead to the Denial of Service attack and the application crash. CVE-2021-45105 has been issued (the severity for this is classified as High - 7.5).

• Wallarm Research Team has already verified that the Wallarm attack engine can detect CVE-2021-45105 exploits.
• Attempts at exploitation will be automatically blocked in a blocking mode. When working in a monitoring mode, consider creating a virtual patch
• A new fixed version of Log4j (2.17) has been published by Apache. Upgrades are highly recommended.

Quick update

• Wallarm has rolled out the update to detect and mitigate CVE-2021-44228.
• No additional actions are required from the customers
• Attempts at exploitation will be automatically blocked in a blocking mode
• When working in a monitoring mode, consider creating a virtual patch

Log4Shell

A 0-day exploit in the Java core library log4j was discovered that results in Remote Code Execution (RCE) by simple 1-line exploit with JNDI url. Given how ubiquitous this library is, the impact of the exploit (full server control), and how easy it is to exploit, the impact of this vulnerability is quite severe. Read more.

The attack surface is very wide, since it’s almost impossible to find any single Java project without the log4j library enabled. It affects internal services and APIs that are based on Java and uses other API and application data to log them.

Wallarm update

Wallarm automatically identifies attempts of the Log4Shell exploitation and logs these attempts in the Wallarm Console. Corresponding changes have been added within two hours after the first information about CVE-2021-44228 has been published.

You can search for the relevant events by using filter by CVE:

Mitigation

When using Wallarm in blocking mode, these attacks will be automatically blocked. No actions required.

When using a monitoring mode, we suggest creating a virtual patch. Feel free to reach out to support@wallarm.com if you need assistance.

It's now easier to configure protection against API abuse, bruteforce or dirbusting attacks. Use an updated interface of Triggers:

• The Bruteforce trigger defines classic bruteforce attack protection against specific URI based on the number of incoming requests.
• The Forced browsing trigger forced browsing attacks allows to protect your apps against dirbusting (based on application 404 response codes)

In the simplest case, it is enough to enter the URI when creating the trigger. Wallarm will collect statistics from all the distributed Wallarm nodes deployed across your whole infrastructure.

When required, you can also use regular expressions (for example. wildcard URLs) or specify specific request headers (such as cookies) using the advanced view. Read more in our documentation.

Note: There is no need to edit your existing rules. However, previous rules “Add forced browsing attack tag to requests”, “Add brute force attacks tag to requests” will no longer be visible in the Rules section.

The new version of Wallarm Node is released. We recommend planning an upgrade soon.

The main changes for Node 3.4:

• Added support for CloudLinux OS 6.x
• Version of Envoy used in the Wallarm Envoy-based Docker image has been increased to 1.18.4

Wallarm Node 2.18 and lower are no longer supported. Note: Existing nodes will continue to operate as usual. However, we won't provide hotfixes and will limit support requests.

Before upgrading the agents, please carefully review the list of changes and general recommendations. Should you have any questions, feel free to contact our support team at support@wallarm.com.

We are happy to share recent work on the quality of attack and vulnerability detection!

We have added the support for new attack type detection: SSTI, SSI and Email Injection.

The rule set for detection of other attack types (SQLi, XSS, Path Traversal, Scanner, RCE) is now wider and more accurate.

We have also added the rules for Wallarm Scanner to detect new vulnerabilities in applications:

• Remote Code Execution in Confluence Server and Data Center — CVE‑2021‑26084
• Path Traversal and Remote Code Execution in Apache HTTP Server 2.4.49 — CVE‑2021‑41773
• Remote Code Execution in Microsoft Exchange Server — CVE‑2021‑26855
• Remote Code Execution in Apache Druid Embedded — CVE‑2021‑25646
• Remote Code Execution in Laravel Debug Mode — CVE‑2021‑3129
• Directory Traversal in ffay lanproxy 0.1 — CVE‑2021‑3019
• NoSQL injection in Agentejo Cockpit before 0.11.2 via the Controller/Auth.php resetpassword function — CVE‑2020‑35847

The changes are already supported by the Wallarm components. Additional product configuration to apply the changes is not required.

Notifications to your Microsoft Teams channel are now available.
Get updates for security and system events:

• Vulnerabilities detected
• Scope changed: updates in hosts, services, and domains
• Exceeded threshold of attack, hit, or incident number
• Newly added users
• Deleted or disabled integration

Read more about setting up the integration with Microsoft Teams on our documentation portal.