We are pleased to announce our latest attack and vulnerability detection improvements!

For Wallarm Scanner to detect vulnerabilities with even lower false positives, we have refactored the following detection rules:

• Main SQLi vulnerability detection rules, with cover of additional obfuscation types
• XSS vulnerability detection rules

Attack detection accuracy has been improved by adding the following attack detection rules:

• New Path Traversal attack detection rules - in particular, Tomcat Path Traversal via reverse proxy mapping detection
• Various Web-Shell upload detection rules

These changes are already supported by the Wallarm platform, and no additional product configuration changes are required.

Wallarm now offers native integration with Datadog! Datadog is a SaaS-based dynamic data analytics platform used in many security and operational tech stacks.  

Wallarm has made it a priority to include native integration with specialized tools used by DevOps and SecOps teams. This integration with Datadog furthers that vision. 

This integration allows you to analyze and process Wallarm API Security events along with data from your other services and products in Datadog. Thus you will have a complete picture of what is happening in your infrastructure.

You can find more detailed information on this capability in our documentation.

We are pleased to announce the release of Wallarm Node 4.2.

Here is a list of the new features which will be available after upgrading:

BOLA / IDOR Detection

When an API-based application is vulnerable to Broken Object Level Authorization (BOLA), also known as Insecure Direct Object References (IDOR), there is a strong possibility of sensitive information or data being exposed. Attackers can exploit vulnerable API endpoints by manipulating the object ID which is sent within the request. 

To prevent exploitation of this vulnerability, Wallarm Node 4.2 contains a new trigger which you can use to protect your endpoints from BOLA attacks. The trigger monitors the number of requests to a specified endpoint and creates a BOLA attack event when trigger thresholds are exceeded.

Inspecting JWTs for Malicious Payloads

Wallarm Node 4.2 also brings Deep Request Inspection capability for JSON Web Token (JWT) data formats. While this will enable many new upcoming features related to the authentication tokens, Node 4.2 expands attack detection for all content encoded in JWTs. All data encoded in a JWT is automatically unpacked/decoded and checked for the different types of malicious payloads (RCE and others).

Other Updates

CentOS 6 and Debian 9 distributions are no longer supported. There are also some changes related to the logic of denylists. A more detailed changelog and instructions on upgrade are published in the official documentation.

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

When defending your APIs, you need a clear understanding of their structure, what resources they use, and how users or systems interact with them.

The Wallarm API Discovery module automatically determines which API hosts are accessible from external networks and which from internal networks, using real traffic data rather than relying on the documentation provided by the development team. This allows you to analyze your API structure more effectively, enabling you to use different scenarios and approaches for internal vs external resources. For example, it is probably much more critical to know if PII is being transmitted to externally-accessible endpoints as opposed to endpoints which are only internally accessible.

See the Wallarm documentation for more details.

APIs are like living organisms, always changing and evolving. It is essential to keep track of such changes, as they can seriously affect the security of your entire solution. For example, PII and other sensitive data may unexpectedly begin transferring to an endpoint, or you have a new undocumented endpoint, also known as a Shadow API.

The Wallarm API Discovery module solves these problems. This module continuously keeps track of changes that occur in your APIs and displays them in the Wallarm Console:

• which endpoints appear in your API structure
• what changes have occurred in these endpoints
• which endpoints are no longer called and should be assessed

See the Wallarm documentation for more details.

See the Wallarm documentation for more details.We have improved our dashboards to make it easier to analyze malicious traffic and identify critical attack vectors:

• The new API Protocols widget raises the visibility of the system's protocols and the associated attacks. This widget helps you to detect the emergence of new unapproved protocols or track a significant change in the number of attacks. With one click you can go from the widget to the Events tab to analyze the details of attacks on the selected protocol.

• The Attack Sources and Attack Targets widgets are now more compact, making it easier to analyze the location of threat sources and the assets that these threats are directed at. The widget "Attack Targets" have now two view option: statistics by domains and statistics by applications. This enables you to analyze attacks surface even for misconfigured applications.

See the Wallarm documentation for more details.

Background

On June 20, 2022 Spring released Spring Data MongoDB 3.4.1 and 3.3.5 to address a critical CVE report:

• CVE-2022-22980: Spring Data MongoDB SpEL Expression injection vulnerability through annotated repository query methods.

This vulnerability was originally reported on June 13, 2022.

Vulnerability

This vulnerability affects Spring Data MongoDB applications using repository query methods that are annotated with @Query or @Aggregation and use parameterized SpEL statements. A specific exploit requires non-sanitized input to the repository query method.

Wallarm Provides Protection

We tested Wallarm’s attack detection against known exploits and have confirmed that they were successfully detected and blocked. No further actions are required when working in blocking mode.

To mitigate this vulnerability when working in monitoring mode, please contact our support team if you want us to create the rule.

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

Further updates will be published in Wallarm Changelog: https://changelog.wallarm.com

We want to share this update regarding the critical Confluence 0-day vulnerability (CVE-2022-26134).

On June 02, 2022 Atlassian released a security advisory for their Confluence Server and Data Center applications, highlighting a critical severity unauthenticated remote code execution (RCE) vulnerability. Exploits are already publicly available and we expect this vulnerability to be heavily exploited in the wild.

We tested Wallarm’s attack detection against the known exploit and confirmed that exploitation attempted are successfully detected and blocked. No further actions are required.

To mitigate the vulnerability when working in a monitoring mode, it’s recommended to create a virtual patch rule based on Confluence recommendation. Feel free to reach out to support@wallarm.com if you need assistance.

Further updates will be published in Wallarm Changelog: https://changelog.wallarm.com

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.