Rule 941310: False positive

[Rolandwalraven]

Type of Issue

Incorrect blocking (false positive)

Description

This innocent german text triggered rule 941310
DE_Matten & Sitzbezüge > Fußmatten_MT

Audit Logs / Triggered Rule Numbers

Matched Data: \xbcge > found within ARGS:*********: de_matten & sitzbez\xc3\xbcge > fu\xc3\x9fmatten_mt

Your Environment

CRS version: 3.1.0
ModSec version: 2.9.2-1
Apache/2.4.29

Confirmation

[x] I have removed any personal data (email addresses, IP addresses,
passwords, domain names) from any logs posted.

[dune73]

Sorry for the inconvenience. However, I can't reproduce your finding, so I'm closing this for now. However, I suggest you reproduce this yourself with curl and reopen this issue together with the exact curl call.

Thanks for working against 3.2.0. Using the latest version helps us with our work.

[Rolandwalraven]

@dune73: I'm sorry we use CRS version 3.1.0. I was distracted by [ver "OWASP_CRS/3.2.0"] in the error log. Anyway i can trigger the rule with this curl request:

curl -X POST -d "test=DE_Matten%20%26%20Sitzbez%C3%BCge%20%3E%20Fu%C3%9Fmatten_MT" "https://DOMAIN.TLD/"

[dune73]

Negative.

Please provide your alert message.

[Rolandwalraven]

[Wed Dec 04 14:57:22.277027 2019] [:error] [pid 8562:tid 140488478672640] [client 11.22.33.44:55097] [client 11.22.33.44] ModSecurity: Warning. Pattern match "\\xbc[^\\\\xbe>][\\xbe>]|<[^\\\\xbe]\\xbe" at ARGS:test. [file "/etc/modsecurity/modsecurity.d/owasp-modsecurity-crs/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf"] [line "646"] [id "941310"] [msg "US-ASCII Malformed Encoding XSS Filter - Attack Detected."] [data "Matched Data: \xbcge > found within ARGS:test: de_matten & sitzbez\xc3\xbcge > fu\xc3\x9fmatten_mt"] [severity "CRITICAL"] [ver "OWASP_CRS/3.2.0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-tomcat"] [tag "attack-xss"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "OWASP_CRS/WEB_ATTACK/XSS"] [tag "WASCTC/WASC-8"] [tag "WASCTC/WASC-22"] [tag "OWASP_TOP_10/A3"] [tag "OWASP_AppSensor/IE1"] [tag "CAPEC-242"] [hostname "xxxxxx"] [uri "/"] [unique_id "Xee7QnjhHkR1Cr9VH@B4igAAAAE"]

[fgsch]

This is unrelated but which paranoia level are you using?
As this attack is pretty old I wonder if we should move this rule.

[Rolandwalraven]

Level 1 (default)

[dune73]

This is very odd. I can't reproduce.

@fgsch: Can you get this rule to trigger on said payload?

Otherwise, it may be worth to upgrade to Apache and ModSec to 2.4.41 / 2.9.3.

[fgsch]

I haven't tried but I recognise the rule and based on the matched data I see the issue.
Unfortunately this is a problem with some rules in combination with languages other than english.

[dune73]

Totally so. I would not be surprised to see an FP here. But I can't seem to reproduce despite the welcome curl call.

[theseion]

The problem is present on 3.3/dev. There was a change to that particular rule and that change introduced a couple of problems. We're looking into it.

[theseion]

This is the direct conversion of the old regex to the single byte version: (?:\xbc|\xbe).*(?:\xbc|\xbe|>)|(?:\xbc|\xbe|<).*(?:\xbc|\xbe). The character classes in the new regex don't work. I think we should start with the direct conversion and maybe use the optimizer to figure out what to do (@franbuehler thanks for the help).

[theseion]

I figured out how the evasion targeted by rule 941310 works. Look at the following UTF-8 string: ¼script¾alert(¢XSS¢)¼/script¾
If a web server transmits this payload with an encoding of US-ASCII the string will be interpreted as
B<script>Balert(B"XSS"B)B</script>B
This is because US-ASCII uses only 7 bits to encode a character.

The bit sequence for the UTF-8 character ¼ (hexadecimal: C2 BE) is
11000010 10111100
and when you strip the most significant bit from both bytes you get
1000010 0111100
which in US-ASCII are the two characters B and <. Let's do the same for the other two characters:

UTF-8: ¢ (C2 A2) -> 11000010 10100010
US-ASCII: 1000010 0100010 -> B "

UTF-8: ¾ (C2 BC) -> 11000010 10111110
US-ASCII: 1000010 01111101 -> B >

What I'm not sure about is what happens to the B character. As I see it, the resulting string would not be parseable as JS but I don't have a Tomcat server to actually look at the output (see https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet). Anyway, assuming that the B is stripped, all we need for the evasion to work is that the second byte of a two-byte UTF-8 matches the wanted character in US-ASCII. It's possible that the same technique would work with multi-byte characters as well, so, in general, we simply need a byte sequence where the last byte is the one we want.