Broken Object Level Authorization (BOLA), also known as Insecure Direct Object References (IDOR), is number one in OWASP API Security Top 10 list. Facebook, Verizon, T-Mobile, Microsoft, and Google are among the companies which have been breached via this vulnerability.

When an application includes an BOLA / IDOR vulnerability, it has a strong probability of exposing sensitive information or data to attackers. All the attackers need to do is exchange the ID of their own resource in the API call with an ID of a resource belonging to another user. Thus, every API endpoint that receives an ID of an object and performs any type of action on the object can be an attack target.

In order to protect your application from BOLA, you need to know all endpoints which can be the target of this vulnerability. This is where Wallarm API Discovery comes in. This module analyzes the structure of your application and finds endpoints in which the object ID is passed. Wallarm automatically creates a trigger to protect endpoints which are most likely to be victims of a BOLA attack. The trigger monitors the number of requests to a specified endpoint and creates a BOLA attack event when trigger thresholds are exceeded.

The trigger for protection from BOLA requires Wallarm Node version 4.2 and higher.

See the Wallarm documentation for more details.

Your API inventory may contain thousands of endpoints. Some may handle sensitive data, and others may become targets of attack. In addition, your endpoints may have open vulnerabilities with different threat levels. And of course your API inventory is constantly and rapidly changing - new endpoints are added, existing endpoints are changed or removed. With such large amounts of data to assess, it can be difficult to focus on the endpoints issues that have the most significant impact your security posture. 

To keep your applications safe, the Wallarm API Discovery provides the following data:

Which of your endpoints are attacked the most
The Wallarm API Discovery module displays the number of malicious requests (hits) executed against your endpoints on a per-endpoint basis. You can triage your endpoints by filtering and sorting the list to find those that have been attacked the most.
 
Stay on top of your riskiest endpoints
The Wallarm API Discovery module automatically calculates a risk score from 1 (low risk) to 10 (high risk) for each endpoint in your API inventory. The risk score criteria includes: the presence of sensitive data, the number of parameters passed to the endpoint, etc. This score enables you to understand which endpoints are most likely to be an attack target and therefore should be the focus of your security efforts. For example, an endpoint that handles sensitive data and can be the target of a BOLA attack would have a higher risk score than an endpoint that simply passed an JSON object with several parameters.

You can find more detailed information about these features in our documentation.

With these new dashboard widgets, you can now easily analyze critical vulnerabilities and identify weaknesses in your system:

• The CVEs widget shows you what vulnerabilities are being used by attackers when attacking your infrastructure, allowing you to assess the impact and take protective measures as necessary.

• The Authentication widget shows you which authentication protocols are being targeted by attackers, allowing you to identify weaknesses and compromised credentials, and take preventative steps as necessary.

You can find more detailed information in our documentation.

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.

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.

With the growing complexity of new applications, technology stacks, and evolving attack techniques, we can implement regular improvements in how the Wallarm WAF detects attacks. This month we have added new Scanner rules to detect:

• Open access to the Consul UI web interface. Read the details on our blog
• Server-Side Template Injection in SEOmatic plugin for Craft CMS - CVE-2020-9757
• Reflected Code Injection in Citrix ADC and NetScaler Gateway - СVE-2020-8194
• Remote code execution in WebLogic Server - CVE-2020-14882
• Remote code execution in Liferay CE Portal - CVE-2019-11444

We have also improved the detection of Bash command injection and path traversal attacks in Wallarm WAF.

With the growing complexity of new applications, technology stacks, and evolving attack techniques, we can implement regular improvements in how the Wallarm WAF detects attacks. This month we have added new Scanner rules to detect:

• Cisco Adaptive Security Appliance (ASA) Software and Cisco Firepower Threat Defense (FTD) Web Interface Vulnerability — CVE-2020-3452
• Open web interfaces for VMware ESXi, vCenter, and vSphere.

We've also added new rules for detecting attacks in the Wallarm WAF:

• RCE in MobileIron Core & Connector, Sentry and Monitor and Reporting Database (RDB) — CVE-2020-15505
• RCE on some NGINX + PHP-FPM installation configurations — CVE-2019-11043

In addition, Bitrix 0-day LFI detection is available within our WAF and Scanner. We sent notifications and created virtual patches for all clients that have this vulnerability in their applications.

With the growing complexity of new applications and technology stacks, as well as evolving attack techniques, we can implement regular improvements in how the Wallarm WAF detects attacks. Here are some highlights from March 2020 that our detection team wants to share:

• Expanded list of possible NoSQLi (NoSQL Injection) vectors that can be detected;
• Improved the mechanism for detecting SSTI (Server Side Template Injection) attacks;
• Redesigned SSI (Server Side Includes) discovery mechanism;
• New rules for detecting IMAPi (Mail Injection) have been added.

This update will expand the WAF's ability to detect attacks by adding new rules and reducing the number of false positives by optimizing existing algorithms.

Do I need to update anything to apply these changes?
No, all improvements in the attack detection techniques are delivered to customers automatically.

How do you ensure that these changes will not affect my traffic flow?

For the next two weeks, the update will work in the experimental mode without any additional blocking. Changes will be activated once we make sure no additional false positives are introduced.

For questions related to the detects and updated rules, you can contact our support team.