Today, Wallarm is introducing API Leak Management, a new feature to proactively protect your secrets and avoid related security breaches.

In recent months, enterprise companies like CircleCI, Slack, and LastPass have seen an escalation in attacks involving leaked API keys and other API secrets. API keys and secrets often leak due to developers' mistakes, missing repository access controls, insecure use of public services, and data disclosure accidents by contractors, partners, and users.

There are three main scenarios for proactive API Leak Management:

• Detect leaks. Wallarm continuously scans public sources for API secrets leaks: public repositories, mobile apps, Pastebin, and many other ways.
• Revoke/block tokens. Once a leak is detected, Wallarm remediates risks related to those leaks by blocking requests with compromised tokens and tracking them across all your API landscapes. 
• Track secret usage. Wallarm tracks when leaked secrets/credentials are used.

Next step

• Read more details in API Leak Management blog post
• Get a complimentary API Leaks Assessment. Get a thorough understanding of your risk exposure due to leaked API keys and other secrets by getting a free API leaks assessment. Register now.

Recently, Team82 introduced the technique for bypassing Web Application Firewalls (WAFs) by using JSON syntax in SQL injections (SQLi). This technique takes advantage of the fact that major SQL databases support JSON functions and operators, but WAFs do not inspect SQLi for JSON syntax.

We have tested this attack technique on the Wallarm solution and confirmed that our deep request inspection capability with support for JSON formats reliably mitigates advanced SQLi that use JSON syntax.

At Wallarm, we take the security of your infrastructure seriously, providing strong protection against modern threats.

We are pleased to announce the release of Wallarm node 4.4

Here is a list of the main features which will be available when you upgrade to the latest Wallarm node version:

Checking JSON Web Token strength

JSON Web Token (JWT) is one of the most popular authentication methods. Unfortunately, JWTs may contain many weaknesses which might be missed or forgotten about during development. Any of these will allow attackers access to your application, for example, with administrator rights.

Wallarm node now detects weaknesses in JWTs and records the corresponding vulnerabilities when:

• JWT is not signed
• JWT is signed using a compromised key

Libdetection library enabled by default

Wallarm introduced a fully grammar-based attack detection library libdetection a few years back and since then commited to improve and enhance it. First introduced as a feature for the power-users, it's then became available for everyone.

Starting node 4.4 it's by default enabled for all the customers. This is a major improvement as our core thing of getting the most accurate attack detection, with near-zero false positives. Focus on what matters, don't waste time on the tuning - we back you up.

Supported installation options

• Added support for Ubuntu 22.04 LTS (jammy)
• Dropped support for Debian 10.x (buster) for Wallarm to be installed as the module for either NGINX stable or NGINX Plus

More
Wallarm node 4.4 incorporates dozens of other improvements. A more detailed changelog and instructions on safe upgrade from previous versions are published in the official documentation.

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

We are pleased to announce the general availability of the Wallarm Sidecar proxy v2.0 solution!

The Wallarm Sidecar proxy v2.0 solution is a stable, safe, and scalable capability for your security stack. With this release, we updated our Sidecar solution to leverage new K8s capabilities and a wealth of customer feedback.

Among all the possibilities of Wallarm sidecar proxy v2.0, we can highlight the following:

• Injects into the K8s Pods automatically
• Simplifies protection of discrete microservices and their replicas and shards by providing the deployment format that is similar to applications
• Requires minimum service configuration to secure your apps; just add some annotations and labels for the application pod to protect it
• All Wallarm features available in the latest version 4.2 are supported by the Sidecar proxy v2.0 solution

If you are using the previous version, we recommend you migrate to the Wallarm Sidecar proxy v2.0 solution. For assistance in migrating to the Wallarm Sidecar proxy solution v2.0, please contact support@wallarm.com.

If you are looking for a security solution to protect applications deployed as Pods in a Kubernetes cluster, the Wallarm Sidecar solution is one of the options along with the Wallarm Ingress controller. More details on Wallarm Sidecar proxy v2.0 solution 

Wallarm supports many other deployment options, like AWS Terraform module, CDN and regular DEB and RPM packages. To get all supported options, please refer to Wallarm documentation.

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

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.

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 

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.