5

I have set up Google Cloud Armor security policy referring to https://cloud.google.com/armor/docs/rules-language-reference. It worked fine. My simulated SQL injection attack from my office was detected and subsequent accesses were blocked. Stackdriver log entry shows corresponding enforcedSecurityPolicy outcome of "deny" and applied expression ID was "owasp-crs-v030001-id942421-sqli". The key WAF rule is as follows:

evaluatePreconfiguredExpr('xss-stable') && evaluatePreconfiguredExpr('sqli-stable')

One point I cannot control. After my simulated attack, all accesses from my office are blocked all the way along. Once I detached and re-attached the Cloud Armor security policy from and to LB, the access from my office are still blocked. Deleting that security policy and re-created it again does not help. This implies there is an unseen persistent database of SQLi & XSS attackers and my office IP might be registered in it, causing that 'all-the-time' denial.

Question is : how can I remove my IP from that unseen 'SQLi & XSS blacklist' database to regain backend access without modifying rules? In our Cloud Armor production operation, once-forbidden IP may want to regain access to the target backend service after its attack source is removed.

Certainly, if I add higher priority permission rule than the WAF rule, I can regain access to the target backend, but WAF check will be bypassed, which is not what I want.

Thank you in advance for your time.

R.Kurishima

R.Kurishima
  • 51
  • 2

1 Answers1

4

I had a similar situation and almost concluded the same thing you did -- that there's some kind of hidden blacklist. But after playing around some more, I figured out that, instead, some other non-malicious cookies in my request were triggering owasp-crs-v030001-id942421-sqli ("Restricted SQL Character Anomaly Detection (cookies): # of special characters exceeded (3)" -- and later owasp-crs-v030001-id942420-sqli ("Restricted SQL Character Anomaly Detection (cookies): # of special characters exceeded (8)"). Not a hidden blacklist.

Near as I can tell, these two rules use the number of 'special' characters in the Cookies header, and not the number of special characters in each cookie. Furthermore, the equals sign -- which is used for each cookie -- counts as a special character. Same with the semicolon. Irritating.

So this request will trigger 942420:

curl 'https://example.com/' -H 'cookie: a=a; b=b; c=c; d=d; e=e;'

And this will trigger 942421:

curl 'https://example.com/' -H 'cookie: a=a; b=b;'

So probably best to disable these two rules, something like

evaluatePreconfiguredExpr('sqli-canary', [
 'owasp-crs-v030001-id942420-sqli',
 'owasp-crs-v030001-id942421-sqli'
])
Matt Drees
  • 443
  • 3
  • 11
  • Matt, yes, I found later at that time cookies mattered also in addition to IP. Intentionally deleting some cookies get me pass through App Armor. Disabling the rules may work, but already I had switched to Apache+Modsecurity with only XSS and SQLi rules enabled. Adjusting with some rule-disabling and URL-exclusion, Now that WAF works fine. As is usual with commercial production system, there was a deadline for the WAF evaluation and introduction into production. Every measures were under review and Modsecurity got my work done. Thank you. – R.Kurishima Nov 26 '20 at 00:39