In July and August, our detection team redesigned the detection of Path Traversal attacks. Hackers can use the following approaches for such attacks:

• PHP wrappers

  For example, php://filter/read=convert.base64-encode/resource=/etc/group

• Universal naming conventions for paths (UNC paths)

  For example, \\::1\c$\users\default\ntuser.dat

• File URI scheme

  For example, file://localhost/c|\windows\win.ini

We have updated the mechanism for dealing with such attacks and extended it to make it more difficult for attackers to execute such attacks.

We have also added new Scanner extensions to scan for the following vulnerabilities:

• Detecting debug panels laravel-debugbar, telescope, php-debugbar
• Zend framework configuration information disclosure detection
• LFI & RCE in Citrix ADC / Netscaler (CVE-2019-19781)
• 0 Day RCE at vBulletin (CVE-2020-17496)
• F5-BIG-IP RCE (CVE-2020-5902)

The changes are already available for all Wallarm clients. No additional update steps are required.

Integration with SIEMs is one of the most common things customers set up when deploying WAFs to protect their apps and APIs. We’ve just added native Splunk support, so you can connect it in a matter of minutes.

You can pull all the security events right into Splunk:

• Hits (attack requests)
• Discovered vulnerabilities
• Changes in the network perimeter
• System messages

Having the integration in place allows you to triage threats faster and to aggregate data from a variety of security tools your organization is using.

It has always been possible to push data into SIEMs using Wallarm APIs. With the native support of Splunk, you don’t need to deal with API anymore. For the Splunk integration, only HEC Token and API URL are required to have it running.

Try it out now in your Wallarm settings.

We have added a new authentication method in the Wallarm Console. We are glad to announce SAML SSO support!

A centralized authentication mechanism through SAML / SSO is important when implementing products in medium and large organizations. Using centrally managed accounts for all products allows IT departments to be effective, and companies to meet the most important security standards and compliance.

The Wallarm Console previously supported two-factor authentication. Now, we have added SAML authentication. This standard is supported by all popular IdP providers such as Okta, Azure AD, OneLogin, Auth0, gSuite, and others.

When using SAML, the company has a separate URL to access the Wallarm Console. Our technical support team will help you connect the domain and configure SAML authentication for your users.

A new integration is now available in the Wallarm Console - Sumo Logic native integration. Sumo Logic is a secure, cloud-based service for logs & metrics management for modern apps that provides real-time analytics and insights.

You can pull all the security events right into Sumo Logic:

• Hits (attack requests)
• Discovered vulnerabilities
• Changes in the network perimeter
• System messages

Check our new video Integrating Wallarm WAF into existing DevOps Toolchain to see how easy it is to set up a new integration and the result of its work.

An important focus of the team in June is to improve the detection of XSS, RCE and Time-Based SQL Injections. There have also been improvements in detection of automated scanning tools—Wallarm can now detect scans conducted by Qualys tool.

Furthermore, the following scanner extensions have been implemented:

• Detection of GOlang profiler
• Detection of RCE Primefaces (CVE-2017-1000486)
• Detect of Apache Tomcat AJP Vulnerability (CVE-2020-1938)
• Detection of insecure NoSQL Tarantool exposed with no authentication
• Apache Zookeeper Detect Available w/o Authentication (CVE-2018-8012)

Improvements are available for all Wallarm customers. No additional update steps required.

Our detection team made recent changes that are now available to all the Wallarm customers. Here is a quick summary of the updates:

• We expanded and optimized the dictionary for the DNS Enumeration—a major technique that is used to discover exposed assets, including subdomains. As usual, you can explore the company’s network perimeter (domains, hosts, and services) / attack surface on the Scanner page.
• The detection team included changes in the attack detection to avoid some rare, but still painful, false positives while analyzing binary data (such as file or image uploads).
• The vulnerability scanner gained a few extensions to identify the following security issues:- SQL injection in vBulletin (CVE-2020-12720)
  • Unauthorized SSRF via REST API (CVE-2019-8451)
  • Detection of publicly exposed Yii2 Gii and Webmin

Each time you switch the operation mode (for example: from monitoring to blocking mode), create a custom rule, or mark the request as a false positive, the Wallarm Cloud generates a new application profile so that every Wallarm Node can use up-to-date security rules. This process is now at least 5x faster. In many cases, it is 10x faster.

How it works?

The application profile provides known information about customers’ APIs, application endpoints, and relevant security rules that should be applied to traffic processing. The rules are application-specific, so the app-profile is individually created for every customer and compiled into a special file called LOM, which is later used by Wallarm Nodes.

The compilation of the rules tree structure is complex algorithmically and requires a lot of resources and time. One of the recent tasks of our node development team was to radically optimize this operation. There is a lot of work in progress. However, one of the most efficient measures was a well known caching technique. This increased the assembly speed of LOM by at least 5-10 times. We are working on more optimizations and plan for their release to be in the near future.

A completely updated WAF documentation portal is now available at docs.wallarm.com. Switching to the new docs platform allowed us to expand the capabilities of the portal. This has made navigation across the portal more convenient. In addition, it has greatly simplified the updates of the documents.

Notable changes

• We added a "live" search widget. Moreover, search results now include a context. For example, if you search the word Docker, then you'll not only get a list of the relevant articles but also a brief context of where this keyword is used.
• For each article, a document outline is now visible on the right side of the page. This is especially useful for navigating through longer technical documents.
• Our favorite change yet allows everyone to have the opportunity to contribute and make our docs better! We are allowing everyone to edit content via pull requests in GitHub repo with the documentation content. To start editing, click the edit icon on the page you want to change, push changes to the forked repo, and create a pull request to our repo! It’s that easy.

Technical details

We know many of our customers support the documentation for their products themselves. Therefore, we want to share some technical details about the chosen platform.

Previously, we built docs with GitBook, which was outstanding. Unfortunately, open GitBook is no longer supported. While choosing a new platform, we tried a variety of options, such as Docusaurus, Vuepress, or Gatsby, and ended up choosing the remarkable MkDocs / MkDocs Material. But the details of analyzing and moving to a new platform deserve a separate post in our blog.

We are looking forward to hearing your feedback! Please email support@wallarm.com with any comments, concerns, or questions.

Recently we launched the refreshed look of our Vulnerabilities page. The page now has three sections — high risk, medium risk and low risk vulnerabilities. This helps you to focus on a certain group without using filters.

The design of a single vulnerability page has also been changed. We hope the new updates make the interface easier to use. Everything is much more readable now — the parameters, history timeline, exploit examples, etc.

If you miss any functionalities on these pages or have any other feedback, please let us know!

We are continuing to simplify security testing automation in your CI/CD pipelines. Many users have requested to have FAST work with several CI pipelines simultaneously. We’re glad to announce that such support was added in the latest version of FAST.

You no longer need to run multiple instances of the FAST node for each CI pipeline. Instead, the only instance of the FAST node can now be used in multiple pipelines. It greatly simplifies tool deployment and makes the whole testing architecture more elegant.

Just specify an additional parameter BUILD_ID in the configuration of your project in the CI/CD system. For example if you work in Jenkins, add -e BUILD_ID = $ {env.BUILD_ID} into the command that launches FAST.

The parameter should be unique for each build so that the FAST node can associate any given requests with the necessary Test Run. Note that support for parallel pipelines works with both modes: recording baselines and running security tests.

Don’t have FAST but want to try it out? Send us a note!