Using a URL Encoded Percent sign, followed by hex digits other than 20-7e produces a false positive

[edgreenberg]

When a form submission contains a percent sign followed by two hex digits may cause a false positive as follows:

A good example is a person who tried to set a password similar to 'Secret%0015'. So the submission was password=Secret%250015 (and password_confirmation=Secret%250015) Mod security reported:

Message: Warning. Found 1 byte(s) in ARGS:Password outside range: 1-255. [file "/etc/httpd/owasp-modsecurity-crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "574"] [id "920270"] [rev "2"] [msg "Invalid character in request (null character)"] [severity "CRITICAL"] [ver "OWASP_CRS/3.0.0"] [maturity "9"] [accuracy "9"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS/PROTOCOL_VIOLATION/EVASION"]

Discussion on the mailing list decided that the %25 was being decoded as % (properly) and then the rule evaluated the % followed by the 00 as a null.

On 06/09/2017 04:15 PM, Chaim Sanders wrote:

Yes as Manuel pointed out %00 is a null char and is forbidden. tl;dr it is used to indicate the end of a string in C and as a result languages built on C (like php) when provided with it may treat that as the end of a string even when more is provided.

In any event this is actually kinda interesting, the problem is a disagreement about how webservers versus modsec will handle the code. Depending on which webserver provides the varabiles and where, it is already url decoded. For instance Apache. So in this case Apache decoded the variable and turned %25 back into a percent sign before modsec got it. Then CRS's rule 920270 applied t:urlDecodeUni decoded it again. this led to it detected a null byte.

TO BE CLEAR PASSING AN ACTUAL NULLBYTE WILL TRIGGER THIS RULE, IT"S THE %25 THAT IS A POSSIBLE PROBLEM.

Now there is some logic here. Early microsoft IIS would do what's known as double decode, but we have other rules to detect that, so there is probably a good reason to open up a ticket and have a discussion about removing that transformation. The problem is going to be that we have to make sure that IIS/Nginx/Apache all behave in the same way, but that isn't your problem that is ours.

Reproduce this by submitting a form containing a field with xxx%00xxx

[csanders-git]

Thanks, I think this should be a good candidate for 3.0.3 if we find all out web servers treat params passed into modsec as unencoded - a dangerous thing to do for others who may not be using one of the three supported web servers... any ideas @dune73 if that is true?? Doesn't seem like shifting to phase:1 fixes the problem

[marcstern]

I don't think it's the point. All servers will decode the url-encoded parameters - that's their job (from the RFC). The point is "will the (a) back-end potentially decode the parameters at the application level, leading thus to a seconf decoding.
If we only speak about IIS 4 & 5 (and even unpatched versions), it would be a pity to introduce false positive to protect only these very old (should I say obsolete) apps.
However, a lot of applications url-encode some URLs (think about redirect URL after login). This is the dangerous case. If it's only a redirect, the victim may be user (ex: a <script> tag) but, if this is used internally, it could lead to any kind of attack.
Now, if double encoding can be blocked completely, there's no need to check for double encoded payload - but can you really afford that? Furthermore, how will you configure that in CRS? Especially if you have 2 apps and only one needing this...

[csanders-git]

@marcstern slightly different I think, yes there is the double decoding issue, but i'm not concerned about that (as there are other rules for that). The question is when ModSecurity is given access to the data, (phase 1,2,3,4,5) can we assume that we NEVER get a urlencoded parameter? If this is the case then the use of urldecode should be sparse (limited to double decoding). Can we confirm that all webservers provide decoded values in all phases? @zimmerle

[dune73]

This is very tricky.

The minimal payloads that allow me to trigger 920270 are:

password=%00
password=%2500 <--- double encoded

I also get the feeling that we can not really make the null-character illegal in the default install. Too many issues on various fronts.

[fgsch]

This issue has timed out as it has not received any update in over 2 years.
If this is still a problem please open a new issue.