Enhancing Day-One Exploit Containment with Custom WAF Rules

Posted on

Bridging the gap between when a vulnerability announcement is released and when a fix is available.

We live in a world where the good guys are constantly responding to threats from the bad guys. In a perfect world, a Web Application Firewall (WAF) deployment and the rule sets within are always one step ahead of the bad guys; or, even when they’re not, they get the necessary fixes out to the public quickly so that within days of an exploit’s announcement, systems can be upgraded with new software addressing the issue.

The problem is that not every system can be updated in such a timely fashion with new software that closes the vulnerability. Maintenance times need to be scheduled, staff needs to be assigned, and testing performed on the updates. Wouldn’t it be nice if it were possible to lock down systems as soon as a vulnerability is announced by adding exploit-specific rules to an existing WAF engine in the application delivery pipeline?

When you have a LoadMaster ADC in your pipeline with its WAF capability enabled, you have that ability. The appearance last June of the vulnerability described in CVE-2022-26134 is a case in point.

This exploit reveals a vulnerability in the Confluence server by Atlassian that allows an unauthenticated attacker to run code they inject via the request. This exploit affects any organization that has implemented their own Confluence server (not the Cloud version of the product).

Until a software patch could be made available and affected systems updated, the best advice was to disable all internet-based access to such a Confluence deployment. This was even true for customers currently running WAF rule sets, both free and from commercial vendors. Existing rules focused on this type of exploit would warn against, not block, these exploits.

LoadMaster Support and WAF to the Rescue!

LoadMaster customers running WAF had another option. Our award-winning support team crafted two WAF rule files that could be added as custom rules to LoadMaster to immediately protect Confluence deployments from this exploit, until such time as the systems could be patched. This results in less downtime (and less anxiety) for LoadMaster customers.

The rules below do this in two ways:

  • Check an incoming request for special characters in specific parts of the request, and block these requests.
  • Check the originating IP address for the request and block specific IP addresses from which attacks like this tend to originate.

The first file contains a single rule, shown below, which specifically blocks the exploit by matching for specific special characters in the request filename, cookies, and headers.

# Generic rule against CVE-2022-26134 (confluence)
msg:'Potential Remote Command Execution: confluence CVE-2022-26134' \
logdata:'Matched Data: %{MATCHED_VAR} found within %{MATCHED_VAR_NAME}',\

The second file contains over a dozen rules that specifically block all requests from the latest list of known malicious IP addresses identified at the time this exploit was announced (June 2022). These are considered “command and control” servers from which exploits like the one described in this CVE are known to originate.

While this tactic is not directly related to the Confluence vulnerability, its worth knowing that you can also add custom rules like the ones below when you see any IP addresses in your incoming request stream that you’d like to block for any reason.

# ---------------------------------------------------------------
# Deny New C2 IP/Network Ranges; allow everything else
# ---------------------------------------------------------------
SecRule REMOTE_ADDR "@ipMatch" "id:'101',phase:1,t:none,deny,log,msg:'IP deny Rule'"
SecRule REMOTE_ADDR "@ipMatch" "id:'102',phase:1,t:none,deny,log,msg:'IP deny Rule'"
SecRule REMOTE_ADDR "@ipMatch" "id:'103',phase:1,t:none,deny,log,msg:'IP deny Rule'"
SecRule REMOTE_ADDR "@ipMatch" "id:'104',phase:1,t:none,deny,log,msg:'IP deny Rule'"
SecRule REMOTE_ADDR "@ipMatch" "id:'105',phase:1,t:none,deny,log,msg:'IP deny Rule'"
SecRule REMOTE_ADDR "@ipMatch" "id:'106',phase:1,t:none,deny,log,msg:'IP deny Rule'"
SecRule REMOTE_ADDR "@ipMatch" "id:'107',phase:1,t:none,deny,log,msg:'IP deny Rule'"
SecRule REMOTE_ADDR "@ipMatch" "id:'108',phase:1,t:none,deny,log,msg:'IP deny Rule'"
SecRule REMOTE_ADDR "@ipMatch" "id:'109',phase:1,t:none,deny,log,msg:'IP deny Rule'"
SecRule REMOTE_ADDR "@ipMatch" "id:'110',phase:1,t:none,deny,log,msg:'IP deny Rule'"
SecRule REMOTE_ADDR "@ipMatch" "id:'111',phase:1,t:none,deny,log,msg:'IP deny Rule'"
SecRule REMOTE_ADDR "@ipMatch" "id:'112',phase:1,t:none,deny,log,msg:'IP deny Rule'"
SecRule REMOTE_ADDR "@ipMatch" "id:'113',phase:1,t:none,deny,log,msg:'IP deny Rule'"
SecRule REMOTE_ADDR "@ipMatch" "id:'114',phase:1,t:none,deny,log,msg:'IP deny Rule'"
SecRule REMOTE_ADDR "@ipMatch" "id:'115',phase:1,t:none,deny,log,msg:'IP deny Rule'"
SecRule REMOTE_ADDR "\." "id:'99999',phase:1,t:none,allow,log,msg:'IP allow Rule'"

How Do I Add these Rules to LoadMaster?

To add the above rules to LoadMaster WAF:

  1. Save the text in the above text blocks to two separate files on the system you use to access the LoadMaster UI.
  2. Log into the Loadmaster UI and navigate to Web Application Firewall > Custom Rules to upload your rule set files onto LoadMaster.
  3. The custom rule sets will now appear for selection when you navigate to a Virtual Service (VS) with WAF enabled. These appear in their own section after all the OWASP Request Rules.
    • As shown in the screenshot below, Custom Rules are listed by the name of the file that you uploaded in Step 2, above, and are disabled by default.
    • To enable them, click the check boxes next to each rule file and then click the Apply button at right.

Once selected within a VS, these custom rules will always be executed on incoming requests to the VS prior to the OWASP rule set included with LoadMaster.


For more information on WAF and custom rules, see the following resources:

Posted on

Related Posts

Mark Hoffmann

Mark Hoffmann is a Product Manager at Kemp. Previously, he worked at Fortinet and Coyote Point Systems on their ADC product lines. Before that, he spent more years than he cares to remember working in diverse roles on various flavors of Unix/Linux operation systems. Mark holds a BS in Computer Science from the State University of New York and currently lives in upstate New York. Mark is the primary responder on the Kemp Ideas Portal (https://ideas.kemp.ax/). Kemp is committed to constant improvement and to seeking out new ideas and directions for improving the functionality and quality of our products. If you have an idea that you want to tell Mark about, stop by the Ideas Portal and start a conversation!