Wir leben in einer Welt, in der die Guten ständig auf die Bedrohungen durch die Bösen reagieren müssen. In einer perfekten Welt sind eine Web Application Firewall (WAF) und die darin enthaltenen Regelsätze den Bösewichten immer einen Schritt voraus. Und selbst wenn dies nicht der Fall ist, werden die notwendigen Korrekturen schnell veröffentlicht, so dass die Systeme innerhalb weniger Tage nach der Bekanntgabe eines Exploits mit neuer Software aktualisiert werden können, die das Problem behebt.
Das Problem ist, dass nicht jedes System so zeitnah mit neuer Software aktualisiert werden kann, die die Schwachstelle schließt. Es müssen Wartungszeiten geplant, Mitarbeiter eingestellt und die Updates getestet werden. Wäre es nicht schön, wenn es möglich wäre, Systeme zu sperren, sobald eine Sicherheitslücke bekannt wird, indem man einer bestehenden WAF-Engine in der Anwendungslieferkette exploit-spezifische Regeln hinzufügt?
Wenn Sie einen LoadMaster ADC in Ihrer Datenkette haben und dessen WAF-Funktion aktiviert ist, haben Sie diese Möglichkeit. Das Auftreten der in CVE-2022-26134 beschriebenen Schwachstelle im vergangenen Juni ist ein typisches Beispiel.
Bis ein Software-Patch zur Verfügung gestellt und betroffene Systeme aktualisiert werden konnten, war der beste Rat, alle internetbasierten Zugriffe auf eine solche Confluence-Bereitstellung zu deaktivieren. Dies galt sogar für Kunden, die derzeit WAF-Regelsätze verwenden, sowohl kostenlos als auch von kommerziellen Anbietern. Bestehende Regeln, die sich auf diese Art von Exploits konzentrieren, würden vor diesen Exploits warnen, anstatt sie zu blockieren.
LoadMaster-Kunden, die WAF ausführen, hatten eine andere Option. Unser preisgekröntes Support-Team hat zwei WAF-Regeldateien erstellt, die als benutzerdefinierte Regeln zu LoadMaster hinzugefügt werden können, um Confluence-Bereitstellungen sofort vor diesem Exploit zu schützen, bis die Systeme gepatcht werden können. Dies führt zu weniger Ausfallzeiten (und weniger Angst) für LoadMaster-Kunden.
Die erste Datei enthält eine einzelne Regel, die den Exploit speziell blockiert, indem sie nach bestimmten Sonderzeichen im Dateinamen, in den Cookies und in den Headern der Anforderung übereinstimmt.
# 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}'"
Die zweite Datei enthält über ein Dutzend Regeln, die speziell alle Anfragen aus der neuesten Liste bekannter bösartiger IP-Adressen blockieren, die zum Zeitpunkt der Ankündigung dieses Exploits (Juni 2022) identifiziert wurden. Diese werden als "Command-and-Control"-Server betrachtet, von denen bekannt ist, dass Exploits wie der in dieser CVE beschriebene stammen.
Obwohl diese Taktik nicht direkt mit der Confluence-Schwachstelle zusammenhängt, ist es wichtig zu wissen, dass Sie auch benutzerdefinierte Regeln wie die folgenden hinzufügen können, wenn Sie IP-Adressen in Ihrem eingehenden Anfragestrom sehen, die Sie aus irgendeinem Grund blockieren möchten.
# ---------------------------------------------------------------
# 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'"So fügen Sie die oben genannten Regeln zu LoadMaster WAF hinzu:
Sobald diese benutzerdefinierten Regeln in einem VS ausgewählt wurden, werden sie immer bei eingehenden Anforderungen an den VS ausgeführt, bevor der in LoadMaster enthaltene OWASP-Regelsatz enthalten ist.
Weitere Informationen zu WAF und benutzerdefinierten Regeln finden Sie in den folgenden Ressourcen: