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)
SecRule REQUEST_FILENAME|REQUEST_COOKIES|REQUEST_COOKIES_NAMES|REQUEST_HEADERS "@rx \${" \
"id:1210,\
phase:1,\
block,\
t:none,t:urlDecodeUni,t:cmdline\
multimatch,\
log,\
msg:'Potential Remote Command Execution: confluence CVE-2022-26134' \
logdata:'Matched Data: %{MATCHED_VAR} found within %{MATCHED_VAR_NAME}',\
tag:'application-multi',\
tag:'language-java',\
tag:'platform-multi',\
tag:'attack-rce',\
tag:'OWASP_CRS',\
tag:'capec/1000/152/137/6',\
tag:'PCI/6.5.2',\
tag:'paranoia-level/1',\
ver:'OWASP_CRS/3.4.0-dev',\
severity:'CRITICAL',\
setvar:'tx.rce_score=+%{tx.critical_anomaly_score}',\
setvar:'tx.anomaly_score_pl1=+%{tx.critical_anomaly_score}'"
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 98.32.230.38" "id:'101',phase:1,t:none,deny,log,msg:'IP deny Rule'"
SecRule REMOTE_ADDR "@ipMatch 67.149.61.16" "id:'102',phase:1,t:none,deny,log,msg:'IP deny Rule'"
SecRule REMOTE_ADDR "@ipMatch 66.115.182.111" "id:'103',phase:1,t:none,deny,log,msg:'IP deny Rule'"
SecRule REMOTE_ADDR "@ipMatch 66.115.182.102" "id:'104',phase:1,t:none,deny,log,msg:'IP deny Rule'"
SecRule REMOTE_ADDR "@ipMatch 64.64.228.239" "id:'105',phase:1,t:none,deny,log,msg:'IP deny Rule'"
SecRule REMOTE_ADDR "@ipMatch 59.163.248.170" "id:'106',phase:1,t:none,deny,log,msg:'IP deny Rule'"
SecRule REMOTE_ADDR "@ipMatch 45.43.19.91" "id:'107',phase:1,t:none,deny,log,msg:'IP deny Rule'"
SecRule REMOTE_ADDR "@ipMatch 221.178.126.244" "id:'108',phase:1,t:none,deny,log,msg:'IP deny Rule'"
SecRule REMOTE_ADDR "@ipMatch 198.147.22.148" "id:'109',phase:1,t:none,deny,log,msg:'IP deny Rule'"
SecRule REMOTE_ADDR "@ipMatch 156.146.56.136" "id:'110',phase:1,t:none,deny,log,msg:'IP deny Rule'"
SecRule REMOTE_ADDR "@ipMatch 156.146.34.9" "id:'111',phase:1,t:none,deny,log,msg:'IP deny Rule'"
SecRule REMOTE_ADDR "@ipMatch 156.146.34.52" "id:'112',phase:1,t:none,deny,log,msg:'IP deny Rule'"
SecRule REMOTE_ADDR "@ipMatch 156.146.34.46" "id:'113',phase:1,t:none,deny,log,msg:'IP deny Rule'"
SecRule REMOTE_ADDR "@ipMatch 154.16.105.147" "id:'114',phase:1,t:none,deny,log,msg:'IP deny Rule'"
SecRule REMOTE_ADDR "@ipMatch 154.146.34.145" "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:
- Save the text in the above text blocks to two separate files on the system you use to access the LoadMaster UI.
- Log into the Loadmaster UI and navigate to Web Application Firewall > Custom Rules to upload your rule set files onto LoadMaster.
- 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.
References
For more information on WAF and custom rules, see the following resources:
- The WAF Feature Description
- The Support WAF Knowledge Base webpage
- The Support WAF Custom Rules Community webpage
- The WAF Rule Writing Guide
