Shadow APIs are undocumented or unmonitored public APIs that pose a significant security risk to an organization. These may include third-party APIs and services that the company uses but does not track, or in-house developed tools for internal or customer use. The new Wallarm API specification comparison feature allows security and operations teams to discover Shadow APIs.

Shadow APIs put businesses at risk, as attackers can exploit them to gain access to critical systems, steal valuable data, or disrupt operations, further compounded by the fact that APIs often act as gatekeepers to critical data and that a range of OWASP API vulnerabilities can be exploited to bypass API security. Recent reports highlight that the majority of businesses have Shadow APIs that are vulnerable to attacks, and cybercriminals are increasingly targeting these weaknesses.

With Wallarm's solution, SecOps and Security Analyst teams can now identify Shadow APIs, including external, internal, and 3rd party developed APIs. The solution gives security teams the ability to compare and validate their API specifications with the ones automatically built by Wallarm API Discovery. In this way, the SecOps and Security Analysts can detect any discrepancies that may indicate the presence of Shadow APIs, allowing them to quickly take action to mitigate potential security risks.

Don't wait until it's too late - start using Wallarm's new Shadow API detection feature today and safeguard your API infrastructure from potential attacks!

We're excited to announce that Wallarm node 4.6 is now available!

The most important thing about this new release is the API Rate Limiting feature. The lack of proper rate limiting has been a significant problem for API security, as attackers can launch high-volume requests that can cause a denial of service (DoS) or overload the system, which hurts legitimate users. Overall, the lack of API Rate Limiting feature can result in a poor user experience, frustration, and potential security risks for both the user and the API infrastructure.

The usual way of limiting the number of requests made to an API is by blocking the IP address. However, this method can sometimes wrongly identify legitimate users as malicious and prevent them from accessing the service. Consider a SaaS application that provides an API to its customers. Each customer has their unique API key to access the service. To ensure that API consumption is fair and prevent misuse, you decide to implement rate limiting. Traditional rate limiting that relies on IP addresses would not work well in this case because multiple customers may be sharing the same IP address. For example, this can happen when customers are behind a corporate firewall or using a VPN.

With our API Rate Limiting, security teams can effectively manage the service's load and prevent false alarms, ensuring the service is always available and secure for real users. This powerful feature gives security teams more control over protection against bad bots and other bad actors. 

Security teams can now set specific parameters and session settings to apply rate limit rules based on any request parameter, including JSON fields, base64 encoded data, cookies, XML fields, and more. 

You can also adjust settings like the rate, burst, delay, and response code to fine-tune the rate limit settings and apply session settings to specific requests. Configuration is done within the Wallarm Console.

It's important to note that with version 4.6, you can only register Wallarm nodes in the Wallarm Cloud using a token. Registering with user credentials is no longer supported. If you used any user credentials to deploy the Wallarm node, you need to generate a token that will be used to register the nodes in the Wallarm Cloud. Instructions for generating a token are provided in the documentation. 

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  

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