8000 False Positive 932100 (Unix command injection) for OData-queries · Issue #2123 · coreruleset/coreruleset · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
8000

False Positive 932100 (Unix command injection) for OData-queries #2123

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
edwinvandeburgt opened this issue Jun 9, 2021 · 13 comments
Closed

False Positive 932100 (Unix command injection) for OData-queries #2123

edwinvandeburgt opened this issue Jun 9, 2021 · 13 comments
Labels
➕ False Positive

Comments

@edwinvandeburgt
Copy link

Rule 932100 is triggered for OData queries that contain an $expand keyword.

URL-fragment (table and column names replaced):

.../table?$select=a,b,c,&$expand=c($select=d,e,f;$expand=g($select=h),i($select=j)),k($select=l,m)&$filter=n/o%20eq%20'10091595'%20and%20p/q%20eq%200%20and%20r/s%20eq%200%20and%20t%20eq%200

Both the "&$expand" and ";$expand" are matched by the 932100 regex.
@fzipi
Copy link
Member
fzipi commented Jun 9, 2021

@edwinvandeburgt Thanks for the report, we are going to review it soon!

@fzipi
Copy link
Member
fzipi commented Jun 9, 2021

For the sake of documentation for other devs, OData comes from https://www.odata.org/

Sorry, something went wrong.

@fzipi
Copy link
Member
fzipi commented Jun 9, 2021

@edwinvandeburgt Can you add CRS version and other relevant information here (web server, modsec version, etc.)?

@dune73
Copy link
Member
dune73 commented Jun 9, 2021

This is a query submitted as a query string. Correct?

If yes, is this really a false positive or rather a architecture weakness that was used for benign purposes in this particular situation?

@fzipi
Copy link
Member
fzipi commented Jun 9, 2021

Well, it is probably a false positive. We include the expand unix command in our list, and that is being catched.

@dune73
Copy link
Member
dune73 commented Jun 9, 2021 •
edited
8000 Loading

Yes, sure. The rule is not aimed at odata. But - with a bit of distance - if some kind of software would send SQL queries in query strings, we would consider it a legitimate alert, would not we?

That does not rule out the option to create a odata rule exclusion package - volunteers welcome - yet I think it would be wrong to tune down the unix command rules because it odata happens to use some of the keywords in its query language. Even more so as evasion is a huge problem with the unix commands where the bash shell will execute just about anything thrown at it.

Or am I overly strict in this regard?

@edwinvandeburgt
Copy link
Author

Here are some more details. We are running a WAF op Microsoft Azure Application Gateway:

ruleSetType_s | OWASP_CRS
ruleSetVersion_s | 3.1.0
ruleId_s | 932100
action_s | Matched
details_message_s | Warning. Pattern match [...] at ARGS:$expand ....
details_data_s | Matched Data: ;$expand found within ARGS:$expand: [...]
details_file_s | rules/REQUEST-932-APPLICATION-ATTACK-RCE.conf
details_line_s | 121

@dune73 , @fzipi I can follow both your reasoning and while it might be a good check, I read on the OWASP FAQ that with PL1 you should face False Positives rarely. For any more advanced OData query, this is going to fail a lot, not rarely. So maybe this particular check should/could/might be moved to a (new) PL2+ rule.

Also, I posted another message ago about some other PL1 rule that fails... That one was about a FetchXML query string... While I understand the reasoning for SQL-injection attack mitigation, as the world is moving to other means of performing queries like OData, it would be nice if the CRS could differentiate a bit better between OData, FetchXML, SQL etc. and check rules appropriately :-)

I'm not volunteering :-), because this particular 932100 rule has such a complex RegEx, I can't make anything of it ;-)

Btw, I do run the RegExes (from the CRS source) against the query string to check while it fails, although the logging is also pretty clear about it...

For any more questions, let me know ;-)

@fzipi
Copy link
Member
fzipi commented Jun 9, 2021

Amazing, that's a lot of information that helps us identifying the problems.

The good thing is that the regexp is generated based on this source file. So that you can check. The problem is clear there.

@edwinvandeburgt
Copy link
Author

@fzipi, @dune73 I have only very limited experience with unix, but what if it still triggers on "expand" but not on "$expand" ?

@fzipi
Copy link
Member
fzipi commented Jun 10, 2021

You can read the comments on the rule itself.

# This rule detects Unix command injections.
# A command injection takes a form such as:
#
#   foo.jpg;uname -a
#   foo.jpg||uname -a
#
# The vulnerability exists when an application executes a shell command
# without proper input escaping/validation.
#
# This rule is also triggered by an Oracle WebLogic Remote Command Execution exploit:
# [ Oracle WebLogic vulnerability CVE-2017-10271 - Exploit tested: https://www.exploit-db.com/exploits/43458 ]
#
# To prevent false positives, we look for a 'starting sequence' that
# precedes a command in shell syntax, such as: ; | & $( ` <( >(
# Anatomy of the regexp with examples of patterns caught:
#
# 1. Starting tokens
#
# ;        ;ifconfig
# \{       {ifconfig}
# \|       |ifconfig
# \|\|     ||ifconfig
# &        &ifconfig
# &&       &&ifconfig
# \n       ;\nifconfig
# \r       ;\rifconfig
# \$\(     $(ifconfig)
# $\(\(    $((ifconfig))
# `        `ifconfig`
# \${      ${ifconfig}
# <\(      <( ifconfig )
# >\(      >( ifconfig )
# \(\s*\)  a() ( ifconfig; ); a
#
# 2. Command prefixes
#
# {        { ifconfig }
# \s*\(\s* ( ifconfig )
# \w+=(?:[^\s]*|\$.*|\$.*|<.*|>.*|\'.*\'|\".*\")\s+   VARNAME=xyz ifconfig
# !\s*     ! ifconfig
# \$       $ifconfig
#
# 3. Quoting
#
# '        'ifconfig'
# \"       "ifconfig"
#
# 4. Paths
#
# [\?\*\[\]\(\)\-\|+\w'\"\./\\\\]+/   /sbin/ifconfig, /s?in/./ifconfig, /s[a-b]in/ifconfig etc.
#
# This rule is case-sensitive to prevent FP ("Cat" vs. "cat").
#
# An effort was made to combat evasions by shell quoting (e.g. 'ls',
# 'l'"s", \l\s are all valid). ModSecurity has a t:cmdLine
# transformation built-in to deal with this, but unfortunately, it
# replaces ';' characters and lowercases the payload, which is less
# useful for this case. However, emulating the transformation makes
# the regexp more complex.
#
# To rebuild the word list regexp:
#   cd util/regexp-assemble
#   cat regexp-932100.txt | ./regexp-cmdline.py unix | ./regexp-assemble.pl

@edwinvandeburgt
Copy link
Author

I see :-) I should have read the sources. Nicely documented by the way!

@dune73
Copy link
Member
dune73 commented Jun 11, 2021

Thank you. Much appreciated.

This was referenced Jun 11, 2021
Open
Closed
@fzipi
Copy link
Member
fzipi commented Jun 11, 2021

Thanks all for your comments.

The action that will be taken from this one is then:

Closing this one.

@fzipi fzipi closed this as completed Jun 11, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
➕ False Positive
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@dune73 @fzipi @edwinvandeburgt
0